From owner-mpls@UU.NET Tue May 1 02:36:25 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20934 for ; Tue, 1 May 2001 02:36:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkncc23247; Tue, 1 May 2001 06:36:17 GMT Received: by mail-control.mail.uu.net id QQkncc09474 for mpls-outgoing; Tue, 1 May 2001 06:35:47 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkncc09467 for ; Tue, 1 May 2001 06:35:42 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkncc20475 for ; Tue, 1 May 2001 06:34:53 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkncc17145 for ; Tue, 1 May 2001 06:34:53 GMT Received: from anil (devdhcp6292.dev.acc.am.ericsson.se [129.192.62.92]) by acc.com (8.11.1/8.11.1) with SMTP id f416Wn513215 for ; Mon, 30 Apr 2001 23:32:49 -0700 (PDT) Reply-To: From: "Anil Gunturu" To: Subject: FEC: Address Prefix and Host Address Date: Mon, 30 Apr 2001 23:33:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit RFC 3036 defines the following types of FECs " 1. Address Prefix. This element is an address prefix of any length from 0 to a full address, inclusive. 2. Host Address. This element is a full host address. " Isn't host address a special case of Address Prefix where the length is full address length (IPV4 = 32)? Especially, because the RFC indicates that length is from 0 to a full address. Thanks, -Anil From owner-mpls@UU.NET Tue May 1 04:14:06 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21603 for ; Tue, 1 May 2001 04:14:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknci19700; Tue, 1 May 2001 08:13:54 GMT Received: by mail-control.mail.uu.net id QQknci27620 for mpls-outgoing; Tue, 1 May 2001 08:13:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknci27596 for ; Tue, 1 May 2001 08:13:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknci14596 for ; Tue, 1 May 2001 08:11:06 GMT Received: from eth.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.eth.net [202.9.145.18]) id QQknci17020 for ; Tue, 1 May 2001 08:11:04 GMT Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 12:55:54 +0530 Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 12:30:01 +0530 Received: from mail pickup service by eth.net with Microsoft SMTPSVC; Tue, 1 May 2001 12:05:08 +0530 Received: from host.secure4-hosting.net ([209.239.41.31]) by eth.net with Microsoft SMTPSVC(5.5.1877.537.53); Tue, 1 May 2001 10:09:17 +0530 Received: (from mplsrc12@localhost) by host.secure4-hosting.net (8.10.2/8.10.2) id f414lvT01566 for murukku@eth.net; Tue, 1 May 2001 00:47:57 -0400 X-Authentication-Warning: host.secure4-hosting.net: mplsrc12 set sender to mpls-ops-request@mplsrc.com using -f Message-ID: <007b01c0d204$fde2df60$5b5da4d0@KENT> Reply-To: "Kent Yu" From: "Kent Yu" To: "Bhupesh Bajaj" , Cc: , References: <200104301046.QAA02582@localhost.localdomain> Subject: Re: RE: doubt in RFC 3031 Date: Mon, 30 Apr 2001 23:07:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: archive/latest/1098 X-Loop: mpls-ops@mplsrc.com Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit bhupesh, Seems to me the phrase here emphasizes the PHP does not require either the egress or the penultimate router do more than one lookup. The authors, IMHO, believe it is necessary to clarify the PHP does not transfer the two lookups from the edge to either the penultimate hop or any other LSRs along the LSP. HTH Kent Yu ----- Original Message ----- From: "Bhupesh Bajaj" To: Cc: ; Sent: Monday, April 30, 2001 3:52 AM Subject: Re: RE: doubt in RFC 3031 > hello, > > as far as i believe the penultimate hop is going to behave in same way as far as number of lookups is concerned )in both cases with / without using this technique.."penultimate hop popping".. > > so i believe it needn't be mentioned in RFC that with PNP one gets the benifit of just one lookup from penultimate hop side also as they have mentioned in RFC > > waiting for comments, > > > thanks and regards, > bhupesh > > Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml ------- The MPLS-OPS Mailing List Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml Archive: http://www.mplsrc.com/mpls-ops_archive.shtml From owner-mpls@UU.NET Tue May 1 09:51:20 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27214 for ; Tue, 1 May 2001 09:51:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndf02367; Tue, 1 May 2001 13:51:08 GMT Received: by mail-control.mail.uu.net id QQkndf01205 for mpls-outgoing; Tue, 1 May 2001 13:50:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkndf01172 for ; Tue, 1 May 2001 13:50:17 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkndf22943 for ; Tue, 1 May 2001 13:49:45 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkndf29412 for ; Tue, 1 May 2001 13:49:41 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f41Doic11250; Tue, 1 May 2001 19:20:45 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A3F.004AA050 ; Tue, 1 May 2001 19:05:07 +0530 X-Lotus-FromDomain: HSS To: anilg@acc.am.ericsson.se cc: mpls@UU.NET Message-ID: <65256A3F.004A9EB3.00@sandesh.hss.hns.com> Date: Tue, 1 May 2001 19:19:13 +0530 Subject: Re: FEC: Address Prefix and Host Address Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Anil, Let the network topology is like this mpls domain Router A--------------------------Router B---------host C Let there comes a unlabeled packet at the ingress router A for the destination host C. Lets assume 1. there is a routing table entry in the router A for the host C, specifying the next hop as router B. 2. there is no LSP for the host C in the router A. 3. there is a LSP between router A and router B. Now two cases arises 1. The LSP between router A and router B is using address prefix which is a full address of router B. Then router A will forward the datagram on the LSP between A and B, as is written in RFC 3036 "If it is known that a packet must traverse a particular egress router, and there is an LSP which has an Address Prefix FEC element which is an address of that router, then the packet is mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document." 2. The LSP between router A and router B is using host address to identify router B. Then router A may not send the datagram on the LSP between A and B, as is written in RFC 3036. "A packet which does not match a particular Host Address FEC element may not be sent on the corresponding LSP, even if the Host Address FEC element identifies the packet's egress router." pls correct me if i am wrong. Regards Mohit Goel "Anil Gunturu" on 05/01/2001 12:03:06 PM Please respond to anilg@acc.am.ericsson.se To: mpls@UU.NET cc: (bcc: Mohit Goel/HSS) Subject: FEC: Address Prefix and Host Address RFC 3036 defines the following types of FECs " 1. Address Prefix. This element is an address prefix of any length from 0 to a full address, inclusive. 2. Host Address. This element is a full host address. " Isn't host address a special case of Address Prefix where the length is full address length (IPV4 = 32)? Especially, because the RFC indicates that length is from 0 to a full address. Thanks, -Anil From owner-mpls@UU.NET Tue May 1 10:41:52 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29055 for ; Tue, 1 May 2001 10:41:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndi21087; Tue, 1 May 2001 14:41:37 GMT Received: by mail-control.mail.uu.net id QQkndi25002 for mpls-outgoing; Tue, 1 May 2001 14:41:06 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkndi24966 for ; Tue, 1 May 2001 14:40:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkndi23104 for ; Tue, 1 May 2001 14:40:34 GMT Received: from web14306.mail.yahoo.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14306.mail.yahoo.com [216.136.173.82]) id QQkndi21374 for ; Tue, 1 May 2001 14:40:34 GMT Message-ID: <20010501144033.95183.qmail@web14306.mail.yahoo.com> Received: from [143.209.238.102] by web14306.mail.yahoo.com; Tue, 01 May 2001 07:40:33 PDT Date: Tue, 1 May 2001 07:40:33 -0700 (PDT) From: Srinivas T M Subject: Label Space To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Here is a basic doubt. Why per-interface label space only used in case of ATM/FR? Can we use platform label space in case of ATM/FR ? Can we configure label space (per-interface or Platform label space) per LSR wise? If LSR has both ATM and Ethernet ports, then how do use label space if label space is configured? Thanks in Advance, Srini __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Tue May 1 13:09:20 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04234 for ; Tue, 1 May 2001 13:09:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknds21548; Tue, 1 May 2001 17:07:27 GMT Received: by mail-control.mail.uu.net id QQknds28755 for mpls-outgoing; Tue, 1 May 2001 17:06:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknds28376 for ; Tue, 1 May 2001 17:06:32 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknds29310 for ; Tue, 1 May 2001 17:04:42 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknds03924 for ; Tue, 1 May 2001 17:04:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA21200 for mpls@uu.net; Tue, 1 May 2001 13:04:42 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknds19301 for ; Tue, 1 May 2001 17:00:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkndr15330 for ; Tue, 1 May 2001 16:57:53 GMT Received: from nero.doit.wisc.edu by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nero.doit.wisc.edu [128.104.17.130]) id QQkndr24091 for ; Tue, 1 May 2001 16:57:53 GMT Received: (from jleu@localhost) by nero.doit.wisc.edu (8.8.7/8.8.7) id LAA06208; Tue, 1 May 2001 11:57:45 -0500 Date: Tue, 1 May 2001 11:57:44 -0500 From: "James R. Leu" To: David Charlap Cc: mpls@UU.NET Subject: Re: Label Space Message-ID: <20010501115744.B6029@doit.wisc.edu> Reply-To: jleu@mindspring.com References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <3AEED3C3.DEC50A9A@marconi.com>; from david.charlap@marconi.com on Tue, May 01, 2001 at 11:18:27AM -0400 Organization: none Sender: owner-mpls@UU.NET Precedence: bulk Hello David, > The choice of per-interface or per-platform doesn't have to be a global > setting. Some interfaces can have a private label space while all the > others share a platform label space. It is possible (for instance) to > put the Ethernet interfaces in the platform label space while giving > each ATM interface its own label space. I agree, but I have never understood how hierarchical tunnels (such as those used in RSVP bypass tunnels) would work over private label spaces. > I think it's also possible to have multiple separate label spaces that > contain more than one interface each. But I'm not sure of this. That would indeed handle the above question. (assign the interfaces that would be part of the bypass to the same label space, label allocation becomes much simpler). I too am not sure it is a valid use of label spaces. Any insight would be useful. Thanks. Jim -- James R. Leu From owner-mpls@UU.NET Tue May 1 13:25:30 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04718 for ; Tue, 1 May 2001 13:25:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndt19989; Tue, 1 May 2001 17:24:17 GMT Received: by mail-control.mail.uu.net id QQkndt08961 for mpls-outgoing; Tue, 1 May 2001 17:23:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkndt08953 for ; Tue, 1 May 2001 17:23:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkndt24675 for ; Tue, 1 May 2001 17:22:38 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkndt17376 for ; Tue, 1 May 2001 17:22:37 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04040 for ; Tue, 1 May 2001 13:22:35 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18115 for ; Tue, 1 May 2001 13:22:37 -0400 (EDT) Message-ID: <3AEEF103.A5A31094@marconi.com> Date: Tue, 01 May 2001 13:23:15 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> <20010501115744.B6029@doit.wisc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "James R. Leu" wrote: > >> The choice of per-interface or per-platform doesn't have to be a >> global setting. Some interfaces can have a private label space >> while all the others share a platform label space. It is possible >> (for instance) toput the Ethernet interfaces in the platform label >> space while giving each ATM interface its own label space. > > I agree, but I have never understood how hierarchical tunnels (such > as those used in RSVP bypass tunnels) would work over private label > spaces. Certain things (like LDP remote peers and bypass tunnels) become difficult with per-interface label spaces. The routers must be able to deal with the possibility that the next-hop for an already-established LSP may jump from one interface to another. When this happens, its label must also jump. If the label is already in use on the new interface, however, then one or the other must be preempted. There are some ways around this problem, but they will not all be possible, depending on hardware. For instance, if the switch has a very large label space, but can only allocate a (relatively) small number of labels from the space, then it can allocate labels on the interfaces where they are used, and prevent the other interfaces from using the same label values (without actually installing those labels on those interfaces.) This way, there won't be conflict if a label should happen to change interfaces. But some hardware may be unable to lock-off a label value without actually consuming the resources associated with that label. Meaning some other scheme might be necessary. The problem is difficult, and I suspect there will be no single solution that will work well on all hardware platforms. But I think there are solutions. >> I think it's also possible to have multiple separate label spaces >> that contain more than one interface each. But I'm not sure of >> this. > > That would indeed handle the above question. (assign the interfaces > that would be part of the bypass to the same label space, label > allocation becomes much simpler). I too am not sure it is a valid > use of label spaces. The only problem with this is that a switch that only has per-interface support in the hardware will have the same problems using this scheme as it will with per-platform label spaces. I mention this only because some hardware designs may make this a good idea. For instance, if several ports are all wired to the same forwarding chip, it might make sense for them to share a single label space, even if they can't share that space with ports attached to other forwarding chips. -- David From owner-mpls@UU.NET Tue May 1 13:31:29 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05025 for ; Tue, 1 May 2001 13:31:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndt01173; Tue, 1 May 2001 17:29:28 GMT Received: by mail-control.mail.uu.net id QQkndt09449 for mpls-outgoing; Tue, 1 May 2001 17:28:53 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkndt09432 for ; Tue, 1 May 2001 17:28:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkndt10746 for ; Tue, 1 May 2001 17:25:46 GMT Received: from web14302.mail.yahoo.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14302.mail.yahoo.com [216.136.173.78]) id QQkndt25230 for ; Tue, 1 May 2001 17:25:45 GMT Message-ID: <20010501172517.23097.qmail@web14302.mail.yahoo.com> Received: from [143.209.238.102] by web14302.mail.yahoo.com; Tue, 01 May 2001 10:25:17 PDT Date: Tue, 1 May 2001 10:25:17 -0700 (PDT) From: Srinivas T M Subject: Re: Label Space To: David Charlap , mpls@UU.NET In-Reply-To: <3AEED3C3.DEC50A9A@marconi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Thanks for reply. In case of LSP's established through targeted session will use only platform Label space. That means, If we want to establish LSP through targeted session, we must configure the platform label space in LSR even all interfaces in LSR uses per-interface label space. Is it right? Thanks, Srini > > Can we use platform label space in case of > ATM/FR ? > > There's no reason why not, other than the fact that > existing ATM > switches don't have native hardware support for > per-platform VC spaces. > > > Can we configure label space (per-interface or > > Platform label space) per LSR wise? > > Yes. > > > If LSR has both ATM and Ethernet ports, then how > do > > use label space if label space is configured? > > The choice of per-interface or per-platform doesn't > have to be a global > setting. Some interfaces can have a private label > space while all the > others share a platform label space. It is possible > (for instance) to > put the Ethernet interfaces in the platform label > space while giving > each ATM interface its own label space. > > I think it's also possible to have multiple separate > label spaces that > contain more than one interface each. But I'm not > sure of this. > > -- David __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Tue May 1 13:38:56 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05191 for ; Tue, 1 May 2001 13:38:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndu08132; Tue, 1 May 2001 17:37:00 GMT Received: by mail-control.mail.uu.net id QQkndu10096 for mpls-outgoing; Tue, 1 May 2001 17:36:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkndu10085 for ; Tue, 1 May 2001 17:36:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkndu22154 for ; Tue, 1 May 2001 17:35:25 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkndu08959 for ; Tue, 1 May 2001 17:35:25 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05326 for ; Tue, 1 May 2001 13:35:23 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20636 for ; Tue, 1 May 2001 13:35:25 -0400 (EDT) Message-ID: <3AEEF403.B76B86F9@marconi.com> Date: Tue, 01 May 2001 13:36:03 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Label Space References: <20010501172517.23097.qmail@web14302.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Srinivas T M wrote: > > In case of LSP's established through targeted session > will use only platform Label space. That means, If we > want to establish LSP through targeted session, we > must configure the platform label space in LSR even > all interfaces in LSR uses per-interface label space. See my other message. I think LDP remote peers can be implemented with per-interface label spaces, but it creates problems that may not be easy to solve on your hardware. -- David From owner-mpls@UU.NET Tue May 1 15:04:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07762 for ; Tue, 1 May 2001 15:04:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkndl23539; Tue, 1 May 2001 15:20:53 GMT Received: by mail-control.mail.uu.net id QQkndl18260 for mpls-outgoing; Tue, 1 May 2001 15:20:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkndl18032 for ; Tue, 1 May 2001 15:18:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkndl15764 for ; Tue, 1 May 2001 15:17:51 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkndl04441 for ; Tue, 1 May 2001 15:17:50 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA23102 for ; Tue, 1 May 2001 11:17:48 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21938 for ; Tue, 1 May 2001 11:17:50 -0400 (EDT) Message-ID: <3AEED3C3.DEC50A9A@marconi.com> Date: Tue, 01 May 2001 11:18:27 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Srinivas T M wrote: > > Here is a basic doubt. > Why per-interface label space only used in case of ATM/FR? ATM cell switching assigns VCIDs on a per-interface basis. As such, most (if not all) existing ATM hardware is designed around per-interface and not per-platform. This could be worked around by duplicating the per-interface labels across all interfaces. But now every logical label allocation is consuming n (where "n" is the number of interfaces) label allocations in the hardware - this can quickly exhaust the label space if used in a large network. > Can we use platform label space in case of ATM/FR ? There's no reason why not, other than the fact that existing ATM switches don't have native hardware support for per-platform VC spaces. > Can we configure label space (per-interface or > Platform label space) per LSR wise? Yes. > If LSR has both ATM and Ethernet ports, then how do > use label space if label space is configured? The choice of per-interface or per-platform doesn't have to be a global setting. Some interfaces can have a private label space while all the others share a platform label space. It is possible (for instance) to put the Ethernet interfaces in the platform label space while giving each ATM interface its own label space. I think it's also possible to have multiple separate label spaces that contain more than one interface each. But I'm not sure of this. -- David From owner-mpls@UU.NET Tue May 1 17:21:28 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10542 for ; Tue, 1 May 2001 17:21:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknej12353; Tue, 1 May 2001 21:19:40 GMT Received: by mail-control.mail.uu.net id QQknej19654 for mpls-outgoing; Tue, 1 May 2001 21:19:06 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknej19634 for ; Tue, 1 May 2001 21:18:46 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknei03547 for ; Tue, 1 May 2001 21:02:17 GMT Received: from sandmail.sandburst.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQknei04311 for ; Tue, 1 May 2001 21:02:17 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id D027994009; Tue, 1 May 2001 17:02:12 -0400 (EDT) Message-ID: <3AEF2454.76A0A702@sandburst.com> Date: Tue, 01 May 2001 17:02:12 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap Cc: mpls@UU.NET Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> <20010501115744.B6029@doit.wisc.edu> <3AEEF103.A5A31094@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Please see in-line comments, below. You wrote: > "James R. Leu" wrote: > > > >> The choice of per-interface or per-platform doesn't have to be a > >> global setting. Some interfaces can have a private label space > >> while all the others share a platform label space. It is possible > >> (for instance) toput the Ethernet interfaces in the platform label > >> space while giving each ATM interface its own label space. > > > > I agree, but I have never understood how hierarchical tunnels (such > > as those used in RSVP bypass tunnels) would work over private label > > spaces. > > Certain things (like LDP remote peers and bypass tunnels) become > difficult with per-interface label spaces. The routers must be able to > deal with the possibility that the next-hop for an already-established > LSP may jump from one interface to another. When this happens, its > label must also jump. If the label is already in use on the new > interface, however, then one or the other must be preempted. Could be that the terminology we're using is ambiguous, but I'm not sure I agree with the above. One way that an LSR might deal with the possibility of a next hop change for an LSP is to use liberal label retention. This will work even if the per-interface label space is in use between two LSRs with multiple interfaces in common and the only thing about the next hop that changes is the interface to use for a specific LSP. There is no requirement to avoid overlapping label usage, in this case. For LDP remote peers, labels are stacked and labels exchanged by remote peers are only visible when all labels above them in the stack have been popped. In this case, the term 'interface' takes on an interesting meaning. One approach (I think the one you're assuming and - possibly - the common interpretation), is to treat all LSPs between two remote LSRs as if they are all part of the same 'interface' - in which case the distinction between label spaces (per-interface, and per-platform) is moot. This approach is the simplest, and - since the labels used are below the top level label in forwarding packets - there is unlikely to be a hardware reason why this cannot be supported. If labels are stacked, then assignment of labels are orthogonal at each stack level from the sender's point of view. If there is some reason why assignments at differing stack levels are not orthogonal (possibly because of private label semantics) from the receivers point of view, there would only be a problem if the receiver somehow assigned an innappropriate label for some label stacking context. An LSR has to deal with its own faults. This approach is not very clean and has the potential to introduce problems if the remote peers are trying to do different things. For example, if the peers are remote LDP peers, one may be sending hello messages on each LSP it intends to use (as a group resource, for instance) with the same LSR ID (including the per-platform label space) and a different set of hello messages on other LSPs to the same remote peer LSR (using a different LSR ID). Possibly the intent is to use different LDP sessions to control labels established for different purposes. This LSR would naturally tend to expect labels it has advertised only on LSPs over which it is also receiving hello messages from the remote peer (also using the per-platform label space - since, otherwise, multiple LDP session would exist). Suppose, however, that the other LSR is JPLIG and is only sending hello messages over a single LSP since it was built with the assumption that it could use any label it acquires from the remote peer on any LSP to that remote peer irrespective of whether or not it is keeping up a session over that LSP. Oila` - there is a problem. I believe that label distribution paradigms (e.g. - MPLS BGP) that rely on use of the per-platform label space, explicitly state this as a requirement. Perhaps I'm wrong, however, and they simply count on the implementer to do the right thing. :-) > > > There are some ways around this problem, but they will not all be > possible, depending on hardware. A working LSR does not advertise the per-platform label space over an interface on which it will not work. A working peer does not attempt to use per-platform labels on an interface over which it is not currently maintaining a session with a per-platform peer. As discussed (in some detail) above, this changes when label stacking is in use - but then so does the hardware dependency. > > > For instance, if the switch has a very large label space, but can only > allocate a (relatively) small number of labels from the space, then it > can allocate labels on the interfaces where they are used, and prevent > the other interfaces from using the same label values (without actually > installing those labels on those interfaces.) This way, there won't be > conflict if a label should happen to change interfaces. > > But some hardware may be unable to lock-off a label value without > actually consuming the resources associated with that label. Meaning > some other scheme might be necessary. > > The problem is difficult, and I suspect there will be no single solution > that will work well on all hardware platforms. But I think there are > solutions. > > >> I think it's also possible to have multiple separate label spaces > >> that contain more than one interface each. But I'm not sure of > >> this. > > > > That would indeed handle the above question. (assign the interfaces > > that would be part of the bypass to the same label space, label > > allocation becomes much simpler). I too am not sure it is a valid > > use of label spaces. > > The only problem with this is that a switch that only has per-interface > support in the hardware will have the same problems using this scheme as > it will with per-platform label spaces. > > I mention this only because some hardware designs may make this a good > idea. For instance, if several ports are all wired to the same > forwarding chip, it might make sense for them to share a single label > space, even if they can't share that space with ports attached to other > forwarding chips. Which is an excellent example of why the per-platform label space must be applied within a context of LDP session management - at least whenever LDP is in use. In this case, the LSR that you point out could maintain this in two ways: by requiring that each interface is supported by its own per-interface LSR peer and each such peer advertises all of the same labels to all peers attached to any of these interfaces (which will get ugly if the same LSR is attached to more than one of these interfaces) or by maintaining a single LDP peer session with any LSRs attached to any of these interfaces (which allows it to advertise each label only once with respect to any peer) and using the per-platform label space. > > > -- David From owner-mpls@UU.NET Tue May 1 17:53:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11092 for ; Tue, 1 May 2001 17:53:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknel28783; Tue, 1 May 2001 21:50:58 GMT Received: by mail-control.mail.uu.net id QQknel23262 for mpls-outgoing; Tue, 1 May 2001 21:50:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknel23232 for ; Tue, 1 May 2001 21:50:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknej10828 for ; Tue, 1 May 2001 21:25:01 GMT Received: from gw.tropicnetworks.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: gw.tropicnetworks.com [209.87.233.9]) id QQknej20864 for ; Tue, 1 May 2001 21:25:01 GMT Received: from mail.tropicnetworks.com by gw.tropicnetworks.com via smtpd (for cmr0.ash.ops.us.uu.net [198.5.241.38]) with SMTP; 1 May 2001 21:25:00 UT Received: from cr437225a ([10.1.2.190]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA2DB9; Tue, 1 May 2001 17:24:55 -0400 From: "Sudhakar Ganti" To: "Dimitry Haskin" , Cc: "Nabil Seddigh" , "Biswajit Nandy" Subject: RE: MPLS Support of E-LSPs Date: Tue, 1 May 2001 17:23:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C0D263.75467180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C0D263.75467180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: MPLS Support of E-LSPsHi Dimitry, Thanks for your comments on the draft. In general, the proposed extensions are useful when resource management decisions are to be made on the signaled PSC. The intention of this draft is to facilitate resource allocation at a finer granularity than class-type would allow, i.e, at the granularity of a OA. As such we cannot replace PSC with CT. However, it is not difficult to extend the E-LSP to signal per-PSC or per-class-type resources. Instead of replacing the PSC field completely with CT, one can include CT and a couple of bits indicating whether CT or PSC. This would enable signaling of resources per PSC or per CT. Would this of interest to anyone? The current L-LSP signaling is fine and does not need a separate L-LSP object. -Sudhakar -----Original Message----- From: Dimitry Haskin [mailto:dhaskin@axiowave.com] Sent: Monday, April 30, 2001 3:51 PM To: 'Sudhakar Ganti'; mpls@UU.NET Cc: Nabil Seddigh; Biswajit Nandy Subject: RE: MPLS Support of E-LSPs Sudhakar, Thanks for the draft. The proposed extensions will provide a needed signaling support for the Diff-Serv's Uniform Tunneling model described in draft-ietf-mpls-diff-ext-09.txt. To make your proposal consistent with the Class-Type concept of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to replace the PSC field of the proposed Traffic Profile with a 4-bit Class-Type (CT) field. In addition if your allow the ELSP Object to carry resource requirements for L-LSP also (you'd need to rename the object) there would be no need for the CLASSTYPE Object defined in draft-ietf-mpls-diff-te-ext-01.txt. Dimitry -----Original Message----- From: Sudhakar Ganti [mailto:sganti@tropicnetworks.com] Sent: Monday, April 30, 2001 12:39 PM To: mpls@UU.NET Cc: Nabil Seddigh; Biswajit Nandy Subject: MPLS Support of E-LSPs Hello, The following draft is available in the IETF draft repository that extends E-LSP signaling: Title: MPLS Support of Differentiated Services using E-LSP Authors: S.Ganti, N.Seddigh, B.Nandy URL: http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-elsp-00.txt The current E-LSP approach allows multiple Ordered Aggregates (OAs) to be carried by a single LSP. The existing E-LSP specification only supports collective bandwidth signalling for all the OAs in an E-LSP. However, there exist uses of the E-LSP approach where it is desirable to support bandwidth signalling on a per-OA or per-PSC basis. This draft extends the original E-LSP approach by defining extensions to support per-OA signalling. The extensions are proposed for both RSVP and CR-LDP. Please comment on the same. Thanks -Sudhakar ------------ Dr. Sudhakar Ganti Technical Specialist Tropic Networks Inc, Kanata, Ontario, Canada ------=_NextPart_000_0015_01C0D263.75467180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MPLS Support of E-LSPs
Hi=20 Dimitry,
 
Thanks=20 for your comments on the draft. In general, the proposed extensions=20 are
useful=20 when resource management decisions are to be made on the signaled=20 PSC.
 
The=20 intention of this draft is to facilitate resource allocation at a finer=20 granularity
than=20 class-type would allow, i.e, at the granularity of a OA. As such we=20 cannot
replace PSC with CT. However, it is not = difficult to=20 extend the E-LSP to
signal=20 per-PSC or per-class-type resources.
 
Instead of replacing the PSC field completely = with=20 CT, one can include CT and a couple
of=20 bits indicating whether CT or PSC. This would = enable=20 signaling of
resources per PSC or per CT. Would this of = interest to=20 anyone?
 
The=20 current L-LSP signaling is fine and does not need a separate = L-LSP=20 object.
 
-Sudhakar
-----Original Message-----
From: Dimitry Haskin=20 [mailto:dhaskin@axiowave.com]
Sent: Monday, April 30, 2001 = 3:51=20 PM
To: 'Sudhakar Ganti'; mpls@UU.NET
Cc: Nabil = Seddigh;=20 Biswajit Nandy
Subject: RE: MPLS Support of=20 E-LSPs

Sudhakar,

Thanks for the draft. The proposed extensions will = provide a=20 needed signaling support for the Diff-Serv's Uniform Tunneling model = described=20 in draft-ietf-mpls-diff-ext-09.txt.

To make your proposal consistent with the Class-Type = concept=20 of draft-ietf-mpls-diff-te-reqts-00.txt, I would suggest to replace = the PSC=20 field of the proposed Traffic Profile with a 4-bit Class-Type (CT) = field. In=20 addition if your allow the ELSP Object to carry resource requirements = for=20 L-LSP also (you'd need to rename the object) there would be no need = for the=20 CLASSTYPE Object defined in = draft-ietf-mpls-diff-te-ext-01.txt.

Dimitry

-----Original Message-----
From:=20 Sudhakar Ganti [mailto:sganti@tropicnetworks.co= m]=20
Sent: Monday, April 30, 2001 12:39 PM =
To: mpls@UU.NET
Cc: Nabil Seddigh; = Biswajit=20 Nandy
Subject: MPLS Support of E-LSPs =


Hello,

The following draft is available in the IETF = draft=20
repository that extends E-LSP signaling: =

Title: MPLS Support of Differentiated Services using = E-LSP
Authors: S.Ganti, N.Seddigh, = B.Nandy=20
URL:
http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-e= lsp-00.txt=20

The current E-LSP approach allows multiple = Ordered=20
Aggregates  (OAs)  to  be = carried =20 by  a  single
LSP. The  = existing =20 E-LSP specification only supports
collective = bandwidth=20 signalling for all the OAs in
an E-LSP. = However, there=20 exist uses of the E-LSP
approach where it is = desirable=20 to support bandwidth
signalling on a per-OA = or=20 per-PSC  basis.
This draft extends the = original=20 E-LSP approach by
defining extensions to = support=20 per-OA signalling.
The extensions are = proposed =20 for  both RSVP and CR-LDP.

Please comment on the same. Thanks

-Sudhakar
------------=20
Dr. Sudhakar Ganti
Technical=20 Specialist
Tropic Networks Inc, =
Kanata, Ontario, Canada =

------=_NextPart_000_0015_01C0D263.75467180-- From owner-mpls@UU.NET Tue May 1 18:06:23 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11295 for ; Tue, 1 May 2001 18:06:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknem20182; Tue, 1 May 2001 22:04:32 GMT Received: by mail-control.mail.uu.net id QQknem00275 for mpls-outgoing; Tue, 1 May 2001 22:03:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknem29977 for ; Tue, 1 May 2001 22:03:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknej00164 for ; Tue, 1 May 2001 21:23:29 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknej26894 for ; Tue, 1 May 2001 21:23:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA10350 for mpls@uu.net; Tue, 1 May 2001 17:23:28 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknej20219 for ; Tue, 1 May 2001 21:22:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknei03055 for ; Tue, 1 May 2001 21:04:44 GMT Received: from exchange01.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.82.134]) id QQknei06686 for ; Tue, 1 May 2001 21:04:44 GMT Received: from nfloat.movaz.com ([64.47.82.152]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 1 May 2001 17:02:02 -0400 Message-Id: <4.3.2.7.2.20010501165812.02e29bc0@mail.labn.net> X-Sender: lb@mo-ex1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 01 May 2001 17:04:33 -0400 To: "Saha, Sayandeb" From: Lou Berger Subject: Re: CR_LDP Label Set question. Cc: mpls@UU.NET, ccamp@ops.ietf.org In-Reply-To: <87009604743AD411B1F600508BA0F95971BAA6@XOVER.dedham.mindsp eed.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 May 2001 21:02:02.0921 (UTC) FILETIME=[F8908990:01C0D281] Sender: owner-mpls@UU.NET Precedence: bulk See below. At 03:57 PM 4/25/01, Saha, Sayandeb wrote: >Hi, >[...] > Label Type: 8 bits > > Indicates the type and format of the labels carried in the TLV. > Values match the TLV type of the appropriate Label TLV. > > How can a size of 8 bits for Label Type field suffice when clearly the >tlv types are > much bigger in size like 0x0905 which require 12 bits. > > Does this suggest the use of only the last octet of tlv_type in the >Label Type field?? > >-sayan No, it suggests a bug in the documents. It's been fixed a new version has been submitted and is available at: http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-04.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-03.txt http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-03.txt Good catch & thanks, Lou From owner-mpls@UU.NET Tue May 1 19:27:52 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12331 for ; Tue, 1 May 2001 19:27:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkner26205; Tue, 1 May 2001 23:25:51 GMT Received: by mail-control.mail.uu.net id QQkner14548 for mpls-outgoing; Tue, 1 May 2001 23:24:47 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkner14525 for ; Tue, 1 May 2001 23:24:28 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkner22752 for ; Tue, 1 May 2001 23:23:16 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkner21918 for ; Tue, 1 May 2001 23:23:16 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA18508 for mpls@uu.net; Tue, 1 May 2001 19:23:15 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkner13948 for ; Tue, 1 May 2001 23:18:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkner08356 for ; Tue, 1 May 2001 23:16:50 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkner12223 for ; Tue, 1 May 2001 23:16:49 GMT Received: (qmail 9648 invoked by uid 104); 1 May 2001 23:16:48 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.499938 secs); 01/05/2001 16:16:47 Received: from unknown (HELO plymouth.pmc-sierra.bc.ca) (134.87.114.227) by mother.pmc-sierra.bc.ca with SMTP; 1 May 2001 23:16:46 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by plymouth.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f41NGlK19533; Tue, 1 May 2001 16:16:47 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Tue, 1 May 2001 16:18:53 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C06@BBY1EXM01> From: Shahram Davari To: "'David Charlap'" , mpls@UU.NET Subject: RE: Label Space Date: Tue, 1 May 2001 14:02:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi David, > For instance, if the switch has a very large label space, but can only > allocate a (relatively) small number of labels from the space, then it > can allocate labels on the interfaces where they are used, and prevent > the other interfaces from using the same label values > (without actually > installing those labels on those interfaces.) This way, > there won't be > conflict if a label should happen to change interfaces. > > But some hardware may be unable to lock-off a label value without > actually consuming the resources associated with that label. Meaning > some other scheme might be necessary. I think all affected interfaces must fully install the platform labels and their NHLFEs. The lock-off applies only to the label distribution by those interfaces not to the label forwarding. This is because when an interface receives a packet with per-platform label, it must do a lookup to determine how to forward that packet, even if this label was distributed by another interface. So you need to install the ILM and NHLFE for every per-platform label as well as every per-interface label on those interfaces. For the per-platform labels the software will copy the corresponding NHLFE to all interfaces. Another method is to have a central ILM/NHLFE for the per-platform labels, and check the incoming label against that table fist, if there was no match then check it against per-interface label ILM/NHLFE. The advantage is you save memory, because the NHLFE is not duplicated to each interface, but the catch is that you need 2 lookups per label. > I mention this only because some hardware designs may make this a good > idea. For instance, if several ports are all wired to the same > forwarding chip, it might make sense for them to share a single label > space, even if they can't share that space with ports > attached to other > forwarding chips. > > -- David > This is possible, because as per RFC-3031, you can have multiple per-platform label spaces. Yours, -Shahram From owner-mpls@UU.NET Tue May 1 19:49:34 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12529 for ; Tue, 1 May 2001 19:49:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknet13575; Tue, 1 May 2001 23:47:38 GMT Received: by mail-control.mail.uu.net id QQknet16720 for mpls-outgoing; Tue, 1 May 2001 23:46:58 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknet16712 for ; Tue, 1 May 2001 23:46:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknet06559 for ; Tue, 1 May 2001 23:45:42 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknet29821 for ; Tue, 1 May 2001 23:45:42 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA02329 for ; Tue, 1 May 2001 19:45:39 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA00043 for ; Tue, 1 May 2001 19:45:40 -0400 (EDT) Message-ID: <3AEF4ACC.BFFEEB73@marconi.com> Date: Tue, 01 May 2001 19:46:20 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> <20010501115744.B6029@doit.wisc.edu> <3AEEF103.A5A31094@marconi.com> <3AEF2454.76A0A702@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: >> >> Certain things (like LDP remote peers and bypass tunnels) become >> difficult with per-interface label spaces. The routers must be >> able to deal with the possibility that the next-hop for an >> already-established LSP may jump from one interface to another. >> When this happens, its label must also jump. If the label is >> already in use on the new interface, however, then one or the >> other must be preempted. > > Could be that the terminology we're using is ambiguous, but I'm not > sure I agree with the above. One way that an LSR might deal with > the possibility of a next hop change for an LSP is to use liberal > label retention. This will work for most cases. If the next-hop for an ordinary LSP changes, there's no problem. You either use the label you already have (if retention is liberal and you have a label) or you request a new one. Some of the fast-recovery drafts, however, don't allow time for that. They assume that labels will already be in place on the backup interface. Which means the label must either be allocated on a per-platform basis, or it must be pre-reserved on the backup interface - using scarce resources. It is possible to not allocate the label on the backup interface if you can be certain that no other LSP uses that label's value, however. This can simulate the effect of a platform label space (at least as much as is necessary for the recovery mechanism) without wasting resources. > For LDP remote peers, labels are stacked and labels exchanged > by remote peers are only visible when all labels above them in the > stack have been popped. Correct. This only really impacts the edge router. Transit routers only use the top label. The big deal here is that the TCP session between the remote peers may hop from interface to interface if the routing table changes. If labels are per-interface, then any labels mapped as part of that TCP session must hop interface with the TCP session. > In this case, the term 'interface' takes on an interesting meaning. > One approach (I think the one you're assuming and - possibly - the > common interpretation), is to treat all LSPs between two remote > LSRs as if they are all part of the same 'interface' - in which > case the distinction between label spaces (per-interface, and > per-platform) is moot. This approach is the simplest, and - since > the labels used are below the top level label in forwarding packets > - there is unlikely to be a hardware reason why this cannot be > supported. I think what you're describing is a situation where the TCP connection between remote peers is router-to-router, and not interface-to- interface. So nothing changes if the TCP stream hops interfaces. But this can't work if you have per-interface label spaces. Since it is not normally possible to use anything more than the label's value when determining the meaning of that label, a remote peer's label space must be shared with the label space of whatever interface the TCP session is going out on. If the egress router is using per-interface label spaces and the inner label is only known to one interface, then that inner label will only be processed if the packet arrives on that interface. If a fast reroute causes the inner label to be placed into a different LSP, and the packet arrives at the egress on a different interface, that interface won't know what to do with the inner label - or it may have a different NHLFE. The problem doesn't exist with per-platform label spaces, because every interface knows about the inner label. But there doesn't seem to be any easy solution to this for boxes that can't support per-platform label spaces, unless per-platform functionality is faked - perhaps by duplicating remote-peer labels across all interfaces - which will waste resources. > I believe that label distribution paradigms (e.g. - MPLS BGP) > that rely on use of the per-platform label space, explicitly state > this as a requirement. Perhaps I'm wrong, however, and they > simply count on the implementer to do the right thing. :-) I'm not sure what's a hard requirement here. IMO, per-platform functionality should be possible to fake on those routers that don't actually support it. But the amount of work and complexity involved may be too much to make it worthwhile. -- David From owner-mpls@UU.NET Tue May 1 21:15:52 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13547 for ; Tue, 1 May 2001 21:15:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkney15533; Wed, 2 May 2001 01:14:14 GMT Received: by mail-control.mail.uu.net id QQkney00918 for mpls-outgoing; Wed, 2 May 2001 01:13:42 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkney00910 for ; Wed, 2 May 2001 01:13:32 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkney09356 for ; Wed, 2 May 2001 01:12:39 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQkney27942 for ; Wed, 2 May 2001 01:12:38 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f420fLN09235 for ; Wed, 2 May 2001 09:41:21 +0900 (KST) Message-ID: <008b01c0d29f$c8501b60$77131796@sktelecom.com> From: "Rae M. Chang" To: Subject: A fundamental question Date: Wed, 2 May 2001 09:35:25 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0088_01C0D2EB.3780A860" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0088_01C0D2EB.3780A860 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBhIGZ1bmRhbWVudGFsIGRvdXRiIG9uIE1QTFMgdHJhZmZpYyBlbmdp bmVlcmluZy4NCihwbHMgdGFrZSBpdCBhY2NvdW50IG15IHBvb3IgdW5kZXJzdGFuZGluZyBvbiBB VE0gcm91dGluZyBzdHVmZnMuKQ0KV2hhdCBJIGNhbid0IGZpZ3VyZSBpdCBvdXQgaXMgaWYgYSB1 c2VyIHBhcnQgY29ubmVjdGVkIHRvIHRoZSBBVE0gbmV0d29yayBjYW4gZHluYW1pY2FsbHkgc2V0 dXAgYSBTVkMNCnRvIHRoZSBvdGhlciB1c2VyIHBhcnQuIENhbiB0aGUgVU5JIGFuZCBQTk5JIHN0 dWZmcyBiZSB1c2VkIHRvIHNldCB1cCBpdD8gDQpJZiB0aGF0J3MgdHJ1ZSwgd2hhdCdyZSB0aGUg ZGlmZmVyZW5jZXMgd2l0aCB0aGUgTFNQIHNldHVwIGFjcm9zcyBBVE0gbmV0d29yayB1c2luZyBh bm90aGVyDQpzaWduYWxpbmcgbWVjaGFuaXNtLCBvciBNUExTPw0KV2h5IGRvbid0IHRoZXkgdXNl IGV4aXN0aW5nIEFUTSBzaWduYWxsaW5nIG1ldGhvZHMgdG8gYWNoaWV2ZSB0aGUgdHJhZmZpYyBl bmdpbmVlcmluZyBvZiBNUExTPw0KKGkga25vdyBvZiB0aGUgQVRNJ3MgTiBzcXVhcmUgY29tcGxl eGl0eSBpc3N1ZSB3aXRoIFBWQyBzZXR1cCBvbiB0aGUgSVAgb3ZlciBBVE0gbW9kZWwuDQpidXQs IGluIG15IHRob3VnaHQsIHlvdSBjYW4ganVzdCBzZXR1cCBuZWNlc3NhcnkgVkNzIG9uLWRlbWFu ZCBiYXNpcyBsaWtlIE1QTFMgVEUpDQoNCi1SYWUNCg0KDQo= ------=_NextPart_000_0088_01C0D2EB.3780A860 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjUwLjQ1MjIuMTgwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SGVsbG8sPC9ESVY+DQo8RElWPjxG T05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPkkgaGF2ZSBhIGZ1bmRhbWVudGFs IGRvdXRiIG9uIE1QTFMgdHJhZmZpYyBlbmdpbmVlcmluZy48L0RJVj4NCjxESVY+KHBscyB0YWtl IGl0IGFjY291bnQgbXkgcG9vciB1bmRlcnN0YW5kaW5nIG9uIEFUTSByb3V0aW5nIHN0dWZmcy4p PEJSPldoYXQgDQpJIGNhbid0IGZpZ3VyZSBpdCBvdXQgaXMgaWYgYSB1c2VyIHBhcnQgY29ubmVj dGVkIHRvIHRoZSBBVE0gbmV0d29yayBjYW4gDQpkeW5hbWljYWxseSBzZXR1cCBhIFNWQzxCUj50 byB0aGUgb3RoZXIgdXNlciBwYXJ0LiBDYW4gdGhlIFVOSSBhbmQgUE5OSSBzdHVmZnMgDQpiZSB1 c2VkIHRvIHNldCB1cCBpdD8gPEJSPklmIHRoYXQncyB0cnVlLCB3aGF0J3JlIHRoZSBkaWZmZXJl bmNlcyB3aXRoIHRoZSBMU1AgDQpzZXR1cCBhY3Jvc3MgQVRNIG5ldHdvcmsgdXNpbmcgYW5vdGhl cjxCUj5zaWduYWxpbmcgbWVjaGFuaXNtLCBvciBNUExTPzxCUj5XaHkgDQpkb24ndCB0aGV5IHVz ZSBleGlzdGluZyBBVE0gc2lnbmFsbGluZyBtZXRob2RzIHRvIGFjaGlldmUgdGhlIHRyYWZmaWMg DQplbmdpbmVlcmluZyBvZiBNUExTPzxCUj4oaSBrbm93IG9mIHRoZSBBVE0ncyBOIHNxdWFyZSBj b21wbGV4aXR5IGlzc3VlIHdpdGggUFZDIA0Kc2V0dXAgb24gdGhlIElQIG92ZXIgQVRNIG1vZGVs LjxCUj5idXQsIGluIG15IHRob3VnaHQsIHlvdSBjYW4ganVzdCBzZXR1cCANCm5lY2Vzc2FyeSBW Q3Mgb24tZGVtYW5kIGJhc2lzIGxpa2UgTVBMUyBURSk8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj4tUmFlPC9GT05UPjxCUj48QlI+PC9ESVY+PC9CT0RZPjwvSFRN TD4NCg== ------=_NextPart_000_0088_01C0D2EB.3780A860-- From owner-mpls@UU.NET Wed May 2 05:22:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04250 for ; Wed, 2 May 2001 05:22:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkngf02827; Wed, 2 May 2001 09:21:04 GMT Received: by mail-control.mail.uu.net id QQkngf10116 for mpls-outgoing; Wed, 2 May 2001 09:20:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkngf10103 for ; Wed, 2 May 2001 09:20:11 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkngf07504 for ; Wed, 2 May 2001 09:20:05 GMT Received: from malmo.trab.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: malmo.trab.se [131.115.48.10]) id QQkngf16276 for ; Wed, 2 May 2001 09:20:05 GMT Received: from trab-hermes.haninge.trab.se (trab-hermes.haninge.trab.se [131.115.158.15]) by malmo.trab.se (8.10.1/TRAB-primary-2) with ESMTP id f429K2u11437; Wed, 2 May 2001 11:20:02 +0200 (MEST) Received: by trab-hermes.haninge.trab.se with Internet Mail Service (5.5.2448.0) id ; Wed, 2 May 2001 11:20:01 +0200 Message-ID: <778DFE9B4E3BD111A74E08002BA3DC0D02254428@trab-hermes.haninge.trab.se> From: Nhat Thanh Hoang To: "'Ibrahim Okumus'" , Nhat Thanh Hoang Cc: mpls@UU.NET Subject: RE: MPLS TE question Date: Wed, 2 May 2001 11:20:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Ibrahim, I don't have any pointer to the inter-area LSP setup issue than you and Suhakar have referred to. /Nhat Thanh -----Original Message----- From: Ibrahim Okumus [mailto:iokumus@mailbox.syr.edu] Sent: den 30 april 2001 17:19 To: Nhat Thanh Hoang Cc: mpls@UU.NET Subject: RE: MPLS TE question Hi Nhat, Do you have pointers to the inter-area LSP setup? Thanks, _________________________ Ibrahim Taner OKUMUS On Mon, 30 Apr 2001, Nhat Thanh Hoang wrote: > Hi, > > I Think you can find the answer at the following drafts: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-lsp-tunnel-08.txt > http://www.ietf.org/internet-drafts/draft-ietf-isis-traffic-02.txt > > As I know contraint-based (the constraints such as bandwidth, link colors) > signaled LSPs can only be established within one IS-IS area, because the > traffic-engineering database is only propagating within an area. But, I > think there are RSVP-TE implementations (are vendor dependent)that support > inter-area LSPs by explicitly and strictly point out hop-by-hop along the > LSP you want to establsih and without the constraints: bandwidth and > linkcoloring. > See also the comment line below: > > -----Original Message----- > From: Dirk Maeckelberghe [mailto:Dirk.Maeckelberghe@swift.com] > Sent: den 30 april 2001 14:53 > To: mpls@UU.NET > Subject: MPLS TE question > > > Hello, > > Can you point me to the right references or help answer underneath > questions. > > I need to know if I can use the TE extensions to setup an LSP using RSVP-TE > ( cross area ) in case my IGP is hierarchical IS-IS ( > L1 and L2 ). > Can I assume that summarization happens at area boundaries and that the > detailed TE info does not get propagated inside the area ? > > - Yes, You are right about that. > > This is case A to B where A,B LER and L2A and L2B LSR > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > > If now I am only extending my MPLS cloud to the L2 routers ( L2A - L2B are > now LER ), A and B are NON-MPLS routers, > can I then use the TE extensions of IS-IS to do TE between the L2A and L2B. > I understand that the L2 routers only form L2 adjacencies, are the TE > extensions communicated between them ? > > - I'm not sure if I understand you correctly, and I suppose that now you > mean the changed scenario is L2A, L2X and L2B are Level 2 MPLS-capable > routers, then the answer to your question is YES. > > - If I'm wrong please correct me. > > - I hope it would help something > > Cheers, > /Nhat Thanh > > Telia Research AB > > A - area 1 - L2A ---- L2X --- L2B - area 2 - B > > Thanks, > > Dirk > From owner-mpls@UU.NET Wed May 2 10:12:07 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12050 for ; Wed, 2 May 2001 10:12:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkngy08857; Wed, 2 May 2001 14:10:10 GMT Received: by mail-control.mail.uu.net id QQkngy09766 for mpls-outgoing; Wed, 2 May 2001 14:09:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkngy09758 for ; Wed, 2 May 2001 14:09:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkngy05309 for ; Wed, 2 May 2001 14:07:53 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkngy25783 for ; Wed, 2 May 2001 14:07:52 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14995 for ; Wed, 2 May 2001 10:07:49 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07203 for ; Wed, 2 May 2001 10:07:49 -0400 (EDT) Message-ID: <3AF014AF.BFEE065B@marconi.com> Date: Wed, 02 May 2001 10:07:44 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: A fundamental question References: <008b01c0d29f$c8501b60$77131796@sktelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Rae M. Chang" wrote: > > I have a fundamental doutb on MPLS traffic engineering. > (pls take it account my poor understanding on ATM routing stuffs.) > What I can't figure it out is if a user part connected to the ATM > network can dynamically setup a SVC to the other user part. Can the > UNI and PNNI stuffs be used to set up it? No. ATM signaling and MPLS signaling are two different things. One is not used to setup the other. An ATM switch acting as LSR (a transit router) will ultimately have the same kind of cell-forwarding installed on its fabric with each protocol, but that's where the similarities end. An ATM switch acting as LER (an edge router) has different semantics on the data plane. On ingress, it must apply labels to incoming unlabeled traffic (or push labels if one LSP is being tunneled through another.) On egress, it must be able to pop labels and make forwarding decisions based on the result. > If that's true, what're the differences with the LSP setup across > ATM network using another signaling mechanism, or MPLS? > Why don't they use existing ATM signalling methods to achieve the > traffic engineering of MPLS? ATM's routing and signaling protocols are closely tied to ATM's addressing architecture. These protocols are not based on IP, and they do not scale up to networks the size of the internet. Finally, ATM only works on ATM interfaces - it doesn't work over PPP, Frame Relay, Ethernet, or other types of interfaces that are commonly found in networks. MPLS is intended to solve these problems. The routing protocols are well-established IP protocols (OSPF, IS-IS, BGP). The signaling protocols are designed around IP. And MPLS works over all IP- compatible interfaces. Routers of all kinds (ATM, Frame, IP, etc.) can interoperate in a single MPLS cloud. > (i know of the ATM's N square complexity issue with PVC setup on the > IP over ATM model. but, in my thought, you can just setup necessary > VCs on-demand basis like MPLS TE) On-demand setup works fine in an enterprise network. It doesn't work in a core network. When you've got hundreds of GB/s of data flowing through a network, the delays needed to dynamically allocate new VCs (or LSPs) will almost certainly be unacceptible. MPLS avoids the N^2 problem in two ways: 1: The LSPs follow the routing protocols' shortest-paths. Meaning you don't necessarily need an LSP to get from everywhere to everywhere. Only along the shortest routed paths. 2: Routers that support label merging can greatly reduce the amount of resources required. Two LSPs arriving at a single transit router, that are intended to terminate at the same egress router may be merged (assuming there are no QoS concerns, of course.), eliminating the need for the second LSP if the downstream rouers. -- David From owner-mpls@UU.NET Wed May 2 10:40:02 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13063 for ; Wed, 2 May 2001 10:39:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknha18905; Wed, 2 May 2001 14:37:57 GMT Received: by mail-control.mail.uu.net id QQknha13010 for mpls-outgoing; Wed, 2 May 2001 14:37:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknha12997 for ; Wed, 2 May 2001 14:37:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknha26374 for ; Wed, 2 May 2001 14:34:12 GMT Received: from hotmail.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: oe72.pav1.hotmail.com [64.4.30.207]) id QQknha14468 for ; Wed, 2 May 2001 14:34:11 GMT Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 May 2001 07:34:11 -0700 X-Originating-IP: [66.30.55.128] From: "Jeremy" To: References: <008b01c0d29f$c8501b60$77131796@sktelecom.com> <3AF014AF.BFEE065B@marconi.com> Subject: Re: A fundamental question Date: Wed, 2 May 2001 10:38:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Message-ID: X-OriginalArrivalTime: 02 May 2001 14:34:11.0111 (UTC) FILETIME=[F3E5E370:01C0D314] Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Is their a table available that compares/contrasts ATM vs. MPLS? Thanks, Jeremy. ----- Original Message ----- From: "David Charlap" To: Sent: Wednesday, May 02, 2001 10:07 AM Subject: Re: A fundamental question > "Rae M. Chang" wrote: > > > > I have a fundamental doutb on MPLS traffic engineering. > > (pls take it account my poor understanding on ATM routing stuffs.) > > What I can't figure it out is if a user part connected to the ATM > > network can dynamically setup a SVC to the other user part. Can the > > UNI and PNNI stuffs be used to set up it? > > No. ATM signaling and MPLS signaling are two different things. One is > not used to setup the other. > > An ATM switch acting as LSR (a transit router) will ultimately have the > same kind of cell-forwarding installed on its fabric with each protocol, > but that's where the similarities end. > > An ATM switch acting as LER (an edge router) has different semantics on > the data plane. On ingress, it must apply labels to incoming unlabeled > traffic (or push labels if one LSP is being tunneled through another.) > On egress, it must be able to pop labels and make forwarding decisions > based on the result. > > > If that's true, what're the differences with the LSP setup across > > ATM network using another signaling mechanism, or MPLS? > > Why don't they use existing ATM signalling methods to achieve the > > traffic engineering of MPLS? > > ATM's routing and signaling protocols are closely tied to ATM's > addressing architecture. These protocols are not based on IP, and they > do not scale up to networks the size of the internet. Finally, ATM only > works on ATM interfaces - it doesn't work over PPP, Frame Relay, > Ethernet, or other types of interfaces that are commonly found in > networks. > > MPLS is intended to solve these problems. The routing protocols are > well-established IP protocols (OSPF, IS-IS, BGP). The signaling > protocols are designed around IP. And MPLS works over all IP- > compatible interfaces. Routers of all kinds (ATM, Frame, IP, etc.) can > interoperate in a single MPLS cloud. > > > (i know of the ATM's N square complexity issue with PVC setup on the > > IP over ATM model. but, in my thought, you can just setup necessary > > VCs on-demand basis like MPLS TE) > > On-demand setup works fine in an enterprise network. It doesn't work in > a core network. When you've got hundreds of GB/s of data flowing > through a network, the delays needed to dynamically allocate new VCs (or > LSPs) will almost certainly be unacceptible. > > MPLS avoids the N^2 problem in two ways: > > 1: The LSPs follow the routing protocols' shortest-paths. Meaning > you don't necessarily need an LSP to get from everywhere to > everywhere. Only along the shortest routed paths. > > 2: Routers that support label merging can greatly reduce the amount > of resources required. Two LSPs arriving at a single transit > router, that are intended to terminate at the same egress router > may be merged (assuming there are no QoS concerns, of course.), > eliminating the need for the second LSP if the downstream rouers. > > -- David > From owner-mpls@UU.NET Wed May 2 12:42:48 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16783 for ; Wed, 2 May 2001 12:42:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhg22689; Wed, 2 May 2001 16:13:38 GMT Received: by mail-control.mail.uu.net id QQknhg01378 for mpls-outgoing; Wed, 2 May 2001 16:13:02 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknhg01312 for ; Wed, 2 May 2001 16:12:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhg07858 for ; Wed, 2 May 2001 16:10:24 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknhg16103 for ; Wed, 2 May 2001 16:10:24 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA26704 for ; Wed, 2 May 2001 12:10:22 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10792 for ; Wed, 2 May 2001 12:10:22 -0400 (EDT) Message-ID: <3AF03169.6F4816FF@marconi.com> Date: Wed, 02 May 2001 12:10:17 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: MPLS Mailing List Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> <20010501115744.B6029@doit.wisc.edu> <3AEEF103.A5A31094@marconi.com> <3AEF2454.76A0A702@sandburst.com> <3AEF4ACC.BFFEEB73@marconi.com> <3AF02869.A71909FC@sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Eric Gray wrote: >> >> It is possible to not allocate the label on the backup interface >> if you can be certain that no other LSP uses that label's value, >> however. This can simulate the effect of a platform label space >> (at least as much as is necessary for the recovery mechanism) >> without wasting resources. > > I'm not sure of the distinction between allocating a label (in this > usage) and being certain that no other LSP will use it. If you > allocate it without signaling, then you are essentially 'reserving' > it. If you are ensuring that is is not used for any other LSP, > then you are essentially 'reserving' it. Not quite. If the scarce resource is the range of label values themselves, then you are right. Keeping other LSPs away from it is the same as a reservation. But if your scarce resource is something else - perhaps table entries in a forwarding chip - then this is not necessarily the case. To actually "reserve" a value would be to install it in the port's forwarding hardware, while simply avoiding the use of a specific label value can be done without installing anything in the forwarding hardware. In other words, it may be possible to consume labels without consuming all of the forwarding resources that normally go along with those labels. >> The big deal here is that the TCP session between the remote peers >> may hop from interface to interface if the routing table changes. >> If labels are per-interface, then any labels mapped as part of >> that TCP session must hop interface with the TCP session. > > This is skirting a thin line. TCP is not normally associated with > an interface and not every implementation pays strict attention to > the interface over which a TCP connection is maintained. Therefore, > relying on label validity to jump around with TCP connectivity will > most probably lead to (if it is not already) a protocol error. Obviously, if the TCP connection's interface can't be tracked, then remote peers can't work without per-platform label spaces (or an emulation thereof.) >> But this can't work if you have per-interface label spaces. >> >> Since it is not normally possible to use anything more than the >> label's value when determining the meaning of that label, a remote >> peer's label space must be shared with the label space of whatever >> interface the TCP session is going out on. > > This is plainly wrong. When using the per-interface label space, > the interface on which a label is received is obviously part of the > logical context in which the label must be considered. This can > be done in any number of ways. I must be unclear hree. When a router receives two stacked labels, it obviously uses the interface in determining what to do with the top label. My point is regarding the next label down (the second-level label). This label is, obviously, allocated as a part of whatever label space the TCP session (for the remote peer) is associated with. This is the same as with all labels. The problem happens when there is no per-platform label space. The remote peer's labels must be allocated as a part of an interface's label space. But since the peer is not directly attached, there can be no guarantee that traffic from that peer (that is, traffic using second-level labels requested over that TCP channel) will always arrive on the same interface. Which means that these second-level labels must either be installed per-platform, or at least installed on all interfaces that the label might conceivably arrive on. The rest of my hypothesizing is an attempt to reduce this down to the one interface that the label actually does arrive on. If the data is strictly following the routing table, it may be possible to assume that the TCP session will hop interfaces in unison with the data packets. Therefore, if the TCP session hopping can be detected (and as you've already written, it may not be possible to detect this), its labels can be moved at that time. -- David From owner-mpls@UU.NET Wed May 2 13:04:16 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17369 for ; Wed, 2 May 2001 13:04:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhk15426; Wed, 2 May 2001 17:02:25 GMT Received: by mail-control.mail.uu.net id QQknhk11598 for mpls-outgoing; Wed, 2 May 2001 17:01:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknhk11522 for ; Wed, 2 May 2001 17:01:45 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknhk20050 for ; Wed, 2 May 2001 17:01:05 GMT Received: from red.juniper.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQknhk11538 for ; Wed, 2 May 2001 17:01:03 GMT Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id KAA24234; Wed, 2 May 2001 10:00:53 -0700 (PDT) Message-Id: <200105021700.KAA24234@red.juniper.net> To: "Fong, Man Wing" cc: mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling In-Reply-To: Your message of "Mon, 30 Apr 2001 14:30:38 CDT." <66E0B27B8A29D511B19600D0B744446527AE25@192-168-1-220.customer.algx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <11258.988822853.1@juniper.net> Date: Wed, 02 May 2001 10:00:53 -0700 From: Yakov Rekhter Sender: owner-mpls@UU.NET Precedence: bulk Man Wing, > >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links > between two LSRs can be bundled as a single link to improve the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface? Could you please point me to the text in the draft that restricts its application to only physical interfaces ? Yakov. From owner-mpls@UU.NET Wed May 2 13:41:04 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18255 for ; Wed, 2 May 2001 13:41:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhf21956; Wed, 2 May 2001 15:45:09 GMT Received: by mail-control.mail.uu.net id QQknhe09335 for mpls-outgoing; Wed, 2 May 2001 15:44:13 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknhe08526 for ; Wed, 2 May 2001 15:36:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknhe26622 for ; Wed, 2 May 2001 15:31:54 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQknhe07336 for ; Wed, 2 May 2001 15:31:54 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id ABAF594006; Wed, 2 May 2001 11:31:53 -0400 (EDT) Message-ID: <3AF02869.A71909FC@sandburst.com> Date: Wed, 02 May 2001 11:31:53 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap , MPLS Mailing List Subject: Re: Label Space References: <20010501144033.95183.qmail@web14306.mail.yahoo.com> <3AEED3C3.DEC50A9A@marconi.com> <20010501115744.B6029@doit.wisc.edu> <3AEEF103.A5A31094@marconi.com> <3AEF2454.76A0A702@sandburst.com> <3AEF4ACC.BFFEEB73@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit David, Please see comments below. You wrote: > Eric Gray wrote: > >> > >> Certain things (like LDP remote peers and bypass tunnels) become > >> difficult with per-interface label spaces. The routers must be > >> able to deal with the possibility that the next-hop for an > >> already-established LSP may jump from one interface to another. > >> When this happens, its label must also jump. If the label is > >> already in use on the new interface, however, then one or the > >> other must be preempted. > > > > Could be that the terminology we're using is ambiguous, but I'm not > > sure I agree with the above. One way that an LSR might deal with > > the possibility of a next hop change for an LSP is to use liberal > > label retention. > > This will work for most cases. If the next-hop for an ordinary LSP > changes, there's no problem. You either use the label you already have > (if retention is liberal and you have a label) or you request a new one. > > Some of the fast-recovery drafts, however, don't allow time for that. > They assume that labels will already be in place on the backup > interface. Which means the label must either be allocated on a > per-platform basis, or it must be pre-reserved on the backup interface - > using scarce resources. If you're not using the per-platform label space, then pre-reservation must be considered a more optimal use of scarce resources then use of the per-platform label space (where all labels are pre-reserved at all interfaces, or at least, all interfaces in common). > > > It is possible to not allocate the label on the backup interface if you > can be certain that no other LSP uses that label's value, however. This > can simulate the effect of a platform label space (at least as much as > is necessary for the recovery mechanism) without wasting resources. I'm not sure of the distinction between allocating a label (in this usage) and being certain that no other LSP will use it. If you allocate it without signaling, then you are essentially 'reserving' it. If you are ensuring that is is not used for any other LSP, then you are essentially 'reserving' it. And, if you allocate it and signal the allocation, then the choice of label space is irrelevant, since this choice is part of the signaling process. > > > > For LDP remote peers, labels are stacked and labels exchanged > > by remote peers are only visible when all labels above them in the > > stack have been popped. > > Correct. This only really impacts the edge router. Transit routers > only use the top label. > > The big deal here is that the TCP session between the remote peers may > hop from interface to interface if the routing table changes. If labels > are per-interface, then any labels mapped as part of that TCP session > must hop interface with the TCP session. This is skirting a thin line. TCP is not normally associated with an interface and not every implementation pays strict attention to the interface over which a TCP connection is maintained. Therefore, relying on label validity to jump around with TCP connectivity will most probably lead to (if it is not already) a protocol error. > > > > In this case, the term 'interface' takes on an interesting meaning. > > One approach (I think the one you're assuming and - possibly - the > > common interpretation), is to treat all LSPs between two remote > > LSRs as if they are all part of the same 'interface' - in which > > case the distinction between label spaces (per-interface, and > > per-platform) is moot. This approach is the simplest, and - since > > the labels used are below the top level label in forwarding packets > > - there is unlikely to be a hardware reason why this cannot be > > supported. > > I think what you're describing is a situation where the TCP connection > between remote peers is router-to-router, and not interface-to- > interface. So nothing changes if the TCP stream hops interfaces. I believe that it is safer to assume TCP connectivity is IP entity to IP entity than it is to assume that it is interface to interface. > > > But this can't work if you have per-interface label spaces. > > Since it is not normally possible to use anything more than the label's > value when determining the meaning of that label, a remote peer's label > space must be shared with the label space of whatever interface the TCP > session is going out on. This is plainly wrong. When using the per-interface label space, the interface on which a label is received is obviously part of the logical context in which the label must be considered. This can be done in any number of ways. However, if a specific system implementation (this is NOT a limitation induced by any specific hardware component) cannot consider the interface on which a label was received, then that system does not support the per-interface label space. Period. And, please, before anyone jumps all over this statement, having an individual label processor for each and every interface is one way to use the interface on which a label is received as part of the context for considering the label - even if none of the label processors is individually capable of knowing what interface a label was received on. As a side note, I strongly suspect that building label processors that are not at least somewhat capable of considering the input interface (in some abstraction), is probably not as good a way to sell lots of label processors as it might at first appear. > > > If the egress router is using per-interface label spaces and the inner > label is only known to one interface, then that inner label will only be > processed if the packet arrives on that interface. If a fast reroute > causes the inner label to be placed into a different LSP, and the packet > arrives at the egress on a different interface, that interface won't > know what to do with the inner label - or it may have a different NHLFE. > > The problem doesn't exist with per-platform label spaces, because every > interface knows about the inner label. But there doesn't seem to be any > easy solution to this for boxes that can't support per-platform label > spaces, unless per-platform functionality is faked - perhaps by > duplicating remote-peer labels across all interfaces - which will waste > resources. > > > I believe that label distribution paradigms (e.g. - MPLS BGP) > > that rely on use of the per-platform label space, explicitly state > > this as a requirement. Perhaps I'm wrong, however, and they > > simply count on the implementer to do the right thing. :-) > > I'm not sure what's a hard requirement here. IMO, per-platform > functionality should be possible to fake on those routers that don't > actually support it. But the amount of work and complexity involved may > be too much to make it worthwhile. Agreed, and agreed. > > > -- David -- Eric Gray From owner-mpls@UU.NET Wed May 2 13:48:06 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18447 for ; Wed, 2 May 2001 13:48:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhn09323; Wed, 2 May 2001 17:45:16 GMT Received: by mail-control.mail.uu.net id QQknhm00903 for mpls-outgoing; Wed, 2 May 2001 17:44:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknhm00887 for ; Wed, 2 May 2001 17:44:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknhm04768 for ; Wed, 2 May 2001 17:42:43 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQknhm09725 for ; Wed, 2 May 2001 17:42:43 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id <25S6S73X>; Wed, 2 May 2001 12:41:46 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE2F@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: "'Yakov Rekhter'" Cc: mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Wed, 2 May 2001 12:41:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Yakov, Thanks for clearing my doubt. Regards, Man Wing -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net] Sent: Wednesday, May 02, 2001 12:01 PM To: Fong, Man Wing Cc: mpls@UU.NET; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling Man Wing, > >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links > between two LSRs can be bundled as a single link to improve the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface? Could you please point me to the text in the draft that restricts its application to only physical interfaces ? Yakov. From owner-mpls@UU.NET Wed May 2 13:49:06 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18466 for ; Wed, 2 May 2001 13:49:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhn22130; Wed, 2 May 2001 17:47:01 GMT Received: by mail-control.mail.uu.net id QQknhn01653 for mpls-outgoing; Wed, 2 May 2001 17:46:24 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknhn01376 for ; Wed, 2 May 2001 17:45:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhm13246 for ; Wed, 2 May 2001 17:44:38 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQknhm16644 for ; Wed, 2 May 2001 17:44:37 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id KAA20697 for ; Wed, 2 May 2001 10:44:36 -0700 (PDT) Message-ID: <3AF04784.64B5B940@pluris.com> Date: Wed, 02 May 2001 10:44:36 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: FEC next hop when FEC has multiple elements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Having studied the LDP spec., some code that attempts to implement the LDP spec, and several previous threads on the subject of FEC aggregation and deaggragation, I have formulated a little question, for which I am almost certain of the answer, but there is this nagging doubt. In the LDP spec, in appendix A for the receive label mapping procedure, section A.1.2, page 101, we have: LMp.11 Determine the next hop for the FEC Suppose FEC1 is a set of n FEC elements: F1 and F2 ... Fn. Suppose the next hop for F1 is the MsgSource, but for F2 ... Fn it is something else. Suppose (for sake of specificity) we are in downstream unsolicited ordered advertisement mode. My take is that the next hop for FEC1 is NO ROUTE, and that the label being mapped is not used for switching/forwarding *at all*. If my take is right, then label_map(label, FEC, otherargs); Is not at all like: for each ELEMENT in FEC: label_map(label, ELEMENT, otherargs) Unless the next hop for each (or no) ELEMENT is MsgSource. So, is my take right? Thanks to any who can respond! CLK From owner-mpls@UU.NET Wed May 2 13:57:30 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18847 for ; Wed, 2 May 2001 13:57:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhn27765; Wed, 2 May 2001 17:55:41 GMT Received: by mail-control.mail.uu.net id QQknhn02743 for mpls-outgoing; Wed, 2 May 2001 17:55:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknhn02693 for ; Wed, 2 May 2001 17:53:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhn01553 for ; Wed, 2 May 2001 17:52:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknhn06431 for ; Wed, 2 May 2001 17:52:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA15550 for mpls@uu.net; Wed, 2 May 2001 13:52:31 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknhn01786 for ; Wed, 2 May 2001 17:48:12 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknhn20631 for ; Wed, 2 May 2001 17:48:11 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQknhn19394 for ; Wed, 2 May 2001 17:48:10 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f42Hkk717139; Wed, 2 May 2001 13:46:46 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame4.cisco.com [10.84.75.69]) by bucket.cisco.com (Mirapoint) with ESMTP id ABE02015; Wed, 2 May 2001 13:47:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20010502134806.018d21d8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 May 2001 13:50:07 -0400 To: Yakov Rekhter , "Fong, Man Wing" From: "Thomas D. Nadeau" Subject: Re: Question about logical link in Link bundling Cc: mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org In-Reply-To: <200105021700.KAA24234@red.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:00 AM 5/2/2001 -0700, Yakov Rekhter wrote: >Man Wing, > > > >From "draft-kompella-mpls-bundle-05.txt", it indicates that multiple links > > between two LSRs can be bundled as a single link to improve the routing > > scalability. Apparently, it can be used to bundle multiple links from > > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > > etc...) to be a single link. However, can it be used to bundle logical > links > > like T1s in channelized T3, or DS3s, STS-3c in channelized OC-12 interface? > >Could you please point me to the text in the draft that restricts >its application to only physical interfaces ? Perhaps the text be clarified to explicitly include logical links? I understood the text to read that both physical and logical links were allowed. However, inclusion by implication is probably not the best practice for a standards-track document. :P --Tom From owner-mpls@UU.NET Wed May 2 14:21:34 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19264 for ; Wed, 2 May 2001 14:21:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhp26361; Wed, 2 May 2001 18:19:47 GMT Received: by mail-control.mail.uu.net id QQknhp24206 for mpls-outgoing; Wed, 2 May 2001 18:19:14 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknhp24179 for ; Wed, 2 May 2001 18:19:02 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhp13684 for ; Wed, 2 May 2001 18:17:29 GMT Received: from red.juniper.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQknhp26465 for ; Wed, 2 May 2001 18:17:29 GMT Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id LAA00987 for ; Wed, 2 May 2001 11:17:29 -0700 (PDT) Received: (from kireeti@localhost) by kummer.juniper.net (8.8.8/8.7.3) id LAA24691 for mpls@uu.net; Wed, 2 May 2001 11:17:28 -0700 (PDT) Date: Wed, 2 May 2001 11:17:28 -0700 (PDT) From: Kireeti Kompella Message-Id: <200105021817.LAA24691@kummer.juniper.net> To: mpls@UU.NET Subject: Re: Question about logical link in Link bundling In-Reply-To: <4.3.2.7.2.20010502134806.018d21d8@bucket.cisco.com> Sender: owner-mpls@UU.NET Precedence: bulk Hi Tom, > Perhaps the text be clarified to explicitly include > logical links? I understood the text to read that both physical > and logical links were allowed. Two points: 1) Terminology: calling a T1 in a channelized T3, or an STS-3c in an OC-48 a *logical* link will confuse lots of folks. 2) From a routing point of view, there is entirely no difference between an STS-3c in an OC-48, and a "standalone" STS-3c/OC-3c. So, while I'm not opposed to making the above "clarification", it seems unnecessary; moreover, there are plenty of other documents that would then need this same "clarification". Kireeti. From owner-mpls@UU.NET Wed May 2 14:49:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19907 for ; Wed, 2 May 2001 14:49:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhr29718; Wed, 2 May 2001 18:47:14 GMT Received: by mail-control.mail.uu.net id QQknhr27428 for mpls-outgoing; Wed, 2 May 2001 18:46:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknhr27391 for ; Wed, 2 May 2001 18:46:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknhr15841 for ; Wed, 2 May 2001 18:46:05 GMT Received: from bgslc02.TBG.COM by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQknhr27118 for ; Wed, 2 May 2001 18:46:05 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 12:31:59 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE70146DAF8@BGSLC02> From: Irwin Lazar To: "'Jeremy'" , mpls@UU.NET Subject: RE: A fundamental question Date: Wed, 2 May 2001 12:31:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Is their a table available that compares/contrasts ATM vs. MPLS? Thanks, Jeremy. --------------- Have a look at: http://www.mplsrc.com/faq2.shtml#MPLS and ATM Irwin From owner-mpls@UU.NET Wed May 2 15:07:45 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20298 for ; Wed, 2 May 2001 15:07:45 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhs21251; Wed, 2 May 2001 19:05:51 GMT Received: by mail-control.mail.uu.net id QQknhs08855 for mpls-outgoing; Wed, 2 May 2001 19:05:21 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknhs08017 for ; Wed, 2 May 2001 19:05:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhs29686 for ; Wed, 2 May 2001 19:05:03 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknhs15252 for ; Wed, 2 May 2001 19:05:03 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA23575 for mpls@uu.net; Wed, 2 May 2001 15:05:03 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknhs07007 for ; Wed, 2 May 2001 19:04:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhs05760 for ; Wed, 2 May 2001 19:00:46 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQknhs10978 for ; Wed, 2 May 2001 19:00:45 GMT Received: (qmail 27283 invoked by uid 104); 2 May 2001 19:00:45 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.641981 secs); 02/05/2001 12:00:44 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 2 May 2001 19:00:43 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f42J0g102601; Wed, 2 May 2001 12:00:42 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 12:02:56 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> From: Shahram Davari To: "'Chris Kuszmaul'" , mpls@UU.NET Subject: RE: FEC next hop when FEC has multiple elements Date: Wed, 2 May 2001 12:02:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Chris, All FEC elements in an FEC-TLV, must have the same next hop. Yours, -Shahram > -----Original Message----- > From: Chris Kuszmaul [mailto:fyodor@pluris.com] > Sent: Wednesday, May 02, 2001 1:45 PM > To: mpls@UU.NET > Subject: FEC next hop when FEC has multiple elements > > > > Having studied the LDP spec., some code that attempts to implement > the LDP spec, and several previous threads on the subject of FEC > aggregation > and deaggragation, I have formulated a little question, for which I am > almost certain of the answer, but there is this nagging doubt. > > > In the LDP spec, in appendix A for the receive label mapping > procedure, section A.1.2, page 101, we have: > > LMp.11 Determine the next hop for the FEC > > > Suppose FEC1 is a set of n FEC elements: F1 and F2 ... Fn. > Suppose the next hop for F1 is the MsgSource, but for F2 ... Fn it > is something else. > Suppose (for sake of specificity) we are in downstream unsolicited > ordered > advertisement mode. > > My take is that the next hop for FEC1 is NO ROUTE, and that the > label being mapped is not used for switching/forwarding *at all*. > > > If my take is right, then > > > > label_map(label, FEC, otherargs); > > Is not at all like: > > for each ELEMENT in FEC: > label_map(label, ELEMENT, otherargs) > > Unless the next hop for each (or no) ELEMENT is MsgSource. > > > > So, is my take right? > > > Thanks to any who can respond! > > CLK > > From owner-mpls@UU.NET Wed May 2 15:48:01 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21359 for ; Wed, 2 May 2001 15:48:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhv05512; Wed, 2 May 2001 19:45:59 GMT Received: by mail-control.mail.uu.net id QQknhv23068 for mpls-outgoing; Wed, 2 May 2001 19:45:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknhv23051 for ; Wed, 2 May 2001 19:45:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknhu01931 for ; Wed, 2 May 2001 19:44:00 GMT Received: from asc_exch.asc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: outlook.asc.com [63.82.128.45]) id QQknhu08180 for ; Wed, 2 May 2001 19:44:00 GMT Received: by ASC_EXCH with Internet Mail Service (5.5.2653.19) id ; Wed, 2 May 2001 15:36:06 -0400 Message-ID: <4AA0C69EF2C3D411B94600B0D04931BD14B835@ASC_EXCH> From: Jim Loehndorf To: "'mpls@uu.net'" Subject: VC Consistancy in the encap specification Date: Wed, 2 May 2001 15:36:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D33F.206E3DF0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D33F.206E3DF0 Content-Type: text/plain; charset="iso-8859-1" MPLS encapsulation team, I need help in understanding the intent of the "draft-martini-12circuit-encap-mpls-01.txt" document. Section 4.2.2, ATM Cell Mode suggests that every ATM cell is prepended by a 4 byte header with a valid VPI & VCI address field. This is in addition to the VC label that encapsulates the ATM cell(s). Must a one-to-one relationship exist between the VPI/VCI address field of the 4 byte ATM header and the VC label? Or can multiple VCs (multiple VPI/VCI addresses) exist multiplexed into a single VC label? Jim Loehndorf ASC ------_=_NextPart_001_01C0D33F.206E3DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable VC Consistancy in the encap specification

MPLS encapsulation team,

I need = help in understanding the intent of the = "draft-martini-12circuit-encap-mpls-01.txt" document.  Section = 4.2.2, ATM Cell = Mode suggests that every ATM cell is prepended by a 4 byte header = with a valid VPI & VCI address field.  This is in addition to the VC label that = encapsulates the ATM cell(s).  Must a one-to-one relationship exist between the = VPI/VCI address field of the 4 byte ATM header and the VC label?  = Or can multiple VCs (multiple VPI/VCI addresses) = exist multiplexed into a single VC label?

Jim = Loehndorf

ASC


------_=_NextPart_001_01C0D33F.206E3DF0-- From owner-mpls@UU.NET Wed May 2 16:11:38 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22058 for ; Wed, 2 May 2001 16:11:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhw08255; Wed, 2 May 2001 20:09:45 GMT Received: by mail-control.mail.uu.net id QQknhw13249 for mpls-outgoing; Wed, 2 May 2001 20:09:12 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknhw13142 for ; Wed, 2 May 2001 20:09:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknhw16248 for ; Wed, 2 May 2001 20:07:32 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQknhw05178 for ; Wed, 2 May 2001 20:07:31 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id NAA24999; Wed, 2 May 2001 13:07:26 -0700 (PDT) Message-ID: <3AF068FE.7A619C0@pluris.com> Date: Wed, 02 May 2001 13:07:26 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shahram Davari CC: mpls@UU.NET Subject: Re: FEC next hop when FEC has multiple elements References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Shahram, Thanks. Just to be clear: You are saying that the LSR that receives the label mapping must check to see whether all the elements in the FEC-TLV have the same next hop, since the LSR that advertised the label has no way of knowing the next hop for the receiver of the mapping. In particular, the receiver of the mapping cannot simply compute the next hop for the first FEC element in the FEC-TLV, and use that as the next hop, relying on the assertion that all FEC elements in the TLV must have the same next hop the guarantee must come from the receiver, not the sender. Is this correct? Thanks CLK Shahram Davari wrote: > Hi Chris, > > All FEC elements in an FEC-TLV, must have the same next hop. > > Yours, > -Shahram > > > -----Original Message----- > > From: Chris Kuszmaul [mailto:fyodor@pluris.com] > > Sent: Wednesday, May 02, 2001 1:45 PM > > To: mpls@UU.NET > > Subject: FEC next hop when FEC has multiple elements > > > > > > > > Having studied the LDP spec., some code that attempts to implement > > the LDP spec, and several previous threads on the subject of FEC > > aggregation > > and deaggragation, I have formulated a little question, for which I am > > almost certain of the answer, but there is this nagging doubt. > > > > > > In the LDP spec, in appendix A for the receive label mapping > > procedure, section A.1.2, page 101, we have: > > > > LMp.11 Determine the next hop for the FEC > > > > > > Suppose FEC1 is a set of n FEC elements: F1 and F2 ... Fn. > > Suppose the next hop for F1 is the MsgSource, but for F2 ... Fn it > > is something else. > > Suppose (for sake of specificity) we are in downstream unsolicited > > ordered > > advertisement mode. > > > > My take is that the next hop for FEC1 is NO ROUTE, and that the > > label being mapped is not used for switching/forwarding *at all*. > > > > > > If my take is right, then > > > > > > > > label_map(label, FEC, otherargs); > > > > Is not at all like: > > > > for each ELEMENT in FEC: > > label_map(label, ELEMENT, otherargs) > > > > Unless the next hop for each (or no) ELEMENT is MsgSource. > > > > > > > > So, is my take right? > > > > > > Thanks to any who can respond! > > > > CLK > > > > From owner-mpls@UU.NET Wed May 2 16:17:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22291 for ; Wed, 2 May 2001 16:17:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhx08358; Wed, 2 May 2001 20:16:09 GMT Received: by mail-control.mail.uu.net id QQknhx15142 for mpls-outgoing; Wed, 2 May 2001 20:15:19 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknhx14996 for ; Wed, 2 May 2001 20:15:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknhw02770 for ; Wed, 2 May 2001 20:14:53 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknhw06740 for ; Wed, 2 May 2001 20:14:53 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA18968 for ; Wed, 2 May 2001 16:14:50 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06802 for ; Wed, 2 May 2001 16:14:51 -0400 (EDT) Message-ID: <3AF06AB7.81EE10AB@marconi.com> Date: Wed, 02 May 2001 16:14:47 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: FEC next hop when FEC has multiple elements References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Shahram Davari wrote: > > All FEC elements in an FEC-TLV, must have the same next hop. This is obvious, but I think the question is a little more involved than this. It is possible for a router to see a single next-hop for two different prefixes, but its upstream router may see these prefixes as having two different next-hops. (I have worked out some topologies where this is true, but they don't easily lend themselves to ASCII-art.) The downstream router decides to aggregate the prefixes into a single FEC and sends out a label mapping. As far as the downstream router is concerned, this is fine - if it receives packets for either prefix, it will handle them identically. The upstream router, upon receiving this label mapping realizes that the sender is only next-hop for one of the prefixes, but someone else is a closer next-hop for the other. The question is what it should do with this. IMO, the upstream router should reject the FEC (send back a label release). The FEC is malformed from its point of view, because the prefixes don't all share a common next-hop. Upon receiving the label release, the downstream router should realize that the aggregation is improper, and should then send out two separate mappings - one for each prefix. The upstream router can then use one, and either reject or hold on to the other (depending on the label retention mode.) Appendix A, however, is silent on what should happen in this situation. -- David From owner-mpls@UU.NET Wed May 2 16:43:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22906 for ; Wed, 2 May 2001 16:43:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknhy09218; Wed, 2 May 2001 20:41:54 GMT Received: by mail-control.mail.uu.net id QQknhy17810 for mpls-outgoing; Wed, 2 May 2001 20:41:23 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknhy17746 for ; Wed, 2 May 2001 20:41:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknhy03765 for ; Wed, 2 May 2001 20:40:56 GMT Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQknhy17470 for ; Wed, 2 May 2001 20:40:56 GMT Received: from notes870.cc.telcordia.com (notes870.cc.telcordia.com [128.96.244.12]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA03223 for ; Wed, 2 May 2001 16:33:50 -0400 (EDT) Subject: Re: Question about logical link in Link bundling To: mpls@UU.NET From: "Anuj Bhatnagar" Date: Wed, 2 May 2001 16:33:48 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes870/Telcordia(Release 5.0.6a |January 17, 2001) at 05/02/2001 04:33:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk This is a good point and I kind of agree with Kireeti. If we define our domain to be just IP (which I believe it is for this document) then *logical* connectivity between routers can be bundled into one link. Another reason for it is that if we have two or more interfaces between peering routers then we may not know which route a packet is going to take to get to the next hop. However, if we are defining inter layer (SONET/SDH/FR - Layer 1, ATM - Layer 2, and IP - Layer 3) somewhere in any IETF document and also defining the correlation between the layers then these *logical* links cannot be bundled into one link for all the layers (ITU G805 clearly specify how to handle layered networks). So, if any IETF document that specifies multiple layers correlation and have such statement like all links can be bundled into one link between routers should be addressed and corrected. Does anybody know such document(s)? Regards, Anuj Kireeti Kompella on 05/02/2001 02:17:28 PM To: mpls@UU.NET cc: (bcc: Anuj Bhatnagar/Telcordia) Subject: Re: Question about logical link in Link bundling Hi Tom, > Perhaps the text be clarified to explicitly include > logical links? I understood the text to read that both physical > and logical links were allowed. Two points: 1) Terminology: calling a T1 in a channelized T3, or an STS-3c in an OC-48 a *logical* link will confuse lots of folks. 2) From a routing point of view, there is entirely no difference between an STS-3c in an OC-48, and a "standalone" STS-3c/OC-3c. So, while I'm not opposed to making the above "clarification", it seems unnecessary; moreover, there are plenty of other documents that would then need this same "clarification". Kireeti. From owner-mpls@UU.NET Wed May 2 18:22:42 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25283 for ; Wed, 2 May 2001 18:22:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknif00353; Wed, 2 May 2001 22:20:51 GMT Received: by mail-control.mail.uu.net id QQknif05537 for mpls-outgoing; Wed, 2 May 2001 22:19:32 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknif05517 for ; Wed, 2 May 2001 22:19:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknif10531 for ; Wed, 2 May 2001 22:17:57 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQknif27021 for ; Wed, 2 May 2001 22:17:56 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id PAA29075; Wed, 2 May 2001 15:17:55 -0700 (PDT) Message-ID: <3AF08792.4A56B50F@pluris.com> Date: Wed, 02 May 2001 15:17:54 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Charlap CC: mpls@UU.NET Subject: Re: FEC next hop when FEC has multiple elements References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi David, I am delighted to see we are thinking along the same lines. I agree with your opinion of what ought to happen, but I feel that the spec, while *unclear* is actually also unambiguous (and the spec also, largely, agrees with what you think should happen). I think that a strict reading of the LDP spec gives your basic interpretation (in the case of conservative label retention the label is released, but in the case of liberal retention, I do not think that anything in particular is required of the receiver of the 'bad' FEC in terms of notifying the sender). The 'strict' reading depends on an interpretation of what a 'next hop' is for an FEC with multiple FEC elements: That is: the next hop for FEC F1 will be the same as for FEC F2 if they each represent the same 'packet set'. An FEC identifies the set of IP packets which may be mapped to the LSP associated with the FEC. Suppose that the set of packets that F1 maps to its LSP is the same set of packets that F2 maps to the same LSP. I submit that the two FECs are 'equal'. In particular, that their next hop on a given router always resolves to the same value. Now, I am hoping everyone is sort of twitching their fingers towards the delete button thinking 'that's obvious' or 'that's circular' Hold on: Let F1 = { 1.1.1.0/24} (The set of FEC elements consisting of the single prefix 1.1.1.x) Let F2 = {1.1.1.0, 1.1.1.1, 1.1.1.2,....,1.1.1.255} (The set of 256 FEC elements that enumerate every possible address in 1.1.1.x) Now, obviously, these two are "equal" FECs, in terms of the set of packets that get mapped to the LSP. Now, suppose LSR "N" receives a label mapping from LSR "E": Also, suppose that the next hop for 1.1.1.0 is "E", but the next hop for every other element is "Q". As I understand it, this means that 'obviously' the next hop for 1.1.1.0/24 is a NOROUTE. Thus, by *definition*, on "E", the next hop for F2 is NOROUTE as well. But some of my imaginary friends have intimated that "N" should advertise F3 = {1.1.1.0} to its peers. (In fact, I think this is not a bad intent, but it seems contrary to the LDP spec) CLK David Charlap wrote: > Shahram Davari wrote: > > > > All FEC elements in an FEC-TLV, must have the same next hop. > > This is obvious, but I think the question is a little more involved than > this. > > It is possible for a router to see a single next-hop for two different > prefixes, but its upstream router may see these prefixes as having two > different next-hops. (I have worked out some topologies where this is > true, but they don't easily lend themselves to ASCII-art.) > > The downstream router decides to aggregate the prefixes into a single > FEC and sends out a label mapping. As far as the downstream router is > concerned, this is fine - if it receives packets for either prefix, it > will handle them identically. > > The upstream router, upon receiving this label mapping realizes that the > sender is only next-hop for one of the prefixes, but someone else is a > closer next-hop for the other. > > The question is what it should do with this. > > IMO, the upstream router should reject the FEC (send back a label > release). The FEC is malformed from its point of view, because the > prefixes don't all share a common next-hop. > > Upon receiving the label release, the downstream router should realize > that the aggregation is improper, and should then send out two separate > mappings - one for each prefix. The upstream router can then use one, > and either reject or hold on to the other (depending on the label > retention mode.) > > Appendix A, however, is silent on what should happen in this situation. > > -- David From owner-mpls@UU.NET Wed May 2 18:40:07 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25540 for ; Wed, 2 May 2001 18:40:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknig20125; Wed, 2 May 2001 22:38:21 GMT Received: by mail-control.mail.uu.net id QQknig07310 for mpls-outgoing; Wed, 2 May 2001 22:37:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknig07296 for ; Wed, 2 May 2001 22:37:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknig06674 for ; Wed, 2 May 2001 22:37:25 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknig18619 for ; Wed, 2 May 2001 22:37:25 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA29746 for ; Wed, 2 May 2001 18:37:22 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA06413 for ; Wed, 2 May 2001 18:37:24 -0400 (EDT) Message-ID: <3AF08C24.86F44B07@marconi.com> Date: Wed, 02 May 2001 18:37:24 -0400 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: FEC next hop when FEC has multiple elements References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Chris Kuszmaul wrote: > Let F1 = { 1.1.1.0/24} (The set of FEC elements consisting of the single > prefix 1.1.1.x) > Let F2 = {1.1.1.0, 1.1.1.1, 1.1.1.2,....,1.1.1.255} (The set of 256 FEC > elements that enumerate every possible address in 1.1.1.x) > > Now, obviously, these two are "equal" FECs, in terms of the set of packets > that get mapped to the LSP. Um, this may be intuitively "obvious" to some, but it's not really correct according to section 2.1 of RFC 3036 :-) Let there be a third FEC in the picture: F3 = { 1.1.1.16/28 } Assume that the next hop for the entire 1.1.1.0/24 range is router R2. If R2 sends me these label mappings: F1 -> Label A F3 -> Label C then I forward anything in the F3 range using Label C, and the rest of the 1.1.1.x range using Label A. On the other hand, if R2 sends me these label mappings: F2 -> Label B F3 -> Label C then I forward anything in the 1.1.1.x range using Label B. This is because section 2.1 of the RFC calls for using the longest prefix match. 1.1.1.16/28 is favored over 1.1.1.0/24, but 1.1.1.16/32 beats them both. Jack From owner-mpls@UU.NET Wed May 2 19:36:16 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26381 for ; Wed, 2 May 2001 19:36:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknik23590; Wed, 2 May 2001 23:34:26 GMT Received: by mail-control.mail.uu.net id QQknik00957 for mpls-outgoing; Wed, 2 May 2001 23:33:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknik00946 for ; Wed, 2 May 2001 23:33:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknik20565 for ; Wed, 2 May 2001 23:32:21 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQknik14274 for ; Wed, 2 May 2001 23:32:20 GMT Received: from pluris.com (do101085.pluris.com [172.16.55.241]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id QAA01302; Wed, 2 May 2001 16:32:18 -0700 (PDT) Message-ID: <3AF09902.5835EC72@pluris.com> Date: Wed, 02 May 2001 16:32:18 -0700 From: Chris Kuszmaul Organization: Pluris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jack Brennen CC: mpls@UU.NET Subject: Re: FEC next hop when FEC has multiple elements References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C0D@BBY1EXM01> <3AF06AB7.81EE10AB@marconi.com> <3AF08792.4A56B50F@pluris.com> <3AF08C24.86F44B07@marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Jack, I overlooked that point. But I do not think it alters the conclusion about what the next hop should be for an FEC with multiple elements. F1 and F2 (below) are not fully equal, in the sense of 'substitution' in the presence of competition. Indeed, they are not equal when in the presence of one another, since F2 would get all the packets. In fact, there is a whole raft of senses in which they are not equal. However in the sense defined in, oh, say section 2.1 of RFC 3036 (;-)) they *are* equal: "The FEC defines the set of IP packets which may be mapped to that LSP." The FECs both represent the exact same set of packets that *may* be injected into the LSP associated with the FEC.That is, if you take the largest possible set of packets that could be injected into each (among all possible configurations of other FECs), then you get the same largest possible set for each. In such a situation, the next hop calculation for each FEC must be the same. Since the next hop calculation for an FEC ought not change as a function of the presence of other competing FECs, this means that in all circumstances F1 and F2 must have the same next hop. But, I was indeed wrong when I said (without qualification) that the same set of packets get mapped to the LSP (for F1 and F2). I owe you a (small) chocolate mint. CLK Jack Brennen wrote: > Chris Kuszmaul wrote: > > > Let F1 = { 1.1.1.0/24} (The set of FEC elements consisting of the single > > prefix 1.1.1.x) > > Let F2 = {1.1.1.0, 1.1.1.1, 1.1.1.2,....,1.1.1.255} (The set of 256 FEC > > elements that enumerate every possible address in 1.1.1.x) > > > > Now, obviously, these two are "equal" FECs, in terms of the set of packets > > that get mapped to the LSP. > > Um, this may be intuitively "obvious" to some, but it's not really > correct > according to section 2.1 of RFC 3036 :-) > > Let there be a third FEC in the picture: F3 = { 1.1.1.16/28 } > > Assume that the next hop for the entire 1.1.1.0/24 range is router R2. > > If R2 sends me these label mappings: > > F1 -> Label A > F3 -> Label C > > then I forward anything in the F3 range using Label C, and the rest of > the > 1.1.1.x range using Label A. > > On the other hand, if R2 sends me these label mappings: > > F2 -> Label B > F3 -> Label C > > then I forward anything in the 1.1.1.x range using Label B. > > This is because section 2.1 of the RFC calls for using the longest > prefix match. 1.1.1.16/28 is favored over 1.1.1.0/24, but > 1.1.1.16/32 beats them both. > > Jack From owner-mpls@UU.NET Thu May 3 01:16:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03640 for ; Thu, 3 May 2001 01:16:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknjg12805; Thu, 3 May 2001 05:14:41 GMT Received: by mail-control.mail.uu.net id QQknjg20908 for mpls-outgoing; Thu, 3 May 2001 05:14:09 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknjg20897 for ; Thu, 3 May 2001 05:14:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknjg21092 for ; Thu, 3 May 2001 05:13:53 GMT Received: from sktelecom.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.236.1.20]) id QQknjg23011 for ; Thu, 3 May 2001 05:13:46 GMT Received: from mrchang (localhost [127.0.0.1]) by sktelecom.com (8.10.1/8.10.1) with SMTP id f435HBL19441; Thu, 3 May 2001 14:17:12 +0900 (KST) Message-ID: <010301c0d38f$7b94b060$77131796@sktelecom.com> From: "Rae M. Chang" To: "David Charlap" Cc: References: <008b01c0d29f$c8501b60$77131796@sktelecom.com> <3AF014AF.BFEE065B@marconi.com> Subject: Re: A fundamental question Date: Thu, 3 May 2001 14:11:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id BAA03640 David, > MPLS avoids the N^2 problem in two ways: > 1: The LSPs follow the routing protocols' shortest-paths. Meaning > you don't necessarily need an LSP to get from everywhere to > everywhere. Only along the shortest routed paths. That's the point I can't understand yet. For example, if you want a partial meshed network consisting of a set of LSPs, then why couldn't you make the same network with only neccessary ATM VCs (not using MPLS)? Aren't they essentially equivalent TE schemes? Why do they make the N^2 number of VCs? Rae ----- Original Message ----- From: "David Charlap" To: Sent: Wednesday, May 02, 2001 11:07 PM Subject: Re: A fundamental question > "Rae M. Chang" wrote: > > > > I have a fundamental doutb on MPLS traffic engineering. > > (pls take it account my poor understanding on ATM routing stuffs.) > > What I can't figure it out is if a user part connected to the ATM > > network can dynamically setup a SVC to the other user part. Can the > > UNI and PNNI stuffs be used to set up it? > > No. ATM signaling and MPLS signaling are two different things. One is > not used to setup the other. > > An ATM switch acting as LSR (a transit router) will ultimately have the > same kind of cell-forwarding installed on its fabric with each protocol, > but that's where the similarities end. > > An ATM switch acting as LER (an edge router) has different semantics on > the data plane. On ingress, it must apply labels to incoming unlabeled > traffic (or push labels if one LSP is being tunneled through another.) > On egress, it must be able to pop labels and make forwarding decisions > based on the result. > > > If that's true, what're the differences with the LSP setup across > > ATM network using another signaling mechanism, or MPLS? > > Why don't they use existing ATM signalling methods to achieve the > > traffic engineering of MPLS? > > ATM's routing and signaling protocols are closely tied to ATM's > addressing architecture. These protocols are not based on IP, and they > do not scale up to networks the size of the internet. Finally, ATM only > works on ATM interfaces - it doesn't work over PPP, Frame Relay, > Ethernet, or other types of interfaces that are commonly found in > networks. > > MPLS is intended to solve these problems. The routing protocols are > well-established IP protocols (OSPF, IS-IS, BGP). The signaling > protocols are designed around IP. And MPLS works over all IP- > compatible interfaces. Routers of all kinds (ATM, Frame, IP, etc.) can > interoperate in a single MPLS cloud. > > > (i know of the ATM's N square complexity issue with PVC setup on the > > IP over ATM model. but, in my thought, you can just setup necessary > > VCs on-demand basis like MPLS TE) > > On-demand setup works fine in an enterprise network. It doesn't work in > a core network. When you've got hundreds of GB/s of data flowing > through a network, the delays needed to dynamically allocate new VCs (or > LSPs) will almost certainly be unacceptible. > > MPLS avoids the N^2 problem in two ways: > > 1: The LSPs follow the routing protocols' shortest-paths. Meaning > you don't necessarily need an LSP to get from everywhere to > everywhere. Only along the shortest routed paths. > > 2: Routers that support label merging can greatly reduce the amount > of resources required. Two LSPs arriving at a single transit > router, that are intended to terminate at the same egress router > may be merged (assuming there are no QoS concerns, of course.), > eliminating the need for the second LSP if the downstream rouers. > > -- David > From owner-mpls@UU.NET Thu May 3 01:53:47 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08534 for ; Thu, 3 May 2001 01:53:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknjj23561; Thu, 3 May 2001 05:51:43 GMT Received: by mail-control.mail.uu.net id QQknjj24043 for mpls-outgoing; Thu, 3 May 2001 05:51:06 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknjj23981 for ; Thu, 3 May 2001 05:50:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknjj03977 for ; Thu, 3 May 2001 05:49:56 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQknjj19655 for ; Thu, 3 May 2001 05:49:54 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 03 May 2001 11:25:01 +0530 Received: from srikn (srikn.future.futsoft.com [10.20.6.48]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f435n1w28045 for ; Thu, 3 May 2001 11:19:02 +0530 Received: by localhost with Microsoft MAPI; Thu, 3 May 2001 11:20:18 +0530 Message-Id: <01C0D3C3.08AFDB40.srikn@future.futsoft.com> From: Srikn Reply-To: "srikn@future.futsoft.com" To: "'mpls@uu.net'" Subject: Doubt in mpls-generalized-signaling Date: Thu, 3 May 2001 11:20:17 +0530 Organization: FSL X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have few doubts in mpls-generalized-signaling draft. 1.) In the newer version of mpls-generalized-signaling draft, "Generalized Label Request with SONET/SDH Label Range" (from the earlier version of mpls-generalized-signaling (02) draft), is moved to a new draft. Can someone give me a pointer to this new draft? 2.) How does an ingress decide about the nature of LSP to be requested (whether unidirectional or Bidirectional)? Is there any mib object for this or is it by default Bidirectional if supportable. Thanks in advance, Srikanth Narayanan. From owner-mpls@UU.NET Thu May 3 06:28:07 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18160 for ; Thu, 3 May 2001 06:28:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkb02604; Thu, 3 May 2001 10:25:07 GMT Received: by mail-control.mail.uu.net id QQknkb19718 for mpls-outgoing; Thu, 3 May 2001 10:24:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknkb19710 for ; Thu, 3 May 2001 10:24:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknkb19121 for ; Thu, 3 May 2001 10:24:03 GMT Received: from sanmiguel.telindus.es by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.201.14.242]) id QQknkb01296 for ; Thu, 3 May 2001 10:23:39 GMT Received: by sanmiguel.madrid.telindus.es with Internet Mail Service (5.5.2448.0) id ; Thu, 3 May 2001 12:22:32 +0200 Message-ID: From: Javier Antich To: mpls@UU.NET, mpls-ops@mplsrc.com Subject: RFC 2547 MPLS VPN Interop Test. Cisco - Juniper. Date: Thu, 3 May 2001 12:22:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D3BA.F6C35C70" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0D3BA.F6C35C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 Fore those interested, we have been doing some tests with the just published code JUNOS 4.4 with MPLS VPNs. MPLS VPNs, as far as we have = tested interoperate between Cisco and Juniper. For more details see the = attached pdf. Hope this helps someone. Regards. Javier. <>=20 ^ ^ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo=3D=3D=3D=3D(.)v(.)=3D=3D=3D= =3Dooo=3D=3D=3D=3D=3D Javier Antich Romaguera Network Consultant ------------------------------------------------------------------------= --- TELINDUS=20 Pza. Ciudad de Viena, 6-2=BA 28040 Madrid=20 ------------------------------------------------------------------------= --- javier.antich@telindus.es tel: +34 91 456 00 08 fax: +34 91 536 10 74 ------------------------------------------------------------------------= --- For more information about our products and services, please visit our website http://www.telindus.com ------------------------------------------------------------------------= --- Full connectivity & mobility =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dooo0=3D=3D=3D0ooo=3D= =3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_000_01C0D3BA.F6C35C70 Content-Type: application/octet-stream; name="RFC 2547 MPLS VPN Interoperability Test Cisco-Juniper.pdf" Content-Disposition: attachment; filename="RFC 2547 MPLS VPN Interoperability Test Cisco-Juniper.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjg5OSAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gOTAyIA0vSCBb IDkyOCA1NjMgXSANL0wgMjMyNjA1IA0vRSAxNjQzOSANL04gMzggDS9UIDIxNDUwNiANPj4gDWVu ZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTg5OSAxOCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwNzI5IDAwMDAwIG4NCjAw MDAwMDA3ODYgMDAwMDAgbg0KMDAwMDAwMTQ5MSAwMDAwMCBuDQowMDAwMDAxNzI4IDAwMDAwIG4N CjAwMDAwMDE3NjcgMDAwMDAgbg0KMDAwMDAwMTc4OSAwMDAwMCBuDQowMDAwMDAyMzQ0IDAwMDAw IG4NCjAwMDAwMDIzNjUgMDAwMDAgbg0KMDAwMDAwMzQ2MCAwMDAwMCBuDQowMDAwMDAzNzMyIDAw MDAwIG4NCjAwMDAwMDM4MjMgMDAwMDAgbg0KMDAwMDAwNDkyMSAwMDAwMCBuDQowMDAwMDA1MjAz IDAwMDAwIG4NCjAwMDAwMDUyNDUgMDAwMDAgbg0KMDAwMDAwNTI2OSAwMDAwMCBuDQowMDAwMDAw OTI4IDAwMDAwIG4NCjAwMDAwMDE0NjkgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSA5MTcNL0lu Zm8gODg4IDAgUiANL0VuY3J5cHQgOTAxIDAgUiANL1Jvb3QgOTAwIDAgUiANL1ByZXYgMjE0NDk1 IA0vSURbPDBhMDE1M2ZjZTdhNzU0ZDAyMzIxNTNkMmE2MzUyYTAyPjwwYTAxNTNmY2U3YTc1NGQw MjMyMTUzZDJhNjM1MmEwMj5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICANOTAwIDAgb2JqDTw8 IA0vUGFnZXMgODk4IDAgUiANL1R5cGUgL0NhdGFsb2cgDT4+IA1lbmRvYmoNOTAxIDAgb2JqDTw8 IA0vRmlsdGVyIC9TdGFuZGFyZCANL1YgMSANL1IgMiANL08gKA/F0fxzENnC3MihuJ3vIaeEpXKq NyQ0Fzek3YTp/32JKQ0vVSAoot3/G9DhLiCDAk5UnO9sIBZxWSROpriq1qHQ71JsL34pDS9QIDY1 NDc2IA0+PiANZW5kb2JqDTkxNSAwIG9iag08PCAvUyA3MjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCA5MTYgMCBSID4+IA1zdHJlYW0NCgNKai+lYolAcqb6guimN/6ur49/Z8L3uYQTV5HO MKvRd/oAmVeYnr9m0sem94AOsXWPl3a89T50CETL9e8iixJbyZxrP0higqipcVN611FGeh9nLzBp PXBxyrVOdv8e2yGnysZpXtES3G0JeBObdSWGZ7T2JV7o/E9B/PuSC/GpRdXZfx/wu7j7m8pIsOWf CpAGxEUUpugo2F+sGBCqAc0bgkJAj40DJcXVfU74UUeq6oWwZwm56v0OnQrGjPWPWQtdJEpsYepv LvMlGaVY4PiY5InjarLsC44NKw5r8FUPfXB9ZpilpGwtHsCAMSUc+UWuD/EtSbHcjUOOKmYrRFUk SVxOeuY26FRiG2L9SS8UTJcqiwL7A6gZVMvRlC9A6uZ0IzaWMnLnnzrADi7M/wlETe/FmCe5V0Wu Mxy4cGe61m3UPCDM9rYjnfz4KtmvldMpySWPnS1vGEQra8MoAen9AxTExWHqMEU1VxYIv7OidFwm HUo+2UeETdnLzuz+SEl4KOD9yzhaV9zyg9VHqHTkAQBqy4GvEeO+gtqiXpDyK5mHUMR3spPj5POl t7rlzXra2jl0VZshqZjJcX/S/2J6jwZ5whMNZW5kc3RyZWFtDWVuZG9iag05MTYgMCBvYmoNNDU0 IA1lbmRvYmoNOTAyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4ODkgMCBSIA0vUmVz b3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAgMCBSID4+IC9YT2JqZWN0IDw8 IC9pbTEgOTE0IDAgUiA+PiAvUHJvY1NldCA5MTIgMCBSID4+IA0vQ29udGVudHMgOTAzIDAgUiAN L01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90 YXRlIDAgDT4+IA1lbmRvYmoNOTAzIDAgb2JqDVsgDTkwNSAwIFIgOTA5IDAgUiANXQ1lbmRvYmoN OTA0IDAgb2JqDTQ3NSANZW5kb2JqDTkwNSAwIG9iag08PCAvTGVuZ3RoIDkwNCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KdAWTe8pZ4OSa+O4lvZ+eHYyp8dcwra194lQHkH9f hsJSsVOi5Tgb/hmE4xIOULkaMVgsWTeluHsNlIBz/QHLHZjXt8W5y2eInE+19UTGkBsk5P9DrkWE RqOmELAddJbcpAVINfDyLAYqsw8cQDIf7eor1oIh7pH2xAkxTiRpTWIrFtjjgfUZeKpUNXzWpuQY i3TMpw+cPJd5p/fI3XS0QUYNlIo4OTOdMH0Q2iFBgGgw3ObLopBD/J97y5VP8YS3F9TsnqA3ukD0 rhsGkLOucvbuKqLaqkTC3YKTpt9Ib4VoZlXfhFsYUFtJdcW9L59kgehFhHBTe0HwvPMligy2yFVK QjBmJ7SDKoRADEFk3oMH05dWPewLAl6c5OpACh5qG8yRHBpSBH5B7I/W9Fw+DxXc++aCEY4paotP XP2FbPexZdgHEVL7KIi7ivVcb+MRtyYbqT7DJ42QhDheKUa4EoW/ubmQ6reNsiPOyisiHZ5s9tKs J6T3c2hslcWPFHfpxVSJjYBaXjkDHQu+f98gh83dCF4fpb2RBU+1WIj2czTwHTjXkkPNyzOVsYEp e552SMZwLPXFcsuJJh4UZ3M1chlczCmxFjJ2aUOr5hDPAZ2nIcodb5zM2+No8A1lbmRzdHJlYW0N ZW5kb2JqDTkwNiAwIG9iag0xMSANZW5kb2JqDTkwNyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9T dWJ0eXBlIC9UcnVlVHlwZSANL05hbWUgL0YwIA0vQmFzZUZvbnQgL0FyaWFsIA0vRmlyc3RDaGFy IDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjc1IDMyNyAzNjIgNTUxIDU1MSA4OTYgNjcy IDE4OSAzMjcgMzI3IDM5NiA1ODYgMjc1IDMyNyAyNzUgMjc1IDU1MSANNTUxIDU1MSA1NTEgNTUx IDU1MSA1NTEgNTUxIDU1MSA1NTEgMjc1IDI3NSA1ODYgNTg2IDU4NiA1NTEgMTAxNyANNjcyIDY3 MiA3MjQgNzI0IDY3MiA2MDMgNzc1IDcyNCAyNTggNTAwIDY3MiA1NTEgODEwIDcyNCA3NzUgNjcy IA03NzUgNzI0IDY3MiA2MjAgNzI0IDY3MiAxMDAwIDYzNyA2NTUgNjAzIDI3NSAyNzUgMjc1IDQx MyA1NTEgMzI3IA01NTEgNTUxIDUwMCA1NTEgNTUxIDI3NSA1NTEgNTUxIDIyNCAyMjQgNTE3IDIy NCA4NDQgNTUxIDU1MSA1NTEgDTU1MSAzMjcgNTAwIDI3NSA1NTEgNTAwIDcwNiA0ODIgNDY1IDQ4 MiAzMjcgMjQxIDMyNyA1ODYgNzU4IDU4NiANNzU4IDU4NiA1ODYgNTg2IDU4NiA1ODYgNTg2IDU4 NiA1ODYgNTg2IDU4NiA1ODYgNzU4IDU4NiA3NTggNzU4IA01ODYgNTg2IDU4NiA1ODYgNTg2IDU4 NiA1ODYgNTg2IDU4NiA1ODYgNTg2IDU4NiA3NTggNTg2IDU4NiAyNzUgDTMyNyA1NTEgNTUxIDU1 MSA1NTEgMjQxIDU1MSAzMjcgNzQxIDM2MiA1NTEgNTg2IDMyNyA3NDEgNTUxIDM5NiANNTUxIDMy NyAzMjcgMzI3IDU2OCA1MzQgMjc1IDMyNyAzMjcgMzYyIDU1MSA4MjcgODI3IDgyNyA2MDMgNjcy IA02NzIgNjcyIDY3MiA2NzIgNjcyIDEwMDAgNzI0IDY3MiA2NzIgNjcyIDY3MiAyNTggMjU4IDI1 OCAyNTggNzI0IA03MjQgNzc1IDc3NSA3NzUgNzc1IDc3NSA1ODYgNzc1IDcyNCA3MjQgNzI0IDcy NCA2NTUgNjcyIDYwMyA1NTEgDTU1MSA1NTEgNTUxIDU1MSA1NTEgODk2IDUwMCA1NTEgNTUxIDU1 MSA1NTEgMjU4IDI1OCAyNTggMjU4IDU1MSANNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEgNTUxIDYw MyA1NTEgNTUxIDU1MSA1NTEgNDY1IDU1MSA0NjUgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcgDS9Gb250RGVzY3JpcHRvciA5MDggMCBSIA0+PiANZW5kb2JqDTkwOCAwIG9iag08PCANL1R5 cGUgL0ZvbnREZXNjcmlwdG9yIA0vRm9udE5hbWUgL0FyaWFsIA0vRmxhZ3MgMzIgDS9Gb250QkJv eCBbIC0yNTAgLTIxMiAxMjIwIDEwNTUgXSANL01pc3NpbmdXaWR0aCAyNzYgDS9TdGVtViA4MCAN L1N0ZW1IIDgwIA0vSXRhbGljQW5nbGUgMCANL0NhcEhlaWdodCA5MDUgDS9YSGVpZ2h0IDQ1MyAN L0FzY2VudCA5MDUgDS9EZXNjZW50IC0yMTIgDS9MZWFkaW5nIDE1MCANL01heFdpZHRoIDEwMTcg DS9BdmdXaWR0aCA0NDEgDT4+IA1lbmRvYmoNOTA5IDAgb2JqDTw8IC9MZW5ndGggOTA2IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoRkeJOKy3qCoTRgQ1lbmRzdHJlYW0NZW5k b2JqDTkxMCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL05hbWUg L0YxIA0vQmFzZUZvbnQgL0FyaWFsLEJvbGQgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUg DS9XaWR0aHMgWyAyODAgMzIwIDQ3MCA1NjAgNTYwIDg4MCA3MjAgMjQwIDMzMCAzMzAgMzkwIDU4 MCAyODAgMzMwIDI4MCAyODAgNTYwIA01NjAgNTYwIDU2MCA1NjAgNTYwIDU2MCA1NjAgNTYwIDU2 MCAzNDAgMzQwIDU4MCA1ODAgNTgwIDYxMCA5ODAgDTY5MCA3MjAgNzIwIDcyMCA2NzAgNjEwIDc4 MCA3MjAgMjgwIDU2MCA3MjAgNjEwIDgzMCA3MjAgNzgwIDY3MCANNzgwIDcyMCA2NzAgNjEwIDcy MCA2NzAgOTUwIDY3MCA2NjAgNjEwIDMzMCAyODAgMzMwIDU4MCA1NjAgMzMwIA01NjAgNjEwIDU2 MCA2MTAgNTYwIDMzMCA2MTAgNjEwIDI4MCAyNzAgNTYwIDI4MCA4OTAgNjEwIDYxMCA2MTAgDTYx MCAzOTAgNTYwIDMzMCA2MTAgNTQwIDgwMCA1NjAgNTMwIDUwMCAzOTAgMjgwIDM5MCA1ODAgNzUw IDU4MCANNzUwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNzUw IDU4MCA3NTAgNzUwIA01ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgwIDU4MCA1ODAgNTgw IDU4MCA3NTAgNTgwIDU4MCAyODAgDTM0MCA1NjAgNTYwIDU2MCA1NjAgMjgwIDU2MCAzMzAgNzQw IDM3MCA1NjAgNTgwIDMzMCA3NDAgNTUwIDQwMCANNTUwIDMzMCAzMzAgMzMwIDU4MCA1NjAgMjgw IDMyMCAzMzAgMzcwIDU2MCA4MzAgODMwIDgzMCA2MTAgNjkwIA02OTAgNjkwIDY5MCA2OTAgNjkw IDEwMDAgNzIwIDY3MCA2NzAgNjcwIDY3MCAyODAgMjgwIDI4MCAyODAgNzIwIA03MjAgNzgwIDc4 MCA3ODAgNzgwIDc4MCA1ODAgNzgwIDcyMCA3MjAgNzIwIDcyMCA2NjAgNjcwIDYxMCA1NjAgDTU2 MCA1NjAgNTYwIDU2MCA1NjAgODkwIDU2MCA1NjAgNTYwIDU2MCA1NjAgMjgwIDI4MCAyODAgMjgw IDYxMCANNjEwIDYxMCA2MTAgNjEwIDYxMCA2MTAgNTUwIDYxMCA2MTAgNjEwIDYxMCA2MTAgNTMw IDYxMCA1MzAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9Gb250RGVzY3JpcHRvciA5 MTEgMCBSIA0+PiANZW5kb2JqDTkxMSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0v Rm9udE5hbWUgL0FyaWFsLEJvbGQgDS9GbGFncyAxNjQxNiANL0ZvbnRCQm94IFsgLTI1MCAtMjEy IDEyMDAgMTA1NSBdIA0vTWlzc2luZ1dpZHRoIDMzMCANL1N0ZW1WIDE1MyANL1N0ZW1IIDE1MyAN L0l0YWxpY0FuZ2xlIDAgDS9DYXBIZWlnaHQgOTA1IA0vWEhlaWdodCA0NTMgDS9Bc2NlbnQgOTA1 IA0vRGVzY2VudCAtMjEyIA0vTGVhZGluZyAxNTAgDS9NYXhXaWR0aCAxMDAwIA0vQXZnV2lkdGgg NDc5IA0+PiANZW5kb2JqDTkxMiAwIG9iag1bIA0vUERGIC9UZXh0IC9JbWFnZUMgDV0NZW5kb2Jq DTkxMyAwIG9iag0xMDc1MSANZW5kb2JqDTkxNCAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL05hbWUgL2ltMSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDQxMyANL0hl aWdodCA2OCAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0 aCA5MTMgMCBSID4+IA1zdHJlYW0NComp5mfpNTzVP4NpunRvbFeHa6h7lZdh27Z01jgGMuHtdUoV ncy9thRYEDToJal3aERU+thRRn+BVOsuuSAWwaA/Kcv2ZSsEpt71imKQtl5Efia2fu8V+N+dppTF 6+O3EIE6DW40yTkU0LKaCYQzBlDx5UxbuhjmA46JOlbdsuqARlUrs5IV5K5rXOi9mJonBadJ1sBB FsE1AjvKwY8IVRzt1Bx4zeTrMksBRWe1QvL6HjstLJ7nAss53Oz+ekj0Bu9rLEaqEYB7NN+7lj8t Wriwh+Nh78dwX4mrXRa6vQ95W3MSFcgu8dIE+RGbGV1aQpcGcpStaXFmW02C+NQbt33fv1v4txDU avDFOIZ4tRZP7Ff9AZrfrJQQUTykeZySsLtyrK479SR1lxqHAH8tGZNLwqgs4chzAAAkGmlEpnCN oxAkpUEWE+iH7KX4AxltN18iJave5Nyn9wj76QJSgyJnalLrdQXlZMVeRHyIXv0j+41Xn/gmLsBt 1RlqIkqXJY3CO1hgsI8/kyNmRoQB7FC2lzIz1jAO+iV0VdXXvOB8LMxAWMekzSn3IrcvLEnbrgaX hkS+Hq+aPKdk6HT+7yQBJ2yqFC/2ehgjXvRBdDDMsgNiaZYXNO84fMT9PwKkU091mBMNThwCDZXt 9Ch+9p7PDAqGL3dpx+i7/GTIsAx04kPuOlX5V/jTtbDbafXJzdkVG12KLxWJpIgiJUpRUK4dCjbQ QYtvkk7VEf5MapaRBecfls4nhsB0RxI+ehPp+0wsFzrOhLLZ0be/oMaLmTTcVW8uXi3IfdNuIrvT udT9tS76zrvCuubLhrZUzfc2whC+3et4caVjlsyVZk5o0q57m7G6UsOD9TQP0za57Kb95+CK1Xiq 0J9QqI6Bg+3Rv2pIXRcf40bnlE7QcYMr8viPUoJud2UMTkL/M7ZabJKGKX4LlOJM+e2h319cdtr7 /Hz+y3bCWO7G7TDdU2XQZxeOygvb6ANqNdvWSkOVpWm+9FA/egGnz6UNY2tkoyr6uLtF8+K4cUcS 6hUo1x1sl96CSikSvINlzJPoBZG8q32uxz9CeyCJscPob9+v5TF6Ua/AS3axApFVoQLr8fDchiVp N/LHbLMDCL3IB8KmJ52Q4SUawPCKCjMR+cZ6zksXHsL5uCVOh+mehkVzP7RNEqDV7ICU8uT1fyPF iRvm30Lg7xOG2bpCRIdsaILG0u7Y8JUJe+4UcMWWloHKI3kNlmXMna9Oi/FfomZ5KiuI60kVcenY XZefGP1t6yBPsK8XA2adMocbjaXwmD3kpexBE5LIIDu+16ttmH5Ap5FPNljUpcTvYXPaBBPhl9O0 7sEyyhZ2zY1cHnyP6uCMdx5A+5HTh6KXeIKO/TVL9ovVgIrf94qbwNE+PI05FuZJUTeYfvq4S+EM 3PHWpvRyF8SxSGil6BI3O8w+EioH3fXkIUzsHqr9Tgx/7pIPNQa/74qRZGJwd2yHr46oZX77cgTl CHmneJql6XLo+FyZM+cb7tPeWKvmdmpYxZT7uOnrrb8eQqHaScO9NuTVApRWAMap8z6Rae5s9reI v75Ix38QSr0NE/wgdFEBhGxlVXywdt4qz03WRc6zxwS5C3K3FfoijGFOBNSAS65xBzW8xK1uPWG5 Bl5kL4NDoMMzYpTNQR+aPF2SaAzB+E99Q9IFvFnWSZXydUQ81XRIKBJJXvF3t/JQ7lKesfzRUW/y 0B1dna/r8Bjvpptj2ESFXPGzGNhBKu/54UGQ1U+IjPkKX7EjwACJwh6+7fW6YK8ZoLCamgolmUyj Q94FCBI6GGXLawvuxY1lJ+dMJSdnSkOjtwxSh0b5t0P7dr5gxdinzhV6Jt91Up67WGKI7tr4Gx7X qmnGtIvhdZED9mw05yAnUMxZT40nf1CO7hVE6/oRJpPUyOT0drnTrbimFZCjh1HnII4xR03klpgU 64d/IE+iH5OUkXNM2PHbQtQ/eA7kRD9rZZguryrk81xv5KOjBuBrfznPzOll5FM2a95OQ6kctmWO FHHocstWKLfKfv4VK5j18FtvATIsiCiGG+LcgGpwcO81I2rdiSXmkcG1h829tdoxzqq+4aHiMZ2D kqyMyBzpZOVTILGw+fPNZe4t7DP87OEnzlEo9ndmE3Eq8sbkCzM4kP+VlIDqlwsBU/k0BaKva0Mj sEKqk4FcMN9bNlCboJJovTNfyrlZwfnqn4JrP0hTo0crzZ429Xp0Ym/JnnO2nYoKz+NTDLa8t6vy QJ6VyZbsSH1MVFv0Lgb0H9g22THwrizgUldr766aXEJVASSebb1Iu8MHiqXBeyRytamrJNyhMjTP LUOSyp8xtCUyAc8BtV8Oy2AJ8ZuxkpVFtS3Ovx3Z3GybSEMuBdlSWau3BMepWfUth/7UNzbGk2uE ZJy+68/o1aQcTwvNCVIBCcAQ65a6jtxs5r37X5s2CIj2EuiKGSoSgTteQPuAFWKkBygosezKEckT STfPb8yPu7qGo+9mbswDfqeekPaaPkjHew0VpelbM/L7iZlUgmQ/FKIx8b2vA0m/xkImSDg2TBOY S5lkg+s4NSbPDOF0S9inbnhxQFwVvMogDQEqNUl60JUTJ+iSWpc8qDrQPMQRRoXqEN+OsIpynwb2 392plTwiLkQyLpCs0GQGU0KeMZPbxc+Y2T9WpagUoCTCB9bTDMaXogbJSDXwyfH58hY/jPHCqV0b k/vzwRpqhFjvFFMkfbOdDyQ/mxgiValP8GIt590sHAwJG/eLnrEh+frKh0G3Vw59kGBHI8l+9jkV sgPQF/bkYnJMAH2AKTSZbDQnrNpZDCRVitR9d6EuZgYLjeFca7+awoVurGyeZtfwUKO2Ez6qap9k /KejMRacK8BDHPDyVbDrM7X9ASBXIy2p9c88DrQDrB3iAx45wk7VQEARh/GozWz5sKnVCTPsfXV5 fg95LPnrA31uKNlTtiQWM2XK3CECmGNwRI0TKYyR9jvup5LfiCmSryXTuNpn/eUWkHYgj3v9a+/F oYNJBxF330Vt+VplJX+g7CdBOdWbzvSnHRluklqVhHZwPFmBWU7Qp8vV/AhCPQZOPJ6NBysvWQgO GJ1xRyMtJw1cs5lPZoQUmW1pg2MB2NS5ct1fqsvmkECTgf/O+GUhl9gimqcPFRjXZesKSKfC/rTi 3+Y3ls9EizJd1lOtJZOzcDNJ1AvIFgTz+X2xd55hz3Fmn9MKiwOz+baBFWVskeE3XfL1bmJ726yN ov4C/F7S4khC7jB+GfLdAMpSaLlvgzxle68AanW6QRkyM9hiiKRurKYgP2YhdUkMTTQSw0cXxCnk QMYqSU/jrUREW0WoHz541kgWx7uQO128MA1+UHLiJnzydBlMPXpPy0AT4C3PkAyl0t2lOW9mSItw hPQXgrLHLlU7D/4ft++J8kx07DYPRVaCM1exWJwlOUXNTiuAVJNOE7WkH2ys22WTty+HULsOrPsr VTissuNPm0B7+tAHOauk6pKXqWhtkB2LHQzBIycTWapEVelUFyL/X6cLKj1u0Q755GSibb/SaBK/ Ureng4Q0oEkyrlHYDKwjlVPA8MUTWuQW6zarXsIxLsq3kruFTd8SAgIGbI8VUe2QKJ/sSqXHeDOQ 3VxWhaWIgUrxzPjH+sE+Wol1Zcoij/tnyF50KPAvuRlorFyGGCvJEToZuPyMJ/9dUdwjhzDEYfOn R2wzFQDTAL4pagbA2NDImrZROfTCaMed0hetlPbnU32RMn2oXtMyeAUh9eUKqXaEb/EW2jUi54fz Y5tQXNbaAClNv8DBv5zJXIMH2UOuRjbhtdRVe/LlVDqpRLmfTUIcIlihiZyIV/z1kGeEzVamhzOb mT4sbK6JLDXhK7xmLmnQV12ob1bfpbkDQfuhRP04QjmgjDJ3gHmuFI32UwHGWObtguCJeFtzbcWz cwT0RA4PgEfxwhmcUqYNiVjusUQbyDWtb4+3qnqRdE49v0X+bEljB3rC1wExGRFp/Aqwga7Pv2KL mWE8040nyH+vNRpz5Uk+ys0B016gcijotrNLi4vZPdRr9Ic/73adPNJpGU8we/jNPvNkeDMutXiT E2pW9P/mccVypyag4i0PV9klPqSmmU3AO/RvC6yFY1jeOUyKZ+pwJ4k3Zi0VLLjoYDBs4s2F4rBo 0vaeNgnbUC02Zjjk4nn+9j1Bpivy40x8pAXsHqj6WixBilRhAXJ4HvYwsmJ60dia/0nMHpaXTsIe GUMmty+GP5oM/EE4YV24CkIQ9Pz96JzE6H59wUQXJWocYx/VuYbbHgTopzQbrKfhVkiOM8ExNV3Q 4xQRNw+Q5EDAvC5QqSfXRiYc59PNYNFQgjMJR1b65oX7tLbkipwVnNk9aBBxeXB7vWStO8OyVKr/ wiEMtUn0bi+FvpjaA1cq8EidwH+gkI2sqm41JJw23eiyzQRTPzPXzrnv+HiKwOYR37f2pGtg3bej jFf/8ddNZ/b8QFIYcGzDAy80GSMNjAyZ9o1QYdHdsHwBuZhu/AjeXJiQ2eldfoYPagoU0W8Tb+c6 +4KYGVpd5x0XLNJD3GaFfacziOZVUd3NEKdR7Z9+5W+2Moet0Rt5+PXKXuCYh5y6kh8f5RkEmFcn U2R/Sfq4AvUQXVoRbtcTSKPfF9TvKv5PwNAPx4Wy2tz6bNJ8kVDwlH9NwnrtMaDoGBPtIy/FrO9U Dnyi9sygh2gydpKWh8O8qjL4mzSycMeCTDBtrxZbcYzqGe9QwIO1uDywzes8I2G8Oo3TsfIbYeYs /B5veXGQuebk4Oegmmm1nfUpbQAi7UMGO0JDmA6wns7d+P+KxQDDTk797Fm0sYuqoTNZ8U2UMZgC eJKK+LqYDr8WIK7xCY9wXzX37Y3rSIUYKwokhXLpfgn2kRFNXJ8rPcdTosV7GKzqeS48WIOZhoxS VeesjzC3PCv+ebtynoVsvOwFRF46b1qNwUg2CTez7biPzy6mVrgCyOua4DJ/MUjvTV5igZMfSYBZ 8h6OL1WIAbVTR4jsvgMuyflX27KrCwWcYFZZCit8ZRID7cur+Gz2g78+SkZFZQdXfq6ZA6PWAHG6 jgPcW+kkbiTyEDHA876YOMJj4Mu+6O6YXnDImhZT8gmK7T+XeE2NU2IMyMXiXX7LmzxVrTSpgTHM u05qVDPS25sL05e2DFYHbrw537dtSXHEJEX1c/FoVgoPoD7vewnxRHOKHxtCUVuex036j9xyboLR rxV5NZ6p/spvlddw3OLi9brETkU8UUkYqRVLTwQ12c7QhCkYawpXJWvvBJoQgVGBOll5ordpCAH4 ApjXpTzDdV+E5a0TDvP9FJ6XAEhblynkZkMZ+6cs8juds+m0e+jROVKZyR4JubxpM1VyhdxfpRB2 Rg5uelo0UsYi14VJafN5mDxlrKMi40fGHPtMNF8tZOyb51SS2Yd1/jDPNdDdcqOBPzZujkbrgvlN z+Dff+cagwYB79EST/XgtwYLQz8t2s5f6lAofsnWjmhANjC7fVRS8dPpE6FbE2C77gIrkqnIouiV egcDDSOfPoWfn21szwg7TFdOrN4EuDSnBjTPB+tGcgKaXPGTG7AeqX/AMb1M6kmwtzrL4YLnRssS GNjI5Z7XJ2JP58WBec7HE4HJjnOsXv5915V+1YtFfBNGyDMOYEFeQlL1XtyugVu5RJSJiRNjTWzK ZhJlvKhBV3EHvGUc5sHq0RFnIGu8AKVh0rJSlZIqNT7fOE9dxrWT0LP/oYfOcKNUR8/wBMvBY95x h3gz6w8taywIwqRQLXCkMvcRx5RbrVtMhT/oCuLkKQSDfmzlg+kcOAQK7cEl5u/vG/ROFWXjpVlB n6IJG0HU6akFtH8rxj2BKpmBuScRdSmwgcmNCx83ib2B6Q8roN8cP9nv2CCwtZSlja4lxvfFBB9i BDTrYdmug0C8gIsNwKPsE4mt6ag6ly+LePpYUksdxIP8lf81PIXL/ofmkBTVbJC2K3d6fv/eamJ3 yZ8ikk63UN+hHJrriOUZKpWdR6YDjCGKiwWplab+KX3+xwwvMGAiqqKiyguJ0SN/MokLueCiZTMj ULkL3Tj1IHjLvtOCLFCypT9zVqQvHxvLRtEhahSSL9hqi7bav4lTdnRvu0QiVU1TaZK+Terc4VCK QnJYFz/CzDW6lAOPf1tpLGQvQr2TyJ3MP3C0XGrwAr/9O8h7FD7NybVaHAAZdGnVOn0IDBn/8/rL UnfQzXyeTjNhqiiRkFm5/sPAc2rUFMLX9NVB/dF4U362wLApR7PNFxqjJi3LL2SI+zh5sPnJjOOa +tw2e6LMsEBM7YcsGHYHxAFYYkLw4QIxjPqNFlPdfaCEsWYdZaq1mTvvN3Ry7pw7Z0y8QKcLZt3Z 5jvao/3g5G//OF61EUq8LLP4UOTx4sXheImVi1GaEHyelAizXv2HPP8cf6uEOP2Yx9jbFAWFqjGq ZMP5JUsXHpGS33TAzdU5yCAd9VpTA2mCtpLcB8OvjADjNVv5+ibgTiIfWGZJ5Bk1YNISJqKiLcRc bpFBYfz5MRkcH5nPMJKsyq6Bq9igaiXp8lyfG7uDDCb8Fek3B27QExc5Am7QSaa0hMrdpopTMwRJ 62iYh+oLNnQPJ4RR4I+KsP7gE8IXNSXPsY7LEm3keDLPBkLAFe686XnbMW+qBxeV7tKhemKA/kit zJkkBIOD9NrUU4fctF9tu1CBBP49s8QSSqKH36tkFUAW/Gpb/vQnq7XV0gUGPyNcEKDrOIZpe7GC LIn3FNelJ/WD+LKRqLawAdo6hr9Bxv9UdgRp8t5GGy2R2ue71bLdAQw4OS747eC+rfcaf18nugyw Z0GqPZudWu1VwYZcZzhfApoBenRL2aO10U5IEyiFQ59UwYRYaJOC6zWDQ+PA+BSvMUySvHSH+4F8 YqC5GqJhUAQ+z5wtLhyOJ1XjLC8u8EjclQbQrVJzDXI766h0iTDhXsbKY4T96fQ0/SF16b/DH8Eq E05y9k68ZMJoNKwkr3JUd/7G+7duR5oV5o5q8wymBnEu5lT1UAQOMOhYgQE6b7UHIVlmjSIWzPOk X4EckhEFKV/s+OeWPBireoJEcp/7bIgnkZPd1GBan97ny4FJa5sRs7UYwohi3BYDy3wF9R8RX8nL jxQHc52KYxQ9GYxvM34wxqeOHB9DeqkJISq4Q3esh2Qrnk7j/TT0cHZpk4PBk6Awk9b/w/a6W0Q4 hN6yQ3lqLZs3+V+Y6u+lLftpNM+8KeWWCE7eNrmRcGK1fhpD9gl9OGqYAIVDD+2TsW2u9bYknf5D af0j8EgozSekqMgWmN6Wyu+yLNEVPXEvEwEW/zRzUmWsVgPZviYJ5lH3+8CaGTY4zfH4s52HBdgk 9imLDbiAW22tCTvAySKFzn/rjg8wMIXEFwXlYyhmHIrx5e5f5sL9zBlG9iYxG1wOI8oHDVcsDkAk 0P1ac17mr0fdRQwt4ELTDSMVAYVbDNr911A7fUb7Zar2G9iV/TpPbQbBzYYSacWO1B+cgplKttA7 SqPirBshdRxaL9pTF33RQIHIOa37bWi/hgLZJNo+tMB2eQ8aqXj252mqy8d5ybsrmLGc+hlRpqkB qyIDL5/+Wz6ASUBKdwQn7bAmlvqgYbntBWNdNYBKmUTfD2NnsQwThU2IjfmZP17NoMIUPRMYScMu Cm9YDNrZJn7R6FWPzzBmS+LSlfl5KpyfaOt2r8GHNuQNVMNXCeQBLQ+h404D6ZR1d21BFINSi4YP 8vCd1Soxv0R3msYX2Mo4qLFh63yta7Ik0g0NBJyRAAVi/c0Ski2KIpcUNNhKlfg+9IW6xxS821F4 j3e5c4HRUCdwZEJBbBsdml97tU2n4D4J2F0C0MuZlFw+OLlHOgRyvthWyJuenZEj2Trkx+NhfMtK Cbv2VHen/ITR3CVGulZfA0F8kL9EtLavNJilxS351lsISxx/UdPxOHNC2TY0YmeZSRP9pmqkjmji kqgynLfQUA8f1IyGmreHnWsOBavL0pMIc0x1WOoZ/kptOM+kVgljo5tMmeN9ePUjSlfqLB5L8w0e 52fH/jlM67MN6iggvRdVJsbTnbhzZjQ2C1opvgEB4vhjGO7uphgfjBtf5HTn6Wua5dtnEtaUE1H2 sUFKVmxHimjmSPrxYXyjvha64u4W21DVHLQz3FIcEIRCQ15jN5/ZBZ1PikaTupB3Uq8SjG0MxsHo +1HuMd8mZUousiecBQsxWUFskCgdxF4rqn2BEvj2zJ6i94R/dffOjWWxwhWZKPqBCcqjBD8hsCUP ZYfqxKWZx+JA4qtV1Z7iy5FLU2E7if/BEFAa1JHi3Ql1UoWfQUUpU0l1BCk47InDva3KoKr28jxs cAL1Hh2tByxsP6lBKGvSYjYVzbQu3jEBZPazXRRW903EVb+zPPVitSU7KM3WFPNIOEE6vp/4n1n0 6f4smiBaXBeL/rPpva6kl2f9IiXK4rrE1K1HIOOgnP24rgVbx/fXNIb9YiJsViFcFd/4bXwTdPea xn55VRiy+6jHH1MMZwHr+ZgXvfrRir9aB0a9LKm0esoSy9RT2UW0tyTKnzJiixgvEEJFqzJLqeYy ivAqdCJdCg0qYVzEV5uUW/sHxjRGypb6rky4O5keQWKBrEn8z8GueuGS1fIzMoar+9R70vDdlUtE oztkwFP85ar4UpHrol4hh+Z4v9YxNbCmZttp/etiuSxNSKACi0Bn4MPRZeg8WqhAe1zPk2fcK4Fr yDEtnt1PnZkdhiko5Er57dZQYv9v9lOX4mQ6qAbca3puJHXWK3ex34o3E+L/3dfbQUE0z2lz5gwW lNjwmvgezMJ9lqhYM8GEFwp5ZnIG1CA75kp1LNcr7R3xZ4VzbUM1s60fW324G/9JB/1xN0HoJbP7 0YiTPadplE+CWCAXKtC88xxy/WscXgIVxe1z/yaeFqDssB8RGKnlGmuuNyN1TdhrBscp3xm2Ap9E vGERbc2jLPs3bpXfK2iq2cGljZRbiHEvRACYnjNtEy4q7eV47O7EAWP59cX5sy6eGnSyiEINiD9k iak5F927kDmgn8QKd/AQMKPXdxjTWYteTL9Ker1klhjAHMu+6je/QXYzBNztT3AJd5Bp7wJKo/Ge KD++dZom6Q6nisspfmwdMc4T92xJkdYoJ4OxnaSC7Awtq8UAWX26mtgixUKraifgxA8BP8XjtcC1 hHZcZ867taynfEwrbBtEDeRkqLN7LG/PJz3O/Jd5sJBUTZNSf3O+l+HsxuXGit2NdIr9+WqSFuPF ALLOQqqML92qDfcKCIngU6e6cneQxS3bGbcODAt6s+gNrZ/TolhHzQj/BayEEENoPG9BwF7u51bD ubrIxH8IuUASvztI+BEQVtJXE90Siu4NwkCJk5YCLKxRnEOMtW+QDm/6KuXI9Tjqi/9xWKXhRJ1U xel44MECDF2vZ72Csh+w9NgtVojzDPU3YjusMXVNfAoGpxybiJY6SmhNIBJhBUmoUYj1qMTvHlqp AOCUKSmpGBLNhxyOEFAUJvGvtMKcOWJ7fkJQqDwrjdiVLEnDDtybnP4U1GNyLWpb2CddU0u728bv PDVOTozVuicrz/SN3vkkoTPgteZhvZDcPCPld3jzPcFSTGHBByfL8w5FYpM4Zw1/ckFvYQSzYPih FyW9Qp1w3NsDAutnh/D9wiH4GJUBrWlurYW1bye/7+1ZSB60/hfUwY4t6aSmVm9M8MxZw5xusRli Mr5Va9KXjSXqwiFKN3/lifG85Fl2n/Cbs4ZIfS8jfCY+M474huj2/uWx7bj0zSH5+sX3OrzbsdTA DPgMyICkuWgPiZu2i7vAGDZTyKdu2RPjnigMLsbtFGIWwL66VV7PuqbV703ckNz2fttrzdO6HA8y PCZZi7NF182vvUwsR6ARDgB7iyD/f0wZA1xAkjRudzZHY4xgF3eN+ULeesGsSa4S+FgOo6sjZ9QX +X47Mmn9GAiw0JCS7ltoQa8rlLBbRhcbsgiez8DZfULI8O3z+MEfh+T2AUJ55i/w+giQwYc3qMfZ Shc5WOmpkRjfDrvNjiDbkvKVBMYw/nXvWmCYz/hE8Bnkakb08Yt48cVzpXCfWT9z+b4lcWGeRnrc Ho2mKDINqVO/TopQIoo2hME1vgVWshqK2dK8BvvhAqrXHHdZJgAq4GySipN3oKKdm7xL6ELDH7zU Coa28e558VoRn+ayL1iwTS2UyOx0Ffs1VYbc4LsNfV2WrquJVEeUSTjWX4l8/uCLelsW9dR75Kvj Ph+0RhWgDBuhf57m4VYMZG+cI59IcdW0IjzsD7hlCFq0fnHHFPoOxdA8FMkXvxmfti2V3L2DmmW9 +W07WuB8s9hxW+Z0Ys5yTcyRYkU6RkAL70GLX1DdE4rnjf1lmrkbd7k5iKb2+Q21AjvenqTZI9my H85RiKVdlBNAfPYrVE/R7Mb4jF4RhlyEDQv0ekmGNHco1Zhxryhmz6yDrGZiLcefIyWIhmjgTYAu BzzGJwmmETrjzZgaVIm7ieE3viVkjw50ZM+yvexhqftL6o6VTFVY+faUUmV4+Yuv4RNz18P1yHDS wHsg82CqbrvMQ9gSVi6VMtH2u+Yc0QKkpPSSy2GwDLY3QefyZh4jWak8MwfXrnG6ggHWzaBUvSlv rLFncsclu43uU7bwLhIqsXxV7/CgsVBX/h3tJ0mnXSkYrmoF6zAbKYArvUErBrPh67XN5z0lg68O ENy7/NRBttCEdP+ryRf/iRcUbnvqe2P4KVqKSFMJvBicR0xU+R424gtrt/ULyceWWsLjeagpdORe 1AIgkDCaK5R1o9/FqTGAoFpMMg5YES+Fr9zyQYs+TR3RGDc9XWIr5AK3W90Gn6JNhOTJnqBf+oRK gVSm7fBtfSHzAsm087bCA8rknfrLVC7FKGqXLSaC02H79Xq0rw1fVjfSdDkONQrG5UNBbG6Uwzcv FswBVs2dPepn13jNzJpvPHxr75ixBPEcGESC2d4gf7cmqR9iJ5L7TcbhKmmwVEsKsJDEzsw+1jNN A7AuNvEoxtD3z0bBt4AFe4oWGW1sXOEzcq9PJysTxpyrFbbYl7tbT9efG77B18kGU3uYOMr64DKb I9YR483+syjdLuF4mYc/zK2BblO7wgLIghNSj+hGYcMc/LqmgLN+bOYFQZKQLtJe7CGabd5I0hVS /REHAmx+MpHTUHQfAhcrXCe9/d1/Sh9BA5zxNR74U2t8mTUidh21mltoJggHz07J5h11qabtK89k zdI1EB8tW8glbHCDa3xdaeehWojFVR/pN8Zg0kMT70NOM4iisjDWty4CUwsTKo/RWTimhS3lnxUa bWW1+LIJfsD0/AOIC2xLGLjMQL5qOoE3nUNwobMVj26I6yvgZeg+/NgzLMRgeES3SvlLT1bDmlef WoYW7DIdDodH4BdLNIrHGpW13fwLMJcvuIddl0jN7LI3jEKIAeRnCLksHPs3munYUdIgI8FFcCBF +QuHQ2BaAsMros8ZQBEhurwjW/MnjuQvA/DXblFwKkxrjkXJEhKar5+Divnt72lYd7877T8tpLv3 BjnKA1YpdToa8mskc1MgGYDlHK6K8+zk50G76vZSaROuqLzv08E81+179IGHxX1ZH04W05ZdVG/H 5ZNIto/eC1EhBSconGz6WTHu4Yy9ap0ql/WpOSPr4JsxUs8GzWtJIuAe3GDChlXbq7x+2DtooV7I wpWCSHmn1fePxipJ9aPZnabvjILCWX5fGep+N4VyXZr7LOUO9/qSu2TPsXjbXSsiMcoX7cRxa3h4 3RwGnDcsiBwUQKJ6gesjQjOE0EI1SJRrxZlKLfPrG2Y+bY3ozlA8UmFNcxGMY54xaxlWL6tysqYa Bl7dkh4kCkmfw1d/l/vLvNx4HVzUhlU1WRcJwpBHjRD1b/GT6g7ZzNUzu1sp6wowox3hFIWZjXt5 ckkwyN2oyV5/4hYvT72pLuA84NH+rBPKctcq7Xal9MTGUo2iYxF+IBb4Qquxz7cci/QljiL3AyzZ 1DiCn1GjZANNEvkreYD8Y+BoCLUzoBYSoYle8Pej12Y5rQNknPlLzY8C6dF+COId37857TfLNI8K 767pnRayjvns3hQH5W8q/VQlHwOrYf1ZPFyAmTn6yOLyTenR0b6NSvDHwtNfcDO+n2vA3TJmLz1T NmVXXJFtE6jj60msgClFiNh9TLtNLB+JSb0UJECHaFSCoDTQxxBDsVG/ClhETFTthlOUBHO09d7y FkBCApEcIkEkF6d8p5x0iI7iaH97J8D+j9NB2LQuzqLD2aIHs4VfAJ2lfGYJN1h399pF74r8TiII F71vgnqCUKIHCN5ski5MslY1yl7OGjo/TyYExDGkJFXK56yWY8PvvGQKZnVmeOFG6gRd6R2H1d3g UN+SrqZQ+R/u7dZ5AZ4cqIwBWgTMpXJveKlXnxZbPxY4T6r08omDtq4uk5AzhHpXkEInceGM/AJl 4tRxT6YvEySn+hPDKZUI2dkfQL4oZKnE+SNnp16JstIodKCRDE/1uV4O2plX3leQp9ZXDn9O4MXs oM7vv4OVlQHYfU4Hx0ri/E4AEOakRVobO8Rbz/BkCwfWYxL8ZSb9xR/dY1MdG26JaHg7oi1KvsHK gTQTIOQMnY3PPty4ZY+2tHMk7d+RfjMEhJnucaLz8ajKnN3daV2RESHawpPvCHcFRtwtd6+Opdoa pL5qJdby8QryB0uvG2yWPHA4yg9A7INQhUe/JonTIVV3fFvBehpvZ8MqpTxgRKqe0FKHxXd6NwY/ wi2yn2pbOac1I3NsvAx3Pz8d4yRz6TWmNtS/x8quJuldpB+fHkWX51I8qReFPTJ6/e36RECyD1DC 41ZCapAoXTfsiQvWLFsQ0iV5BXPgrzJmfwYperVDqfbSy+ZdW9dPVuX0XjYwTG0xF8Y8YtOByK+k nbqq7272ngw3kb1BSr4jjd6w6TZ7CB94CerA6yB6+q2r7qOQMur5jx3ejV8xzfnODoVlvZiGkUY2 ksFr6C172UBVyz2caJEDeZccJEVmul90m2Btkcdqn8bA9tFWxWUYsHFGhyVeecvaeO6wQ7jAKuvm XxIyWUdRQt6M/zNzUwVoln6PhRH4jIwOqj5OK8+gAOE6c8NXbZ2r93woRdTbSHjaS1RFX3fhPS4y zINUYrPCgYG249UzJne1kEz/oPQ2dQE9yL8icvX6QsMsiXBmte/o6SOZrCjLZljgXUUTlNUqSYcj cucdE+MkxJ1B738AWJJmpPhH8iKC03vYXq0HChL7KKRrQytbpH7nrnAtTTx+rflCYm8ergBbu4Ae I8AEvPihCnQmvvjLcX6xNfuawvWKA1/NAsXZXsQrlgscNHeLA5oCozRe+uFJmT6L+lq+IV1sCSqP 1m/AV1og3/gg/swtYmIszBY8kp9ggobGSQT6QfXHAGrbhqeG0ntMAkUuKRRYPQyk0KIxgLmG40tG E7lsf5HUQvIousLoti91Uq75OdH60CeGqMjhAp3i+InUqVfKLIDCRn7kZ3Mjx3sXqpSk1VSXvPSQ 1Q9L3O7iqzQi9iUnvFci4PdBNoK61woPRUs1NVlxjrHp06EgphjI2G/SHN51aqsA9oNcoxsBISY1 eZxlr4OXkZ+uiUejnjRExKRdLraTCpopnh7dRQqAepXRwH1hiMUj0dblIn3p9nsMyPmoxQV6Rn1S lY88vi76bIX9mRooV+kyihKAHoWcCVFsq6f7/67xbhF09UBrP4fX5hyWp/kMAZ05ESImRHZFE57L Osje7Jhbf43PD0fGdFtFUCGFLU9+VMXOYrU/eRr8rEqCwvrfm7ds3pE+C05DUJiwKin0eaco+H7j Iuq9IHw63Yb2fx9yMbIJ0AkUHMWzGHceEX2PIwM70LMRM+M9EE1BBjRozYyDXSFtT/jrPuphSFsi F7DIrJSUC7kA7ygn5Rd3klpcmiL36E9CJvR6fIrhlGD6hTSYzmmJlV6hz34C6lbSSpqh6OLoRUYc R7iItFJLZRFZAUqPYKnDPWjC2/Fmx3yWjxrhCYorblLUZR+V4dYNW58/ETr42Lfen7CawyBzS+QJ yU91RxMnlrUG0dU6NzOHuKrd5Ubqc7Ha/QiyptjfYrqiVmutR4CF9elMvOr5wBuCosGF12ihU+i6 hzORouTJGfDqfZNAWlmHUTvRgvz7/6i55O2y8MOnjcSwbrDGcGC+jYPlUsx5M1DgPNzWjVlo8LLC L7fvMuo6dvJ+Kp0USzcl1QDW6xq2VWYUlJmD8omJE1+cMa1G9jnXRfjZ8hiEbacql1dC5jfg30lh 3WumqdIqB+hqnOYoGi424PgfdtaWG8KjQjzlWy+JXa+aqjGDWRPQ2w62dTQD5Hiid5TnChwyVUqC DWVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODg5IDAg UiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjEgOTEwIDAgUiA+PiAvWE9i amVjdCA8PCAvaW0yIDg3NiAwIFIgPj4gL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDIg MCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0g DS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDVsgDTQgMCBSIDg4NCAwIFIgODg2IDAgUiA2 IDAgUiANXQ1lbmRvYmoNMyAwIG9iag0zMjkgDWVuZG9iag00IDAgb2JqDTw8IC9MZW5ndGggMyAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KxCkM4ZtUgkeCP5g4cuhas8SFXzwX XHQflO/VuLbtcMeYgijGxd6+mxFQGpJrPVY07ZxVHuamoLwBDihp5+LCw3xPkf+PvlJqLHos2cbY P7I5j27UcPmIFymlQ9Aw2zx4Jr2ksRUE3FRtlM//GI5Hx5YQJzzG45MYUNJFKKSO9llOBzsd2nr/ W0VHTMmuTmvmupehSBGrYWohy06Jh1KHzsz2KplVygMMWg2d53dKrihIhczDphOkWuIDo0/vWoV4 EFWC54/ehgzPbm+u8z313uiQX2BrBhMHeljLq22qPdlV87GH1r7qJEpLdwyMdcD3OG2QnZ56Uyf0 CmQHXH2YQt708lMxz6Ipf7dmZlI1ySr3vh7BF5iAjfwxt708JGxdQ4h9MXbj08ahvLe9c7YrIBZe x2HnvY5slso0bVF1ixePoGHoXuPRK9wNZW5kc3RyZWFtDWVuZG9iag01IDAgb2JqDTk3MyANZW5k b2JqDTYgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1IDAgUiA+PiANc3Ry ZWFtDQrZY0xU7it8srAD9mKqkzrQDttw+6g5ryj6USo/U9Z2RXAP0MI8XwMoSD4B3QtDVUekSd5q WavxXmBKDjK7hUqsNAoEr1ynHmrHpCtL8uKVewbcU+lFIhx7oH3miXBQmkmWMsL6DMFBsyRlA0Kw ysKbnFo4eQ47gfrGHv6yEXmB/Y4di0VHHe7LGl2J7iVdK17sQ+d8e2IILSLjEjRw2SHEg0URk9aE OjEmGMUwuJm4xaqOIC4b/ncfy2Tgr2wZrXs5vnCTiTKETKt4drNfmTzEQqaE4vh8H0OpnZyTNiYT J9uIpmvM+wIl4gDVLbxNMq4BkQF4QD43IzbMRnieT73rhIASiYCJXyBAgWO5kCnLzFOwkwQQ0e4e Zn8rfqa9Ji5aIb0TWkM34H+ZRG1h7k5k2zdSOiZpjFfAdv55v8kAx4tDSyocnd8ZvsQlvah9UN8u 7qh/Cl9UvfE7wStuoAIvPH5MMU60s2M+3TEtB3Ggdn+Ef387ctOwWqM26PO40vLoCzuhAvzIApoT 0aigG/hjdfxfvALXzyVM7NxumQoOa3QLlZiFesAl9xuP10m6lS6eaizEdQY+2OA2lkCRxzWUgwOJ SJ89HH/nEQBE8T5XDb3MtjEee4WnpjzGQEIBmjkXylwnjy7U9svIxcLXYlN9n/U3kvCvWf3URwSK Ok3PvVIFEw7rRfto6yRjbvbTLX53GS10QKmbWDFzBGlR0QkWQoZG42GGZkT+CRdMQtgBYWpGkBQI dO9XXfsf3bJ2kdkJ3r+0LbvETt9Z/K51iK+4CdXJ9UrbzI9BLVRRGSiIS19bwMAWod3CBdmAC1mB IDs5g4hbPQEvWKub2zsShVfp92Xc+qEkWHsYTYCR/cO8S1fgYu5o+xfqlJHNW1FxKOnhpkVv2TIB 0AVP5oQu16kAyZ8NzPNLl9Irqc91s3f8o21bsDEPyT9ct9NnsBNBmk2d0Fj6ZUV9wReK7p4eV72n WIXBNpWj4BiBQcbiKmTjwflKNcb24m8/USv8faG+9Gv9wXiphvc915PBy5iuw7nIixRDtekQBhp3 nCs4Ab8ORvKxexuBVNV9jtUdNpr2tCzk3bxXQ1kCamH8biCRe58WCQRyG6KVuDIRx4+ED7X/LjM3 WQ4SpvMnOkKbuwx6a5i3mg4VXY/VzVQ4cyRwJjbE13L/4ZJ3M+7tvdmmaGYIeTz393hD+7QpAA74 f9vWGeVmeE7v4s4s9DFSdfnpdHCxoYZgN3WIP57Nl3EcLYID8/RqXlSHlo+V9OkrEvQZ+Lz5Pm/h z2vrsAD8tq+/DWVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJl bnQgODg5IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjEgOTEwIDAg UiA+PiAvWE9iamVjdCA8PCAvaW0zIDg3NiAwIFIgPj4gL1Byb2NTZXQgOTEyIDAgUiA+PiANL0Nv bnRlbnRzIDggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1 OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04IDAgb2JqDVsgDTEwIDAgUiA4ODQgMCBS IDg4NiAwIFIgMTIgMCBSIA1dDWVuZG9iag05IDAgb2JqDTMyOCANZW5kb2JqDTEwIDAgb2JqDTw8 IC9MZW5ndGggOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K0G9/PaXG1EvQ He0FXSjzrapa6v3F61v5Hlg/We/+ZP+TFl/jrzOQ1zJ4dYlS8RkKrnx70FQGY3XZXYGo7sS+k4Ir 2BeL2KLypNOnvj/HiDuwZobGvf+o2E5f1FnMWWvSIELVGTc6s8C+pROtWB1m+i5jhu6UQ/iziPmc m2whUEEMZQt3AjcFKNahD0SHVkZxShCLHoTQZETqhnChiYV6LSO3jAs/zF+E+5KSOkhifLwPA9Fj 1hifVLXrXHQi0JbFdgwXvUy9E0GJAfwN0o0yj5JbBF8CXML5tie2o6JGH015rGARk6i2FR4dA+ee 9yz5Knxng33EQEfjuc6jtFjIUYpIhb4o/gU974k5vl/AQRaeejPxxQUsmp3eB9MVGMaIbv2/HYlm snFq0uge7UITA92zSAtACAcxqX2sLbPssalCRNXaYpm+fQ1lbmRzdHJlYW0NZW5kb2JqDTExIDAg b2JqDTU3MyANZW5kb2JqDTEyIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MTEgMCBSID4+IA1zdHJlYW0NCsN9qSw6Uuu+tw4G0vWY0SSIbCPkBleOlt8n/w2y/6qSCxZWqu4e 2vcmnP1hl3QVt2r7pV4+LiXRm+tWWJnxGQOy3XBb7DMbuXnQJS3BDIe5FdSVMy6GztwwNxWACDm+ st+jOSEC8cJfYFNV30oZzj7S3fxuJRfpT5p5BgljFFCW0XS3KovUYYIQ9zKnSfEeE3XnJQuXFQAT I9rTev1vY+ZP3m3P9ayVahIWXpuBMSo7IdhaR3BOvjlCzWrp1mdby9s2AR+Eb9rcwyNLDA/eBiZj qOzS8unVkMYOIjDzSXl/nDaDV62Zl13SPu3eMtWGpNx/kJDDwntRRWOKpAeyDsvRTwrIGpNML2k6 BySxFZ8DcHuA8GQKwZgzP/5Wbl+ikJaA8PCluAeieYUKEUjHxt8287EkClyMK1N79BYOUTdkl8Ur TKTkL+q7ejKleCwS51BG5cRM9UVa5fk6C/dI95rZSFKbncCwybuRYhTmkWIA38IkFOqMfxaXOWhk hrwbuEwH1EuEsC/wW5NLvdnSRGDmWW0p4/j4NwWDKClNQrCOvRq2LFRllsWIQsNwvTOZT/l2SL4+ FtQ67qxsqjWFL7Lg4r+DhGe0fYJF9rb3rwER2mOpUANJ9FE5bGrySKBMV+NiLH+IhxT5oGPqTARA PqVl0a+F6xSA/1BfIWjPuf5AJlxF7Qe7tbCJ0KIe2GG04Hx0e9tK4vwTYZSP/18oErqWJYxeY/RB 6vl2FbMPbw5Y/Cnto3PdnK94YFN7tA1lbmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCA4ODkgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcg MCBSIC9GMSA5MTAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTQgODc2IDAgUiA+PiAvUHJvY1NldCA5 MTIgMCBSID4+IA0vQ29udGVudHMgMTQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0v Q3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNCAwIG9iag1b IA0xNiAwIFIgODg0IDAgUiA4ODYgMCBSIDE4IDAgUiANXQ1lbmRvYmoNMTUgMCBvYmoNMzI4IA1l bmRvYmoNMTYgMCBvYmoNPDwgL0xlbmd0aCAxNSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KkAz7wnOYdoc/nYoZ2LXLD8oJQHvQmDZ805/o4HEzbvfg6+qY+Kb+A+hXx4Ydw0M3 nsufVg2Qfv8odMEJdv14MDuG1CFWnsjEUZcu/v/85Hxd9WicJWgcFaE1Kkh6AK1jgYb1gnPeNz8w GKgxa0rFG9fWjno+68hH49TaDzbimYsJGsh6RAkV86eK1Yt4BU4OqT/uXV4cTzJNpIkdCeXwVvm6 VLIfEcfW7vcaDwfwLEOHb8UqtNNrNTrRgGP/oRdpFft85eljVMxhK2rUFgql7NO6LVDYQlSb1F2D esKqo9svIx4IWFJcCEUJ8IwEXImMeJxmsEnIbsyfz4zCw+WkjDzLn3EzdWDXNkdJ+717sd6ub5aD 6FC9Bm8w2rQZEZ4QGw8cSXR6tfsnWio1mpD4TEYNQ2mteQSUffQ79Y3we2IktGYnf80/UA1lbmRz dHJlYW0NZW5kb2JqDTE3IDAgb2JqDTEwNzQgDWVuZG9iag0xOCAwIG9iag08PCAvRmlsdGVyIC9G bGF0ZURlY29kZSAvTGVuZ3RoIDE3IDAgUiA+PiANc3RyZWFtDQoaShLo/BVqGgds6avjAN6afXpD 3+cHJSdtMLb9VLpmMCYOqV4iUH9PH/3JF1U74Nm6Jl32r3OtHVBZimtulAskBaIehVzokwXOYN8i hgSgvI4pENsaHqqNblvYV5L7NJAsgc/xLQ6Z+IZBpEPAMTYg9VjVytrmjnFRd+6DUgR8kwjv7CIm x2xPgtel0a+dNtVY/ZJty3yO3Vf09U0FYsDPft90giXKZwgerujIhqvN+wMf4qOS8pKDdNGJqL/F B9Rb+7OeHBWAuGxOSbeYY5FVjmyEv7dHevgtIcP0P1jyTVgPVfR7s5VME7z3PtmD720JVNQ9Jsob ZBrh0YEmXetRLdBqxgCwZKagOTjQjLup98XQGxpd9s/XdGrJKB0y+UDO0s+Pk7yKZnW4MN5vdGyS AcYZz0Q1HrC7zm7NhsHCRx4Gs5eedTtS89q9XcvSTCS8BxRMQYDKZv0asrMgi0iHb/cNUvyVi41o xTZwcUJ/TQWK+suQ+9rQaj1m9c1mNsvZip7NMKeaiVsfy4XfGPagAIYuOkxJKwyK8vzsGyx5LswG tDFf8MQnu+Up+E6huj79CWyys+BYEv+4tqUGLa369VQoC3E/6oi8cSN3+4Qx21qPxdaN8CWoK9+r r6GAVjTgKNKiOE8mq0nF32wmtdVq0PmWm9EbP39f5ZmiiM1uCq9UGY5Cq+9Ljpx+0iU03v/U8EI3 /NYIHAe8DtdZansHqbw2RWae0NdkdFBCLYPUZ7Bu6vPXYCssRLOyGzCJ6fjjcuNJn9tkU+oev7rK +7vtg44vo34o9FPXekr8aZaJppf9EWFoUaLg6x/WBdpJjCYP3yStoT2mH0AOy6dIORQuVTI15PZs 5dQxOUVkpGnQ418DkX9tcD6etYMxJtu6xBJ5UZcaEZ0+jbcJCmFlqQdD8PCZqkgy37tT6Bus1fT4 JTfh3D6iKv6qu4v6k7CYHZFDSWa7AwlC4tgwvLWP1A4/HODA1p3tt/g93wLXKSyrpgPAW5gdk4lj VRIlkwnFvBcaNZ8tjzI45ThvQ1JdFtzrHPAekbL5tlMWC+LSCl1M1zrzQMNZ3tmR2ne7JT5dbrZ/ DaiqJJZBCPz4LJmLD9N3icB5jURRCte/Ro7MEt/xy4DjZBCJZk0F0voIbEF7A2Ly8G3kBsgjRmLv qGasfcW0+GVInJayyaUxNpzqIIWxcCi6vtPpXmwfLcyptm5qro/NVeYCXvj6FzsizchDzUqq+Wz4 U9iAODkHlwZtlabeZjjT0c/NuXnvyzJU8U8VxFygqQA7bRW8CTK2JDG7jZjIRtVOeZ+qcx5DwdDq Ifchr0obYTtqNlHJR2+psvHfB8xzI01X6FJfm2+V4rRKMpfFsM7w5ysEznvITAXZVPA7eWRJWF9P 4fSw/DrVuc9Jwm+aaGRwhzCnLKNqxwVucZeAcTwNZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODg5IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAv RjAgOTA3IDAgUiAvRjEgOTEwIDAgUiAvRjIgODc4IDAgUiA+PiAvWE9iamVjdCA8PCAvaW01IDg3 NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyAyMCAwIFIgDS9NZWRpYUJv eCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+ PiANZW5kb2JqDTIwIDAgb2JqDVsgDTIyIDAgUiA4ODQgMCBSIDg4NiAwIFIgMjQgMCBSIA1dDWVu ZG9iag0yMSAwIG9iag0zMjggDWVuZG9iag0yMiAwIG9iag08PCAvTGVuZ3RoIDIxIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpYAlkFU5tHWn+6PuM8rxUqjUlCs3HAq6u5D1HV 1RV4a5Z+F2eZWl/c6NSA+lreDslOkAb43rrOYSPoxa85YlQ14cEZkbCtXniwRWz5ZlLfiIT0HIGW UgXaKexFNM0XfEMCS6Vo6TW1Pw03sr3nTqBF5ZwFDLiDaq9EgKHll0HQI0/j1xaVXUTUciKH0pos kJWHD8eMfWQtDxc2QzemyBD/hz4IN2TKUrcnqjZ00CxEPTerFKYnyEschlbEt346HzwdWGgFnvaW i/CmvWdWXNe16yDfmFQ+nUPt7HIpxPGgvNzzQkCC6YNPH/N3RDmzfDLutj8ZZDTpWC9xfNpqzHU1 wI1ErzehZjPuT8Y4Kp4cL0D2rygO9csNlVZT72/ZXLet515LDNeBmzAecin/pZ1LaecfFdHjOvwi 8PsnEAe4FdPO81tPL6uCDWVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNNzI1IA1lbmRvYmoNMjQg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyMyAwIFIgPj4gDXN0cmVhbQ0K fsS/WmFwABVSo/TLEfvRe0wZEGOYn9+46SzyaV2JucsSXHyu61ktw9eVkbhsqYH/UD1tATVEUEl+ rG4QCacnvbHxsyGy7rY2C/SzcPpzUcZ03B5ROUwpRqZW1Yy1b1WfOQon1R+HLiuq6W4xWQJTJzlV 0flhgPjI3V5WJwuTx5tatMzlxP6ekal7AajtFsgNGgpPWeu8Ip86lqIc9oLfR++HHXah9aGM/uho znDdtdc+m/7AAb9rdgpfQBKjmJPGEYJv9hKffizhjOYQq9X3TL7PsW5YIAbMGWGOfwRLJxSdw4Y+ R7fAP96WA6beP/AUrclYUjfu7rf9ZZf7Iq0zTBNjX/hxmgjQ/PY3KN2GDDj8iYKqXMUgQ9a5nNCy ASdsWOfKkAzH6ypy8sGgYCfhUZNkLy18b/l+daHxblIIoIs9G43sX75E1jzKIPtZO3WBllVIL8cW p/IXRmgbyx9hQZQTzUpo4l3j+vnKF0ybCRLLF2i81P0f/OCX4QCPXWTEqkuYtUy7pXmTHhznZ94k oOBpOxfvKF3FRaizukUwIuFtZpD8yvL8wttRXBr7TniuoLknO4tic57NChvGaTdJH5X2fDzoza6K OtQBZ0QhmyJIZPEsUjO+JQEJlJXTGvjMqgzeKhIbRaDEzxBiGWonZSvlDfyfK+vwC5b7YnQOowhq Ac4tA2A/ZI4IV8AIJMIMj7bJEpN7gS9Pk3cLrTOv+DA3+eSEc6B6canRV5iNIGoJfnvVWTjIu18E 1aj4DPFDf4fZCaSPFQhPUPSRWC5jtQs56thGnqAi58kcBjorMIwLabxsoS4p9iBW1q4VSuYjqUJQ gLkrZKZ61Usb60di7Gd4Q7tBB072e2nedbyHXFegR6KsEvpokGSqX7HvE1ELVx0erP6riJ+A6SOQ G6yG5IykR5AUsLcGG0dlTrmUTKTd3uqWidLvfVmPHQ2eryTPwly7KfYNZW5kc3RyZWFtDWVuZG9i ag0yNSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODg5IDAgUiANL1Jlc291cmNlcyA8 PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjEgOTEwIDAgUiAvRjIgODc4IDAgUiA+PiAvWE9iamVj dCAyNiAwIFIgL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDI3IDAgUiANL01lZGlhQm94 IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+ IA1lbmRvYmoNMjYgMCBvYmoNPDwgDS9pbTYgODc2IDAgUiANL2ltNyA0NjEgMCBSIA0vaW04IDQ2 MyAwIFIgDS9pbTkgNDY1IDAgUiANL2ltMTAgNDY3IDAgUiANL2ltMTEgNDY5IDAgUiANL2ltMTIg NDcxIDAgUiANL2ltMTMgNDczIDAgUiANL2ltMTQgNDc1IDAgUiANL2ltMTUgNDc3IDAgUiANL2lt MTYgNDc5IDAgUiANL2ltMTcgNDgxIDAgUiANL2ltMTggNDgzIDAgUiANL2ltMTkgNDg1IDAgUiAN L2ltMjAgNDg3IDAgUiANL2ltMjEgNDg5IDAgUiANL2ltMjIgNDkxIDAgUiANL2ltMjMgNDkzIDAg UiANL2ltMjQgNDk1IDAgUiANL2ltMjUgNDk3IDAgUiANL2ltMjYgNDk5IDAgUiANL2ltMjcgNTAx IDAgUiANL2ltMjggNTAzIDAgUiANL2ltMjkgNTA1IDAgUiANL2ltMzAgNTA3IDAgUiANL2ltMzEg NTA5IDAgUiANL2ltMzIgNTExIDAgUiANL2ltMzMgNTEzIDAgUiANL2ltMzQgNTE1IDAgUiANL2lt MzUgNTE3IDAgUiANL2ltMzYgNTE5IDAgUiANL2ltMzcgNTIxIDAgUiANL2ltMzggNTIzIDAgUiAN L2ltMzkgNTI1IDAgUiANL2ltNDAgNTI3IDAgUiANL2ltNDEgNTI5IDAgUiANL2ltNDIgNTMxIDAg UiANL2ltNDMgNTMzIDAgUiANL2ltNDQgNTM1IDAgUiANL2ltNDUgNTM3IDAgUiANL2ltNDYgNTM5 IDAgUiANL2ltNDcgNTQxIDAgUiANL2ltNDggNTQzIDAgUiANL2ltNDkgNTQ1IDAgUiANL2ltNTAg NTQ3IDAgUiANL2ltNTEgNTQ5IDAgUiANL2ltNTIgNTUxIDAgUiANL2ltNTMgNTUzIDAgUiANL2lt NTQgNTU1IDAgUiANL2ltNTUgNTU3IDAgUiANL2ltNTYgNTU5IDAgUiANL2ltNTcgNTYxIDAgUiAN L2ltNTggNTYzIDAgUiANL2ltNTkgNTY1IDAgUiANL2ltNjAgNTY3IDAgUiANL2ltNjEgNTY5IDAg UiANL2ltNjIgNTcxIDAgUiANL2ltNjMgNTczIDAgUiANL2ltNjQgNTc1IDAgUiANL2ltNjUgNTc3 IDAgUiANL2ltNjYgNTc5IDAgUiANL2ltNjcgNTgxIDAgUiANL2ltNjggNTgzIDAgUiANL2ltNjkg NTg1IDAgUiANL2ltNzAgNTg3IDAgUiANL2ltNzEgNTg5IDAgUiANL2ltNzIgNTkxIDAgUiANL2lt NzMgNTkzIDAgUiANL2ltNzQgNTk1IDAgUiANL2ltNzUgNTk3IDAgUiANL2ltNzYgNTk5IDAgUiAN L2ltNzcgNjAxIDAgUiANL2ltNzggNjAzIDAgUiANL2ltNzkgNjA1IDAgUiANL2ltODAgNjA3IDAg UiANL2ltODEgNDYxIDAgUiANL2ltODIgNDYzIDAgUiANL2ltODMgNjA5IDAgUiANL2ltODQgNDY3 IDAgUiANL2ltODUgNDY5IDAgUiANL2ltODYgNDcxIDAgUiANL2ltODcgNjExIDAgUiANL2ltODgg NDc1IDAgUiANL2ltODkgNDc3IDAgUiANL2ltOTAgNDc5IDAgUiANL2ltOTEgNjEzIDAgUiANL2lt OTIgNDgzIDAgUiANL2ltOTMgNDg1IDAgUiANL2ltOTQgNjE1IDAgUiANL2ltOTUgNjE3IDAgUiAN L2ltOTYgNDg5IDAgUiANL2ltOTcgNDkxIDAgUiANL2ltOTggNjE5IDAgUiANL2ltOTkgNDk3IDAg UiANL2ltMTAwIDYyMSAwIFIgDS9pbTEwMSA2MjMgMCBSIA0vaW0xMDIgNTAxIDAgUiANL2ltMTAz IDYyNSAwIFIgDS9pbTEwNCA2MjcgMCBSIA0vaW0xMDUgNjI5IDAgUiANL2ltMTA2IDYzMSAwIFIg DS9pbTEwNyA2MzMgMCBSIA0vaW0xMDggNTE3IDAgUiANL2ltMTA5IDUxOSAwIFIgDS9pbTExMCA2 MzUgMCBSIA0vaW0xMTEgNjM3IDAgUiANL2ltMTEyIDYzOSAwIFIgDS9pbTExMyA2NDEgMCBSIA0v aW0xMTQgNjQzIDAgUiANL2ltMTE1IDY0NSAwIFIgDS9pbTExNiA2NDcgMCBSIA0vaW0xMTcgNjQ5 IDAgUiANL2ltMTE4IDY1MSAwIFIgDS9pbTExOSA2NTMgMCBSIA0vaW0xMjAgNjU1IDAgUiANL2lt MTIxIDU0NSAwIFIgDS9pbTEyMiA2NTcgMCBSIA0vaW0xMjMgNjU5IDAgUiANL2ltMTI0IDY2MSAw IFIgDS9pbTEyNSA2NjMgMCBSIA0vaW0xMjYgNTU3IDAgUiANL2ltMTI3IDU1OSAwIFIgDS9pbTEy OCA2NjUgMCBSIA0vaW0xMjkgNTY1IDAgUiANL2ltMTMwIDY2NyAwIFIgDS9pbTEzMSA2NjkgMCBS IA0vaW0xMzIgNTY5IDAgUiANL2ltMTMzIDU3MSAwIFIgDS9pbTEzNCA2NzEgMCBSIA0vaW0xMzUg NTc1IDAgUiANL2ltMTM2IDU3NyAwIFIgDS9pbTEzNyA1NzkgMCBSIA0vaW0xMzggNjczIDAgUiAN L2ltMTM5IDU4MyAwIFIgDS9pbTE0MCA1ODUgMCBSIA0vaW0xNDEgNTg3IDAgUiANL2ltMTQyIDY3 NSAwIFIgDS9pbTE0MyA1OTEgMCBSIA0vaW0xNDQgNTkzIDAgUiANL2ltMTQ1IDU5NSAwIFIgDS9p bTE0NiA2NzcgMCBSIA0vaW0xNDcgNTk5IDAgUiANL2ltMTQ4IDYwMSAwIFIgDS9pbTE0OSA2MDMg MCBSIA0vaW0xNTAgNjc5IDAgUiANL2ltMTUxIDYwNyAwIFIgDS9pbTE1MiA0NjEgMCBSIA0vaW0x NTMgNDYzIDAgUiANL2ltMTU0IDYwOSAwIFIgDS9pbTE1NSA0NjcgMCBSIA0vaW0xNTYgNDY5IDAg UiANL2ltMTU3IDQ3MSAwIFIgDS9pbTE1OCA2MTEgMCBSIA0vaW0xNTkgNDc1IDAgUiANL2ltMTYw IDQ3NyAwIFIgDS9pbTE2MSA0NzkgMCBSIA0vaW0xNjIgNjEzIDAgUiANL2ltMTYzIDQ4MyAwIFIg DS9pbTE2NCA0ODUgMCBSIA0vaW0xNjUgNjE1IDAgUiANL2ltMTY2IDYxNyAwIFIgDS9pbTE2NyA0 ODkgMCBSIA0vaW0xNjggNDkxIDAgUiANL2ltMTY5IDYxOSAwIFIgDS9pbTE3MCA0OTcgMCBSIA0v aW0xNzEgNjIxIDAgUiANL2ltMTcyIDYyMyAwIFIgDS9pbTE3MyA1MDEgMCBSIA0vaW0xNzQgNTAz IDAgUiANL2ltMTc1IDYyOSAwIFIgDS9pbTE3NiA2MzEgMCBSIA0vaW0xNzcgNjgxIDAgUiANL2lt MTc4IDUxNSAwIFIgDS9pbTE3OSA1MTcgMCBSIA0vaW0xODAgNTE5IDAgUiANL2ltMTgxIDYzNSAw IFIgDS9pbTE4MiA2MzcgMCBSIA0vaW0xODMgNjM5IDAgUiANL2ltMTg0IDY0MSAwIFIgDS9pbTE4 NSA2NDMgMCBSIA0vaW0xODYgNjQ1IDAgUiANL2ltMTg3IDY0NyAwIFIgDS9pbTE4OCA2ODMgMCBS IA0vaW0xODkgNjUzIDAgUiANL2ltMTkwIDY1NSAwIFIgDS9pbTE5MSA1NDUgMCBSIA0vaW0xOTIg NjU3IDAgUiANL2ltMTkzIDU1MSAwIFIgDS9pbTE5NCA2NjMgMCBSIA0vaW0xOTUgNTU3IDAgUiAN L2ltMTk2IDU1OSAwIFIgDS9pbTE5NyA2NjUgMCBSIA0vaW0xOTggNTY1IDAgUiANL2ltMTk5IDY2 NyAwIFIgDS9pbTIwMCA2NjkgMCBSIA0vaW0yMDEgNTY5IDAgUiANL2ltMjAyIDU3MSAwIFIgDS9p bTIwMyA2NzEgMCBSIA0vaW0yMDQgNTc1IDAgUiANL2ltMjA1IDU3NyAwIFIgDS9pbTIwNiA1Nzkg MCBSIA0vaW0yMDcgNjczIDAgUiANL2ltMjA4IDU4MyAwIFIgDS9pbTIwOSA1ODUgMCBSIA0vaW0y MTAgNTg3IDAgUiANL2ltMjExIDY3NSAwIFIgDS9pbTIxMiA1OTEgMCBSIA0vaW0yMTMgNTkzIDAg UiANL2ltMjE0IDU5NSAwIFIgDS9pbTIxNSA2NzcgMCBSIA0vaW0yMTYgNTk5IDAgUiANL2ltMjE3 IDYwMSAwIFIgDS9pbTIxOCA2MDMgMCBSIA0vaW0yMTkgNjc5IDAgUiANL2ltMjIwIDYwNyAwIFIg DT4+IA1lbmRvYmoNMjcgMCBvYmoNWyANMjkgMCBSIDg4NCAwIFIgODg2IDAgUiAzMSAwIFIgMzMg MCBSIDM1IDAgUiAzNyAwIFIgMzkgMCBSIDQxIDAgUiANNDMgMCBSIDQ1IDAgUiA0NyAwIFIgNDkg MCBSIDUxIDAgUiA1MyAwIFIgNTUgMCBSIDU3IDAgUiA1OSAwIFIgNjEgMCBSIA02MyAwIFIgNjUg MCBSIDY3IDAgUiA2OSAwIFIgNzEgMCBSIDczIDAgUiA3NSAwIFIgNzcgMCBSIDc5IDAgUiA4MSAw IFIgDTgzIDAgUiA4NSAwIFIgODcgMCBSIDg5IDAgUiA5MSAwIFIgOTMgMCBSIDk1IDAgUiA5NyAw IFIgOTkgMCBSIDEwMSAwIFIgDTEwMyAwIFIgMTA1IDAgUiAxMDcgMCBSIDEwOSAwIFIgMTExIDAg UiAxMTMgMCBSIDExNSAwIFIgMTE3IDAgUiANMTE5IDAgUiAxMjEgMCBSIDEyMyAwIFIgMTI1IDAg UiAxMjcgMCBSIDEyOSAwIFIgMTMxIDAgUiAxMzMgMCBSIA0xMzUgMCBSIDEzNyAwIFIgMTM5IDAg UiAxNDEgMCBSIDE0MyAwIFIgMTQ1IDAgUiAxNDcgMCBSIDE0OSAwIFIgDTE1MSAwIFIgMTUzIDAg UiAxNTUgMCBSIDE1NyAwIFIgMTU5IDAgUiAxNjEgMCBSIDE2MyAwIFIgMTY1IDAgUiANMTY3IDAg UiAxNjkgMCBSIDE3MSAwIFIgMTczIDAgUiAxNzUgMCBSIDE3NyAwIFIgMTc5IDAgUiAxODEgMCBS IA0xODMgMCBSIDE4NSAwIFIgMTg3IDAgUiAxODkgMCBSIDE5MSAwIFIgMTkzIDAgUiAxOTUgMCBS IDE5NyAwIFIgDTE5OSAwIFIgMjAxIDAgUiAyMDMgMCBSIDIwNSAwIFIgMjA3IDAgUiAyMDkgMCBS IDIxMSAwIFIgMjEzIDAgUiANMjE1IDAgUiAyMTcgMCBSIDIxOSAwIFIgMjIxIDAgUiAyMjMgMCBS IDIyNSAwIFIgMjI3IDAgUiAyMjkgMCBSIA0yMzEgMCBSIDIzMyAwIFIgMjM1IDAgUiAyMzcgMCBS IDIzOSAwIFIgMjQxIDAgUiAyNDMgMCBSIDI0NSAwIFIgDTI0NyAwIFIgMjQ5IDAgUiAyNTEgMCBS IDI1MyAwIFIgMjU1IDAgUiAyNTcgMCBSIDI1OSAwIFIgMjYxIDAgUiANMjYzIDAgUiAyNjUgMCBS IDI2NyAwIFIgMjY5IDAgUiAyNzEgMCBSIDI3MyAwIFIgMjc1IDAgUiAyNzcgMCBSIA0yNzkgMCBS IDI4MSAwIFIgMjgzIDAgUiAyODUgMCBSIDI4NyAwIFIgMjg5IDAgUiAyOTEgMCBSIDI5MyAwIFIg DTI5NSAwIFIgMjk3IDAgUiAyOTkgMCBSIDMwMSAwIFIgMzAzIDAgUiAzMDUgMCBSIDMwNyAwIFIg MzA5IDAgUiANMzExIDAgUiAzMTMgMCBSIDMxNSAwIFIgMzE3IDAgUiAzMTkgMCBSIDMyMSAwIFIg MzIzIDAgUiAzMjUgMCBSIA0zMjcgMCBSIDMyOSAwIFIgMzMxIDAgUiAzMzMgMCBSIDMzNSAwIFIg MzM3IDAgUiAzMzkgMCBSIDM0MSAwIFIgDTM0MyAwIFIgMzQ1IDAgUiAzNDcgMCBSIDM0OSAwIFIg MzUxIDAgUiAzNTMgMCBSIDM1NSAwIFIgMzU3IDAgUiANMzU5IDAgUiAzNjEgMCBSIDM2MyAwIFIg MzY1IDAgUiAzNjcgMCBSIDM2OSAwIFIgMzcxIDAgUiAzNzMgMCBSIA0zNzUgMCBSIDM3NyAwIFIg Mzc5IDAgUiAzODEgMCBSIDM4MyAwIFIgMzg1IDAgUiAzODcgMCBSIDM4OSAwIFIgDTM5MSAwIFIg MzkzIDAgUiAzOTUgMCBSIDM5NyAwIFIgMzk5IDAgUiA0MDEgMCBSIDQwMyAwIFIgNDA1IDAgUiAN NDA3IDAgUiA0MDkgMCBSIDQxMSAwIFIgNDEzIDAgUiA0MTUgMCBSIDQxNyAwIFIgNDE5IDAgUiA0 MjEgMCBSIA00MjMgMCBSIDQyNSAwIFIgNDI3IDAgUiA0MjkgMCBSIDQzMSAwIFIgNDMzIDAgUiA0 MzUgMCBSIDQzNyAwIFIgDTQzOSAwIFIgNDQxIDAgUiA0NDMgMCBSIDQ0NSAwIFIgNDQ3IDAgUiA0 NDkgMCBSIDQ1MSAwIFIgNDUzIDAgUiANNDU1IDAgUiA0NTcgMCBSIDQ1OSAwIFIgDV0NZW5kb2Jq DTI4IDAgb2JqDTMyOSANZW5kb2JqDTI5IDAgb2JqDTw8IC9MZW5ndGggMjggMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmnr2lMksNyc19gBwl6b6DkNbdfPmdCYsafBbDNCmBR8 M/XRVrGoG8hZGNioPCj9k8Kk/T9XfrMTFSi+0NignczsBwPakX4XLlA0SAeItxJXCOAGbBkH4bkS xzqilJUDvIpwVH7rOcDlJi0Xstc0vITh0VAzQ/Pr6ZdEWj38XINtBVRhcWMThiMXPg+u+j69epS3 eRPpzV7KohTxEVTcG1C+JK+RyF87REE04iX66j5PlRsA9NYkfpR3jFspWq5VGUkhAeWZFRd+0JSc G3Eje4baLz1lEW+YeeNy8H+sLUsWQA0V0oMF12rie7vofVSLlO3YIOLtXJhMPSXlSnLIn/Lcmah9 KXPcaPqqq1jHUgjxRMfgtNUQBcwC+j6RE/PO+WJ8dloLis0ftkDPBmM0/ox6BqEo4l8VXWafhtoM bYhZr2aHbUZyAtniDWVuZHN0cmVhbQ1lbmRvYmoNMzAgMCBvYmoNNzQ1IA1lbmRvYmoNMzEgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzMCAwIFIgPj4gDXN0cmVhbQ0KTE9E FJyqudLHAG+Wh9GkhER8hoX9Lvccf2yY1VQ7DWoTd5YdkUCj/OIMJ36yPGZx8xjfoHbGiNe6vDly wwYnLDJN6leOzGQncNDokG03YfMWu77togFS8e4dYJlv4lCC1euQUHkyWiXExXhKh48ctyWXEoh1 w7KExenj9I5T4oru2AF1HBi1Sk+9UtbxuL4tIZ5eL0rQRIXd13+nGP3t6FeBqCUa2RAUqixyKhdn BHtjeajAg4aB3laLcZLu5dz3tssIRckIKu6b1wwoAfCEIohOipzyCJ22XgF25WTvEGwskEfwngwN 0nGWqm6NbTtAuOhqji9zaFyUrtVavqO9vqTzvSZuLg2+CZ2M6ImC3vEQ+x/LZ1rPEm4STDxD0E/B xUd+WjN/nCLv2N+fMSMidO9yvbNBRYrvEgmhfpkCT+JuLWYWFh8cUXL1+gbNA8JaDK6qOZok8LVI /DE7m5tFmPrkiFfBSW2jZTqcHeOrChLSot4atn197Kry3Pg26D7/eCg8cfeQBiGj87UxjQOddWAe EH0v6poUSjw5wMegaMdf5wCqpwGtPS39AlDoiyTx5hSvzyywUdtLiRIYqwZ1yaSAZm48y4V+jKKS 5AQolgxzU87JLEqtPq0JEfYDWrpCBupJuoI6xqw1xvNLnQEO+II3omCJtUStbN/FOHV685UprA90 Y/kDJUEWdniDLP2/DKS8CgDuhHaDzvZkBGGsCrKhoVyQX2m8Wc+TBVffBX3ZpW0+zACrdCmG95dT bPHcEtbC9VUtEAZxTdo1Q8sdt4k3hnnS5IMDXMF5O6evgO+7v1JF5RcUIXDI7jGHJSzbWfav76e/ Q6z/nkcTBRNFwSXAKwC0l0TAoRGpbUmSgg8w7Z0AtPpEcAnHOKjvCIkApeb/iCJcFoExB8QYlpSe Y0xQI80D4Xbj5o12JQXyH6tWyJ/fax4b+nb0LSQwtCKq9FRr1PJtWGC5QEXYJ1ha8dstMQm1P80J wQ1lbmRzdHJlYW0NZW5kb2JqDTMyIDAgb2JqDTUwIA1lbmRvYmoNMzMgMCBvYmoNPDwgL0xlbmd0 aCAzMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KDk6Iyc+Qw3O1KgYNw+ud bXepg8Oaem8fZD/fVYvLHQQKD5mynraRqv6TqsYBKoBDEIoNZW5kc3RyZWFtDWVuZG9iag0zNCAw IG9iag00OSANZW5kb2JqDTM1IDAgb2JqDTw8IC9MZW5ndGggMzQgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCrvCkuY2QmDVKrnjFqMHNHQozZPtTeU2QSjeHFcnMRdQVj/2xJQq 2YzhAm1vDdtaMC4NZW5kc3RyZWFtDWVuZG9iag0zNiAwIG9iag01NCANZW5kb2JqDTM3IDAgb2Jq DTw8IC9MZW5ndGggMzYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrlXM9uD caMYmIyuTbZsCUdni7YRaEtoJIaFQI79pP3rPwaP1kBTgtpzGKH928xiHgoXbSFBGw1lbmRzdHJl YW0NZW5kb2JqDTM4IDAgb2JqDTU0IA1lbmRvYmoNMzkgMCBvYmoNPDwgL0xlbmd0aCAzOCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KEB2P3G9+VcmwZDuvUGZC1MKFirYdr58L jFH/V9+mDOI9YwPhJ+V23VCD/tULAl7MMkMXUGf/DWVuZHN0cmVhbQ1lbmRvYmoNNDAgMCBvYmoN NTUgDWVuZG9iag00MSAwIG9iag08PCAvTGVuZ3RoIDQwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQqp6Bd0M7j8qZhKktffiKOPGPQCpZ6Je893diznJOhKA9aKC62XMLdQEcGM 3wI7jZZ4IyByBLJYDWVuZHN0cmVhbQ1lbmRvYmoNNDIgMCBvYmoNNTQgDWVuZG9iag00MyAwIG9i ag08PCAvTGVuZ3RoIDQyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqSeqbd EVEOypP1N//UvYPONUparPSChPmqD+VczT7zWF/+5rshdu+RFOfqdNrnK2fCgyAXusINZW5kc3Ry ZWFtDWVuZG9iag00NCAwIG9iag01NSANZW5kb2JqDTQ1IDAgb2JqDTw8IC9MZW5ndGggNDQgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NChbKRbOvuNNFOEi7sjE3JbSFe7lMh5re xjzHXdeXYWJmRvrU0sbIU2FiBLkIFGUkXaiVSdWHJLQNZW5kc3RyZWFtDWVuZG9iag00NiAwIG9i ag01NCANZW5kb2JqDTQ3IDAgb2JqDTw8IC9MZW5ndGggNDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCh8QGFenKQx9vt4u28BM1dCUDQ1UuMnD480LsPHE9xC8Mvuua3hN6eWo AJUW2umyzgzaX0hKCg1lbmRzdHJlYW0NZW5kb2JqDTQ4IDAgb2JqDTU0IA1lbmRvYmoNNDkgMCBv YmoNPDwgL0xlbmd0aCA0OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KUH9C PSWjOior9gr82Js8Qm00cYL7gJyCHENou+GYZN8aTe/YQGnhuzgDFw/LwqXkNQKSZZvlDWVuZHN0 cmVhbQ1lbmRvYmoNNTAgMCBvYmoNNTQgDWVuZG9iag01MSAwIG9iag08PCAvTGVuZ3RoIDUwIDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrwWy5kcw2OyixZjZ4Z519RhfcBjMFf csK+dHsD9X+q+SX+DaLfA040l7E6tg6ziVV7vy318g0NZW5kc3RyZWFtDWVuZG9iag01MiAwIG9i ag01NCANZW5kb2JqDTUzIDAgb2JqDTw8IC9MZW5ndGggNTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCo7J+vqxNJkWVjCSPPA+XGvqUlddtaua3iEbCuOu+/aELcpeiJLl08ug dac4bGh7rNcVzGWvdQ1lbmRzdHJlYW0NZW5kb2JqDTU0IDAgb2JqDTU1IA1lbmRvYmoNNTUgMCBv YmoNPDwgL0xlbmd0aCA1NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KeRXL K5CvSwLhxXuXJ7I6w3hf0P2P3ve7Z2zgAX0nrUaZAHQouE65PFqHgYilnqZScCaT6NcA5A1lbmRz dHJlYW0NZW5kb2JqDTU2IDAgb2JqDTUyIA1lbmRvYmoNNTcgMCBvYmoNPDwgL0xlbmd0aCA1NiAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KbkvbzwrugKpni/o7GZ2fqGG5Kbma gSYyYYBFxDM2MPjRh1FXWeE1MEOWEOc/Z85Zm9rL0Q1lbmRzdHJlYW0NZW5kb2JqDTU4IDAgb2Jq DTUzIA1lbmRvYmoNNTkgMCBvYmoNPDwgL0xlbmd0aCA1OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KufvTpV4D5yB52EyZRQm/IiqmwtcCWcKd/mA5/pJ8aNzVwhm0M1hwaCMx Z+cHf/vlTpxHJnwNZW5kc3RyZWFtDWVuZG9iag02MCAwIG9iag01MiANZW5kb2JqDTYxIDAgb2Jq DTw8IC9MZW5ndGggNjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmn9Tr4N AmfvG2I3gBzjdl+7ixmMf0CTPLbwqscUb7OV0pkiT7GR4X4G4npYIKzZ9w5DszYNZW5kc3RyZWFt DWVuZG9iag02MiAwIG9iag01MyANZW5kb2JqDTYzIDAgb2JqDTw8IC9MZW5ndGggNjIgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrXrJ6LGs2CkZxL/Gl5A+ge6+Pk9kvqHg+KY QY6DTAT2hEG+0k1EeF/ZCLcFaijZhZiRiCn4DWVuZHN0cmVhbQ1lbmRvYmoNNjQgMCBvYmoNNTQg DWVuZG9iag02NSAwIG9iag08PCAvTGVuZ3RoIDY0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQqrvC0Ct1O4CWGyawzANqNJvfFzcFtkRvsWFIYSfqxPRzIbvy3lTPCujCD0nR0F stuTJEpgjL8NZW5kc3RyZWFtDWVuZG9iag02NiAwIG9iag01MiANZW5kb2JqDTY3IDAgb2JqDTw8 IC9MZW5ndGggNjYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCoXkTR3U4v8I 17iTznzAe1mjvOB4GdzLwAadhXhVgz3uO3Caw/YpWtSBPKNbWp86YdZBcloNZW5kc3RyZWFtDWVu ZG9iag02OCAwIG9iag01MCANZW5kb2JqDTY5IDAgb2JqDTw8IC9MZW5ndGggNjggMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmlmaEVhpWJ8hbGMTTojyW49CrqwvzXXcsl3PSnp 8JzEVZiN8M1mOuFTajKqei7DjDSlDWVuZHN0cmVhbQ1lbmRvYmoNNzAgMCBvYmoNNTUgDWVuZG9i ag03MSAwIG9iag08PCAvTGVuZ3RoIDcwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQrQI0GtfLlgiBspjue6sC0C56pbQ0qY688hrVjzGmae9qIbeit00ZSdRe4Qb28xq3H5rqTE 0R9oDWVuZHN0cmVhbQ1lbmRvYmoNNzIgMCBvYmoNNTIgDWVuZG9iag03MyAwIG9iag08PCAvTGVu Z3RoIDcyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrWdHr20bya5UWzQg6h Fev/GQ0/g2P5CR2SqaqEEbvxNSShQiBYQwLKC/XFBJEhPuSlUunQDWVuZHN0cmVhbQ1lbmRvYmoN NzQgMCBvYmoNNTUgDWVuZG9iag03NSAwIG9iag08PCAvTGVuZ3RoIDc0IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQp3sIpnH7FqyEFIoYh8i+L/ox4jpxcrMPDBpDQ0BZ60SR89 cNO4gSe0brBVeWMNxLMRLQ5wCzR+DWVuZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNNTEgDWVuZG9i ag03NyAwIG9iag08PCAvTGVuZ3RoIDc2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQq6hHlLntLUHyy4krA9VprfRVHzUpEdFkucl4IN/LoAfHogPwXFAOP4xT6j7hSpz+fIXeoN ZW5kc3RyZWFtDWVuZG9iag03OCAwIG9iag01NSANZW5kb2JqDTc5IDAgb2JqDTw8IC9MZW5ndGgg NzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCu964zMTC+1Q3vQfhw89NEmk Il+QZn7DgNjB/qU2qFrbGi2PCwbOyBQ5TBePXRJLam7X02kd3PENZW5kc3RyZWFtDWVuZG9iag04 MCAwIG9iag01NCANZW5kb2JqDTgxIDAgb2JqDTw8IC9MZW5ndGggODAgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCmagJG9u++OQ2VtlRAEnPf7dsSvkNC2QExX6BfQdF11Ca3tG XgWlivPCPS0zvaDCzjK8UQehZA1lbmRzdHJlYW0NZW5kb2JqDTgyIDAgb2JqDTUyIA1lbmRvYmoN ODMgMCBvYmoNPDwgL0xlbmd0aCA4MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0Kyl6Ov9Q9ofHHkfGjasleMo14xizlSoO0HThKwsZPyQYsyCDa3mwpske/D8U83vu/2pvNIg1l bmRzdHJlYW0NZW5kb2JqDTg0IDAgb2JqDTU0IA1lbmRvYmoNODUgMCBvYmoNPDwgL0xlbmd0aCA4 NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KeUIKUz7eLwTkSNkS4sq389tw O/yX7mkpvjzLQQKqaAZgV9iPmu+stD2iZYSHvuBx19th+OQvDWVuZHN0cmVhbQ1lbmRvYmoNODYg MCBvYmoNNTMgDWVuZG9iag04NyAwIG9iag08PCAvTGVuZ3RoIDg2IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQrB2Uv8/lgZvi+/Nri7pvw4wC73PrVEUAe+8/RNxt8A/gMaGWId XdkOJGYVcXHHfkjfVPbTqg1lbmRzdHJlYW0NZW5kb2JqDTg4IDAgb2JqDTUxIA1lbmRvYmoNODkg MCBvYmoNPDwgL0xlbmd0aCA4OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K a7ScQ7MOUtl8k/LCp6ta23tw5OsfhFH8F+TTJwVUbetl+vA+wz7IVznVe4wZb+l2m1WODWVuZHN0 cmVhbQ1lbmRvYmoNOTAgMCBvYmoNNTAgDWVuZG9iag05MSAwIG9iag08PCAvTGVuZ3RoIDkwIDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrN3Gh2OxYCFKqKJSYvLxXQxebjE8pD G5FcK0z8Gg8bEGTMZ08AXE6bdxpUubvJu/8McA1lbmRzdHJlYW0NZW5kb2JqDTkyIDAgb2JqDTUz IA1lbmRvYmoNOTMgMCBvYmoNPDwgL0xlbmd0aCA5MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0KtxVB/NGDNAR8dYjItmo0INbM3MlbwsTF1PjTIK+rnIvCjwu47Gp0LAn/zhSP qnfYF4HBYXINZW5kc3RyZWFtDWVuZG9iag05NCAwIG9iag01MyANZW5kb2JqDTk1IDAgb2JqDTw8 IC9MZW5ndGggOTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCqXBk35iKu10 akjXLL4WVDUbE5xJ1iR6ap7lKXx+6GSOQ87TcbLjCBmFsS/DopcpR3978J2KDWVuZHN0cmVhbQ1l bmRvYmoNOTYgMCBvYmoNNTMgDWVuZG9iag05NyAwIG9iag08PCAvTGVuZ3RoIDk2IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrBvRVI3S2VPubLZ/ZEle7m8xw5Z6AC4Cr/jNxZ XjNlfU5mnSctsfXf+1qIzgCJMuekwcObFQ1lbmRzdHJlYW0NZW5kb2JqDTk4IDAgb2JqDTUzIA1l bmRvYmoNOTkgMCBvYmoNPDwgL0xlbmd0aCA5OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KefAaYeC8F4U3bW9PfG237Ec01W/Rp/O8MX8iseeuLtFT0RngTEIjqgGmw+bGPXMH d2nSWosNZW5kc3RyZWFtDWVuZG9iag0xMDAgMCBvYmoNNTIgDWVuZG9iag0xMDEgMCBvYmoNPDwg L0xlbmd0aCAxMDAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCiK499zz9VDy Gq6aaREZXOOJHrcfMwsPYrogEci8NPG5CBvIugE+JDJywUGhF9w1N7TRVykNZW5kc3RyZWFtDWVu ZG9iag0xMDIgMCBvYmoNNTAgDWVuZG9iag0xMDMgMCBvYmoNPDwgL0xlbmd0aCAxMDIgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCoaNv8iDzm8TFC6MmzoO2/z/yM/D9kgegPMG unARmp9iFDOjJZucbOEWCuhmbjgoruAHDWVuZHN0cmVhbQ1lbmRvYmoNMTA0IDAgb2JqDTUwIA1l bmRvYmoNMTA1IDAgb2JqDTw8IC9MZW5ndGggMTA0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQqCRP5KBfMToRywi8B8B1fYdfI/OOuzeSHpmis9sMzvEye/rAlhZ8YrrFAUefAD tSVtVw1lbmRzdHJlYW0NZW5kb2JqDTEwNiAwIG9iag01NSANZW5kb2JqDTEwNyAwIG9iag08PCAv TGVuZ3RoIDEwNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KYy4idcSEDsw3 sj5en5Aew3PPDg6ywzLljBg6lcvgFjJ6j0RoIZd9THV8RfFA4BNOCvzx35ZELA1lbmRzdHJlYW0N ZW5kb2JqDTEwOCAwIG9iag01MCANZW5kb2JqDTEwOSAwIG9iag08PCAvTGVuZ3RoIDEwOCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0Km+iuMke9nMsqQdgF/ay/1s6jQVVSpsr7 8yNB1ZsTg+TiV4eTM9tGfKhsnBWsfCLmJPcNZW5kc3RyZWFtDWVuZG9iag0xMTAgMCBvYmoNNTIg DWVuZG9iag0xMTEgMCBvYmoNPDwgL0xlbmd0aCAxMTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCrf9M11dSsNLesVewGo4wGmXFoA4lmLE71P5+iySD9G6/SQLxvfGeTwjXmW0 qOROQ7Jda1cNZW5kc3RyZWFtDWVuZG9iag0xMTIgMCBvYmoNNDkgDWVuZG9iag0xMTMgMCBvYmoN PDwgL0xlbmd0aCAxMTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCnFakRK4 7KoP95wG0o/VLVII6ksWevj2aWy3ofnnr4eo/EGnnFsADF4WCj+mK1HxkIoNZW5kc3RyZWFtDWVu ZG9iag0xMTQgMCBvYmoNNTQgDWVuZG9iag0xMTUgMCBvYmoNPDwgL0xlbmd0aCAxMTQgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCl7tCRrXwqjn/crH1pLjZmZ6cspeOHmRSefR 6ffito8MzUtSOxwctewGfRONyGDG4HZnIgQSvw1lbmRzdHJlYW0NZW5kb2JqDTExNiAwIG9iag01 NCANZW5kb2JqDTExNyAwIG9iag08PCAvTGVuZ3RoIDExNiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KAoi8A429XXb54bxzR9QEpFptzkkbkG5xnBkVnotOuVJcVj4trtkMXheJ phm6APog6fggEQglDWVuZHN0cmVhbQ1lbmRvYmoNMTE4IDAgb2JqDTU0IA1lbmRvYmoNMTE5IDAg b2JqDTw8IC9MZW5ndGggMTE4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpi dY63Oyc/gbv37ZSjhHhGGtaF/7bU+UyJJ7xZXlxgmERXSkMmIRBDRmDat63dimzD6yiFAQwNZW5k c3RyZWFtDWVuZG9iag0xMjAgMCBvYmoNNTEgDWVuZG9iag0xMjEgMCBvYmoNPDwgL0xlbmd0aCAx MjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCibJ7RkqT+PRv9ndKc0LxEiH cyeBVSFz7vpKrCEbJgsUw28vaZ0vpt5BjHDUP9pW80D9HA1lbmRzdHJlYW0NZW5kb2JqDTEyMiAw IG9iag01MyANZW5kb2JqDTEyMyAwIG9iag08PCAvTGVuZ3RoIDEyMiAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KJAGgVYTlrTGRvlWFT8OS93m00nfsAqQ6WeC92wEovs+tWjlx bMf8Y12+2ubj1uVWsZS4ajcNZW5kc3RyZWFtDWVuZG9iag0xMjQgMCBvYmoNNTMgDWVuZG9iag0x MjUgMCBvYmoNPDwgL0xlbmd0aCAxMjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCrkHOu+8sgBiml8VRj0sg002/WkCa5vctLQh6tUROe6SsyqZieXZXx5+5bdGR0qZkLGCgml4 DWVuZHN0cmVhbQ1lbmRvYmoNMTI2IDAgb2JqDTUyIA1lbmRvYmoNMTI3IDAgb2JqDTw8IC9MZW5n dGggMTI2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoq1z8LYOzOulJwn5Bh hYk+exd8C4SvXTxit9ALIF9ug9Cdi6zbC3myU3NquE6rRg+6iEMJDWVuZHN0cmVhbQ1lbmRvYmoN MTI4IDAgb2JqDTUyIA1lbmRvYmoNMTI5IDAgb2JqDTw8IC9MZW5ndGggMTI4IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpKgxePtvd1fpdKbSaKZoD5kts6+gevHS9Rh5Va68Ao FPBmvJIdgl/8+8JJAqTzSr53V0gjDWVuZHN0cmVhbQ1lbmRvYmoNMTMwIDAgb2JqDTU0IA1lbmRv YmoNMTMxIDAgb2JqDTw8IC9MZW5ndGggMTMwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQqaTvouf5ntFmi8yd1hPDSLqubcWHCgl2s/xH4psgtEXS38NkDkcw9GgG2p7AjaOISB aoeYMcQNZW5kc3RyZWFtDWVuZG9iag0xMzIgMCBvYmoNNTQgDWVuZG9iag0xMzMgMCBvYmoNPDwg L0xlbmd0aCAxMzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvIK1m8kdvLR unfEsj7l+U6xo0NlLRBXgI8xSmJ7uEz+STRBywEV2g0Ye+qMzJyWdB6x7YN7pA1lbmRzdHJlYW0N ZW5kb2JqDTEzNCAwIG9iag01MyANZW5kb2JqDTEzNSAwIG9iag08PCAvTGVuZ3RoIDEzNCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KLKHU4IGLQgTP8efS+Q7lQ8qPYL7Iy0gI 3N3+pR11e017ne+KnBOcbRp/xuSN/yJZZVDGhIUNZW5kc3RyZWFtDWVuZG9iag0xMzYgMCBvYmoN NTIgDWVuZG9iag0xMzcgMCBvYmoNPDwgL0xlbmd0aCAxMzYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NClbjvZ2/nel85qzZAeIdo/WSY7fxvFTk93RKxT5uGeEw6CCqC6CrSVFr ME6d94bPC+ThldYNZW5kc3RyZWFtDWVuZG9iag0xMzggMCBvYmoNNTMgDWVuZG9iag0xMzkgMCBv YmoNPDwgL0xlbmd0aCAxMzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCm3/ kEJYbwbwovYsTtxu80Yv1fc21wv6c98+EBD40U/RJjz+Z8hbCOykVsrAlY5Mwgza5C4BDWVuZHN0 cmVhbQ1lbmRvYmoNMTQwIDAgb2JqDTUxIA1lbmRvYmoNMTQxIDAgb2JqDTw8IC9MZW5ndGggMTQw IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQo76kph4L9dSeYVWTQ5pxtIaGum bvaX6Ik1ITipyQybjM3LEVt9+OR/aUmDo/14F465w0oNZW5kc3RyZWFtDWVuZG9iag0xNDIgMCBv YmoNNTIgDWVuZG9iag0xNDMgMCBvYmoNPDwgL0xlbmd0aCAxNDIgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCtQQZYl2U5yI2TqQSR1/9sqZ+4ZP1OrOjnLoO+IOBlzDmKeQ4dJl MF0L/K+7+AOYFFQLmpYNZW5kc3RyZWFtDWVuZG9iag0xNDQgMCBvYmoNNDkgDWVuZG9iag0xNDUg MCBvYmoNPDwgL0xlbmd0aCAxNDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0N CgQmJcxxWHxN2YgE/KT+kgiLt/StMnlMkVWzb5DyTljOiqOqsnaTZwv68FD5VBA5LboNZW5kc3Ry ZWFtDWVuZG9iag0xNDYgMCBvYmoNNTEgDWVuZG9iag0xNDcgMCBvYmoNPDwgL0xlbmd0aCAxNDYg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NChb7YxzqOwZ76MWjx4Tt9mX7l+di 9xb1fYsrv6+AZpeRid5uVc3QG9+S9GF5Ns0oC+GtHA1lbmRzdHJlYW0NZW5kb2JqDTE0OCAwIG9i ag01MCANZW5kb2JqDTE0OSAwIG9iag08PCAvTGVuZ3RoIDE0OCAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KYj9iOcyL96nh8EE2OBThp5pofYy/E9mrGIbXcCWZ9ImNj+/Fvn7D B3GK213MVkQC4JwNZW5kc3RyZWFtDWVuZG9iag0xNTAgMCBvYmoNNDkgDWVuZG9iag0xNTEgMCBv YmoNPDwgL0xlbmd0aCAxNTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCjgb wjPPpYdpZYSKeLgc3HoHv9H1CkodJNNH+s1vsFqd/jkLVwjm7LUPbnnCUHjKIJ0NZW5kc3RyZWFt DWVuZG9iag0xNTIgMCBvYmoNNTEgDWVuZG9iag0xNTMgMCBvYmoNPDwgL0xlbmd0aCAxNTIgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkcNkGbgxsPJE2emyGsNDgIXrWWQWwAk Qzx7tK1MwGq+8rSEs4FYrqERFKlk33p8y4vqDQ1lbmRzdHJlYW0NZW5kb2JqDTE1NCAwIG9iag01 MyANZW5kb2JqDTE1NSAwIG9iag08PCAvTGVuZ3RoIDE1NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0Kgg4doQog4HnGIOcsDliZJoIJjFnOOIRGLqadBojdecyPAhNR8ZhJ18by O7WC7/sg3LuhjxsNZW5kc3RyZWFtDWVuZG9iag0xNTYgMCBvYmoNNTMgDWVuZG9iag0xNTcgMCBv YmoNPDwgL0xlbmd0aCAxNTYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvan WO38eYDksUxWsL6xV4VlavwYMsQbk73T98RiZz5yRvhTAKRMoia85YmZ4HOmExekHoyUDWVuZHN0 cmVhbQ1lbmRvYmoNMTU4IDAgb2JqDTUzIA1lbmRvYmoNMTU5IDAgb2JqDTw8IC9MZW5ndGggMTU4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrFOvgbCLm9kt7frq9tMfWiXimQ HdLRAgNm9s95inV2Tw8dbhmGfrNsnjDBSQOqyhC/yaYtig1lbmRzdHJlYW0NZW5kb2JqDTE2MCAw IG9iag01MyANZW5kb2JqDTE2MSAwIG9iag08PCAvTGVuZ3RoIDE2MCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KUrBhtD88G9OYOEqMNSSejU40+n2pgZ9JRkDFSFx+9dUlWEUi 2ZLVQE8VgSIhmoiH9JieNC8NZW5kc3RyZWFtDWVuZG9iag0xNjIgMCBvYmoNNTQgDWVuZG9iag0x NjMgMCBvYmoNPDwgL0xlbmd0aCAxNjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCpv8bUgRnhAqPFkowR9cw7mblK03/KK28EMp/78niVdRt5BEPro7ZSWT9LRM40i+uzDvXJO+ Tw1lbmRzdHJlYW0NZW5kb2JqDTE2NCAwIG9iag01MCANZW5kb2JqDTE2NSAwIG9iag08PCAvTGVu Z3RoIDE2NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KHUX+Xx8q5XLebPCD oLoO8pzZhtqef1l4mqdKfqyHhhuuGR7Q9DfgVEkngKEfbnuGJPINZW5kc3RyZWFtDWVuZG9iag0x NjYgMCBvYmoNNTMgDWVuZG9iag0xNjcgMCBvYmoNPDwgL0xlbmd0aCAxNjYgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCoLZrO++rnyYWH5JC7yHxYo0JrlKZUa3BfXJpWBjKuhT s1e5NyLvBZyr1rjhVHfXmpGrhgbbDWVuZHN0cmVhbQ1lbmRvYmoNMTY4IDAgb2JqDTUxIA1lbmRv YmoNMTY5IDAgb2JqDTw8IC9MZW5ndGggMTY4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQq5tK7z3Fdd0S3XByEZxLdRFj8CkMFowJ3dhF0OtzXC/cb46Re38CIAjNBL/MfuU42h S1sNZW5kc3RyZWFtDWVuZG9iag0xNzAgMCBvYmoNNTIgDWVuZG9iag0xNzEgMCBvYmoNPDwgL0xl bmd0aCAxNzAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrybEdITMji3ET1c AlJdo4M/8lMCIqqdVami2XyIh52AVNtgwN3Ol+eVtTGPSvfVIBDabucNZW5kc3RyZWFtDWVuZG9i ag0xNzIgMCBvYmoNNTMgDWVuZG9iag0xNzMgMCBvYmoNPDwgL0xlbmd0aCAxNzIgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkoeho2CyDnx2gY4nqxXsQ5Z5gYfKAs9s7aOIfz5 RAEk2CC6ErJPVDH5qHwz8CiFK6FiGIn9DWVuZHN0cmVhbQ1lbmRvYmoNMTc0IDAgb2JqDTUyIA1l bmRvYmoNMTc1IDAgb2JqDTw8IC9MZW5ndGggMTc0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpfbmd7XJmehK0oxK4qHxnh4gEOTIQuZiykrSYYe6oCdjSNTvo1/BQUgd2irn8s vYjNcSzQDWVuZHN0cmVhbQ1lbmRvYmoNMTc2IDAgb2JqDTQ5IA1lbmRvYmoNMTc3IDAgb2JqDTw8 IC9MZW5ndGggMTc2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQphQroGKe1+ Rx5hsQpJxwSEn62xWk2OEmiA55RBiFvt8yawz8Q1HxgTMf4kQ6x6tz+ODWVuZHN0cmVhbQ1lbmRv YmoNMTc4IDAgb2JqDTE0ODIgDWVuZG9iag0xNzkgMCBvYmoNPDwgL0xlbmd0aCAxNzggMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvuJGiZAOlc6sxgK5KqLrRoRW5zdU2325grv ES1mMIrJXI2dYYgRdPgMttHejb1ifD8wgEh3Vla8lWVh3GSfE3tNJ+WL76ekjKgbTLcRR6gZsNkm JfkqiL4QH8C/PEEHnriqhfWiCAs1cyHyGephRCm0taOH88mcJOie5sL9i4pyzraEXUefYbFrV187 mj0e4Kzh6EacEul2OqCe4Kzw+di/in3jCQjTy9r0YNOHmFCrOqPS4sfMZz3lqN54STtZkA4RRff7 H7XR3LnDds9oQDDK4TJuG/uTH13o6FL/QQMm8ug0RqnX5RZy1IKfcEZz1Kh78ruqV9DIxzE4zSad uZtYee4sqZw+l3xadIGQaqAva6I9KFT2imJAZQzYyw72L4WzxIYCkLJYgTyPtrvCNP17/Wsyk9fd Oq4CQ9b/K4IQCZURKqDxeKwLtO6zBA4Amiui4wBghAz0RBqA1lNggsT9dy6p2YNjCfEa8LMNa65z bGoiw/F/OxryYkRDek+keoLm2CJ903SGXYECepBAmjVimb27xBmIdTTRpZ75rXyxK76ayRKPhC98 bo8Lm5Pf0FQDmvcu6g1x4/crjtBFR0ENLGRZm3gNNS8FWKZTl5YSDI0vVKhonk3alSqV2dPQCGsj XoRc+DZxCd2NhUYlcJNcIMaGq59PwHBcrSID1C8rn1QE82tYQdmwyrUS4RMkXwtiwvP2EuGhz44V jK7u11ySit7U/gysLX7gNDZp1s9Fk+eTGk4L9c7nb/g0H2FSomZym7yQgsXxhw2NLEKwykZzgKtD iG5AcU1FD8Dwqs9VkpnM+6NPpDsU98YhuDrxhtmnqq+hbw1D/yA3zuiZuAdqgbk3HKu/JJJJEnBZ CQmJqDxZEM3aAG7JXyUsKPcCS637L6SMvJ5B9r1WB2zu2UnSgrQ/SQxyxCqxMHTLLJ0mk9+bDfNA 5r6H9Bp72OVIYdu/oLeRzYJ02/N2DFY3yGSM89kutdL4M3jyNYsXPqmALFoobnRU0sscDEjYy1PE xRI88Ddo/rPWDnx0s+kJ+4xSJeMTLefB8Bw+ll6IdaR2pngBVrstLW53gXEdlgU9cFOROsxyQi5B bpPAN5lXAtY2U+qt8IPlxOBqm8yqNbiQ6dpVy2sGq1qWilXHiSkLy89P7xo4p3xEppKiyMCNNK2q T9Mgrt6kFnJFBUPfgZmOLCDsrGm8dN+Dj7kFrGIzeuvFr4pmIHSBbkr6GH6+uXUcxde2h86W55Gb eVq+thM0E7lDMZdfgcs82h1E+dA6/59dKZnFjm8BMHcJKqRnjqmL9Pzlsv5TawF3UUUKHD7+UpaG Pox9nZD2r6VUZQ0W312e8h0/qHZjLSu5uh7kd+Ce/IqLGuKAbJGpV0ceGHZRpEidtv9D49V+98EL svZ7FVrb5jLCTL5qF8oA051dCP00C7EqJNBU7Lh5oj9D5Yd06/W20jpHOZMbTAX571oHyJUWIHNQ dU6fnNqKFM0yeGTirYJtJjEEi6nZXbDK1O00qOcUDgMYM0OIMxA3ZUqaavxLF5R5rzJ1z8wL2+U7 FBsnPzyuowxlp0dIGPXJasyHvM5dFQ2Ez0v4P16wlZLvYI/fL5XJcwwR5wMRzpkFemXi2WrT8aCk YRPM+8AID5YY7QWSuya44Nw+YxLBe0wrfiIP5eULSHc/NsiNfXgQlv3p1pG1yS4BuCXtmNgMQCTr ezUZrCPhsdPyANgvr0dVapJnhTWdwlcv4c8918Lo8zxY/5Mrx/XeaNrEAmCqiFl5AXQ/AxgjpH1U HBqKQE/xLlsoN+opIwJhA01SsoE5mO4ExiI5ypy2gl8yN72PmO3mIt6l/WCogI63x9nf68cgQktR QLjh+1HnTP4ts8qfCEhLx9U74RsQ9j4sP0NTuXAhUgbOvdjViORGrzwpu9uxu9jMGSvc8fG8q0hG QPP04gql81JK0xlEmAU62KuwDgH8zD1H0xg35uf4Wg1lbmRzdHJlYW0NZW5kb2JqDTE4MCAwIG9i ag01MSANZW5kb2JqDTE4MSAwIG9iag08PCAvTGVuZ3RoIDE4MCAwIFIgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KGVwWEaRzDEurm/3pC/ztlQOlQChNKMEbrP1ZMnDkTDYA64cgiQE/ Nic1MOxLJMXj6iaxDWVuZHN0cmVhbQ1lbmRvYmoNMTgyIDAgb2JqDTUzIA1lbmRvYmoNMTgzIDAg b2JqDTw8IC9MZW5ndGggMTgyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrj Cv4/s2BqAYjFz3+LopdaUXe4kufUL6F8CwgnxQRkB0G6Z+QJuwnyp/4aqM5HFWoSAznG3A1lbmRz dHJlYW0NZW5kb2JqDTE4NCAwIG9iag01NCANZW5kb2JqDTE4NSAwIG9iag08PCAvTGVuZ3RoIDE4 NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSTi2v7UcsC85F0yTdsOz3I4Q EDv5nYyhyjyEb5NpgyCv3rY1b655lCC8rcPOGPHce0SRj500DWVuZHN0cmVhbQ1lbmRvYmoNMTg2 IDAgb2JqDTU1IA1lbmRvYmoNMTg3IDAgb2JqDTw8IC9MZW5ndGggMTg2IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQqVlMBTIrslQP3hlvnAg1xhAPXAFBLltZkCPFNfDqVOpyCi 6g4rk44dTsD9qqlqL+O8R/plyek+DWVuZHN0cmVhbQ1lbmRvYmoNMTg4IDAgb2JqDTU0IA1lbmRv YmoNMTg5IDAgb2JqDTw8IC9MZW5ndGggMTg4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQr4OWesAUxMSUQ3DrFSDeqH84nks8MCdLAs4vo17vi0ITjiYTUaWq61jx1WW9Yn4JQQ rSLYD8gNZW5kc3RyZWFtDWVuZG9iag0xOTAgMCBvYmoNNTMgDWVuZG9iag0xOTEgMCBvYmoNPDwg L0xlbmd0aCAxOTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCveMCpSekQiu gEp01rDIbgCvIikBuhT6g5VnHrh5ig3neppVB21D8A0hmWSAlDa5Pcyw28hcDWVuZHN0cmVhbQ1l bmRvYmoNMTkyIDAgb2JqDTU0IA1lbmRvYmoNMTkzIDAgb2JqDTw8IC9MZW5ndGggMTkyIDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpgebaCEuUsr+Ob3lZ5Q4wgEPUetz97SfvH TxlcXIshLRMLAlOPpIR5fgdI2QEwhREyakbVSiwNZW5kc3RyZWFtDWVuZG9iag0xOTQgMCBvYmoN NTQgDWVuZG9iag0xOTUgMCBvYmoNPDwgL0xlbmd0aCAxOTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCuNQsWzScOcf1ZjtoBtkSsfRcsoJT9c96MQkKjusyRzCZTFZX8NGr4Cq 4/CInIvDQea4+h4tSA1lbmRzdHJlYW0NZW5kb2JqDTE5NiAwIG9iag01NCANZW5kb2JqDTE5NyAw IG9iag08PCAvTGVuZ3RoIDE5NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K w6eYsCYOKIKVBcMtXk3PjQJBdVklWDZc/aQschwOrnZHPmptkZa/XJRBNoQMru8ryj8mT8Q0DWVu ZHN0cmVhbQ1lbmRvYmoNMTk4IDAgb2JqDTU0IA1lbmRvYmoNMTk5IDAgb2JqDTw8IC9MZW5ndGgg MTk4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrMfxymL9F/XXXXwRHwqzbt TT2If+ui/4Xxfhp68WzicJgaMtnme4vph/XgnJwiUVhPnOPqgbANZW5kc3RyZWFtDWVuZG9iag0y MDAgMCBvYmoNNTQgDWVuZG9iag0yMDEgMCBvYmoNPDwgL0xlbmd0aCAyMDAgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrSiZGgpsC4TbM4Id0fuwhZt8lREgxp1X3G3NXj91KQ8 9dMFXo+pvD8hXxF/8yLz0ym61le0kg1lbmRzdHJlYW0NZW5kb2JqDTIwMiAwIG9iag01MyANZW5k b2JqDTIwMyAwIG9iag08PCAvTGVuZ3RoIDIwMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KLV2AyEibTvWS7TtRDPs72p8FFy24AIDuj6mXgTCGw66SG1Xt/E/jzgx25OZzxqY+ e5ViZF8NZW5kc3RyZWFtDWVuZG9iag0yMDQgMCBvYmoNNTMgDWVuZG9iag0yMDUgMCBvYmoNPDwg L0xlbmd0aCAyMDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrXDjm+r7vEl gQMhcaOpYOqvc/Mhxo5j4iNXaTWkU/DMbdY42WWJAWYODrFg65H0EgrKMAl6DWVuZHN0cmVhbQ1l bmRvYmoNMjA2IDAgb2JqDTUyIA1lbmRvYmoNMjA3IDAgb2JqDTw8IC9MZW5ndGggMjA2IDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqr1hiHvUplkWqqYgMepK0/I4R2IPC+pPKz E/aYxE4MukoLgyfkpmpgqhBsIMyoi6KPSpAZDWVuZHN0cmVhbQ1lbmRvYmoNMjA4IDAgb2JqDTQ5 IA1lbmRvYmoNMjA5IDAgb2JqDTw8IC9MZW5ndGggMjA4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQqEMXclafcMwza1CRGAaNpeicboIqN4faCrlr810A7529/Fuu0RizuTNAKc hecsgn39DWVuZHN0cmVhbQ1lbmRvYmoNMjEwIDAgb2JqDTUwIA1lbmRvYmoNMjExIDAgb2JqDTw8 IC9MZW5ndGggMjEwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqYKpQZXOyn f5Z5IHhJN/PD+y3xaWHq/CV1+zWcS02Nad1HjMKgraoIeisyZRNy3h39Bw1lbmRzdHJlYW0NZW5k b2JqDTIxMiAwIG9iag01MSANZW5kb2JqDTIxMyAwIG9iag08PCAvTGVuZ3RoIDIxMiAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KXDJ3PI6pgXlCB560rKcvgQYvGcsFGAx+b0eR X/yUeZdzXtHi/DlC7yruGQZ3qt8SBPKZDWVuZHN0cmVhbQ1lbmRvYmoNMjE0IDAgb2JqDTUyIA1l bmRvYmoNMjE1IDAgb2JqDTw8IC9MZW5ndGggMjE0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQqMUwabjRibOl3atC82tL9aHUQZkepQU22N0ZDt9pMV/olz3kmeCooeQ36l80Qs E3qWVUR9DWVuZHN0cmVhbQ1lbmRvYmoNMjE2IDAgb2JqDTU0IA1lbmRvYmoNMjE3IDAgb2JqDTw8 IC9MZW5ndGggMjE2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpmapTfh+FA XUdv9dpCrZFNY82yVWiwzOkc/lrTtJN9nMBtO7mD+WOLzRRv3xO3VO4Qp0JscgQNZW5kc3RyZWFt DWVuZG9iag0yMTggMCBvYmoNNTUgDWVuZG9iag0yMTkgMCBvYmoNPDwgL0xlbmd0aCAyMTggMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmM8e6Gin5DX4RmlLAHwQfOoI8xiOn8n faG0SwqdILzkIUp+tNOPs74R76HmQzUCvWwdVgxLxdwNZW5kc3RyZWFtDWVuZG9iag0yMjAgMCBv YmoNNTYgDWVuZG9iag0yMjEgMCBvYmoNPDwgL0xlbmd0aCAyMjAgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCn8JNmqb/4ERwSkIkWFlQmSmzVR6tm+N+kPyHtPAOQpiYTb9hbaH ESX5IycoEQX13wFtW2qtvlblDWVuZHN0cmVhbQ1lbmRvYmoNMjIyIDAgb2JqDTU2IA1lbmRvYmoN MjIzIDAgb2JqDTw8IC9MZW5ndGggMjIyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQope8AHTQc4bgvKpPo5B27YJ2FlN7LKA21KMSagnP6k0c2qKiNZ7P8VZT9INJs71UBHqaJ0 ZexYyw1lbmRzdHJlYW0NZW5kb2JqDTIyNCAwIG9iag01NiANZW5kb2JqDTIyNSAwIG9iag08PCAv TGVuZ3RoIDIyNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KQ7ke91MgiFDs xRjRkPW0y9p4EQrbdAaYjQJ49qTtDK/cbsoImvziLm6iLmo3FIPQ7dq08e8Ldz8NZW5kc3RyZWFt DWVuZG9iag0yMjYgMCBvYmoNNTMgDWVuZG9iag0yMjcgMCBvYmoNPDwgL0xlbmd0aCAyMjYgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCi5ZyUxxDKFiG5YOAWp4O0EUXzMlobLB Qx3iCAiGudkJXynh5FMtat62UIJsPH8hNxS0zR9PDWVuZHN0cmVhbQ1lbmRvYmoNMjI4IDAgb2Jq DTUzIA1lbmRvYmoNMjI5IDAgb2JqDTw8IC9MZW5ndGggMjI4IDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQrY3XPlyYz3PrJcVTMeu/WXqZ0pbxYJ1PgZqTC39EXXiB2JIcukJMXk elUGNTN2UFhdFpLVTw1lbmRzdHJlYW0NZW5kb2JqDTIzMCAwIG9iag01MyANZW5kb2JqDTIzMSAw IG9iag08PCAvTGVuZ3RoIDIzMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K LctgowauAIK+7hKgVSo8JXCYqrpm4nGa8VvqY3eo1irq3UuoEosIt4sn67r+f0yAoJn7M40NZW5k c3RyZWFtDWVuZG9iag0yMzIgMCBvYmoNNTQgDWVuZG9iag0yMzMgMCBvYmoNPDwgL0xlbmd0aCAy MzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmUJmd/ANbAMlCqrnWjRsYhZ d+Nv1ikSAKQg48O2kMXPFY9aqM9cR1h8dwgzzWmDtBf+r0O0Sw1lbmRzdHJlYW0NZW5kb2JqDTIz NCAwIG9iag01NCANZW5kb2JqDTIzNSAwIG9iag08PCAvTGVuZ3RoIDIzNCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K/iZiZM6bS1kLpfa4g6SmIvH5NcOCqJawp1Yz2kLg8chP YrTi6+K8B7ltsEdf8QFytWrGUY69DWVuZHN0cmVhbQ1lbmRvYmoNMjM2IDAgb2JqDTQ3IA1lbmRv YmoNMjM3IDAgb2JqDTw8IC9MZW5ndGggMjM2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQqq/nqvYI4pEUPyVAH9ZUzjMa9MD+SY8R+kvSHl+Sf9WRlHXmQltNiR/mFRo9E8NQ1l bmRzdHJlYW0NZW5kb2JqDTIzOCAwIG9iag00OSANZW5kb2JqDTIzOSAwIG9iag08PCAvTGVuZ3Ro IDIzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KmsPv4Sv+q9jkyMQDckPO 7QRcok1tOlBwq/EJRLTsvSA/Ig1u7PVO2rJtg8Qg0Ps1FQ1lbmRzdHJlYW0NZW5kb2JqDTI0MCAw IG9iag01NCANZW5kb2JqDTI0MSAwIG9iag08PCAvTGVuZ3RoIDI0MCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0Kxz7ea9n1HWh1CKM8zet25BWKF4SJ+QAcPqiB0q43bZP5vaWp 6L77Di79NkRVLqVd5EYlsNtmDWVuZHN0cmVhbQ1lbmRvYmoNMjQyIDAgb2JqDTUyIA1lbmRvYmoN MjQzIDAgb2JqDTw8IC9MZW5ndGggMjQyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQpeklHHnZDK2kdd1LwkjC10pVpXkX1qX6nJBZ26EVElnR5+owythOoZE1n9wBZ9c7QZh6CA DWVuZHN0cmVhbQ1lbmRvYmoNMjQ0IDAgb2JqDTUxIA1lbmRvYmoNMjQ1IDAgb2JqDTw8IC9MZW5n dGggMjQ0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpxJaeU1XtkOA0+Ckfq z3UrsTHHkKXLePnjE5+XEYjTHegWzIitpaRqP3XJFKZj5VnvyVgNZW5kc3RyZWFtDWVuZG9iag0y NDYgMCBvYmoNNTQgDWVuZG9iag0yNDcgMCBvYmoNPDwgL0xlbmd0aCAyNDYgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCsbH4BXK+0AEnzW/DtxD6Q/W1WjOsQq4ffhiOQHmVG7S yRhp2n6PHUMUWqjoGeXQWC1HIehKUQ1lbmRzdHJlYW0NZW5kb2JqDTI0OCAwIG9iag01NCANZW5k b2JqDTI0OSAwIG9iag08PCAvTGVuZ3RoIDI0OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0KoLRaOiE4LotLDwfOZlIscJfO7CGuCFq64FsiVvb+uNyOwAfz9T8uYn/AXRJYd9l4 B6hzCZGGDWVuZHN0cmVhbQ1lbmRvYmoNMjUwIDAgb2JqDTUyIA1lbmRvYmoNMjUxIDAgb2JqDTw8 IC9MZW5ndGggMjUwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrZE9hGLuWM mZ8UkbtFFkgWRsZmROIU+6UGKb4FJ7+MW5S8Lc+6apP9cvesVPtfBnMRk0vODWVuZHN0cmVhbQ1l bmRvYmoNMjUyIDAgb2JqDTU0IA1lbmRvYmoNMjUzIDAgb2JqDTw8IC9MZW5ndGggMjUyIDAgUiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqWY/FkR1+JHgwM26gTmRgOaTdZ7aGCUu+v m7Taodt73eouP+snHXofXg/sG5iw9cGNNozL0PANZW5kc3RyZWFtDWVuZG9iag0yNTQgMCBvYmoN NTEgDWVuZG9iag0yNTUgMCBvYmoNPDwgL0xlbmd0aCAyNTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCiLqYui22gsAcXltT+yqPlHUQ7eTnlhJUEaQIJJGsskPpo9O+HvEfnrJ oAaPq3g/3z+XCw1lbmRzdHJlYW0NZW5kb2JqDTI1NiAwIG9iag01NCANZW5kb2JqDTI1NyAwIG9i ag08PCAvTGVuZ3RoIDI1NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KD9P7 tHJHK/zmb4IgCW0iT8RDSwc4WeKdTsxF3wGZuKa8Aa6jYSr0zVETYGk0gW3ci3PzapnNDWVuZHN0 cmVhbQ1lbmRvYmoNMjU4IDAgb2JqDTU2IA1lbmRvYmoNMjU5IDAgb2JqDTw8IC9MZW5ndGggMjU4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpncPu1k3cJONLxfoTewYFM2KEK kbZuqECVl4uFqIRC7VYQJ1unQSsF7nAJQ2iXKIdPyPEAC5XcbA1lbmRzdHJlYW0NZW5kb2JqDTI2 MCAwIG9iag01NCANZW5kb2JqDTI2MSAwIG9iag08PCAvTGVuZ3RoIDI2MCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KKRw8O8A4FHdxxLooM7h7EpZ3ypymE3BMni0dFk+AsVMH YUMAqcYHV7RfxbB9ThRwPDxqdsZQDWVuZHN0cmVhbQ1lbmRvYmoNMjYyIDAgb2JqDTU0IA1lbmRv YmoNMjYzIDAgb2JqDTw8IC9MZW5ndGggMjYyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQq5uqdgdlf1+KqGe6Vu5AQrZ4jvIf4AaTngLclkhepIWSOC/1JkAmQZXE34irZIbHyQ DYO1bfoNZW5kc3RyZWFtDWVuZG9iag0yNjQgMCBvYmoNNTQgDWVuZG9iag0yNjUgMCBvYmoNPDwg L0xlbmd0aCAyNjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCrkmV7qJNvNH rntnT+30jjhNSUYnl1TfRH8jbwWCElb3RT61rQeBsFTyBdGrJgM7Uj5KnZxtQQ1lbmRzdHJlYW0N ZW5kb2JqDTI2NiAwIG9iag01MiANZW5kb2JqDTI2NyAwIG9iag08PCAvTGVuZ3RoIDI2NiAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K+r8CmKOR93kCej8u6gPC3Ze8FdjdROXs Bi8GmiVK/fLJzNxuAOyNN/L6uWbc06Lw/Xj48g1lbmRzdHJlYW0NZW5kb2JqDTI2OCAwIG9iag01 NCANZW5kb2JqDTI2OSAwIG9iag08PCAvTGVuZ3RoIDI2OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KmFkP9M0f70YKuaw7EJMcS4LSyqBVY1wbqbQaHkDXgwC4rwGG0d+Gs2Wp jnM5nv3DZXXiHXOADWVuZHN0cmVhbQ1lbmRvYmoNMjcwIDAgb2JqDTU2IA1lbmRvYmoNMjcxIDAg b2JqDTw8IC9MZW5ndGggMjcwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrG V5w2d/rcq2oJ2DdE/McAdcH0kL1cwPiUyBg7Cx32rCwz9i8ihaYY4FoeqUOcgDadVWIiZqf2nQ1l bmRzdHJlYW0NZW5kb2JqDTI3MiAwIG9iag01NCANZW5kb2JqDTI3MyAwIG9iag08PCAvTGVuZ3Ro IDI3MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KbwvxuNRsZGQeNGaIaSwg aC1OoksSNlOKl0OXEmmtxH8L8APK6+Fgi7a0ELTTuqXgAd4zvFIbDWVuZHN0cmVhbQ1lbmRvYmoN Mjc0IDAgb2JqDTU1IA1lbmRvYmoNMjc1IDAgb2JqDTw8IC9MZW5ndGggMjc0IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQp0lmqBfC8LUgY77iv6z5FsUWXzKPxNS0rpIFuurvfi TC7BqLvRe1gkXs0+CYHsglAs2p2qKNRLDWVuZHN0cmVhbQ1lbmRvYmoNMjc2IDAgb2JqDTU0IA1l bmRvYmoNMjc3IDAgb2JqDTw8IC9MZW5ndGggMjc2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQoVOfNkNWatAw8CgqaOLKfRLkFszFdUljBCryvlV60FtwGHWva5oS6wdmzxNnK1 /wkTMvXffa4NZW5kc3RyZWFtDWVuZG9iag0yNzggMCBvYmoNNTYgDWVuZG9iag0yNzkgMCBvYmoN PDwgL0xlbmd0aCAyNzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCpUpNhmA tgHWiXQiYgAc4SuevYa5ZorEG9XnsXhQOiDb58O97avdTDmvBHzw542+CT4frwjrkwQDDWVuZHN0 cmVhbQ1lbmRvYmoNMjgwIDAgb2JqDTU1IA1lbmRvYmoNMjgxIDAgb2JqDTw8IC9MZW5ndGggMjgw IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoRzH3Hwp7h6lIJ54lB0lovmGrJ bkl6UFitr/lem18fAyAFwx2hJNyXig8roGXUKXCTD3gn5aMMDWVuZHN0cmVhbQ1lbmRvYmoNMjgy IDAgb2JqDTU1IA1lbmRvYmoNMjgzIDAgb2JqDTw8IC9MZW5ndGggMjgyIDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQo/ZSQGj4nttK+IxGdL4q1QtRnh0eaZojRto2Pfry/K0bY3 WPB7Ph6Hgs0A1n9ug4L034mxRyTADWVuZHN0cmVhbQ1lbmRvYmoNMjg0IDAgb2JqDTUzIA1lbmRv YmoNMjg1IDAgb2JqDTw8IC9MZW5ndGggMjg0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQq74sSqJe/9EQqLIA+3xc5EaD2D0Ecbkms67zCtgcLlxvPESK9NYkkdt73m8SAg13o0 2N6h/g1lbmRzdHJlYW0NZW5kb2JqDTI4NiAwIG9iag01MCANZW5kb2JqDTI4NyAwIG9iag08PCAv TGVuZ3RoIDI4NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KdDhz2sPS1pOR J5S/oJz4Hy/LhN/4pu5bPaUgStYVfie7Dn+kwIVPwujS4pphKwxmsnUNZW5kc3RyZWFtDWVuZG9i ag0yODggMCBvYmoNNTMgDWVuZG9iag0yODkgMCBvYmoNPDwgL0xlbmd0aCAyODggMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCpXJsBoFbh0QmSXAa1uCxolU0V/2oNzgshsnzPfN 4mjRQxM5nsfBULlumhywNyIRPW4KIq06DWVuZHN0cmVhbQ1lbmRvYmoNMjkwIDAgb2JqDTU1IA1l bmRvYmoNMjkxIDAgb2JqDTw8IC9MZW5ndGggMjkwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQrocTlTvfJ/P5lr+hpSJyttsy/0yvHLbmTPyGLuXwty3vvSnIEsgh23JENm+7uz nzOAvpKaLvrBDWVuZHN0cmVhbQ1lbmRvYmoNMjkyIDAgb2JqDTU1IA1lbmRvYmoNMjkzIDAgb2Jq DTw8IC9MZW5ndGggMjkyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpqiPIf iJnrs4I/qnDz50zp/SFNYBaACVde7HLH66aoAzJFiZDHQf0u/E3PEFMaFrtX2S+8uEBXDWVuZHN0 cmVhbQ1lbmRvYmoNMjk0IDAgb2JqDTU2IA1lbmRvYmoNMjk1IDAgb2JqDTw8IC9MZW5ndGggMjk0 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqdrmao36W6wCG1ilrlWfwdBw+L v7Bch6n3TeiAXpf0SFVpMh6SIBJIBXL8o02NduF426ZIxYlgOA1lbmRzdHJlYW0NZW5kb2JqDTI5 NiAwIG9iag01NCANZW5kb2JqDTI5NyAwIG9iag08PCAvTGVuZ3RoIDI5NiAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KhGAnlL2F6dq7cFdE3F7DYWN7JcAWrWG2Vfdm3EUYOMZ3 mE33LmpsPlwUKCEknea20+ccTcsaDWVuZHN0cmVhbQ1lbmRvYmoNMjk4IDAgb2JqDTUzIA1lbmRv YmoNMjk5IDAgb2JqDTw8IC9MZW5ndGggMjk4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQptsk/yaB9rAVPlFzXtiuvdXf/seEF05iTLcYukdgb3FIx5ah9P5n1DbPWs+6vgYy+w 1uCCMg1lbmRzdHJlYW0NZW5kb2JqDTMwMCAwIG9iag01NiANZW5kb2JqDTMwMSAwIG9iag08PCAv TGVuZ3RoIDMwMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K0/gYf2KmHyTi OjwegzTC5Nl3C4dGNUhjQnHILrWUa56/Usfw6j5SITuEv/yTeLTgixYcligE22MNZW5kc3RyZWFt DWVuZG9iag0zMDIgMCBvYmoNNTYgDWVuZG9iag0zMDMgMCBvYmoNPDwgL0xlbmd0aCAzMDIgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCnITxmahEzvz3kRHtliiao8OBEy/gznt e81yJiAgPhHzx0fAb2avRpSxdq0aywKQso6sz0r3OQGmDWVuZHN0cmVhbQ1lbmRvYmoNMzA0IDAg b2JqDTU0IA1lbmRvYmoNMzA1IDAgb2JqDTw8IC9MZW5ndGggMzA0IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQoP/n5T13d7fVAaUr2v5Qdx3PiQ9VZEsNnOodOrD6f/nIYiwFGD IouW4buoanJxq8xqugoDsaYNZW5kc3RyZWFtDWVuZG9iag0zMDYgMCBvYmoNNTIgDWVuZG9iag0z MDcgMCBvYmoNPDwgL0xlbmd0aCAzMDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NClgfkXNJRVhqNz+gbny6x3SiZnl35SOm03bjw+LHWDLdauRHI0TIeK96aa3ITl+vG5rPbTAN ZW5kc3RyZWFtDWVuZG9iag0zMDggMCBvYmoNNTYgDWVuZG9iag0zMDkgMCBvYmoNPDwgL0xlbmd0 aCAzMDggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCjWNdgNZ5kn3XqiVt+d/ pATPYl+EP2MeONb64XNyxHk7h3x9MUNAu4V4mciSjqCEe+MAH06OJP08DWVuZHN0cmVhbQ1lbmRv YmoNMzEwIDAgb2JqDTU1IA1lbmRvYmoNMzExIDAgb2JqDTw8IC9MZW5ndGggMzEwIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQonUlf61mCLbZ5DK3gGz7Q73it/NjjYvmiEVnF4 3/wUht+Do8p35GzqUs7re89CiCYBPZr3pUTqDWVuZHN0cmVhbQ1lbmRvYmoNMzEyIDAgb2JqDTUz IA1lbmRvYmoNMzEzIDAgb2JqDTw8IC9MZW5ndGggMzEyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQoz3tZeDUjhYt24AdCg+mw27abybgWwSGNe+SBQnXRcrgJWbXFrKzdaqxxB Xi+wiEMFxOQFZQ1lbmRzdHJlYW0NZW5kb2JqDTMxNCAwIG9iag01NCANZW5kb2JqDTMxNSAwIG9i ag08PCAvTGVuZ3RoIDMxNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KIkdw 3sCONm32dlv/XOSfWwmojivifBXU+dheygrd7mmOZvVT0mL80Y+Be9PIL+lCkPocx0G/DWVuZHN0 cmVhbQ1lbmRvYmoNMzE2IDAgb2JqDTUyIA1lbmRvYmoNMzE3IDAgb2JqDTw8IC9MZW5ndGggMzE2 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpjMWj8HY/w8JXqXmmB/vW8PS8Z kpLs6oVEkTDcw9UYC77JYolbDzPQjZuMf79d1CkE1sHRDWVuZHN0cmVhbQ1lbmRvYmoNMzE4IDAg b2JqDTU0IA1lbmRvYmoNMzE5IDAgb2JqDTw8IC9MZW5ndGggMzE4IDAgUiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQr9w50XubSzoDlEsqxn31Ond9Pf1FMVsJM0otwjUCM5FSO/rnBV W1QJf4aKGcLTqz/yZ+QNs7cNZW5kc3RyZWFtDWVuZG9iag0zMjAgMCBvYmoNNTQgDWVuZG9iag0z MjEgMCBvYmoNPDwgL0xlbmd0aCAzMjAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCq8U8/0QwiMTtJBafZCPCLZecNfiKB2GAcclAJoLzGiWlpPoFm//it+nSPZyQuz2IuBRwC3y qA1lbmRzdHJlYW0NZW5kb2JqDTMyMiAwIG9iag01MyANZW5kb2JqDTMyMyAwIG9iag08PCAvTGVu Z3RoIDMyMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KIWWFy71qZZp9LURg nE5nfGwpm3ehearBWHH8qvKWAB9PwWP+lEzSENo/yLWxRqmMdKDhNYANZW5kc3RyZWFtDWVuZG9i ag0zMjQgMCBvYmoNNTUgDWVuZG9iag0zMjUgMCBvYmoNPDwgL0xlbmd0aCAzMjQgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCiKnNA2mJgwBcAwZKoBzU/b2FO+QHOPOtUxQluQe TPuF2990ERwH460IlmhF2TsEZ5oDPzMfhS8NZW5kc3RyZWFtDWVuZG9iag0zMjYgMCBvYmoNNTUg DWVuZG9iag0zMjcgMCBvYmoNPDwgL0xlbmd0aCAzMjYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCvT57tA46m6Raj5VoxYYMcT7rRVhRTXBYs63Fsi8+BTwGOvHU//Vi81HL1Wd hozvBQoDV34R4T0NZW5kc3RyZWFtDWVuZG9iag0zMjggMCBvYmoNNTYgDWVuZG9iag0zMjkgMCBv YmoNPDwgL0xlbmd0aCAzMjggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCk7U drvvxpNwbc/eGY9S4jLhKzkd3p0n/gvtJTS0nDLWUtfTTwDh7sZsDRAUVoEhUca/6PcOE9RbDWVu ZHN0cmVhbQ1lbmRvYmoNMzMwIDAgb2JqDTUzIA1lbmRvYmoNMzMxIDAgb2JqDTw8IC9MZW5ndGgg MzMwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoTrmiizpWEVzhvK9BMrR3c 8nqR0Ka7GYHHFicwvA2mZKhy71t8H+X0QVe7+gKB3ESqg+SlxQ1lbmRzdHJlYW0NZW5kb2JqDTMz MiAwIG9iag01MCANZW5kb2JqDTMzMyAwIG9iag08PCAvTGVuZ3RoIDMzMiAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KLEGSvfTdURbzToARXCVprLgnv6xqI4sdafewRjneUP7Y DKabUZ4IP1WvQoY1kQhHRVMNZW5kc3RyZWFtDWVuZG9iag0zMzQgMCBvYmoNNTYgDWVuZG9iag0z MzUgMCBvYmoNPDwgL0xlbmd0aCAzMzQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCjYZDkWH6xNvv0OU3NAQxr8LqrAvtXySrzHBNDmIBg0xezj5cUvY/Nh3nK1360R2B5vHbeog UH7gDWVuZHN0cmVhbQ1lbmRvYmoNMzM2IDAgb2JqDTU2IA1lbmRvYmoNMzM3IDAgb2JqDTw8IC9M ZW5ndGggMzM2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoXDWQ2Uz0mVStL OT5quJSKxITGO4JKJngUUU01Dk87Bt7z8IZpXrMMqZ7iCyiAODam69fL67/uQg1lbmRzdHJlYW0N ZW5kb2JqDTMzOCAwIG9iag01NCANZW5kb2JqDTMzOSAwIG9iag08PCAvTGVuZ3RoIDMzOCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KGGbc4re7kYtlzdzxFpp5fG83puznTXNe pyazlx6L/UcGR/2YrsRID4cBY+tBubyHf+wpqIGDDWVuZHN0cmVhbQ1lbmRvYmoNMzQwIDAgb2Jq DTU1IA1lbmRvYmoNMzQxIDAgb2JqDTw8IC9MZW5ndGggMzQwIDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQobm/UCVBBxSVcKzNCV+WQGfpSBoqesuwjmWvb89RX92EygKq3rNz+F QwykiKqTOra4qHcCS5uMDWVuZHN0cmVhbQ1lbmRvYmoNMzQyIDAgb2JqDTU2IA1lbmRvYmoNMzQz IDAgb2JqDTw8IC9MZW5ndGggMzQyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQog+6rBaRAXiWwYF9tnNvetvpicH7Q1lyvZ2r5Ude9iUkHQlXvG21cP4vn+UBIjvKzW+DmdTtsI xQ1lbmRzdHJlYW0NZW5kb2JqDTM0NCAwIG9iag01NiANZW5kb2JqDTM0NSAwIG9iag08PCAvTGVu Z3RoIDM0NCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KB/1gH5wwxnLdnSnV 9rtmR5ILkm/1Tc7KmgN0D32y1pI0qI+GeIkk5luGSpffM/FHvBScpnqGWakNZW5kc3RyZWFtDWVu ZG9iag0zNDYgMCBvYmoNNTUgDWVuZG9iag0zNDcgMCBvYmoNPDwgL0xlbmd0aCAzNDYgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCiFww7xCgyCBXjL44xVwxzfoqw5HOTraeJ4+ 0Kfk559KZHBqo/xP4kJ7BhCoMSnJH3olKuJsf/wNZW5kc3RyZWFtDWVuZG9iag0zNDggMCBvYmoN NTIgDWVuZG9iag0zNDkgMCBvYmoNPDwgL0xlbmd0aCAzNDggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCl67H/0UQeE55H5+vn1yXxOXkY5mWTW1OVIUsWx0laI5a5O+MubbEphH rBDI1JNjQVYqIKQNZW5kc3RyZWFtDWVuZG9iag0zNTAgMCBvYmoNNTMgDWVuZG9iag0zNTEgMCBv YmoNPDwgL0xlbmd0aCAzNTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCseC e6ikPZdJg5cmLQt5GSsGt96Kg+GFhZQreXrmnj9tj7/S6jrGWiAtALID5D4SKHv/lsDXDWVuZHN0 cmVhbQ1lbmRvYmoNMzUyIDAgb2JqDTUzIA1lbmRvYmoNMzUzIDAgb2JqDTw8IC9MZW5ndGggMzUy IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqt1U3rMrudOTvW7A1LWY0EdWi8 frykCvz8CV+TsR3oRP3/GyczNBV7ZfPd2q0MSc0OXGtxWw1lbmRzdHJlYW0NZW5kb2JqDTM1NCAw IG9iag01MiANZW5kb2JqDTM1NSAwIG9iag08PCAvTGVuZ3RoIDM1NCAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KKBGLVn8RUgssIrWtuUNgSSPIacMWXHWAFL1ZaC/ZmPXFWO6D SqSykQccFTc4LpE/kMbYSA1lbmRzdHJlYW0NZW5kb2JqDTM1NiAwIG9iag01NCANZW5kb2JqDTM1 NyAwIG9iag08PCAvTGVuZ3RoIDM1NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KFQMSx9u+suKPvF+C3OjVAMDvqXKsIEKfvw8tzMWcgBaCaf1qruUz1N33dFfgKBU/IzRk5BP3 DWVuZHN0cmVhbQ1lbmRvYmoNMzU4IDAgb2JqDTU1IA1lbmRvYmoNMzU5IDAgb2JqDTw8IC9MZW5n dGggMzU4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQoBL4e5sU+vYxbctEch Z0DQJYBjRKIkt/niUVeJTbxBgDY3S6fdw0B93d3V1caMDrEdjy2jCYluDWVuZHN0cmVhbQ1lbmRv YmoNMzYwIDAgb2JqDTU0IA1lbmRvYmoNMzYxIDAgb2JqDTw8IC9MZW5ndGggMzYwIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqDfk2rUQXJmH9F/rjEqYEjq44K3YR9ehnweQg+ TFtTPaeRrZzLhS9560GeAooXtaur4caYmbgNZW5kc3RyZWFtDWVuZG9iag0zNjIgMCBvYmoNNTYg DWVuZG9iag0zNjMgMCBvYmoNPDwgL0xlbmd0aCAzNjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCjqJ778jbFpmNvINRYs/nHjbOw57A++7DcIVsMIz/OYQr5rL6Ux2X6Pam321 RhA9WRHz2drl57RUDWVuZHN0cmVhbQ1lbmRvYmoNMzY0IDAgb2JqDTUzIA1lbmRvYmoNMzY1IDAg b2JqDTw8IC9MZW5ndGggMzY0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQqI NKjRVKjiZ1ZhiYQ2a499XmGKqrCXFmzv3ZdOw4oPvbOZx6iYPt+LkoPsBZkPz5F0SC8QMQ1lbmRz dHJlYW0NZW5kb2JqDTM2NiAwIG9iag01MyANZW5kb2JqDTM2NyAwIG9iag08PCAvTGVuZ3RoIDM2 NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KebC1kJfBjJ4dyMZ+suWtPcZn WIK03VggHZp38tvbyQtvLn3RoPGMK/bFCDJtF/i4wlk0LfENZW5kc3RyZWFtDWVuZG9iag0zNjgg MCBvYmoNNTQgDWVuZG9iag0zNjkgMCBvYmoNPDwgL0xlbmd0aCAzNjggMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCq6/zniVnt4Qg7HFE+AZJMrERoJapX7lFEc7z0aFy4JgKurj Wzshtb8h1grJ4Qd+0QnIbL36Uw1lbmRzdHJlYW0NZW5kb2JqDTM3MCAwIG9iag01MyANZW5kb2Jq DTM3MSAwIG9iag08PCAvTGVuZ3RoIDM3MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KhbzEZs0whkwBBc2gdTw5mHm7VjAzFCTpGy/HEhR5DSrrdD7MXxvW3DkV+bRtdRKs0TRp p80NZW5kc3RyZWFtDWVuZG9iag0zNzIgMCBvYmoNNTMgDWVuZG9iag0zNzMgMCBvYmoNPDwgL0xl bmd0aCAzNzIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCtLg0gaD8KZR719/ fl0kWO/DNqWaNO6decivCdvVGYfjs2IS6ABZ0tmQPp3IMNTdsHXn2p4GDWVuZHN0cmVhbQ1lbmRv YmoNMzc0IDAgb2JqDTUxIA1lbmRvYmoNMzc1IDAgb2JqDTw8IC9MZW5ndGggMzc0IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQp9PmBE8iIwtAwsImW+5iqzdTKgOyoj+aacYX+z rSXQ6tlb8bV933d/L9QAUL0FDVB+1igNZW5kc3RyZWFtDWVuZG9iag0zNzYgMCBvYmoNNTIgDWVu ZG9iag0zNzcgMCBvYmoNPDwgL0xlbmd0aCAzNzYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCnUx4asWcZ0+LGIbjGeqhqO4Pwl2P3Jbrr5ugjCA9EyXYxWqb5E3wKecNUpaAC0K RMlnbhkNZW5kc3RyZWFtDWVuZG9iag0zNzggMCBvYmoNNDggDWVuZG9iag0zNzkgMCBvYmoNPDwg L0xlbmd0aCAzNzggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmtNKxufApqP V38Ux/o86vKfzhaXJY3yzMvvINcSc5vLvuPvoryFEwqwSRE1Lx3ecA1lbmRzdHJlYW0NZW5kb2Jq DTM4MCAwIG9iag00OSANZW5kb2JqDTM4MSAwIG9iag08PCAvTGVuZ3RoIDM4MCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KfQZFiqvBv/HMfvUgvqVZ5AmU+MeFdyHI0vzAazCc QsAwvE1Y96pp96Pgb0wFD85mTA1lbmRzdHJlYW0NZW5kb2JqDTM4MiAwIG9iag01MSANZW5kb2Jq DTM4MyAwIG9iag08PCAvTGVuZ3RoIDM4MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KC5L9j3JXThaUUdnI0OT0qzAk8qT1L6HnwpSs0Df0uADvnBZ6tgXvX9yiZFb6Ju6o2HPi DWVuZHN0cmVhbQ1lbmRvYmoNMzg0IDAgb2JqDTUzIA1lbmRvYmoNMzg1IDAgb2JqDTw8IC9MZW5n dGggMzg0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQraWvenzyyh1fkU5zZy 1vBZZkrgnOTXQruyYlmamzJkkNNbrqKwHvwSOuwg2wKmgzqIbdDKZA1lbmRzdHJlYW0NZW5kb2Jq DTM4NiAwIG9iag01NCANZW5kb2JqDTM4NyAwIG9iag08PCAvTGVuZ3RoIDM4NiAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KExMU3qAQdKmlZ3NqutOA3d35XozDaQXbpclDDWkn dD4Hc1ewyt+fX5aN1UegSu3IoFmfd0ApDWVuZHN0cmVhbQ1lbmRvYmoNMzg4IDAgb2JqDTU0IA1l bmRvYmoNMzg5IDAgb2JqDTw8IC9MZW5ndGggMzg4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQomhzXJj3TVAQegfDZnB44ojbUj2p790zOmj2V53GLbiLTMXOVai8FIqb0tRqG7 Rl7CeiYYpCoNZW5kc3RyZWFtDWVuZG9iag0zOTAgMCBvYmoNNTMgDWVuZG9iag0zOTEgMCBvYmoN PDwgL0xlbmd0aCAzOTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCpmzziIY m3dcw+4HyKcDsHEgMi0YS+YvENc2iR8SOdJZmbYFtyndwjxS9WJFvzvvYKswrtQFDWVuZHN0cmVh bQ1lbmRvYmoNMzkyIDAgb2JqDTUxIA1lbmRvYmoNMzkzIDAgb2JqDTw8IC9MZW5ndGggMzkyIDAg UiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQorYFO8HHijgngwK7z+sIaKpHGkxETQ okdCac4ZX+o4us9MA/wsPhOcdOVuhEew32hvnHsNZW5kc3RyZWFtDWVuZG9iag0zOTQgMCBvYmoN NTEgDWVuZG9iag0zOTUgMCBvYmoNPDwgL0xlbmd0aCAzOTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVj b2RlID4+IA1zdHJlYW0NCjmOMT6tJ3yEXQoQf0tQhItSZ+LBjvQitHlNyz/aDXCsw7Ems+Clj4uL fVfmgbJtWh6Fiw1lbmRzdHJlYW0NZW5kb2JqDTM5NiAwIG9iag01NCANZW5kb2JqDTM5NyAwIG9i ag08PCAvTGVuZ3RoIDM5NiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KjWHd sgBJxo6ccPQ9SuH2hZCx+YU4317MYWOK3L/WOlF1PBIGVwaDdrUhAT0zizNwqoLVybJUDWVuZHN0 cmVhbQ1lbmRvYmoNMzk4IDAgb2JqDTU2IA1lbmRvYmoNMzk5IDAgb2JqDTw8IC9MZW5ndGggMzk4 IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQr9DdfZnM6LuB7mciLvPQ9Q/j9J peEyWJNjL4kOqNPNcjqpJc8UW1ieIehhWliD2nAUKIgaKCHc2w1lbmRzdHJlYW0NZW5kb2JqDTQw MCAwIG9iag01MiANZW5kb2JqDTQwMSAwIG9iag08PCAvTGVuZ3RoIDQwMCAwIFIgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K015ACPrP3UrZVgIiT9HJVQVw3KA4cWBxN2LoFpU6J+UT d/El8epB8Dof8oMvbGIcHCUZDw1lbmRzdHJlYW0NZW5kb2JqDTQwMiAwIG9iag01MyANZW5kb2Jq DTQwMyAwIG9iag08PCAvTGVuZ3RoIDQwMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KAPzuq2EwMsv2hmGO1RLEED5z8KHIB3cRRj2iy12ALwvHJHW0i29mXkSmZ5ckJnQgik2D zLUNZW5kc3RyZWFtDWVuZG9iag00MDQgMCBvYmoNNTIgDWVuZG9iag00MDUgMCBvYmoNPDwgL0xl bmd0aCA0MDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvi52EyQnw9/Zt22 Gktf8PUHrD+WZ5DXz4u5PTpgoAjQw16RNcQR6dltQCLak4pBC/byiQYNZW5kc3RyZWFtDWVuZG9i ag00MDYgMCBvYmoNNTEgDWVuZG9iag00MDcgMCBvYmoNPDwgL0xlbmd0aCA0MDYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmUeqJknxWh+wslPa04cORoYHVUswWoWCgbgJtIG aNjIbWAASd+GxPuBbqCO/xN29vN4VA1lbmRzdHJlYW0NZW5kb2JqDTQwOCAwIG9iag01MyANZW5k b2JqDTQwOSAwIG9iag08PCAvTGVuZ3RoIDQwOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4g DXN0cmVhbQ0K4d+fcmjtr0bixnZlcrbKZm/F8TewRUN9lS974/PT3P013dxKMITOYMc8bDqLhdFK gITxI3ANZW5kc3RyZWFtDWVuZG9iag00MTAgMCBvYmoNNTQgDWVuZG9iag00MTEgMCBvYmoNPDwg L0xlbmd0aCA0MTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCtS8l9qliCZo FnjeSLKLhODUl8jMT3FKKQ3Ko/CwPZmJNHi9z2J8HgByGlY/x/PQ/nSq66MAow1lbmRzdHJlYW0N ZW5kb2JqDTQxMiAwIG9iag01NCANZW5kb2JqDTQxMyAwIG9iag08PCAvTGVuZ3RoIDQxMiAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KH6WyLehoNmQ1dCPAa6+cEzeUrJbxnS53 lhb6UvoIbXY6EfBBV4QfabeZIRksidr8VQC+mXzrDWVuZHN0cmVhbQ1lbmRvYmoNNDE0IDAgb2Jq DTU1IA1lbmRvYmoNNDE1IDAgb2JqDTw8IC9MZW5ndGggNDE0IDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpBCTYCEgSvbdDwm8sHzmPLFPMOuD86ElNEV8xuAf6DTE7LMl6lIEtE 3yB3YW0p9Dx2QAl48FkEDWVuZHN0cmVhbQ1lbmRvYmoNNDE2IDAgb2JqDTU0IA1lbmRvYmoNNDE3 IDAgb2JqDTw8IC9MZW5ndGggNDE2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpEtgOnifc0jofIUd5IpmARx88QatnhgqaawuCzfUverL1zMi27Emgd82BI0618RSyJHC3fYsoN ZW5kc3RyZWFtDWVuZG9iag00MTggMCBvYmoNNTUgDWVuZG9iag00MTkgMCBvYmoNPDwgL0xlbmd0 aCA0MTggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NClUFHSjK775eWF/HGAN0 XZOpVLd83FxLjnuC7JG1dUnp/E81oBU0ovC6BVNtkpcJgtXFmG2T/2MNZW5kc3RyZWFtDWVuZG9i ag00MjAgMCBvYmoNNTUgDWVuZG9iag00MjEgMCBvYmoNPDwgL0xlbmd0aCA0MjAgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmjdEo0i6DAeH2Q9fGrjB+seZvBZaixeZL18S6CU QiSpMY0Zy8XkZETWO9iNOtwdEkVmfENS1ZANZW5kc3RyZWFtDWVuZG9iag00MjIgMCBvYmoNNTQg DWVuZG9iag00MjMgMCBvYmoNPDwgL0xlbmd0aCA0MjIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NChyPlgC+2fCZPXMtn6SmRUmj4+6oBKYp/IAecmKdveUy5Zxvj1hMkzA5gdZd BQIQdxwRJktoEw1lbmRzdHJlYW0NZW5kb2JqDTQyNCAwIG9iag01MCANZW5kb2JqDTQyNSAwIG9i ag08PCAvTGVuZ3RoIDQyNCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KLPTX PJH/EB+5MFoTI5PRKfWHoeqAIDJ5LV1uOMGnH14TefFukhwtAUCYGNCw4KArPwQNZW5kc3RyZWFt DWVuZG9iag00MjYgMCBvYmoNNTMgDWVuZG9iag00MjcgMCBvYmoNPDwgL0xlbmd0aCA0MjYgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCnR8tzahuDB5VSgcGIb2UcFzHIaMPZgi 2k2CAfy5FwfJhr+AoJve2SMJcxJ8omJ8Mgdy57YgDWVuZHN0cmVhbQ1lbmRvYmoNNDI4IDAgb2Jq DTU2IA1lbmRvYmoNNDI5IDAgb2JqDTw8IC9MZW5ndGggNDI4IDAgUiAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpdyz7YSnrBlaYZ1X6plMbuHXRiPHSknsIDAX9wXBnWMv83xNNgZTOa nhdwxaXtxhKZzhNAhJCwcw1lbmRzdHJlYW0NZW5kb2JqDTQzMCAwIG9iag01NSANZW5kb2JqDTQz MSAwIG9iag08PCAvTGVuZ3RoIDQzMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KRqgKYj7IIfyoXKCMlaI7p4xqxK01UnVVodnkN0NGAgYk3jICS4Y54oGV9nuRaAd7EEz4iqsI 6w1lbmRzdHJlYW0NZW5kb2JqDTQzMiAwIG9iag01NSANZW5kb2JqDTQzMyAwIG9iag08PCAvTGVu Z3RoIDQzMiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0Ko4UdbzNu0hZLQDuG ZS5NXgag0Y52Hgpt3NquEStUKsYpV+uhynbPosI/PNBAWbAL8Lz4CvpO7Q1lbmRzdHJlYW0NZW5k b2JqDTQzNCAwIG9iag01NCANZW5kb2JqDTQzNSAwIG9iag08PCAvTGVuZ3RoIDQzNCAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSfGdXnUrPxnTZK/D9HKl5PXwD/ZbsugJKxvY EQAqQReoRR8pC6zVpphovGAzIHETjzjrcnjoDWVuZHN0cmVhbQ1lbmRvYmoNNDM2IDAgb2JqDTU2 IA1lbmRvYmoNNDM3IDAgb2JqDTw8IC9MZW5ndGggNDM2IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQohSOY2RIgzGBTIocy6qqrnWDpXgCQcXcZ13uzub7todUvRQ5iNjqCVqSAw qs+TJcU4p8Teh1t4mA1lbmRzdHJlYW0NZW5kb2JqDTQzOCAwIG9iag01NSANZW5kb2JqDTQzOSAw IG9iag08PCAvTGVuZ3RoIDQzOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K JSZJez+GIbW5552EKO0N2EKoKpwUPyH/aZ9e5ZmIRHIkm3QnBsqhGISMBUxrGCI4E+fuBoMP5Q1l bmRzdHJlYW0NZW5kb2JqDTQ0MCAwIG9iag01NSANZW5kb2JqDTQ0MSAwIG9iag08PCAvTGVuZ3Ro IDQ0MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KB8eyxExDkkVumodkBN5H Gdd4Ss8d1A0q13MmB7q/APbcqTpEb9QLA7pTwDQc+0Ey8GYLhMmUtQ1lbmRzdHJlYW0NZW5kb2Jq DTQ0MiAwIG9iag01NiANZW5kb2JqDTQ0MyAwIG9iag08PCAvTGVuZ3RoIDQ0MiAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KdYX0KwMQbBAM3gAUu+nWkepx6TK02zr3ItupceF8 5BhWNDwVUnR6NJfdGRl2mfpa+dUB6qP/7isNZW5kc3RyZWFtDWVuZG9iag00NDQgMCBvYmoNNTIg DWVuZG9iag00NDUgMCBvYmoNPDwgL0xlbmd0aCA0NDQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCnyB4sjDLM3pp4DAqB6PLuvRbZviHNLiiB+T+p4F9Bqc1XuiCB3YX9OTHuCk lokeeMVZuiUNZW5kc3RyZWFtDWVuZG9iag00NDYgMCBvYmoNNTQgDWVuZG9iag00NDcgMCBvYmoN PDwgL0xlbmd0aCA0NDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCmS/RDlv DLfBLAC5Hvb3LGCMxd3ZgNW5gpCSo9mGgPB1hF6zi5MhZM5lz8k94ihZrYDZVODsbQ1lbmRzdHJl YW0NZW5kb2JqDTQ0OCAwIG9iag01NiANZW5kb2JqDTQ0OSAwIG9iag08PCAvTGVuZ3RoIDQ0OCAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KjK8rKmXpIwkznfmbqHdgUT+cyxdC xCUJ4XkWRoNm85wVd46N5J7a2Yc1QXbeerlZ3TcRK9LDDlMNZW5kc3RyZWFtDWVuZG9iag00NTAg MCBvYmoNNTIgDWVuZG9iag00NTEgMCBvYmoNPDwgL0xlbmd0aCA0NTAgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCgWisNwgtZIDqHnfuaM2aO3Y0gIQsHg+vzJaO48bGaVvHs0I NchPtRM556DCNCcWnLMyNUsNZW5kc3RyZWFtDWVuZG9iag00NTIgMCBvYmoNNTUgDWVuZG9iag00 NTMgMCBvYmoNPDwgL0xlbmd0aCA0NTIgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCr9wK1+ATaXlI1/+CS5IylrNy4xTUOE/cfh+kcRP7aklky4j13KWJHc8PSgHo8uPaxtlqkVh F4MNZW5kc3RyZWFtDWVuZG9iag00NTQgMCBvYmoNNTIgDWVuZG9iag00NTUgMCBvYmoNPDwgL0xl bmd0aCA0NTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NClsxT5+0TJ+D5UV+ t3SOOvWJf8+4W8fQoFHQRrptphfKZx1gi+0vYC5pJeXzujYGcWVgq60NZW5kc3RyZWFtDWVuZG9i ag00NTYgMCBvYmoNNTIgDWVuZG9iag00NTcgMCBvYmoNPDwgL0xlbmd0aCA0NTYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NChOErJwBp4FpkKKzrDQ/cQIs9UwZdHu89LrwTg0N MaK6RZwWjaJss5SM0Pj093rgtgPExDQNZW5kc3RyZWFtDWVuZG9iag00NTggMCBvYmoNMjI4NiAN ZW5kb2JqDTQ1OSAwIG9iag08PCAvTGVuZ3RoIDQ1OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4gDXN0cmVhbQ0Kkv+C1tTh6epk/QiCWbWFQyd3O/VBDYVLgoVSekmhhrxRH2drH74I50C6ITRW eVX1Tvi3F2zmAHZr7Tz4HiU/nHpoH2nFcNDyOPNWyGCPYZkgrsh5DI3c6rLSlsQh8oEpGJuN+55N ZYWnUnut0qgy5IqwaEV0WJrJJ3kVx5vihI6mbtnFum9YM0bzkcq9wnyItN1IJXPWpKhmFl74DZQX icIddbnOCwDm1PDPk4u2RlbVFfKe96dQLSDk2h8y3svPiAxk25K8wigULbnEyaZfX+d+hDar2iXJ pGTC3H4LOnC+pavro/1jogYGdb7A0eknBpAGXAgNwz+6so4P/XaYzT2BmXZW6qi1+NN0IcPbKhzK UZ2nhHULhfVMRuu2F3z3Q6IdeH1Nzhz+dBdybRLmPxT2umJpmBRmG8mREhyKuc4kT3ZGBdzmpTNB at2pbl0Y9xF7r04+07pUdcVTURl5MCcaUkMdu5PfC76zIwGUJQJa7WVNPcrUikU0zlgYjzJRMzhq Tz/KQ0OlAnUNlJEC/GFLvFxeuVV0aj72JSqb20Il0sCHMZzpbVTZcUBOTuk128wK8FVzKfCv5LsG IKKTiSbFdUzs3O7iYJhLdYTzmmotk0YIIffsEDem4ssmQElw8bedRlXcWkjUqScpsChCaw8+keMU HgGC4JPvcfEg9qUx4+rpLvGqbmQdkCI7DR3q8rYiWKapTp673oGEktWNL30kmOHlkQvQdzLct4Hl MHcSW+x0crhmY1jlEHIheZOCO0OK5qjUWtL+ygd2Il8blVD9rYAP/6JAQOriMKe64enAWFZhc2w/ pDmFTjIhVeldo2WOIVhctVmusFBS6hk4jeeXVHDz6vKPPpELLxQlOzh9/XdF3q0+GGAMuswZymrg IxKmhfuYUg+KB/XzWON8/zVa4LECUN8zbb/jbKmY3Qujj17GTr/jiOYXoV3OXUH4g8DD4jGsoCbu dorYsyh+T8QPgUrXPspgW2zE9tjFktsPlkLxlzyfypmXtd8/5mECvRVg7L5a0B3sguWrfn04Pbcy 3N17RKRAivJEoCUFj4r630/v+hBP67QvLNwraK03MQ3Et+b1XXE3Ef7qFX3c0DXpKw49J2WaAvy0 II20CcZfYMTcNdha72d1S0rOix3lxwFlfrqrfAlQoDR1xQj9UU9MhTfqO3ChWsJAN5aBNp79IKmh rD+Rf7xlJ4GBtMb2qCrFco+L0cBkJq5S29JgD5vvj0jFseu228gY9an184UP3HXimFEUl938FORT T9tKPcDajns0fm6CnTbOW1NVelMMqOR5NFth7uUBa7odnBGuj+Tw46xyC2Z99KO73p9H1FgPg5Yt 50Qrfbr2WZyaDildjJqoVjBM+9xHZjHAD2XX0xDQEu+tG1YBFPoqRqUtVZutSUC/8NnKtu+1h1Px UiYjj2gBbGF1LlPgjp37FNX+erZhH+b9pMvw1GXw5igFoiVoO3mvadNcTZ+TdJvSlIQsfgkgBQDJ itykBkJG7qT61NpLeB8BRFg0KjvCbm2aDfKfqfYg4/RjAEO2FhH3WT7d3lGKMqrG10uROFL5hbLa ZhN4YlKbPO5q5/cbWGjk8fLQ/RbPsrVfGzOP6FdeCNCNTiSDSQ1IVOrJW+KMqCp9NpPUZ1mSdoxt e2sNvk72uCjsJGgVY65XJuH2RLSHmZKuapXsKMAnN+GiS7M41YBxqPgSGxzHw0tpzvZoNgEN39vV RvzGi3LEKM1zg03+3a9UB0I6OhGor6bEDpudnm0kFvWN+TW2DewfLTxrTfQiekPl9CLS2qiTlA/O FqLcvmHrNkwgZsySSK8nqbRviB1vyJCKOUzmxnCGXLyCRwW5BVfr2ylidm2115Ry5i/cIUlUeBD+ Bnq3E/XUTINVKoV926JZC0nObtrBsYzZ2CF4QMECULs3THEDSFNe0enm6t5mkbua+p8YeTk52mPJ 1pdqs55RpXJcsq4hEUGedJTnpybdI2nj1vkQZfXTysYr0/Ga/HRlNUAY7SanX966IJUxEFK/GuDZ 83b08dWYeURPNdPdTNA+Pr5q2fmd5hYbTPCHrrTX+EBcHtvN2Nj5Qsjon1mHUnkEKEELW0ImUTTa 7JJhAMe0rTrhPa47CP6Y+HpEo+fAZL23Ao5LcH4Ey89pDkzOfCnzBc7/JEJEQvUAyQmta2/Sw9n5 SBe3xTZQFimISsCm3zb/cmfP4av28VaQQB/5KrZEXIz9KObBWjLpoJftujO4Z/jZizIqk1uDYerQ IhkNAR8+JycBD8E+rRh9CzmylEoVTuM7+g7qniMyCKB/tDziyHzrZ1evE05CVYOrpnF3nWK+bpFo kvPqzVs3Dx2ZJTI6800NEUS+1Cym35Qimh1ELKoIiLbJiwlALTc8tYq65J77+wRbPlk45kMSEPYD UApy6gT6Q9ippRCksDssSbrKOK5Kt0q4C/20gmOLhmc9mE9lYGFURuAFhK0lPiLd4CT6QqqVxSM1 4CRpQSgEhLSMdHpmAD6rggR/9z+jQLJuPdbK+6ZeX3E1axLjzWff0qDEU+7fx4VfkNyhHuebtF13 S27I+h6AKLqSare0t14t0wG8QXiqg3KKz4J1ZRiwrZg3dE16smXMRbq1r0v3YLVqsh7shxVO/OMi /CdYiMzpVMNS3wDmi9IDPgUY/Q0c0McFZYvBijXyx7Sp555F87Far6VtUbz/IJ2mBV637tpK2Piv /64OHJrWCjVALPN7c9DEK1um73KyA4uSI9fEWlwX4K0lVCj11YStsaM2uOlpJFFP06WOfVVMoog4 a/WRSfXtKezA4vfAb1KaaHxnwGSbdJKWMacP4ETwB0D3VWe473dw+ZsX6VCnb0DZnEi4AVh0Dujq fz+m3L4OaywWMGZo17jSp0mDTFj3CDG9/Xq/WQ+liIWiVmPc5I6MNCNSHiSGSEw/Akq1Jqd8KCD3 u1cTzXkxn0TGR/PHBmUlVT/ChI8o2SRuljD317H8vkA0iI8Y/cjZLBkYG8q69HzJxWuFgJ3Oa+Wr wz2be7Xpw9S8zKkpl0uaZM9KDWVuZHN0cmVhbQ1lbmRvYmoNNDYwIDAgb2JqDTM1NiANZW5kb2Jq DTQ2MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNyAv RmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDIxIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNDYwIDAgUiA+PiANc3RyZWFtDQobrTrH dmfAH8vvdPUFxTqbzzeBxt8naDoYH2Gk5jINeZOMGH3OPeTH/tSBRkGQi6dQNuJCb/rLwW0X+MRZ bNuYDQEVv9LM3GdVtbJ1tr28Ao2L3ytAcbrsLgHm5oEwxUgwty3LphT3g/ePdeZtKAssw/njUXc/ PFEo8Zww8FtLEkHeQClQ0rMwlAz/Uu5ofUX1xo77NWLo/RQnJ2qWwhecih4T+aGda2XZOcjaAQKA g231Kc9k5X/sJb4dKZDqKUH9XjRKdCsJ8kfbbLDKthFZDK/6aT9yJTwvTecotFeqqWaxM2c5EmiX vczOLT/hAkRUsluraITTkflTYVj4JDk5zeYMNFWeYD0qDSYbnvbGAJuPOj1DqKVylSY7P5/aeM/h 2X2nUO87h6LzpR7M7EYgWSRHZ6PYSxMquc0LEWeBlALF8S3evIma0I50qt4v9I4Piqlhw2UKQdg+ v2gbNZUBT/9zgw1lbmRzdHJlYW0NZW5kb2JqDTQ2MiAwIG9iag00NDUgDWVuZG9iag00NjMgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTggL0ZpbHRlciAv RENURGVjb2RlIC9XaWR0aCA0NSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y U3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDQ2MiAwIFIgPj4gDXN0cmVhbQ0KbJfQVY7uSbNUbZr/ qk2OXAu0CEuiP5cgM0WUWqze8Cxhj51cMiAU4izYK5Iw8BOKG8rHXSRuyBtUM+fnnY9DWv/AqMSO EjzUf4aVwU2y5/b7t82O7abRBWeynKnASn4sNbRrlH+jRErWv32STYfB7lC4yWnWRX7ky3xXfciS 9JhP5WqUGyqBh9rZKtsPp02svLhsENNt3/5qDLTHC9LnkPBOwNrvkG0MDm/PcS9IkP/1gwqVa8rQ lRymZu3cdCjd5CDVqLgZR5xwlwg3ZwUF4Ml83oQaLEyd99/2eWMu1bTRWmBIeO+8T74lxYFjlxqG 6p0F7Rk6ZNySuEI3DpoazUdJs3tBvEYWvsIhCD6+sB8hJHOFCvONkRoZpYPSFvWax5DttpZFKOvl TA2adZkaHl+v1psRIf2YXFR0x2DMac+k13/LgUjxYvMMfukUWK0FwhYBoH0Lm/t5sYgkHPCxvZq9 arf+v1ONEBWTVXSQN0Hd8g/SCA4ATVJWXeAT+dLOvCcgxfK2z/gZv6vn3cNm4dAd39VxtrRfCLlv BD5sONgM5AMJar60b/2+lw9n+FjM6H8SMd0cVpucbYoh6Q1lbmRzdHJlYW0NZW5kb2JqDTQ2NCAw IG9iag00MzkgDWVuZG9iag00NjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9OYW1lIC9pbTkgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCA1MSANL0hlaWdodCAxIC9C aXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDQ2NCAwIFIg Pj4gDXN0cmVhbQ0KryQcdEmByeossnsrrvF8jSxFoz2D6OpNEWKJ/zyTETI3cB0M+NOFcOSM/iXf 0M6xFlf7jipjCCyVKMJ3txAVUqgjmvIvlyiGwbvTbxPGy1adeN1M00ZHTwtbdc7jQM9r9r+dSqjY gDPt5Mse5bD76xeCvL4KktNHFU3sQ8sz5JOIfTApKTv2KPleDi7DZTI908QAivmKWNxu9U0HuyiJ k6FdI0B/KUEs10EmtonJm4G3/A2iGCjmgnrE5EgiRCxlgMiVVBtXjKyVAXRO9GIujdoGI88pJEev QHLpMWYAdZplt+MxZ1pSI1IZXLbtpHW+CWNLdo9a4gSN3vR4lsOMFkGiY04aUkZgQhqTYpVjEgsI HRiz26JbgG4fn1dyN8kvqD2vZwky2swfVzvtsvw1XBvLUVtDAEQGEIbMzpsbdWiQkZVA1G/OTZJg lquIr07lwj+yrit5aiQqtkUlkWCx4ENbaTpCoN0kb5NJJ7vNID6I9j/eGIgBH4TYVaK2BkcLc6xJ PZW78nrR3s6ngE5EhqiF0P3ERSMhG6fU+0EnJb1oyE8Bt4b43pPq9DjBXaVshPOWbFEjzw1lbmRz dHJlYW0NZW5kb2JqDTQ2NiAwIG9iag00MzMgDWVuZG9iag00NjcgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEwIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lk dGggNjIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VS R0IgL0xlbmd0aCA0NjYgMCBSID4+IA1zdHJlYW0NCneCt/cDxA3wPIOQTu6BLwyNId7OLXNsnfSt jJ4w6EujQnp/zPMNtPAlOp6D01OvgBaLS/BJ+3DKn4BHKXoPzcuoMNkebXy2A8GzCvlKFHfTaVHa 0KN49xueEisJW218bSR/tbXQNRyluyXeDGjRAgPKO7wjA+9VCZhFPOLfqRRlDfma+muvT/p5PFC4 dKxe/D5zNF+DPpN6S6zS2YTRHiea+EXg//Lpe0NzvJNCMyMEwHC+Wtu9Ij8eLSWPomK95Xfsbjf0 c7wg+eCQLh5SRV922Q7D0scAdSRDFxK5GMqJpUgSV0J4TTnVadmWPY43LKRV9LXtLL3Px5mEhhrA qGx0dUGENi6Qwn7Ah72jGx5FEK8M43/yQK+iU2RZzYU0+r0ZJTEqStZUK0ZgBtvvhRtVyBLkEYZe tUTQRBFZQAlL3fpkRxgE7/aPpdt2cGCVK5AajsdLT6+dli/bj9L2JJO64DzUYwbt4VcJj9dDsJn4 lrtUlPvueA0wnpP5VcCteNugqr4b9Xa1iq86kObuKq7ioFIU4QMU2KQtqMMgAqpHzQHVhGPif9JI muXj8S8kPowNZW5kc3RyZWFtDWVuZG9iag00NjggMCBvYmoNNDE4IA1lbmRvYmoNNDY5IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMSAvRmlsdGVyIC9E Q1REZWNvZGUgL1dpZHRoIDczIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JT cGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNDY4IDAgUiA+PiANc3RyZWFtDQpSa1vc2/b64H4gm3/B w5DAESWXlCQx0sgAh97hl/dMHDZCWM9d1oZdAYJHLpQ8EUTEVNmuVClhY1RhUOlDaA2woPITcf9k TNLAI3Fs0trod9xK5L+HnGmvV7pFqqjih69szABT7+3ZgQ3L0cF51hQfhRmPqV5XcBKKBFFV97uA i3MO7RbsZ0kTiPBUY9b4xOb8dW4KDjHKBjtm8UTv7dhadAdbVfLZXJihQAs5eeRIIqjTIjkYA4M5 w8p7P+AwoSYbBIAUffmtOnqVfXyE3npd8r304nYvX8UelErx7G/KnYttZJObAr9DGceicz2dcRWf wIrY3jdG51Rh2/6zCL7/ntgv6WENjgcm4BD9vTkyMRLS4Sb51HgtauUz0JRXgldm8cOVotXoDJuG VBDSrcAo1XoAkbbq7J47mX+GT/7JoP2dr6+H8lJMJCxqTAylYkMSVVGfkQNk8J/1YrUditNwt5pY WOFMVlS5apsTneouEr+2uZVaqjaC+uDs3jHbEvyACu3ZjXAdOfrDMJQ4Ma0xDQRfLRie3OALMRsm an5rEV0GDWVuZHN0cmVhbQ1lbmRvYmoNNDcwIDAgb2JqDTQzMSANZW5kb2JqDTQ3MSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTIgL0ZpbHRlciAvRENU RGVjb2RlIC9XaWR0aCA4MSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3Bh Y2UgL0RldmljZVJHQiAvTGVuZ3RoIDQ3MCAwIFIgPj4gDXN0cmVhbQ0KMH9LnmZoZCB7PBOzmv06 h0lZG9Vz7GkksAKon6oomcsjXEENuuO8mPf3zoP1dIzUcngW/VaELFTQfBmoC/55P36DHQIKlJgh J2VLSatcLCnCK3EY+CGQ07o/jSc5v6OEwGNr80LIPb0C6P45U2NzRLgC0Lx25/tiOxgltegber+4 y7fIRhUfzaAJBc5yEAO9/+fUeJm9zNoozd04A89apw9N/G4Csd1GWG5gKaoKaRJjSHjH1NwV4Sv4 LkZS04ic2Tqh4QPlKHek/+nOnF6a3vVyFmzCgNXGh6rS92zhqrHSm6cXg25mHH934sO7oHKr4CZe nVpDkfFrAtZ9qxYMAs2Z2U+i8ThR3iRmXHowU8hEIf8oYhtGrHoTOi959VDadyFLc4mEMqGNYOaa 1yL2+M5LSyfSYcXQUOjSc+ElZdD+9+UxLYfs5R+h+CmLY4ughw+lBsXLph78GWR5qx0/51pWve36 KHcstg+YRywSn7je64fKqDauMjSP+ofSdk6XZkFXc2JHl1nNCxNq1TydxLqlZUGd9raHoY/wqPrQ vw52VdUbfWiUTvMakO4a2AYNZW5kc3RyZWFtDWVuZG9iag00NzIgMCBvYmoNNDUyIA1lbmRvYmoN NDczIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMyAv RmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDg1IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNDcyIDAgUiA+PiANc3RyZWFtDQptZawM zLMJVMS6qY0BU1Vr23FfAue58oPZ6nsXcm4wG15EWHh4ZPAvTQ3nrbIuNlMhZXF2q2Bv0glRrV6A gj9yIMmg/ubT22Zl15IiJLRbMFGgbkzTBgFmhrZadyApiu7bd6daVOhotCOIi4MpuDiZHsFz0qaR g9PK/LFGojBAMR4j/rkT+aBoRW6PH33E3gnufR6mhT852hauzNVGRCT+kfIIhEsGBQWpuBb88gGC Y0eJpNFM4AtBU0RPgTSf0BMw25Djx66XoJWKEiyuG4IT/9YTrL7XULFo8oUFlb3hI0GunVbnaRxu SV5o6argth/dynjjY2BR37nuH6C7VTOiE4epF7+F6gT4feRgyd0rbP6M0GDNuwZgrFB8FfHhodet qauw48Y7Tx6OFVuJY0D0rSTFe3OYKmfyOgp9agjRfFCer+ziBUUVnflYjzGs1B54Xde1oY8k9kst USdHZcg3xI/KhpmNpErNoubV3ynGA6p7oo7y80Am89FptIG/v3TTfGZDjWCWUCwhmaLtIEdI+S3L JyzXvX8yqMyHsygmOAedoWUkqwgsZp2PYPCVllBDYTN0WrQhZBPF4gNFxjdOY11VQw1lbmRzdHJl YW0NZW5kb2JqDTQ3NCAwIG9iag01MjUgDWVuZG9iag00NzUgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTE0IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGgg OTIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0Ig L0xlbmd0aCA0NzQgMCBSID4+IA1zdHJlYW0NCnyXL/VbOJ+wXbQ5CxMVtDOsAO/coSIU0in7MMkX YESEp+twHozodfI+IpczLYypGjbmP/SRV37lSjipQdSRFWBjDQFU1/VqAKe91Eh1itKRdd63PYf9 ZBLt6mR/77XieLdvI716B+QYxc3Y6NXvHevSqULYe8pB3MiP4YfPAnStv/LS75Q8HbioIZWzNAmQ 0KKo2oezF4rYyeZkumgC2L8xinlHUn0WUPw/4UPQBJ28X7jk89PM3njcrya2ovuCJC2++Iry4kah 5qJwiZ2rpo8iSng9bf8Hx4JuwfcRRPbXsjrIaad/U+Wq8RkwK6FrCfLuDqXQMwTLVlYOjFt229NQ iGUJyfmplQXrFxpiBZZp5RI0oyNZqJz68p/ymrbqfcZO4HIgUjVYy6zIcpI49E6qwPmaKnHC111F JuMx0Qun2bQqW8BN8lp2P6fmQAJwziKvEmISTFvIqwrpoVMQWYS5x7dyUIihSaFyYxRY4aeCFQGc 5XEHvwu1mTzEv0AYPQKfa/XjKneQhiYHouAcCqOROK/u9S/oVsjEmwnvD0SH6Da0qzKzMCIzGUTL MmnZ0BwQvhEHJsNw7xEMRpn5R9hPBcCaAXnXq0OMJNqmepYuxnnk65wIwdH75hY1ISPELD6b1qQP IHBIneGy4VmfYsNO+bkrK3R79drmrn7JWgwDOoRzSV79WQM5GhG0PQ1lbmRzdHJlYW0NZW5kb2Jq DTQ3NiAwIG9iag01NTIgDWVuZG9iag00NzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9OYW1lIC9pbTE1IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggOTcgDS9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA0 NzYgMCBSID4+IA1zdHJlYW0NCgYnRvUYjRR4DLe5DvfYMAJEhA2TlfSQ9XNJK6bU3ICLkhqafqVB +w/yc0F7bjAZSChIrscI2Q+Ft/7V5+OdqLDTBmZqxYqZA1HY3oSSMlaOG4Emwp1zabet7hXZmjHa D+/4Qlvx0CqXGRbk5kq9V2UCu0SmGCnGmTK/iisgC6GZ0Q89u8XEL3Gw+xt4VVEW6X3YwkJdfAIM 9TCHKO6uR89N672vllGlLOVmAj/9usQLOJ2dylCokJeViELHVWLNDNUPXt1A7B8pQeOiG8txVfJP RJg8XREJWpSuAfqjlCCKU0yznFLHcXKgnZu0nxwX8YqSkxqZ4MWGmS0okYjLN9nOqcMcoKQ9Rfoa lEoL4aF0raxxS6RMq32bR318tfeEu5pABZCgV24c9RlWgF2ePgnVeQ8B5y3aVEF5+VvL1L7dyDxW nEtABwkJH1Dx6CMbML2ClPgeJPPAOcIgs7/siLrlFaR3x8Pbe1O0IWPo/ezkG/oyE/hvCE66XoS2 3y5tRyPyvZjaEChHXDIMK9PMOWqaTRLD9sXatxg4TQuOIa1K/WQd5JB5c79DoA18wH0g2w1s31B6 /mnlXHJnueflOTMpaVY24CPRJOdD14qo2sCoRCvg26u7amyQEVjSdDrep6YfBANy6nMNMBGkMQdh XQLYEkveboqTj8OuX3BuPQGQg0ksSHI7jZhRlP3LDwUNXg7rvM+KOjl3if7wChR5tvic2dZGQmJd 8w1lbmRzdHJlYW0NZW5kb2JqDTQ3OCAwIG9iag01MjUgDWVuZG9iag00NzkgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTE2IC9GaWx0ZXIgL0RDVERlY29k ZSAvV2lkdGggMTA0IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAv RGV2aWNlUkdCIC9MZW5ndGggNDc4IDAgUiA+PiANc3RyZWFtDQqVKdv5dwiPMvuK0ZIXHyRsFXd6 oDwDf2YWKSDLQNsS6eNHfe5BKW7p5mHq33ydSYo5197P+EjkoWWPJLVcd4XRDsJrl26WZj7aEPRx BTFeAucceVGT+2Q++82ggjwo6rC8shNP1+p2J54qh0nlo68dHgis2oi28Q7jtFxImP2Ymbqp54Z7 dl8evqLZsahd7vijxnhopj94nEOIZvPQ+B7xUpum1DI3UsTvyeF43BNQU0xKj0xhIFF8x6lR8jMD luY+noCjrhP/7bbsrQJ9mpSLLLJSdcDljBHzEuAlksTz/YYzJfvbieUF9fBqgtZxnHqJ97owD//x iI1JmpFwGkOh8GLCEQ1jNryCoWpLYZtKLkf4uGhrV9T0WC2PbMfxHTKqi6G87xoxIiJpp403ynE5 su0OgvfuB+BojiaqTcBVRd4sCXHinmhit03NHIWuML+2Co2A9lnqJenB+y0q/MsMq9moMItRo0Uw SX5hbRR+3I0tlRVhkR+U0G7/6mCxmCpLDehEazWz7bT5Mbq/Qp9BQPAF5R33vzT+aRrF7qN9cVE8 ytoESonimzSyWDUutt6EYReiBAiyeZR2Sc9aAWow2VtEb036SylHtHi8EcbYwgqalu9UfRIG3wnE HsA1BsI5h99hLE5RR0dfEAUywxm1EJGnsNJnipf0dAaIBUMoe8CGgM3y3KCgE0/9tbMNZW5kc3Ry ZWFtDWVuZG9iag00ODAgMCBvYmoNNTUxIA1lbmRvYmoNNDgxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xNyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRo IDEwNiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDQ4MCAwIFIgPj4gDXN0cmVhbQ0KETJZodQ1S9nQpqJOCDtCC4HNJwXp6o5tYTAz PxA4BQegFmp8dWwa712hMkFxr6IND1hxQigV3dbfI/d225pUCrTs4v5WHjH/AbzJjPI8DimT65fE eAlA+yFGHkx5ULxwnhdIBzxPNj2vMP1Tolca+OpA0QDEPx6EKFQ3CbyweZJqkSPe3c551Z13zIJW N2NN3neyEYRytMFffG9DByyqSiIGuIKuQmIjJi1Zbeewhc5Aku5DFcDBzCTqM7UWagZ6U4Mfz4pi B1lxeqMSg7L5xB0l0ACK9NqtIks0h6Gb9EbOaVdYs6c3/2inYfGb1BSlLAKfTe8rMScFviUoHfrI S1fgiMmGga9zYrrljS6z4Z9FE2Mlj55SiHBlrcvoYP0sbF5US+JjqmdjamKg2g91cMttIrfroO4Q dKoaOoMx3TkqXZNv11FfFKGWt1IJ4wez0BLpGF0uueHs69Zc9yHLBjVcnaGyUBCIYCC+uVE9uH5f zAiCAkawTkJvwqZcui54+RDzNemqHwWouinaC51DmkXI2K2T+TdZZmYtEZf5Ge0badA11W8tNFJ7 A2t64l1PGaPHVH/0PeW0xZNyJ4F2meYDf6BF86b6Q5/R7fbEivYlKKE5IvtpfNmkWn6pnmaKYxm6 MobKMugLzuYgfOK+tNczAvSgOPzzdAcC5jM2xzGlvRM3WMcVBiBv/KFaBTkdCIu2/g49SVqyGHVD Wd14qdJWuCkMiPUNZW5kc3RyZWFtDWVuZG9iag00ODIgMCBvYmoNNTgzIA1lbmRvYmoNNDgzIDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xOCAvRmlsdGVy IC9EQ1REZWNvZGUgL1dpZHRoIDExMSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0Nv bG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDQ4MiAwIFIgPj4gDXN0cmVhbQ0K+08cBQ7b8aB3 0nYTSP3ifqkYTPkBtcmWS7zXVmq8eSi4Eb7S6/ygftc8M6tLAc0mo342SLAoxUo8GXnBrj9pYCs2 BVzZv+oi/eLlkktDRU6z2JORMcRiwjT442VWzO9OHzfTa7C4VMzPQluntHzk4w0AVF/XoOmEFmmp Xnr5qv7nHh4lAbCwcj3VNvNtY+WB2tG8Aqja1LDYdHCW6Eweq7Y2EFV2JDpefqtomzndir6GUITc CNjMDo+isHEJ3wPRStqFTj4pTnWR0rjCDU2kGsiDCed4UkwoOgflRTqgptN1fnUfXhsDKQk8S3yu dPkYo7l/9gbkyQ9kdh4EEW6jRABVYqhfrcN4w7VS8bF4j5Nq4PB+bl7U/1z9usOsLBpgMYdRZZBt lX1E022NfRKrodFgsSkhyrEXKzDjYUTbPu9aDdEQa/kP7iK88+YvcvtRZsAMPPZHTghE5cW2/IkL JUYpA0JNSqbOY7u/UpE9GdUuMWl0XuQW2MsdHa8PrGXnUYqUmiAQDoN+fDbq7yMPAQ0DmLO5Ju5x 4c/yt0lh2gLT5skNao5D12wZ8WRVQc8bp9BKXKpcAKYgPCMA/C2OEAyGEdJ97Hv0941QBINabynt DafAEuIXlpLwEraGgKRoCnByl5+exBK/lqw2Vzpz5dHU/6+TKhP34cwpL4gN1hS8bzcUB4PmbkaN pH2d7a7hIUpEU0M+g4j3VY/NvNNy4CWxXM8TyI//w7cT45gruGoR8Me8ugQPsooQu0faqCcVcKZn gIuc6A1lbmRzdHJlYW0NZW5kb2JqDTQ4NCAwIG9iag01ODEgDWVuZG9iag00ODUgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTE5IC9GaWx0ZXIgL0RDVERl Y29kZSAvV2lkdGggMTE2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFj ZSAvRGV2aWNlUkdCIC9MZW5ndGggNDg0IDAgUiA+PiANc3RyZWFtDQqduBlSK77/dWCFyAMr3wjq OnEBrFpR99ZMB/4yIiZeJFSOhwkWwo9b4FllhpIBdgom2sx8Vl1sPAx2JVnoV6VyRVmQj7b6woZS eDKYtDctaSyA9V6Zskz6ex84CUZJ4fICgqI7M9rB2XsZschZA00D/sa3sgsvtnAwZWpHMvuFgy+F jr0gFsxuuwhzliADLJb7amS6V65nkFaedgn8pFSz0cIjfigRLFL5UZWyX4cxmfrb6sRahPgApwek 9BXQQi+N7Rt6B1IuuiSDpbqbjfJWQ9Q5EU25aWI2wKVpcOcQl/5nxIQkESi9Wdec9Ry+DjmAj5fI xMEeDIgIKchXrx+urbqM5xi5ufFdwacuZYGzcwBaFhuALgmh4K/oAkZ8q80/ltvho7SNlSQmSig6 0HA+r7Rnj3QYOnE4LypShgA5gmdznzkOI7xciAea36wrWFgzROAJMrelGvfVPoDn4B8UMw5ig+NQ M5UKtxw1HTE58+9UH+VhXIdbyArYs4SllCBCWJ1I78i/r05wyJMRSeTuW3LGVaFiLlUSXmOCDn+1 B77Z2KRDnZcqVwT3S0QmnPApAH/nFWiNFVAE+kRGIkwYV4M43LRx2gwXxYf7Ix7UXp3cYw7h/XXi E+MWL3fnG5A12+S8Ve+KVXW1oZ1bNFp2Ev/o01OZANwR1CuMEhsbXCxrbmXY+4VqQxCzQN/2FWSi 8KN0LoJGD6q5VZZhAzG0FPO00NthA5r0xq3rAehcW+q/5hPBob69T9qvs32E5IOSDz2VKA1lbmRz dHJlYW0NZW5kb2JqDTQ4NiAwIG9iag00NDIgDWVuZG9iag00ODcgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTIwIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lk dGggMjIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VS R0IgL0xlbmd0aCA0ODYgMCBSID4+IA1zdHJlYW0NCs5yGbC7EGfN6ER0Vev67PfU3MxJiIL+UI/v ZUR+ip0aZmNeRENeFRGuG9V/mlXwAfsXn+SkymCdE8yxFldv1eXxzyigEDFvq2Ykv9qCFXuzN1W3 +d3aouS+WFgqybYADtLo88yrWSdqQS074tkrsrr2w1aSKtkStSTWEgHWfYxzzW9qbZh3lPuqNCLD fsdCH4uy4FrJ3s6A4/w9ME0qrxXkhl92fv7dfEisaIpaVP4O8YWnSNTq4AM7pq/Y/fHMntdh4tNQ DY/1UjJMCNkvruSchYH7u+EkPWap3tNKhmcFfdsrMo2IiZ7wEwL0WxFnuynZZrwGl3tbyYC1nHdw Nb0eUh/7+MfmFFQtEZRkohuNYt1B639KUMFSkG5yxDYijC9XzPyPwE5S+/4WXo3a6zqp1aDZxJcg sLm1W8W8iAp+AI0I2xnvX19Fx1WrQPfA2tsTqkK7hUzeIcd1mzPKjQ9V0F92MXfNnw/cIey3z6qv 7BCZW8G3hHhsxn+//dwnq849M8m1egxxRRa/UhmSGzffA0csw9SRiHvDdrHnhZkYckEn/14/vseG XurdQcTJ54Y8mWIM2kdmcvUNZW5kc3RyZWFtDWVuZG9iag00ODggMCBvYmoNNjg4IA1lbmRvYmoN NDg5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0yMSAv RmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEyNyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDQ4OCAwIFIgPj4gDXN0cmVhbQ0KJPzM vUx+9ASfQ5yzH6gl7Hn8JR82xxtV4swtIvJhMu4R8aIL+fdrjmQKa7KE2q2MDI6tKFuTJdRZbZbn hfWDfRs6d5xi5wDqXkXg6/dwp19v1z5sHYMjpqZo3g19OnrwpOGoG8ZM6i2Lq2+GZVOsKmbp8ZXJ M0PkOA7zdd2t6dB7j1q2cg+SDRwR1OBjnlmjYQDIlW3R7f1ZAlI8xTamuGPEciCH8vggC0lgINxg j763ohC5aCrZaYrrX2uDafnEwpTsfRUQwf6GPFLIqnYGAUswaxe4TxqcwcLk06t0yohjO8MaDKSl FrzBnn9O1qQFBXD6NbzfmIZOYos8AFFHal2VASTBDCXMPmJ94b4w/6lPgwSdEIVbbH4tASZdLilX //LAZbplUFP0/QqfwgTYX0SnCXSHkwTFPLBLFzRjzVmDQCb2XzFPkxFbYzTSOZOcTzrG2A2aM9MI sOT1Vt5MhLmPnZq6ZipJ7KYf2/LLz/2+26BcZprA67XLnqgpYL9yz6oow4Mo3NpKFsXkG5xqG+r8 DtCdEyBnmjeJN4iuPZxIiuQxJiI8EiYwcv6ghshfFEaJPRByCe7OdXlxuTcBeqxkYE7Ji/M04L/v fmuiBOPW6Pmao/NObJ/refXlbdEWEmwXmZIXrVvWxe+JZmMlXVgWQ6hYqizJMXTxKBm8aqbBbz01 /tSyfHwn4d6wWJwIEy9CGUGFEREX2IWM4s8mYqlbu1S6VaCslK073PrQTsZIqsgo7v+SJmHTptZT YMVCPywC8BcOUpiGca6QjmzW9p4IjxYG2HQc1KnqRz9sIJp7Abb+adfv8Phe0oMBxF9h9FxF+1Fn H8j9035g2mJrMvM7ScG8sQdHAWM6sy+rUi9IjaIdl3oQY1va/AZ4LWR+KLlUwrNO712x2YjG0VW/ 4g1lbmRzdHJlYW0NZW5kb2JqDTQ5MCAwIG9iag02NDAgDWVuZG9iag00OTEgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTIyIC9GaWx0ZXIgL0RDVERlY29k ZSAvV2lkdGggMTMwIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAv RGV2aWNlUkdCIC9MZW5ndGggNDkwIDAgUiA+PiANc3RyZWFtDQqq+euJ+2BMe/DRLGiG3hw3A55w JnLXRQYg2n4dCCtTg9jCun3JoSMWz4AJkymVZSVUpINfMz7lpW+x3xbKW8nwfgfhfKtQ258OWhQ8 JSsM8FRWd0aCOVWvm5jYh560cqWAt4stuwkDVCupw6vojZAscnicVdy3I2Pe4EyX5/AJWANswTPS kVY3gGFbN4gWIrC6Br2ZOD5QY1X3T8CijHD2c1NLguaAcFytD0gUduBHHFLtV5UtxhAklg1/YK97 haEhON1LYxB+TlQOm3QFUmpMAuV71GGQhzgOJFmyLXKHgCvp9muA7w5YHbS6tOxZUnHn82xpn/55 f3mGpX/kpceb0FTKQQJn4Ay28861ncxFe3dPNCKzKKanFp/IjZCyH0il5KJpiMQ0wX7BRNwZUiL7 KZDGTLZWp9ZDRjtir8+Ch4BGGTu58UutHW41b0A/1oTeYF1cg0xEkArICdYWlK99E9Z+edO1UzQB sLusK6IbEIdsfjFxgo6BVCwxwsg6iQGtKlqpj+UQ+ceRnvTnQBJdp1C5e3boraE9dGExO2+td/z/ NDO9xoogFM6D0KxzBFK7cCrEABlHcSTVWEyqeNjF+m7b8vvf3gg5COFjP6+CBY//tsRc9mGDpWOw rJEZdsgCPdqZ4VZzivVuaD3pEYwQ3RLpAieocYkgl8QklN7QE/RHquTHEQvkOGdMQTZsNE4EXno8 8v8e3Bj2xm+mW7jeE4oYU8f4O+siB2yt+Fd1+++4M7IstaXMx84noy5c1ZXuEc3vpAHDkMTAdz4T +T4C7CCXt5KM2O9rXjO0/Ki83sQPKh/zz3M79aTiRAMXeFRQdbNQ7pttnyMWPNOK/KTkDWVuZHN0 cmVhbQ1lbmRvYmoNNDkyIDAgb2JqDTYzMiANZW5kb2JqDTQ5MyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMjMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCAxMzIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VS R0IgL0xlbmd0aCA0OTIgMCBSID4+IA1zdHJlYW0NCr21JCrsEhTPESA6rSIXfy21HP5Mh8XCKV8q fz9Jezc1UjfBF4C27Lo1IvEWK49J6uR1Sowxi/a8fst0fBwjK/Z/xqYYRgliXKWx106sk6Xkl82c GiAVidsmQT71ftEXsg8YQaHdgxEzDHuTO99Da7HBJkknhE9vCV4XeS2Kd35V7Gn/mAJC5k2rjTe5 6Re3gCse4EQSF/oYzJ59i5YPnj38e0L64TgsukYGvsLsIU3j9rBydmtr/4T92MGZwvk5ntN08zMy YBoQwQUlR2p6xQcS6gT1QmDkECVWNJYWbWn/RGmE/VJOtquTEGoggYl4x3Klaeww2hTm5O/d9Qh0 3XLoaI/lRiPI0oTTV1hHV/nblxcav8G0I7lZVWEaOd6EF/SU++eTaRS4zn5UuJbJ0G13f2PRxq31 Nd/U6xXpJ786pdVmPd2PIMlYbxcN3dhtWvB8DG6gbhVdXT4aU0fjQvZ8lNL81W5YFqKq44orl+3f x6px+4Q8OfgV3X6ztrDiJkoupc+UiL8qvGAnULxIsn+C41j9whexiLeJHmHNJovim2mYEWvjfbYg Jv5FepjHCAkwVqT8TaSjNe5iyZFFZtvhfJy9JHMmYHnomjfMcdjTYLH06iW8RgvGWvltEGPlxwig CbAZxi8DKd+/+jmN/mv/+Mefp/XOPqtX9SsIOVDoOA4/nwWTfzW3gqowwRwjaIclxgrA9zOtNFfO pkl1VaZtm1hUsr2rtyijRskRwrhrwvASfdbfMmh58IyPfGsI9JCS6G7zONed+s1qGzmTlO4hOpa0 tCb9vOzOliEHzXkzEKnkiUBJYKnX5sUA53kEEGSCXgfPKBBSDWVuZHN0cmVhbQ1lbmRvYmoNNDk0 IDAgb2JqDTY2MCANZW5kb2JqDTQ5NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltMjQgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMzUgDS9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA0OTQg MCBSID4+IA1zdHJlYW0NChG0LLqKTmIFRcc6lp2Mhv1dhau3Nu23p/1IH8QbFvwjO6sva+UOuqH6 A20U5XPb83ZFOhGV0Vzy4PmRu3v5pJFpqruPTHoOVeGEHYgDBnMTEfBhRhKsc7w1MJ+ubBDp/jK6 myypzmri4cZ2OrAhbnrOvSZHjWWtGY9svitGX8WZvxLc+k/onGFVRaftR0zRJ2cQ/nDesy/+YPE8 mp4TyIb2HM751PEwSfNH7LQn7SJwE/9OH08VpBQj/c1hbGcHTGjxZ7irSMGlHcBG6gbJ6FEyEojg +7o1UlWM9TOnuaRfLzmWk9EgtyZMjPPVmhMgMBB2vvECwB9T8ttjyK4tCmMAdCVf2Df22RV9wWUi 6vOcG82lZ9gCGIB12MfaOv9h2Cz9Y6ly78gCgCWiUCt9Hez0S2aiidPysf8KYqOmRPNerfrNkSxW lCQTSOPT2DnVJcr5GB/1VO9uwPut4K2hWfjod3x0AHuJLttDoGTmvXzg47COjFCRNa6kwOYfE/oh xoIRqRBmsuhhq+4GNbj+NHaaly33KftEV3pi9Gk6FoNTBoCxoCoHKs5JGm9VUfwTtAdg4hGqWxV9 Yb51heG+shb+PBUErsG4VyBGwJyJsJjC/roL9N0ufW4UU3OjiFERZP4IbscNYl/ePvnCD74kKq8D tnAw0JOD7V2tk3WLS9j+zPpSgHqvU5nE4Hx5GgwdpOabGbnsgS/H3Rx34qaJrksuhZQbpaAJiO/2 LaR50Wp9pyGFcrHHY8N/1dJOS4r+TcFRhtPLxJV8Sr6VIaMzJGPVx0JkMehUFU/CkQWWS8Y5Fn1R 7p0kgEIjrEcf9HboyD6xJzRm0BCISUHB9kN54jVEcm+cfZQEpehT+fhaidWXYhgEPQ1lbmRzdHJl YW0NZW5kb2JqDTQ5NiAwIG9iag02MzIgDWVuZG9iag00OTcgMCBvYmoNPDwgL1R5cGUgL1hPYmpl Y3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTI1IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGgg MTM4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdC IC9MZW5ndGggNDk2IDAgUiA+PiANc3RyZWFtDQpfyuDSOI0rtvEZpMMCiDKfBQSsZJON+b2szR9G B7rEyILlFtG7DMxmrh1+4z44GGAqyxBC9doFVyiJDLo41a1ddXl11DnQCNciwdF+ZkPUc4FBabad ot1u7ERZYL4FrfskG5oaoxAvjE+rGbUnB1IbHPKKRdGaUyo8KA+C8WBxPwxjRUp4Cvv6MFy2dxqY a2+TeH4a/a5PWHM7vWWHU96CgMG+MWQQsbJGXOkz3ge5/llp06fynHVaHl7q5t39N5iK2hHCmJu/ rf80PxQRexIzc+NFHBmoqyrvCwSbL7yv7zcO/WyrM1/djHgfTpzxJOFw7ACY4UGxvx5G7vV/TJTL nbJsUAoNAbZ2ydF10J++j2+o7LIz9ms7U8vQxFESy1HlLPdvsDhDpxDy0WyM8vWGgSYx/Oc2Wu8U l5iFANoKyXBSi4PRsMMIoXrwLJW2OOjMEL0NPH80e1bMxl/FLFazoug3Amdcpym0UJ6XcW4f4Q5A w49jNhoFUK9wOnzMCiyNOjLHQsf4kxDRXcuOQ/W+BT1k5NUTMKV8eXCONxx/61FamUJEN+wOw7yn OqiPFqkLOQe2CYmZEgQC2B1tNeqg0qbvWtvqUxILsfEUseDfO2N8iZ4UAlhTKEcpTM2/PzT5lXpl CyDFrG1tqpNjHUw+T07U/CJfrTakCvqVWbAEZp+v2DH/OuvBxRYPF0x61mSWdYSOwGlsaYdgsEpw C3SbSae1GfrastXcdajxOJseC0+Ge5hL/JC6Z7vrxFMs3UlVx2NU3wrn9Ls/r48Dz5cibxV6EvKZ 6+Zxsj0xGbOhuz5LE3j7xWWnf5PFJa57AUF3QzEpTs1pFw1lbmRzdHJlYW0NZW5kb2JqDTQ5OCAw IG9iag00NDYgDWVuZG9iag00OTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9OYW1lIC9pbTI2IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMjYgDS9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA0OTggMCBS ID4+IA1zdHJlYW0NCpBHpmyl4hw7TfOkMMQ3P4wNKHAmkpjdr3JdEApgn9Oayz5EhUA8PEqd0lPb lB/KduBpu9qrRbzMIoHnQoZALiKY/WebuIFuoFrKNjTTC5N983PsAG6jw/eeg1zekkgV+Sk3Ancc 14j2fQbG/GyBny3CAUpWhu3vDiB8Z0W7ka/jtxYt/NvgN2RDFvqUn0acVGrp39PQ1WveI4bW4Wzz otNbDITr9w4t7uFBAhiMqS3ZpLwPpqZ1U25puP1yjc3ZuKm/Nes97oJOj/bp0p+gcO017Iz67WBf cZt0c9HNBKuYhb2+lUsLEUM3/RDnwGwdEpLruTFoO5rG7aYhmMs7F9pCrB+7UCDb5dqia1hEyVtA WKy7tdU+8ITgBlRi5mNaVHMfjgTPH7EdblmnUAkbjtRhfQvLKBxUwyg8e0Ilev+mslfqaY7d91CR OC+ILplvRAX4GraaGgWWlCYjUCFqd8PR3ElO6LliM7klWhotQcJLd0coPj6CJiFkaRMhQmfZE7DT QTkpQwMrGdIs6RbTOIgCDFpEZq2cpAXsgBKnCfxAZouzIeltJZVmpKiuyMpHeMHzTL37VzKgdk5o BWk9DWVuZHN0cmVhbQ1lbmRvYmoNNTAwIDAgb2JqDTYxOCANZW5kb2JqDTUwMSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMjcgL0ZpbHRlciAvRENURGVj b2RlIC9XaWR0aCAxNDYgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNl IC9EZXZpY2VSR0IgL0xlbmd0aCA1MDAgMCBSID4+IA1zdHJlYW0NCnmIY4U83fDbwJBJAG0AOX9P 5fp8OsK/qTXQoQpMU8LxGyck4MHzM0CLDrBLCmHK+r2ug9EEAN8FJimCemojYplsBM28yE0N8F54 K8hNG88UjVxYc3saZg5RAKN3s+X9bM0LbwK17eaX75KNvopM9icpVz+/hhV6skXFv31msnzpyGu8 NESL3M4s5kxeQ9SfySj5OXq9GyebVMl1Fj0sjdN1LrCBQXfHlQlzcd60yRPtoSz1eHkAConsjteV laT2pGVIBm3qfXLOIvlRrnb5adJ3IRTOpaWpl8d+L7OMwwlOe1Pfu0K1G2tsJkGdrNrG+Qyuwybt mXTwkkPe3iXTAgYh04wOl3HWKaKoqjd5ZDMemQWXqLuIGUFdwXdqJ6CTKSBFYALj4BgIkBumSyfV uaV2hcYfw08231864gf0tzEjJaO6oE/Wm1XOcGVuJezMDtmtJM2oc+4LnTpYc4g4ZknqJPrufUGr Q1Im4X47j/WR2PalpDDJNgE4zg5Iex59r/ujmWRPjeBcF0NV+I5pzm28b2Em23OTToaQGEg00mMz KzhKfgAaTKzgWyVwnnlmPiqz0UxUV0wzwJR+C685Ly7Q06aeOMVqvfIiIMsTRUdxZ0qOu+FWUgId Mkj0qB3zDheYoBMe+hQYLvOvqHF1xy9v2QUq5AAxsk7/WqH17NjyzEDCKUV6NCDnNrcWEUPh8x4f ZH9GvcgNgRAnr/lCYnw2CmApvRJj2n7NwA9MEJmfUS5A2FU6UH4ExEpMkmLvvayidu5PtMleg5Us Yj17PgaBn33g5GpBfdZmDiw9ha/FAd61+A08/t+35w1lbmRzdHJlYW0NZW5kb2JqDTUwMiAwIG9i ag00MzkgDWVuZG9iag01MDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdl IC9OYW1lIC9pbTI4IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMjggDS9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1MDIgMCBSID4+ IA1zdHJlYW0NCsbWWf/IbEGDJWfo93aKnpRT+BT7W6iraUMWy985ld2YN9XMgwXwfGMgI6G21bZg Cyq5gJIZYjYubn/h1T1WJ4Isj1zrG1OcHePoVpyTrxdsS4i/CfY0C7hJgpZmII5GOj7hxqSiBKjz KGQpCkk8xAXd5+U2moqZYRBwDzl8GHCVsD7S0h/dcZB3NusUVgiTSSC8A5G8LIIDaPRBv5wjnjOY 18KNTgu9X58nhp0Ebuuuc+pVIsPeR8Rvmjpw/aP33Udr8K5/6goYb4991dOqqMdD65IiNJsREKut nD9ctDrk0eIRHuLRjb/vXpxEXQiujjgklmVA4GghxZlnvrn4611PCp0FRq6F4JI72qQbNDt025Kb o2EZSzDq0OBSoBupWsIqZNOtWZ0/s7fX1m1NNK862SZ6ToG5fKzk7R3Fhvz45vFwO0UFs0BBCi8f wKcSLzApMVP1b4naVdle/PtH5ftrUSEaoZIhD1dkEtqwp+vROWfCmSHI2zgS+R43WHE3dTkOrXGt oGtsxRdPCihKs4CH2lp9YzBtLunsyqAcCkWS3otIyHnBnrsLIPgPn8ApPHm3WYZji7wNZW5kc3Ry ZWFtDWVuZG9iag01MDQgMCBvYmoNNzMwIA1lbmRvYmoNNTA1IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0yOSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRo IDE1MyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDUwNCAwIFIgPj4gDXN0cmVhbQ0KvFlP2Pg+jvnDYhOCnZn+J/Ym1OSYxBeBnBzp V/vhK0qzhAwZzTGv68wQYPFrUy6H3UdZPDzBm+NdNEXLEs3v0VvctlxIZkGiFmnDDBpBHJ/O5PB6 Qj2lwfEscnXY6UvluuLsmeuM9qrAp59ZdFyBeIlUuXxe8AJBTLi6spwgKM2rHnelBLjt8LyM2ccG EZPfgIiBX+eRCKleWqRuEx/u9mt5hpfEA95fIRi2skcW+GJIaDgv+aMTAKvnnmH5iquDLfWbz1kr 3dKpIbbc91NzBtSpbvQwXHfuau96h0Qi/lycQ5H1k8q1zPySVRErxo6BR4ZpJlOp7kKyDTsrf7bf NTAl9G4Buk1AFZpKOQqePSKwvntqu976t7yDMXmgxpdxklXWzewhhK4cFSjxzf8gQgtdoGGM9M4z L+dIssbQBZ04nqWYmpTqtMiAXDfsoPqdA+64hLGAq54oeZ8RRolhpCYjhzfwBjki5jVpW3nv4OLO fi+NFCjmAcJw9m22AcYaKnsOOBse+GaGj9ADdREAPm78UdekfiKa/Z+Oxi9olteS9hHtt1rUhlkn /938Yeni/r2Xlu9Ec6AbvAAlxzFo+PCAc9BmLTSfbQ8iqVQwzpO4M+42Ry7xrvEUE6ydAe1ZWs91 yUJZHpWjAtEMHbNqdeRwyH0q5/aL0ncTn+drTwGD8IwG5BZWWDBrqZD1EwF7JvmN+ki7HLm7oxT9 AxpcwAFkIJEFnvWcjF5FThifPPY7EGV1tp/PAN37YuEimRQOQiDMXT9Eg01yysTJ2XBOpYno8h8g iIlcfLKwIzTkcah9MiohvbhT4WM6pKfQuy+EjsXizOM6QmIcNntxPZpkM1C/tcXr/1mJ8Cg76Ndc WkGkAECYxfkAlWlDgIUrZdm5NroDo5IzCtEGnyJQlNK8d0WE3t+FcunW/hIV/NM3m0oEHeqK12Ce 87mZpYPPoc8rA8lo/SA+e6V23g1lbmRzdHJlYW0NZW5kb2JqDTUwNiAwIG9iag02NjYgDWVuZG9i ag01MDcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTMw IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTU2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25l bnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTA2IDAgUiA+PiANc3RyZWFtDQpk BFZ6iD5hSCd24ERrvcN42RRqLSt0kJUY2tZDUJgAAbmIqqz+ACM8jgLMncQ+n01dbMfpYkX7n6yY QdByYT5Mg0lBbWGej1Vm7SAmT17/cgxNRWxA71h51xlnlXXgle1dnQ4onj+OsBzXIakoP8hx20vQ XE3XwWBAWUxQ36MG84HS7kTrOoWABJrbEm7e+XOxHK/WD/as8rQlpssBRSzHWwZ/W20jJv3K91B6 BKSFB+RBqFQX07DHrTXlRlQbucNr0PxXd81Y+lXYBQ2eVqCic8+dVV0gF+4/eXLqqRP+C40VZzSQ igU9VahleSVp6J+oT6ajxy+txTYirmAIXr0ilWgSrzUznMzbFjHkHJHLIXm1Ak/iipXhk4+/dbhr E+GpPsFL9qgXhWZMRbCEMnY075iG9UHQsVNol5qMfsXl0gajiez4Cj4nDZTn2G4lWqBZqTRM7Do8 5RW4Edy9fQzt8I5eC3Z4tkxHPevvodGfjqiumJL78JSHA0eHC3u3QGdmONw7THhIjKBe2hcvjAz7 6QsRa1dsbgTvBaWqfj3OCNxzA9X5Xa9YY+vWWUZOxMzjZDJbQakkAd4mtDN+UFL6fBZwcCuUQ5vr 7S5ztrwnfj5ruakNCOVPDMkl8bC6MzFDY2NeISvtyen/JVvEMMXRfUrcs+009xt6aIwGw6tYKTOQ 0mmLGkf/5QeAmF8qGjeak2qHFutBFILaWW5zyJNnrIN6afE/ByR8uTusBptk9KgS8b9bgc/zR4oI GPQmpbYMB0guxJ4u911J5OmduxdZRv7Dr5LmKHm2l4TA07wwmsN89BWAQgFDZCObqRA3uro0ESfi ZuZcEXQxtUkGIdYRZiKulH4BNu02oVEGITnS9Kkl98mBnuaLKBkNZW5kc3RyZWFtDWVuZG9iag01 MDggMCBvYmoNNjYxIA1lbmRvYmoNNTA5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBl IC9JbWFnZSAvTmFtZSAvaW0zMSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE1OSANL0hlaWdo dCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDUw OCAwIFIgPj4gDXN0cmVhbQ0KAK81YO2C8gQAwVaHrR1w7ovsT/jocXtT/UvxgXp8e4yuIrcg30U3 IVnrpnLJQ2/sQU8tmse6Oi8oQteU+hsnnodmFvtMF7cEzlNBQiwF9IQ/s8YG4daIQXv4fpCBTISH IRnwq9i3+3C3cY5rb7tVk4oaTqwJurLGf1He1yyKpBMlClWK4lOf0MIUxD9x4CfjKdk3W7teq2ri y3rK/jXSakZSW4Vyx2N4VsQ19gUgvw1CEf4dYt0qr05dHjho62QG/UnZXFL66P3R9oW/zWd7tLvX NgySZjDw8gE3lCRcFEEcOLgfLQPoaNmrtOkCyuM4gsFBCU0BDUJhUZTzVw5wB3OoZZTPimyLxNgy y4IFGCJWkOoLsBnFSAQjiIBsRyLNUZCWcXFxogINcBoXDMuDo+/gxNhMFQJdsSs3D0ufFANKOFrT 5fq3LdOtgIYm8myusYNtm9P+uZ1ALqFHl2cpweVeK57OPiH6kT4qIhGxoCkZa4TdC6wCF6e9LlTC lmM88qTUyCG5CUmLuqF4svwIu6lcjS5hs6EFuFdwW83a5IVr055hWqXOppktIChLdYv6TKJzQQdj tNwqgqgBNi2krbODecuJNE6/tcq5VvvUMmN+d3h5CExdqg+5mhu4u0JJqen6vFUh0ybA4+8KLwav KdqM227aomWR4YTzA+fb7xPypKTUYXEh6f5wwfHUZOeYbrP850V9+ljpkaYufQMJDTQ+X57eReM/ jGkV4Wsj/yYaot4lQkZWPpk+ZvMzYTLEu7zWdmtdeC5BILbBL35F/l6zTYUr+kQ8k1+voImWhMCL i87PIw9D2GMkaDNwjhuFH8/aqeJjcnJyQMIibj8vsQP6e3R/DOHq7cczcYtvyqdtJvjgkg1lbmRz dHJlYW0NZW5kb2JqDTUxMCAwIG9iag02NzggDWVuZG9iag01MTEgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTMyIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lk dGggMTYxIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNl UkdCIC9MZW5ndGggNTEwIDAgUiA+PiANc3RyZWFtDQqxq0crWdQaWhr0C1LAiqAoojkRPHmnUzBT uySZFIMP4UpyTli9zB60Ipxhqwtj2bk0JW+2FNFNsWs9BC2th5VPANGL5eKNBj/1qVDVaFpc087C N8vL5iYNiCcIEVdaBXfWEphA7KEAy2wy51FNJLuqARNPH9e++SRTYqb2HK3W89wXndSzbrCCl5yL JYPle71/ZaLSQYbBAgE9GcayGkcBDZSRTPGBOz2YS1vsqjiV7oBOvCHyP+moI2UXJc67kR9LyzMy YfysOohZ2jTAIR1CCO2JiJqVqEBEvirLLC56s7egIxt1ViIy21v268DYNviHhI6C+dG60AxlHXqg KvP8mj4CbLYIpvdqKOn3i5PxZRRHB6iQkwXt334mJ5JvOF5yDFVKnO62RjsGnJNDjNhM2YLp1wpJ eeyC1EKzUJ7BjZpCoY5KkVfVNbOXWLOYc0sofVNCJhDueixYGU0D/fjNylcrDNPf/V4cFlGQoBgx nvJT5VM94aYGE+QY/ciQgsaLhM4/ATi8bRyOm5pWjiQa9BVOlPcsCz1d0MVnD7S/Pr8zFoWK9tah Z8J5auymDOaFdNbwrTqpQX1bqQwXH9WQ6zmKPHnAO53gXBcis5avxdKtU8W5RnvJ7VnpD6QyFzKG Y/B1S9G1yQGzKOgPNeUObAsEUv8pRdJ8CwQAWdnKCP94IbLDEHO/CT3QVUlNxxBk9yGi1+xKX3gE KBEtoQxDr0thy2HwykY2AvmHUQLzqNFRtA6qpzkXwBn3l32iNZVSVn6B5R8e4rWCxJGasvNkV6LO INOO5k1fbXzVdv6UFa4yqhmkmmzqLm6qYYQ55Klwd4WGbi4muGBJn7O504JFDdueZYyHOPBXjhvR hOu6o8vYOOEJ8fzIf48ZDfWweG8kzy1hSLYNZW5kc3RyZWFtDWVuZG9iag01MTIgMCBvYmoNNDYz IA1lbmRvYmoNNTEzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFt ZSAvaW0zMyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDMwIA0vSGVpZ2h0IDEgL0JpdHNQZXJD b21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTEyIDAgUiA+PiANc3Ry ZWFtDQqx7FNaOe+2FkzVnxzHCajQlCV301cWZAownsxDittyII1M6wfZd7FDQjPcEc2W+qj+O5gt UF0oLhzEBSSPuk6dtB3FHzzJXuJHwjh8NKAUcqW0jlRJLmbKQYnDViiVtRqXRZvZrkKj8RmEsNjB /Uky7yC5etjgRqjjY2QSSNcjE/ModQ4DxgS6jDrtHxcbWoF7BnzgacNgWuYkNda8QnhPKrGowmop 3Iuov7XWn9WijyuH70In6Vp8/eQ0HNOQdx8tPPzB1X1x37lGMSthLr4ORhrQeCvECCPv7jX9Zyo3 7OlE0vMRz/lN8UCmSW9krxAakpKYQf/CV5JFRPDbNOiMMD+HAPvGzZEH/KD2lcS0MQsn/qhRZd// EmCKlz6ZVr9UZakxJNpnhSCnUN+pXQQ7DZqI9menkpV6gPnMapFQ2w39ICdL/AD5TkH4DQqIQSSo st3aDALGLCeydixhU0Gc4hDJaSG6j/j/V1mtFmcKQJjUDHqrQzAjwXTLdr9wXaJWk/8Usoag4LCr 1fcVJa21whb9BnlfMXp/1cJg+Bb24JAMJGUdQaZXg2k5DOQEMLjaBpT6MVXcMA2iPWsMzcrQuoHI p0/3UxBnpBS8FL1EDWVuZHN0cmVhbQ1lbmRvYmoNNTE0IDAgb2JqDTYxOSANZW5kb2JqDTUxNSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMzQgL0ZpbHRl ciAvRENURGVjb2RlIC9XaWR0aCAxNjYgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1MTQgMCBSID4+IA1zdHJlYW0NCkfmG/WAZj+4 DK5gjpNBuP8d3sv1gvAd3si78P6WYtH0iHy7Y6BWNEsmzL7kL81H9vpt7WpemEzw5gTaFLYZIu/G rgQy6E+rhAGSjpEQgwhhDZ2gtNyR3zdSkMDlfexu147nMOg65S1N2HHObOaInSlXnZ+AaxTgJwgs 6pkWSize/vBv4mKOgCki7Ikf1SuvWt6opR5iwEl+/beGAL3XeV6gofD/CzwjXc57e4mWdHyx8iFW C1TB5Tfn0eHBNHeSHAICuIhDeeBAm3HKNfRzFYODMSJpLuN5ce1e2vGfkr56oAinNeMgiJR15Afb uC7KOi7LjXIJcibowl5NzlUUmqdVOCrgCeQBrWf7ubEbgEm/FalkCEzcuMbxMHNO7i1EOgQpIvKd YA9fJhvEHFapYySJHsRDNai/xVgJiTtTRhkKfsy9GyRt9nWo0JcwbmVRz+YDPsw4EHV2pzpJebOP SzNGckXL3GozKrQOoxkAxP6QIhGL8dG65tGZbOASS3o/jG4r/H7mOnpWb3tJDxRwmmr/v69Jz1b3 QX39kDBtI8dZeFsYm+zloEPPWeremEZ/HYXEtUfPP1HB49RsRdWvhddBDEOu+HObwAR5mg3peiOX c++QfdJke1jcpuzbI8zq1gSR/zxITxqIKvMGX9UOPBCEgD3kzRlBOBKRtnpnzZ2/o34mbgbNGl7f m8ErjSduLdwmOjgrWa9+f8BpWowveBSi/allsLQfhibJKLS1ZRrKhXxUTtmO3axvJpyxZOQA/05O 8db0ou2x1iLSjYCH+UsHA1phNiV9Gvx9VNDQILHb2YviikdivfnWw4INZW5kc3RyZWFtDWVuZG9i ag01MTYgMCBvYmoNNDY2IA1lbmRvYmoNNTE3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvaW0zNSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDMxIA0vSGVp Z2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGgg NTE2IDAgUiA+PiANc3RyZWFtDQqso2Lh0M7pSirJGwP1opSDw3Z8HJn9cZVahkJzFM5PLpLuofAN VD+MxrdsN5Eadxd1JC+yzNiLue/K/xsUdiWeNfQU/6BCDUxhpRFkfegA568zEpDaj+xTOUSuCwoo GjWV9NPg44h4jiDNMTCv0A9iONPcnOzrhL49vHn5h0W3/v+hyTgvFY46LJpwJTTLu3RuFDcMo4Hp 9b4N3JEowAPAwWYBEHSCrbpPjulQFaXmqqdipxfNT5+TEqxAke+l15gusPFJaXkxDlLJYk6rqocl gHj9Ko8CQ9gwvVxBJNn65tQx2Dk6QsXNRvNioN2543DWA3sDQa80rxITddIn8SypNEoUq9JusJRM SyvfxZAjHPPYkVj4vSiJwMA9h4u2Ew6OkAzdJ1zXD/KHcUz23d4NESSpqhANgJ3zlQYjIGmkk9+3 LVZgypsymr0nzwboLEPiAcX+ps4Tm2y4ZowZNPzXFvIukCJe6aMeTjl2akxER1TmL9r1UTylTaBn 1EvuIAqibAxzYM0qbhsOOw2skvOu6PluGVmZY4kvTYFrmOdzXrG/LRPFHtps4/gMLpCdzd3t7GfT 0bFlr9E1rud5Cb7HGfFR2YRzhIbk6NYuDXV23fMuDWVuZHN0cmVhbQ1lbmRvYmoNNTE4IDAgb2Jq DTQ2MCANZW5kb2JqDTUxOSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L05hbWUgL2ltMzYgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMiANL0hlaWdodCAxIC9CaXRz UGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDUxOCAwIFIgPj4g DXN0cmVhbQ0KHO8IbqGMaScPDnsUbLneVKil3n3wRL3AczIGQ0xUh0a5veuHLPUuEuJ9b2KS/6lx fx8og6MlIMx/U0UdfVAytexDDxP8rcShmxP8/+txfoqovg9dDy3M7exGoMkuHTHBkCF+REA1tvCg jeI3ap6PaIWs0d9kcsEZQRWg2zmGEeFgP0+PsMAwgDSoTzgCFx6cz83bkhqDytLx/oHCEtf7eHNo esS3lRnhxFPreGC2dHX1ePlsCmURodGlNyIWARTnqSNPu9ecSackL71djMnBLS0vg3bwgkxb+Qr4 NJus4os59X/6NN5b4IBI+AGFaGvGSK8OqgqrnqDFhC6GkCDukk/suzV8IbJGXAiz/12CXlN4SZ5V NJaQLHNDe84qINCxpqPFuk9jqIAEeZrIPcnHgwKJIZ+3R7K+SiuSp3b6scduUwMNxlklBSuWmNuA CGwgoevA3m+dln6bnGUH9yTdZC3WRDzW32KBEqX78PZWVqZUnqKI3zgYJ5TwU3whNgMwU5xeXtMC OStrSrO6FZr98lFXItyNIj6MTtFvar0M0d+Ag2icqO8v69tu9jHCcu0j4/F/GdD6LrvgKQ5rLy4t PTA007etKZSPSq1gLw1lbmRzdHJlYW0NZW5kb2JqDTUyMCAwIG9iag00NzMgDWVuZG9iag01MjEg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTM3IC9GaWx0 ZXIgL0RDVERlY29kZSAvV2lkdGggMzIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1MjAgMCBSID4+IA1zdHJlYW0NCtY/OPIDIpzF pDkAY9TvgfVXtsUW+eQvsd0dDcylvB1yt9DaPoySbk6q04jv4mAujsbtS2uWjGyHwn24LkNNqbYa pW3TRpQSganVlzQZFGWM/l4oQwT+YfMIq3Rz4iCifLaIOq2MFdRrw+IuYzoldfGsvQf1NVF4dNXR otSvdMU5XJY9qTVdvQ1T8fqHs0AYIyB/Ivz6jscWoCA5sBZbcewGPEqllT0ZluLtExHAXnRB6R/1 FUTZjroiluULGa1B4BBk2ziFgqg3NEvMWeWISOqIFThTgMLES645vzVdbnzXGfWntwoviVyDjGvl jbw/2qFYHXi7gZLUNwggRVoMSt6jw7qVMQOENT5raV/N6HCjGFLGTGW9PHIcQCQkh3qWsPhePIN/ 68smbk8tb3PsUaVJw5fpp9IdilG54xG8PT26UP2gD2CQ3Rir0a0w3146EdtvtRUFAjihtpy4s3l5 JsICIbiEn5TfOI7gy6vDBfOPtqVQ2tz3D1X4mutmr7kHVFzzrvUGCmjMyDP9d9gYvOsLwuQSJhbw 03qaYZMmQ9H3HF5cIkdSt4KC11MUU6Bb5dZMvv49s7hjyBuI6uy1aMV+Q7OKDj9Qa3kjBbb3nrVJ AWBp0i7j1/URDWVuZHN0cmVhbQ1lbmRvYmoNNTIyIDAgb2JqDTY4NCANZW5kb2JqDTUyMyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMzggL0ZpbHRlciAv RENURGVjb2RlIC9XaWR0aCAxNzYgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xv clNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1MjIgMCBSID4+IA1zdHJlYW0NClDTormvDbhdBG+x ZvpLMvt2+X5vY/74+9qSf6zazGrKv4KnRXvQNqAUbreoMex5l1kMzazOOWQnMIlbizOgg0plM+SD yna7+XUSkejGk/ZX9U4CG7LvncnT1bm+AeIV1xMA8p0qSog+zzxkzfklgtQQ05fk+PD8SqyVU2/d +l0zKIrea1n/ypSs4tMoOBJGhbG7u5yVDv/qam7UvMP/9wOhqUzn59yktUnPRQG8f4r4gQ9uWCeF tvw3xiyZ+EMdESehZXPO+XXqoAlnsufMkom5Th9+ZwSKTZ9EYWo5RfZwUI9tKu5Dw51+cDAc+hcJ /sBE3U9OsFQtihVWcLui1GnlS1VS/9TQWjNqSWs5xFkQAsVMEDOCynuwgj45uiH3s2tNTmGmc1IT vDBHzac3d9UrRqqlkhy68VB13457n3kNAzi/xFweE0/42oWgU7JSs62vUfkZo4nxQZeE0IOjYQuT wJaBz6D9bM9w+7bqMcU7obJlLb3Co0sRUAkFp7iYt6XohqqjPeNcQeXR5JvCA6as27x5jQUvKPAF 5zI88hXWWrywcKZhf6b6vzW9ZtsOvkSpNAvNsOJX1MiFC2DEb833wdo8fPyVeWhwkd4NifWEcioa 1mHrTADc9rP57lNEk08tBqTF6fTbMDeaw3ytPB4C5aLkYhLd8h8PDC571q8Ct2FyB2uux8GDByGD a3cNGNOTwpywSNWDThizYZ39ZpXxdElNHQgRSJDPZpoD47RuRaDqudmLStQaBXiXK4H1VK9gBWH2 qYjs8fpif6WNdp/+g0a6elC21nrO+HRctvfoRUdP2VjVFAY00FVvS7MA6VuVc7t+ywGVkBi43oA6 dOrExtO/3zGKUR88aO3VZR9aCG6AJyVEBCXebtqv/wRz+qWtECI47d2vXEpzYw1lbmRzdHJlYW0N ZW5kb2JqDTUyNCAwIG9iag02MDggDWVuZG9iag01MjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTM5IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTc3 IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9M ZW5ndGggNTI0IDAgUiA+PiANc3RyZWFtDQq9iC0PS/yGQdUQWZhHRhp6q9PimG9++9r7dNAib4p9 olihOzMthDV4RDypsYqL6dtC4ZJuXjlhatY1YEK3vetU5minfSZxcIvBL3AwuTN86GLBLPuYBQoP XZxY3f+rQE+q3pirCcluFWxaCBDeIvJ7JN0xQYlN4EdxXdu5QN8q2TSKDaw+adbNWfETf9uA4wh4 FTzgkLszh8ZSvgxsH7nSjO5yeG3B/G0NW3fFFhZG9qH6XaufuPgslgRu5Sku2oLcDQl/jCN+vJJM 563ocu6SNiWQHy/MzgNNx6Jc8alM0t3ESO3PRH6Xof2zK6Gml8C2bPI46sXjjevFoW8NECz5+wiZ 6kP/ZpQ0z5D5LhlSe47d5hg9tFHH9lY58i7Qa+b2ufWR458dHjIG9yeLkoBpYnjV9T7x1EW3C5IC sMIfPgs9QsAhIMm8g5uh5nlhtjg9BCwDyTskFiklpLbSdqQB65FcElTwzpvZzf8D3kXcsR2Lk1Ed lLgpA4+7icx5XN5ki7Zn3fvcar9bja2Vov7XuS72ccOM0mrK8cBgff8pN22ejWMtp80OWZrx++kZ X+wmtZ1Qs5mSNUh4t0NtdSS14vRyRyEladMj7OkhKuLKDNeIb9XE84pHrYi6P9l072h0GGhkWh7A BagkAgXDmhItRAEpiMA2anZ7DuAYA/SGQZ6n4rN9V7vg7XoaDutAkzZ+2aqwg/sVGMfVns5Bn9s9 tZOsQECargYf9BVQpuUvWnBoX+AvSLr0CYYhUhLvzkSq1H+6wh8yW8uIIoBRL/3Bvxtl3j0mXVpc +OvE5YQd/g1lbmRzdHJlYW0NZW5kb2JqDTUyNiAwIG9iag01ODcgDWVuZG9iag01MjcgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTQwIC9GaWx0ZXIgL0RD VERlY29kZSAvV2lkdGggMTc4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JT cGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTI2IDAgUiA+PiANc3RyZWFtDQrr7TLz/1sjjcy/NGAt qova+ihzVPtg2xl6xgCMp9O1K4iOXw39UmehewbUCph6COl/5Fd8/0rj0sNdNkznb5ZhFwi85N6V NfjBMXcAEDls69wKsSXwFeKNcHTj8+WYtbshVOgRg8m+bxtcYyP+42p4i/KLuGexyPQa4YDTjg8C 8KkHAiF/Qb5deR285ncKfTMUDNdE4ehIiAcskbUB8g9lu32nZXVI0GIiGrJm3Da6+Ub4b9RKApK0 cKBLuZRwxtVBsKDp6zkNgooxJxfJ8xi0G4AHhkeES13y4DVroayIX0+A1qCvqZTWqGlDG1PeyHbL cFqOfiNgaNAFUmoi26onKM2ke+6jq4xDKcVaXyYZXFh+9f3Qrn0E5jqCbp5ezZfpCXTHuo/aifnX Uc0CRm6Ic4+BzyFcBH+H5E6Mj2h1M9RsxNeiXDOZX/Zh2d644OwJead7IGARJ4PdDyZstP8chk4a MmtzipU8gln3FCjXAcgFxNrMqlw8tugwAM9tu1KM+H3iI/NarVStMDlWq+lqCj8Swn8Suo4NAABJ axkAboTdD4r22iyMYZx7Or9GGjo7becmJ+PQ1UuRTSEMNQHMt0WudjFGgMjajpbPm6MEmQq5vSFV 3tEhM5+s9aFCFaKwjMBUzXhN44ajlfJBSyaLgMOE06deOinMt+Efv3Nwr2pLLssGQScduKjuyxTs +FEwZJTYAjevcjtoqnzSCWl1deWjMWC/ghEA+HpIaTJFv8bXmFpQSX/V1vIPgiQNnXbPNoU8n9Mi OpoHDw1lbmRzdHJlYW0NZW5kb2JqDTUyOCAwIG9iag00NjIgDWVuZG9iag01MjkgMCBvYmoNPDwg L1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTQxIC9GaWx0ZXIgL0RDVERl Y29kZSAvV2lkdGggMzMgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNl IC9EZXZpY2VSR0IgL0xlbmd0aCA1MjggMCBSID4+IA1zdHJlYW0NCtjHUhIHYqMnPFJ/grG9tbpv OMU0a9dcIaP9bgdzE6ZuB213ReGWHctTlzG63NBCmGz3+wdGt5UKwNsqYck+1caI5T/ySU4jpTLT jloknAFvjTQaHGd1S/jUEr8LgXB5Ml45ErXWEQ7wKUEut78+m4l46gvMFDUTV61DmlIleEmNB9Hh 6G2UqZHYAc9aeGpr22wUMIubXwMIWo0KzhU+PjWxd7WE/jKhptRZH6d9/vbuVLyjtQiVWW8RTMgK PdfxhXCdghWxuqc92VFQ6/F/WCzzlZa+vuWhI5ucUf5ycfer31e5CpK6Kz3W2c+vIpjxbXfa9Yxn S8xvafQnkYrIu5KDGotwBWcqq18stVhRIS1ua70yKZmPzgDcRNYp+c9+LqZEd8jxF8Fw4E+TFktC PZ+DtDPAPNOrUVKuBmONZKCAPnZiuIBbZkIicwFSZOeMQ201Xko1ji67gwL25XwUr8OkLFb4uBUr ce/G5/LVAsEFZNuL3XCZk90/LqHIsdsj7dtQmMaOIERKrl+oLlpqtom/puzQ1VhQQ+KqK2r77WM7 t3wrGFYb9twPKMN3XBPPwBP/7j+0ZAKF4yrYKfKnrhHm619qzYy3VYt7hNVKHg1lbmRzdHJlYW0N ZW5kb2JqDTUzMCAwIG9iag01MTEgDWVuZG9iag01MzEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTQyIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMzQg DS9IZWlnaHQgMiAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xl bmd0aCA1MzAgMCBSID4+IA1zdHJlYW0NCt0imxA7vwoWX+XRKATcSAlWQgW4I8YHnK7d2gzuInhW RCN+jd31I3Y6hzESRMJL0PCPcs+PDUyTPsO2sQb2c+yCNCF7r8s4MMDgMDO7zXGuVisiJRk90E/R /0Ie2oykASNuf9FdbJ3Q/eFkOfAtc/7naSvKaRaiiSsvSop9jget2MLQpBGzY3g8fuw653bfTVJB 8DHjTCGkNWNuPS3dJ0Qet8ceblQSSGsrjRwUJu4XR627teuGKM47PouoY8K+ilbyISZmrbQ/yazY eEXqJr0nxyJx4JRNBMyFV3PjU5+NyVNqR8hxVYsZRceKBGlStVmspZiXk4FNioeJybi0RE4CON9Y bRB0j6DaCwTDkdSKFx+PZ3OCcH8Juep51DIoUhxA01C+mnRLbPbRitE8gSqo95+9yY5Du7xI0hmx gUtQP1WmAjFJb1MMrfD6c9q0UtI6ZzH+mwlUqi9AbmfaSPQIvAn0GQgvb1EHQI+Oc0I3bmELQfFn dq4eBWG18UBXAwY4WmdXADKCHbBkLIfIYQRtNl8Cz4RsiJ8mzfn/u8Mg7nBe4VH1b3svfWH3OgqG jSRmLi6S5td3+oW/tPtx4fgZdkEKiuB2+lwZYUORj1Z+0hMMjH4E4NlzyIBorNfPUqb5EzbzJSJ3 nMg2YC+MExx2gMhkuj+GfGdOvVDKn10NZW5kc3RyZWFtDWVuZG9iag01MzIgMCBvYmoNNDExIA1l bmRvYmoNNTMzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAv aW00MyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDM0IA0vSGVpZ2h0IDMgL0JpdHNQZXJDb21w b25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTMyIDAgUiA+PiANc3RyZWFt DQoPHWzQLKAuYxjZbUcjQM3u6kp1IptjvacrSyf2tJJe+NSpgqawSYwMczCYqp+L+RUMXKfHMQ1O cJN+brkHdOoFaxwz02KEGZzD7An6CVKLKIzPBY3AHYk68jerEhvc2O+Vl7YoI5BrZC0Gn607+U/M I5IuFLRIJyIwhQneJrt+XBmBSoURgQI2O7q06k192u9If/8Ca2jdEoOxSoKqPE1lv0OKAzrc+XkE /ssCWalRx42u2tc6i73+w8gP1HzYxH6Kfz5dB+hkiOpDSx0iVxi2oBSBhppfrKRYj7mpwVzwAVYX cvnAyZfQIgaIWa3N8yhxz+J+FmCtY2Ch68sOmuHp9G9rCAryuBT7yb+JIyod4iv3fF+IsOqM+Zjn kajo6ucpQ8hObhUaTX3dftYb8pL0LBGu64fZ9Lh9ShA+ZS1wvgrC0LFg5JmEQsGpzaVjyOc5jAgu S7VYRyCDPj/K0JwJYXv9/oaD7hu+qKCyUyeBkoiOWn/cYb909xX3AtAiwD1CyshxS/EsCwdZfBH2 WnyNjtzsKhbKl9bhTxgNZW5kc3RyZWFtDWVuZG9iag01MzQgMCBvYmoNMzkwIA1lbmRvYmoNNTM1 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW00NCAvRmls dGVyIC9EQ1REZWNvZGUgL1dpZHRoIDM0IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAv Q29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTM0IDAgUiA+PiANc3RyZWFtDQoeBPPTQGRJ LIEJPlP4RB/y4vfDjmv0HhSGcyaf7/+6PpjuPwrdRjnaOmKiMA0yHtGVW4BZowX0Jn67ryG8ZqlI CuA37t0k3GPxARirG2eO5RG7TKtIUCLgaapqzhiLPprDTc19Q/vpTx6RWolZO9+tffIHocdGl0wp sDfxvHUto3BQ2C3vFrBM3Gyb+YyQUKqXI3rKkWecjsKMSDKrQnJfHaFGxHfSbClixia+t82Li8ew ENKn0pYhBVx4T0SFtZlf0AP18Y4TYd/3G2PJvFrsaI57f3vz5eywcBUkEeSbsoEK6pWBZQJtSSZf KI+zBI/NARIF64SGCvoRUFXwL0bBz55QoTMMbJlj/TvwY3CN/HV2Q4R1Q/kV+v3Bxx59Y9TAgHg7 haZNOEPlPSDU0GfvLv56G9uGS9e4QL8odqjAsVGY2qBzQKKBuoausoPxdgVAcHgJKUV9EOLcPfT3 kX/sojUPFaolLXFXzHCVuoHz1Ipyv6QNr692Eac66uVK7Tpj7G7Mcm0NZW5kc3RyZWFtDWVuZG9i ag01MzYgMCBvYmoNNDk3IA1lbmRvYmoNNTM3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvaW00NSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE4MSANL0hl aWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3Ro IDUzNiAwIFIgPj4gDXN0cmVhbQ0KR8zpSzfoNEfhqxjCv400XYA3kOAYsQ1b6B/lNMn/D0B7umrm t8lmSCEauywT4liTd7rjyA9PxNIaUwXIeiJxPSu8PB/ygByNwmALB1ynioiH7m4CrM3cFFb+++X9 l67YkD7xidW48ChkwVcxbSJpiLyoAXH0QiO5HicxhtWsU41PVFXIirZn2aPkTCBRd7H9Ovm4Oy42 RMdLbDl2e19z4ESULKkEj5P7PCXz3XN+XEfYBPZOClQSUwBNKYrzCfw4wFQxVg/vZCedYBvz9a69 dfzA+lL+4Qmbtw61tVWuDlL342nlXHf3OqOrpOKvN1WEROZ308txmz2UokgenoZAKow3Y7Ue2Hdl QEOeama4B+/Um6CzrNwYPNUZNIlYMP/aaWS4B8c60BvizXOssMnhzXYV1betYDj3NYBGNVvgWai7 9NUrDmKE5X8snOfR1A9emY/9IABzRKwGO+JQx3sBHiqXEsrVh/A7YmDHkZ5jlMIi8pkKYHteRIwa O2ee8N32wCnUUdouipu0cqJ5/6WGJXg7jiWiozafK8ZQdCme20eAD6SAMNBr7raeIfCGAteXKvSb qxN13c2qx3SaCgEQ0XYrCkuhzOl0x2ADON8EJKncBrHYOSLHNb3E88p4xjL8Fl84Nbw3C2hPcmOc 7gJWnygNZW5kc3RyZWFtDWVuZG9iag01MzggMCBvYmoNMzg1IA1lbmRvYmoNNTM5IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW00NiAvRmlsdGVyIC9EQ1RE ZWNvZGUgL1dpZHRoIDMzIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFj ZSAvRGV2aWNlUkdCIC9MZW5ndGggNTM4IDAgUiA+PiANc3RyZWFtDQppPn6/xu40boh1ME2g+HGn 8dDpNWB1QFv8hrZR5LlDB7GcFir9ywwLbpmHb/4Nyc7Kz2BQRhMdREn4XyrIMT2ZQMIyzIGoFKbp VB1DI3xf8xLCkqtvK3PJK/8mw1kgaiUyw92VxNXxEsZZMCW9KXT7iV+/zMwvtSBnrCVqBjnVvMLB NtscCkzv8o4GRGSBn841Sts/CYdcOOd1dRKLvVzjiMnlBBFYQqCbdF4JXfCA6Qo8waDV7yUDcP0V HusLoOlu+j5t0SfpFDE3FQLiuph5KulLoNha+azwt1m2ykGKKbgI7dFmNmCRJsdJwEJ006ofkOge fautLktLi0THI4ILrCjpgbfsCKlXnO92M5OS3Fii6Y5LugxUCQFBrK2MZvk2J8cc3HnUz7cO2hrG +UayggVUQOcRXLUA5yYefuXn5pc5bJOapWm42uNQ7T3XLLasa3c1lrbN51mG0VpNIetQFh28S+0C iwAWKdZDTH5RWahhpCW/51jRSJ402Lwd311XDWVuZHN0cmVhbQ1lbmRvYmoNNTQwIDAgb2JqDTQ1 MyANZW5kb2JqDTU0MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05h bWUgL2ltNDcgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMyANL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU0MCAwIFIgPj4gDXN0 cmVhbQ0K78ydw0ss73A8NzRoBoKx4tkN55c286BNyJJOIAS2ScuBG0GB5B5VgwIgZdjTWXZo8pzz amYRbC/nq3b4mfUYmz/BRteQTTnHrKRw5Q0s/jgc6ezacGCTXTQH8juRyBKDFKofp/dK783Yihgi TbdMWoT3LZkrPKWmAL8M5WFvQy0cJx0LrDf82Gm34FBvN5qiJAGuPP3L+vDkHU3at9vKOe4EOwq2 Z1Z4UwpBd+RxfTepdNReH+WQSi16ubLGS9M+KVkQHz3De0Rr60ERLQdagck+6eQ6I0JA2nmgcq2o VxbL3L9SOJoaC5ZCDN8OL3FbaC7wRU5Y/8v+ROj7fQa+x3SZIbsjoYzwsi86plqgD9wby6H7mdW0 D63PQ1NNcmcnO7CjHjPbeh9kW5/vU7MQo5hrpX2H4moD025C6bcrpHdeGNUo5W/7WynF+HfOPKgn hfq5BzL0pSAxXdsUCzSmMvhQf+9BDHHFXw/MU2y7DbLh1t6or490966trU8Q15vGMCxlV7TflY7Q 1YxJtoh+SFz6Mlx1pRR8mxaf274xegEQZCAid5zE3zY0Kh3zLFLEkLE7wKVFWAGT1IPR5O11m+vT PjuIDWVuZHN0cmVhbQ1lbmRvYmoNNTQyIDAgb2JqDTQ2MSANZW5kb2JqDTU0MyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNDggL0ZpbHRlciAvRENURGVj b2RlIC9XaWR0aCAzMiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2Ug L0RldmljZVJHQiAvTGVuZ3RoIDU0MiAwIFIgPj4gDXN0cmVhbQ0K+k8wA9TgNp5RY4orwP40XYi2 n3zgQRehjO96IXELrmB6NX/8ePQakrUBQzOaU2QIbuX4Ze59FHUQVKuOQQl/0PNHx3SbrxcX+hUa NAJMf3t8+sgioXNdXOjjnZszODexMXo/NdFUfzzK9KySNnuN/rY5yJOJMMZNGCddhx4PvTkOdR8p Ffczb1XzevfUwA/hWDZKjug/sYtMt/pV8d+mSb6n58++2MDVE73vObTIOI7Nk1ZzfruPOySZHwm6 TsR5V4I8nSAZ+ddtjHIlfE3Be5suXEnxIttzkAezlBJGxShOffKnRI2CRHpUAYBNzI1UEsdMlr5D oRG10buwMa4o/VOTaRT+mTBy3kMgIsN4iLhUhFq3rnQroaT8PaU1S2IBMLRxYTO1Fg6BvD8LwE+c YfP7u5+35WoTvSoeAQ5VFZZMPPt9fy62bM1wlkcQNIhIyPpnsDObl+3JjsJ6PKj9AnzDS2RAO2oq tL5U1HVZ1NcS8ekZiEXB08WxTztyHXTVLQfKkgjwTauRa2bdElhpnEZ4BgcZl/mLDQv0L3m6JPIQ j0X8xy2YEU7GT9pPj3zJvMerjnqZXqRURVvZ3EuSNJMTv8QSDBrz6t0ZPSYNZW5kc3RyZWFtDWVu ZG9iag01NDQgMCBvYmoNNzI1IA1lbmRvYmoNNTQ1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW00OSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE3MCAN L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVu Z3RoIDU0NCAwIFIgPj4gDXN0cmVhbQ0K8lEqfM88la7SbhK7UUMNduwzfIYgqlMyJkk6v4NMHjUw h925VwfCOcMUgogL5+QHN9gFgc6cVUAVsfA+kS7pnCP1bqEV+oeJYCQU04+lednSrsSrl4eDRwnh y+l3MMJLEH83UJBV9ycmh9c1W1XcUgPW4ZglX4Jbg2cc6x4lAqTLj90bZ2eX3MBe1rV/ZzQKjCBq H5XFN52NblouoiM7N/2TtEeA6S2lzuLf3AUeMPZRqxmLB5EYRd6tCMHUFWKk1Z2d/Eov7SCaXDVu 48Gf+HGo9nbAtVycTP6CJT5mGLykKfflQBhmUiGdk+bZvMRBaumorAonGOjVQ3j9glLnx+A6w+N+ hNlWLMGlT+qVr3uYZRw8jslfAfpI+Te3ae0Hpl15Ndzx55LzoDGAKwOD/kNcIPOzFmHC7kvjLBUY m4zMe/wWZHvcXasHn3mMAGvrsr5PbrZ0GqadRQhUkgTxenFde/KZeKB1+0TY5htg2qrPl8nbFs46 RmBADU9JX6LTUvPPX+Fi/E1OuUf9C/CTHDimZ35T6lMygTMMK+beHQvB8XthvqNo5I1JA0GYCWQi JmDI5pixUaU2z2r78YJPE1R18Q2KgMFBUFUSOOslSiDSJvUrkdcimwSBtTGozvvQL951ZsGdSkVP WJ8ch+i5Tv7reeJPONL1pq1rAMUQfDrbBxNmeWvXLoYpWOBMILb5JX2wjLEL8kIeWPyUl9FfZSL4 og8jXnZ12y7LAMlGafwoGJrTdEnHvtAJlgh5kG6X4ny11e2Wb/hf7V3qhL311ErY/EBPRZdCunns c0D5AhdTN9KyzsjHQkoc0HwrsAMZM4fUHalA4FNXkopoHyCCDTd5Mhh9t5hwU3GzCxjCW+ua9eZX cNXWOSMWFsauB8+fQuP4WxtQFqThD+eabrQPaWGpj3VZGx1JJUQxUGitZ8R7EPAe7QZShIJYaEpL PE7TodndCf8NZW5kc3RyZWFtDWVuZG9iag01NDYgMCBvYmoNNzM1IA1lbmRvYmoNNTQ3IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW01MCAvRmlsdGVyIC9E Q1REZWNvZGUgL1dpZHRoIDE2OSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y U3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU0NiAwIFIgPj4gDXN0cmVhbQ0KXfzZHd4TA3IgcVkm LIV4i3bbZz4bqjp8Zq9kVDwL4Rpgmw3zyC00Zb3NO2MsHMJlgFcmy4SItqxqQXCwdDdE38mfEpHM RwnjtVCbtaYvA/tjWKBW6G/7H6OKTzm7q0ULUQBU5mISjCBKAtUY2DijmBxS3lW9y8Q86vJW2hew Tiu2iNAKgM/4xVBKyOrVtlnQdUKSsLzTK+3N7G9Mo460Ammw+ESt6bYqQXpANugGvF/ulYiYNt7m 6/MGNo0fTPkMa/MTUCn/bpsckygXlE6h0Yp9JWoKwVNO4a3RvKbcVpemY5DjuKd+bAxUbgODlMZC 1+wWN7cpic2vYpe2rIX8tgWnHNdfg4SDqZFD+q8qk/YFR/3N4Bpv1lyw+LyQZjncFXBocLfaQJdu JzlUnDMNb4QoiEF0NH+yXHWW5Qs6Wf/1KFVNWJL8OWzC+KR7SLtiB6SyvKs7HBugcQSFcw83nODl Q0VPJXTkx+AAXhTV79DdcvGZQb0RPxjwcT1LB5+XJi8rNqN7cx12KQHduGnuwvHE+fjdVbVNB1eJ BwKA9pkOa54yyUETw3YX21GcwStXcz/xDMBOk1z56WbAMcfJMP5dzLc26fYLQ4V1tzifiLxR1MuP MvxbifBWZ9WMTIAkRdiLHnyAuM4noJ7dcMs5U3Lq0W/9Xc2Afpijs3dyy7aphOxHjY5JfnBligTx AM1RGqiZkLysixcecDO7CKGFLuZ3BMc/ZbfedAmJjFIcH37ACzJ+eDW9iOXLM9ZvrpUfOodePDYc /HNVtQw/JCcCIOMXUaznoXFiY4mB5ZVSG8WODvEYTj50tq/+18wPNPT483IfSr5YUBEzQ93o9Yzt 1+Vqkpspd7bH0msYmbxIzKsnPWZoWXaZnF+yG8cIBQb/31raovEECdMHhaDxQb7KDTVJyIDboA/D RafjGbo+G9S74cGCTh8NGBbkeNXKKHa6Qxav1Imf99E4vSsediNyDWVuZHN0cmVhbQ1lbmRvYmoN NTQ4IDAgb2JqDTY3MCANZW5kb2JqDTU0OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlw ZSAvSW1hZ2UgL05hbWUgL2ltNTEgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNjcgDS9IZWln aHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1 NDggMCBSID4+IA1zdHJlYW0NCq1PN5DzjX1k4D1XTDmwWCvXV/rTfztVgLcdJC2kOSqxZl0eC/3Y vISZUGeBeOdruWh9tfOK3TlGZP+mHsBDAd42FyLh6iQ0fnkGTo1Nzj5roQJ98DZZAUyeO6/8+pPK NKGvKxSwVPKX5yl/ZnEyOWgQHVQnvLTNZV2e4qPbSyDpQboqqi0G+3P+g/1ToyZ7HQAS8+8poZiQ jVeny101SjCyjf2yqr9mN/PcxG7KzwaIkpkJEZux2OqQu05TV3H6B07zK89ZffsTB52KLZYVkQRZ VGOguPpwpsJ4DgJ8owU4k+WJg3s25N5LoeARJ5VZGErhuamie+ia2Wy/BSrRpNfg8LcFB+B5qumB E7ZR3ON4i3jDYNL10Ch+2tUAwD83YD2FTlbTlM8410/fwmjPFgB29l4xT2+IGvpYPXAh4Wbgf/hU nzkxTmUQQuiQdbIdJYQHFsG20gC9s3q5VSf596vMED8JBT8KXhohn+MUqQvLuRwVp96U06lSuK01 a8M+ttu4/wbER58DqRGlgau6sdVnRzrYS7jowgsv6foBP9sTmjQDA4Farbch/hPA7ZsNCyU/YyZW gu0y5xifjWL4s2BRhI35KeXb6TYGyZs+U8Izcqt4aKr8TNrxemrlkFLR3ym9OZTDUCWn7Q1gYK75 t/YAD9fk/MyX5ShwXBqyTdIFoprSzZGrqfkltJWISBW5CiwX1K2esa+1w5PDNkEEiAS4JrvmPfxy t02Vj0UJAvOdTGg2jllY/vvegpEPH7Vkv+jLh6ecffRgVo/xwdDVPSPPP4igtFuveHfr9Vu5tT5h TBrJDFhCyyaliCxVdLhd8izV50n+iXQVPv4icH5wibwXJc5QI/QGZmNeva4HKbf7jmW2YS5xt4ux hEzyrzoNZW5kc3RyZWFtDWVuZG9iag01NTAgMCBvYmoNNDUyIA1lbmRvYmoNNTUxIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW01MiAvRmlsdGVyIC9EQ1RE ZWNvZGUgL1dpZHRoIDMwIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFj ZSAvRGV2aWNlUkdCIC9MZW5ndGggNTUwIDAgUiA+PiANc3RyZWFtDQq/PXNNVyq/YxgnNLlxTrgn BmKELklYKdVJVvUBkwro250iNoLZsWHxKb6BrRgURpA+PKTYG8ZDbR/1/AxTn6/kiH+xteVN4/Gm aWhuJHus+dD1pMnMrZ6NkjGZWYL2bGT6d2FyTNS/TiV8lUTHUBO2yZLecrVGh7+tQw6Fy6B5gD4c eju/KTWJC2a95pMYmp+zYLBHwo8K2pTjNe9pdAGkWT1ubihGtZQt6NbtFus71+Nczcz8oLFo/rl7 JpFziSU82wp1xBsHuwrZkF7hUNCmp3EsgF6eIipON2wNg2BsjUAk2Dd/BrLi8jVmvOBJR4l2WST2 uw8EBQVk3YptcwQYm7q6B5vfjLjqNI4W3fyyCKjnzyKNqf0yNBpgvDSL2lX8mGDp9QNNtIimmmoA 8qNTBVFMD9DM5Ixmd5OEG2UNEAEs1DwlCYIG+ICZIZjYOKykToTTVDdwnWz40f3nR8hVvQqkHTE8 Ye6TwBK+O0SAi5vZS1fInZd5AQKj7PT3xqv+0FF9OR5hajStp/d4SwXURygPrYfugkcoKHlO8PhU 1LjPHTfWT/WzT0q3G9M0zHb14I3PE+PTN9LKiBYVgRvoUnyX2Q1lbmRzdHJlYW0NZW5kb2JqDTU1 MiAwIG9iag02NDAgDWVuZG9iag01NTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9OYW1lIC9pbTUzIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTYyIA0vSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTUy IDAgUiA+PiANc3RyZWFtDQpO1C7Eg5lIySei/q/GXK+rKcA4d8NV9fOE1SNgpo4knuN7KiDN5wbn BONXHTIA2dCPSL3Rt/rJPMzaRKiZP3LKxgKsPkLGtd2Q3UCPNXNk9Q1zPdEkFxH/pzqiXKK/JS9T TkxMClhF/kotxj7dhyaWlEEpzgPBa71U3eK6Dk+vxi3jVkJH1p4L2xsSn46gW/147MW5Y2xnxn9T wnTuRZUjFdsNzcSY3PByW6vIiZrFYNpYrsfNwJR+j697w78tLLpXdj21qfop9OzFFJLl044exyIt kbxdglHfY/OQlTOnN+g9Jz7t9BbGvNVfikstzkYp/If8n2rFqiFoEJYHyJaorfULSbVGe/ZaWhcU pP+xq6NdiLSUNxPuhNrEvf+6Sm/h/0zOeh5PJ9Zlxq1AClpdcunmtSYbeFfEb804FSH/eIFdc4zN 9JxmC/kyXE1KgGh/LPh/n/msXNgTzQ1Nz/vrQnqO0Z5ArKx8b9jEpHUD8PFlHkFOPgSt/FrBAEQt pMX9YMEX5RL0h6IM9k0BICq6dq9lzVjVeVXw9N7Gh1PjuaxuTTa9yvcr+iNwcEWRN31H8OBlB+JC tx+HK0pUJEX56tFBmlYGUqEsaItylcomKrsla6ghdYl4EPyntZZXJbvsqwDWCVm6YvfCwZyBzxFb erkukDRuKkdKuwcf2Ymlbw+31cnAOk7jFHXWiYZz0IJDUxpGBy/sEgVCjZGXaPzoCX2Aaf8CZMD4 bLGxQBfWfV02gDTOEL/cxjfea+9IdVQsSLZcwlt1meJbCz9kIYjiDccNS9Zc9Le8REEYgvum6nLl bRI3cthOn6gb+CFev7GAoxRqK4LeXLGpBpaiSlN4DWVuZHN0cmVhbQ1lbmRvYmoNNTU0IDAgb2Jq DTYxNiANZW5kb2JqDTU1NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L05hbWUgL2ltNTQgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNTkgDS9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1NTQgMCBSID4+ IA1zdHJlYW0NCmceLDD9YoaY9Yrvit4lXyBZN+Fb/sIXzuVhxpZr+nlsmgCBsr+rWzN/JtUgGirf iACnpJSnRJ4I9UsHzqId2ewDJ19qt6QCS0nv49EncXG7nEXEMs6cyCJYug3IwOX/Xz3OnTtqOsAA K/Uuaaewa2wDqZPV7P6sJ29rGctdAc8bROK4mMrYJKA8NPuIWgMgneYn8IiQd4pziGmC3Ysx2chm yagVjZdTT5uECXSuF1FPtlTolqgPj4GMAHl3f2JXsenhCWBnV/6v2rsuWVMglVnwbV8MEFzeVeR6 V2Mv9WLSFO1tY/+Y92Syv0suEyW/ukcj2LJb87zyqAaATfkySreiG/vVjl0gFcHYFhQ4/YxbFgcC QcRhkqfBQ8mIam+tH0Ihtz+/h59VdFuM2TAE7PtFUrnV2Omqt7ieJwgnf09CdYaTIZU4J1O/dKNO wwDEhW8IAM7XPQRlA3FR99kCzsvagfwQSqhsG0yKr12GBiWYdhetpxYWPEPfez0IFszrVn7qA0Jf OQBZ9ih1NZs6hc8urHlRO06u8KmNn7m3cP0Qt0Tf1EJewq1GNyf1TKRpKKUNG6m+DdtyLD/1gXg5 wND7Ao/hdYi5c+2rLbb2fwnfDZYzISc+yalaRm1HmrIkVGzYjHiRjz6NQ1WM49UFz0T1EwUOzI2s 0LHB+KDBKYIXgBmxnsQkAhZvOe18d91KkesYYXmkkwSFEiOfhmmPocvbyrG1N9WVcCihXYli1iSk W1CUpJ96qzK+ycQshrpu6aD0pc34O2sh6MwgQzYQQKnSYTFws+qe7MUtf7ylCyH9ioLWKtTHlBcN ZW5kc3RyZWFtDWVuZG9iag01NTYgMCBvYmoNNjA2IA1lbmRvYmoNNTU3IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW01NSAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDE1NyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDU1NiAwIFIgPj4gDXN0cmVhbQ0K7eCZbde/m1pfryqURGwdrr1bF9Uq WWecUdlj9F5LZGpVdPQU3j0ecTMhwVotxv/lK+8OZhljFk9cBtnHMWi6HoVyiN7V05b3lBpTXueR KCwFcSv9C7quc2ppbTjCWWCC+//PF/GD634WlLxSDCwrrBSzMYooQH7jbTfpEqIOdI1iC/Z/MWep IaPudqLGg6C/31dMXXvi1H4XcuehKC8CMpVQ1Mo9CTPjrV5SVHr7GZXTHxBNsRLnjcuEfAHHcNfa 9TWrjlwuQd955c0uqC4DBGRGupkFJtB1MBClMmWyEPlY6+daC5oRG9mPXZPrFwvheLqomGMotEyo r87dyBmsBahEN9f53vDnZS4p5JH+hkH8nULy5l9Iuz09XzYzEuPK2o3uLfd1esgt+2rxsRyvJ8RS 1gXu4xZvV4swid00/l5oXDYQDh0LZfSKcxRBlVWFTUER96t2tJjrpm8mAIiaBCJMH4eDV6pwfp21 iVipfxYs8iJyFHQ/RXGMxAbok6kjBSTubbbzoZLzGpBZeH63/nDKdpKqk76zYYgJZ2rXVS5WqzQO HQuzgk7W7KNavj3OU/O5gs6xHdUV8apeVtzr606qeSME50DSlRBEGcUrO6lZ+LWsLiZc42jMuTVm vuK9LvJPg4abVxvrjh3GFpQvfvnPyPMu3mFnYbMy0xaW+FN34lOgbpSn31/j8JSjcAGgxiaANS9O +mS/+4YBbZ5kF80hz8WWfEquUbdV6uQ+S1vbIFuimtE4djA/LvJPZjkxIH4RTOb0C+B9QWuHhcPy GMcCph+vM9OeeQx+/CVBDWVuZHN0cmVhbQ1lbmRvYmoNNTU4IDAgb2JqDTU4NyANZW5kb2JqDTU1 OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTYgL0Zp bHRlciAvRENURGVjb2RlIC9XaWR0aCAxNTQgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1NTggMCBSID4+IA1zdHJlYW0NCiZ1MlHI 6eDD9qG+uGH6uEYtXbj8WJjvK79pnfflQ3t6ioVicDnHrGnXttQ8nujzz62x5JQgcSGyBbQ6xDZ9 FOHhUJKwujhEt9UeubUnsVXyQ4nJG3vHr93OwquYgR7JSFBtrOASFHfXNTkk0FRmrCuDDoPK3gt9 v2eGEUgoP/NiE1q5YgQAXP9rlg/5nlEJ1uzbXjrgqIAvCIiZfpt2j1jfqZMDYSSvW6ogrpgvJTOF 8ToXo48LqZRCzyDewlWdAQY3umCyoEDO9iBWk8QwM0cZZzAluAOxvLpYKL8NjrIPeGoielF/THI8 57DCDRYEau0rTUCps/f7wnp14S2CrY7M+INQAH1LPB85KIIgqanWs8qCcqTn2u/Eo9nUr0ok7LJG kHL34SaOjZDwtb8ui2o1vFdKpUF9YfUohGDfQUbgimIOckgiD8ADBri9g5TUR1/OUOTBNeGfmb4k gDSwkL3VgrknKHoJTgKMRvgNzsi0QJ20uk3ozUb8LFGZx0blNqPxpeb2B3SblDB7Xofkuqutbvv1 BzhMR9BmFUMCmBOOabBr4kZZx/SX9iANk9pqsT7xH0eWJpoctOU84EdJ0hS05TU5Ep4uA5pxluAv sKLSf2lFdCGiB1hiTKuy/DE+ZJTLiZ86iKoqoRXvJxqyLbIbQvZbOwpLHyebnmiyqGzf7gVxO6TL CtX7XC5xERNj6sBeA8FONt/0MT6mGpjUzZOwMrbs3uud7iVacZ4WP1P+qAQZMt6ModoTbX4xvwr3 /s8mGJ+E7dFKU5ZwDWVuZHN0cmVhbQ1lbmRvYmoNNTYwIDAgb2JqDTU3NSANZW5kb2JqDTU2MSAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTcgL0ZpbHRl ciAvRENURGVjb2RlIC9XaWR0aCAxNTMgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1NjAgMCBSID4+IA1zdHJlYW0NCtUNGWtpXOeO Wu8bsTTmHiD0ljGN1PQso4/0J2N+SYzPApZriouUfAdOZDKHsU6Ypa2UJ3rANEHv6cqWMvLZlGSK I84PvAvqRWKtJc4E2emyZYivy6K8rT8Yj+vpsbW32L5A7pS9JUPOC/vyyJGEcB6vlsdRZlp2P/DU T+6Ki1DXoY9t/QKQ8fwbF/z7qyKWZ0hhjH7hrC3J8/N/YDesbUzGx369feEMBftGXAtFnzFmn4e4 SUJ4Rt5d9KsUi3T1QHiiscvDwPlYWBl5h/50jPmffl/Dwc6Zl4JcyzXbEt62xXLfEa1xOVeal3kF 6e0ymjr66Hz/SDVwoYzBdT22MSxDZK1t+qv4jDs8h9IrvdZ7t1Lh5R4CzcK9N2txRJzHf5s6mOmu LzOSl9jtIUMIm4p15ecSvRhnnvaNEq0eYAetsbspsW5VyloPuCIDyXIj0oXBGkX6Wll5i4veXosH xVxxyu97Z4QLvojFnOHrci2kIY6VPGPDoTKRiffuqTklI83t9IcebeZ72gDqiQMWIRqxs5UXLv3M x+st8u9k7Ake17QJrFuR3e+nv0xPqzb5kXWCGi3MbarYHayFpk8j1w8gGDw/kquUuV44yP/FYJMW oDq1LrdEAETUZisIeWFmvdO0BMMhv/ME0/dmvMEHu96jdrRIfrb23XePfx+5dcIYaPSiyueKuTMK IQ1ipHY+BZkWjq58oz5TlEEhWqxbGlSY+Acfg2GwBJrTw4oduPVp00+wXi/LFj2zKjsPf1GTDWVu ZHN0cmVhbQ1lbmRvYmoNNTYyIDAgb2JqDTU4MiANZW5kb2JqDTU2MyAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNTggL0ZpbHRlciAvRENURGVjb2RlIC9X aWR0aCAxNTEgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZp Y2VSR0IgL0xlbmd0aCA1NjIgMCBSID4+IA1zdHJlYW0NCjqUInuDAkxHC5jp7L/kJGLAfE1bT+Hv ozaiA94QnD3nK4AXOFRhuRUcFkG804QczyKmSR1j2gc13FhFWRH8MQjIyS/cICvbOkv0evsc1hmL muiEanLGY3q2QcfpLKJGaLuZk1vJLXJJSFOfq7WDWgiQx9d0Vyx++h5eh09tEZCLMpXS7L3eidNJ QJ/dYKOAGnch4GCQjbEKg1SAx5I0JTNlLHpCT6A3o/NgGl8v3XM7GPQXmMqP4piTScxKycpBB5cC CimiUNjVEMDzCCCPpE/JYZ9abHKYkPENiRhU3yd2jt2U+INkj2uDbvmmtvcYIpZZC/XlFROQ8+VK 7sWpj16kiSqL6bUJ+hyVqu4Z+8YxUxZlqKOnn7Zci8oLuIH8UbDzgdn5Vb1A4wbJ9H+XtSKTk1up 9EcwklyEra1yy+bH/5bJdl5CgCI3/il7RyJXqOJv8RVTeg2fdXsJjwJ9i2TQVtlS7xPX81Bncgpv w+WW9lO27WuF5fJX93n5/YCJXwkPZPOa3ASv2Dw6gwsVUm8gsAVGVIlAWHxhF6+IdrkPVuaj+Pi7 dpIGcS+FH9O17JHx+W5OA9thFmBvPzNvMFT/Q1Ku1jEmBg/DUYTQSnbltj+G3ryBNyI5HrkNj+bq AJTtJVq3VJVRFi7mgOZ+Nu4bvxpq+5bfewCih6fEz2sGm36hxJa2RdQt1Q8btKrSo69VMxfKHYUo XK3JvfTWKxQhRgOXZoI8MFl60Lp660Pe33LgCWM3cUrsWy36pZg6dLJCthiYnQ1lbmRzdHJlYW0N ZW5kb2JqDTU2NCAwIG9iag01OTUgDWVuZG9iag01NjUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3Qg L1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTU5IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTQ3 IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9M ZW5ndGggNTY0IDAgUiA+PiANc3RyZWFtDQp8QsNgku5DBOT+r3aWCKnpU1iT1A1JuJnjPd2C8Z3N aMNW/+pqhzP/WH+qMyLI3jiHvHBimu20KD4zGi5StNfadpRw4RR6KI4B/CPyR0E5zuyQzpFOahiH n55zjzi5OSWL9jB7roAhDZ/bX+yUZBi+UxU0ERmOfmZShn4fY602+j9Ww4ULhLxiuuq45YUPd1QH Hm4fP9sIuWaRiRoPimlHwPKw5Ea6+Yhd0erDQ0uaXbpLLqo1rggBuxd0NQrTlLb/lyquJuID3KnK bg9pE9JDB2RkVifl9AZpYoh/ygy+GeqvAMSVhaOsLi1AfwfQlUnjYBuAzrQEy9Bc4t5CFV6r1WUE 1kBk/Lv2k3QyUPxNJw0A+Uwr9kkDNi4+umjX7lPZspVyLG8E43evy2DDeAtJm9P0uG6EuOGSCaEy 3bjT/ujabxMuhaP59htgmMoTr1w655aoLyCpTWOMSM2bRO84cp/MnU+9lseiWnyyTmtWG7JSCwjR IKt2F2Xo5JO0QVK+uFfdUqdgqgwwYL0bxPqhE1rSF+tTSeJcNiYJ2cPtnebwoWLKkFtZblIocPoy HQzB4U6BZxgQ9zMpyjfFeXK/BSuTQsAaUdK2zT69FsqepebN2z61QntSHMj/GYFHa+cHZks1sqi/ NcOBlZ1OUHRaE07hAQOxrPNdXNJ4lHW2QiW+pgHBuvl9aYx96zahC4RAY+jQNiEnqDSrECoWUyFy 1MAY7E2slW6IOR8OYLoRHeg+83PcD/WL2fWZXmJMj71i0ePQpx1gu/geKTyFQkTXpBD0DWVuZHN0 cmVhbQ1lbmRvYmoNNTY2IDAgb2JqDTQ0MyANZW5kb2JqDTU2NyAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNjAgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCAyNyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDU2NiAwIFIgPj4gDXN0cmVhbQ0Kn6lF0bYreqV4p9BBBVdYRlQMbRef/4JJk0wP 88ChpQNSDjF53WkRJh3vxbooQ7gIauv3Wl95Mh7aO0lrrKHbk6KuqtxuBskVHnMHo1x2SViFNDw8 XuoeMpT5HOg+sGogahokwI+JJW5/+nxrsCbX9vzxvWm3iQ3OKlDv/g4ZSXMjAl9QEDRMLEfGC+II KKzYZ//G/bxCZ7qSt09RyBmtLrFT2VsmOWjR7A8xpZ/6ZU6FMHtCIekQ9mgrF6/JyIwUhHX1dI8U 3+PqcX9v1swdyhqweWzGgQtFr0nkfjDpvQ219co91CygLdIyCdWDkfD2Zz7isISDyV4xSk3T6/c7 3HchYifWuxLgh5CeTJ+gfP+nZtUij5AZWtviMblDsHwOCGltW/r6gVlPDF9fMQHYWwhvrmGxQwTl oMx9El7oBpW4CbXV+JMaZ7mLC6GFH58ssMNvKajKHq4sMwja22ROPYaByhcgohy6bnlPnwsE/1Zx eYeFggUpjHwtt4QsSjRerVjR7UfD+K+cFjQNFPzYezRwVsq6ek3p6uyB+Bk/5TBlAcqvRpmGLHWs wieri06Hqw2P5ojg8uQu2NENZW5kc3RyZWFtDWVuZG9iag01NjggMCBvYmoNNjA4IA1lbmRvYmoN NTY5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW02MSAv RmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE0MCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50 IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU2OCAwIFIgPj4gDXN0cmVhbQ0KtJdB q2KwpKoz17DmYPdtnMfIxKb+zsH+f6tQvKNFNOJD58MMjpUG6otV7uhEsyZ4EIKJ1A7+V5bRZB4/ Qt1VU7UzG5esRvQfqi8kobcQAmWYmdXZFme5XueicYEQWoJZYnI9CAa4RliqrlVHws74A28pxI8h HSlfSwTbtcaQMO/H1L11hsTtTkvj8bXD8+CR+9YJQ4J0Qqa3kO74WWpnQZmd38S9JEazz21I1xFF xNy/1C8/4ar/OvfjmjbGCh/ebgMKukvYVgeUHpBDrr+Bp5/6Kr8d/bcqZDfin8nwC4BwFMCULKN5 iBNOPcBWcY+V0w/VEDhfsbthtqAabSETt0tPGokKGSrwzIPTDmqObpQ4ak9LM7dk7HwgmJkfMw1S 8aapgZnuabRETgBOoo/5XecOfO/r3TSm2A3Sc1EZYu7IchqULP//mBhLJ4P3aNHcexFHBvuBwYQ6 GsE+8Qx9IdWLPpeuzWQNztqm4Px1GY0NZAgCDVIDN3EfIIvZoTo6DlPECwiu6UvtyDFKite9P4NV N+7U9i7ZD2T44JMisIS8PN4cwY+4IVhPb08JT/U6Kv8ksgPbb0F0p9VC5qX8LOHZXSql4Kf34ULM R0STWHuhX1+BVZO8VxiKNAWbuaifaeouA5Jy5lN4TRgu0xPA/oVNSombUoDi9Y/U3o72wsAjUKOo vKhq8QHQmidbbDTtVnj6WEd4d9InR+iy0KjDxs+LrkARXBGG8WihHQWwhZPz6YPTdinR5Xqj+1Kd 4lEFm07wuKlsCSM5/DLlcSlgLTyfz+6zycQbxOPr5S4Fu4cNZW5kc3RyZWFtDWVuZG9iag01NzAg MCBvYmoNNTcwIA1lbmRvYmoNNTcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvTmFtZSAvaW02MiAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEzNiANL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU3MCAw IFIgPj4gDXN0cmVhbQ0KYHyLnoJ4slVoZDGeykjD1BnuvC6dyo02waQGPwwJNp9xliS6pyVlsEZS qqdr+LEny0PSWzFR/jeSOVrFrMHhkuXsKXbxWMMdrczu/3wczlAiWBfueEGbBnR65DBCGahtvdlT c+O+3ZIM0JEAsBBYj1511u7pU/AAVP5ja52mLecEQ+jBhTna9D5Yi+hoSfb9yMPLYnm1wxpQn/r3 l9joqH1UnfUnAaexLqY6eLOGqeQvnloe9BhwVzdy2sUShNi65bnRCj3/fFnrq0s8b3MV0uHxL1BV qLtrWsBdaBgr5K/J1ddPipmhBJxKoSn/+xeKW4qYWCWrlJqVYwCzyluNtlKkgWNclWUmuXDX+f6w XHlHRflnu0wv30f9gje5qvjTSx0uOBplz+PxncRtmy1bPOfegit+Gek7G1UmkFtrxDM/2PK+UlVb BVWufR19CRa1oj+g++/QvNIY5iSIXnQzC42fsRcdw1dhbwhZ2u/XrSqlvfuOruualZRvqejAlzG+ 0/Di91zqDx1SfGCOgRL4WyadMHuHj7O1YJ6mtomt0WYyxGyjfoci2huTPqE53clFFbUD9V2jvX9D 43rv4m/ISqYzW53Jr3A3WdneT8662Jd7rhEuq0XdSYaxQZtsDDda1WvfPvoGFO7gt5zmNZRoN1+L egO/b/hsMKZEsW0Y1O4lyQk9whBh3TYMI2sMxCgQAW1qFinI8TrqEOzj65S/0fHZxSoQBowZzZEZ jY0HiBbJgRXcQ9TAJjp6DWVuZHN0cmVhbQ1lbmRvYmoNNTcyIDAgb2JqDTYwMyANZW5kb2JqDTU3 MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNjMgL0Zp bHRlciAvRENURGVjb2RlIC9XaWR0aCAxMzUgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4 IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1NzIgMCBSID4+IA1zdHJlYW0NCollJ9nY uq+dKDZ99Q1W1qpv5ilVBmZP7ZsI8L8TFAu/u1pBP0Ij3DuVoo0kjyMLYF6xRNgfOcdgckms2qZ6 huLQr8KDQSwNJl7HlWjo4WHmEqXMTQjyFfXp+WrYpAmAWciYHGloaNwXiXAECRahI+EmVoXSmUEy jeoNF06yzDJbjYdfI2eFh+maPj6XHngSJZaFw1plJbEEIshnuGKAWH7cFV5SwwH+1cwCAHkXZgc1 ijYhGoRDRibrdsq9Jg+HYuisy+lbINBmFn66zu6WFkaQd5NXocHipGTmMMSwT9BC1/hYG7H1Ed7q RRDp8QPiixggs9H8cIAv6T/89ySThDHqrWWM/kRxoH6GWwzz6kQisyluZSnPx6+tKIXr6JxyGZmB eybwPlWoRKFcDOChOpyYtzVgcQWc+K3LHdbe1r2iNFF/1mpFJLdZbe12tknF+tpKz6jODwwpGJwK +0nc/E9EvZlnEffb8aWzCyUeJ+qFWXqBmYcm/ZPZFfs7fl0goeawNJ57/iMrxiyms4CVV11FaGy+ Yy9V8akHY4BPHMRdYYWfDoSQWBfH9XyxAWyUbmvKrIg4+bAORart3i6xc8+DyHwFbfcgN9S9FZN0 0psqY6gZrAKewJDzrJSHFBXfI62F5uNO5d+ghie2OjIljGiN+1z9Opci9/t2Cy3QxLO4jT86t0Ca qRVbYvbk/eHifeUmeE6uQnjcylm/w0a0Fnv3WlOaXqM0A2Q/xzT2QvfP5t24hQBnCf+r2mZ1p6QE UqaQpeAKtC5B68lba9J0XlxcMHUDZQTx6KpCTQ1lbmRzdHJlYW0NZW5kb2JqDTU3NCAwIG9iag01 OTYgDWVuZG9iag01NzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9O YW1lIC9pbTY0IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTMxIA0vSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTc0IDAgUiA+PiAN c3RyZWFtDQr0Kr9o5RBn7fDraJxsFbhGgR5UPUcIiFdKySyStvz0gTFWgIMzz0m6ngjvTdUjsZ7i mpzwmyjMlg5OnAnwqlXyGp9A1N7biG8WPNfbGsZl3PR8gKJijEgDrSixFdl3GrNbGVSpEfFPaKCE YWNS1ct46bz2YyPfNGWwYQSTos55kfeb8y9TuwxfDjECdca/8fnvHyjKrxdG9i3PsOGVCFJuNUzV UjarGpjseY8Nxm7sdnTtJnGZFEVYKZTyIJL1Npslwk2WLAzl8Fnm+i04viY2bQHliIbXEjJT8pc3 LEBODgKBpK6ijniOw79MsYwv4tA7xC30akdcz4Gjt+7m4QDUuYrP77yFn6HcGzJV6pWZDC5dZGDV uLc882pZOQ+GtHLZrK7d14qvH6QTvnNxkYfEIL0BGki5AnaOqn15kY9h+6QWbPldXLLqoZpFJiMS +a0jfsCRhjIEnzLpBF3eoBem4LiyeybvDAiJxhmTRoDnQbijbz/O6s1oWT+1uUrcl6jQzsVJdii4 QTxrwHZ28mVVFQgxb7N0nccwWNVh6wBFUXS7fafACAj6Hm572YOeGhy0658feuYq9DK0QpU+kDO6 HowwivzdDSuUpbXlWJYEyIznPizuI2O8N/YJ6DRPuOgM8049ynmEi94KKZNYOINAw3AujLY6ulFJ MMbX+BbrRQoEEYCYnrDVP5Vm+oAc75Cz33+HLew/FbcaIhGwouIKbQvXUruxnrnQNYYJlmHaI7Ff Lj1vnVPYeQOshl7tJPNSV7Nt+AbqoJAQ9biiQu8F0b6cNA1lbmRzdHJlYW0NZW5kb2JqDTU3NiAw IG9iag02MTYgDWVuZG9iag01NzcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0lt YWdlIC9OYW1lIC9pbTY1IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTI4IA0vSGVpZ2h0IDEg L0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNTc2IDAg UiA+PiANc3RyZWFtDQpU65J3+MkKDDFINibHIf1zaiqfTcX3Lh5UWqMQhCqQTqCQGXEP3Skmcx+d CXdbDAdiSVGx65SiaKER7/fLdxR15F0ehn7AzPXhf2dizxlooSF5hOEYAyR7UeXeQu/Klwb4Jhxa 0X7NtX4o8aIWnd4LiR6jfSvKXtpLke+j6jjggrd5Grv+sKFtnUrQhyUXKiLuPxiHLVoqU9FEXx79 csiJZzZXcdYyblUs/qE2CiDnvmERu8ifxrtIcCuAmByoy68lpJZuiGpph2nr07wtOEiolPEkxBuU rhzj77PM0/m5HE2Q7ajFHjXOlL5awpVT0BSir8SQrPLwgkhK7x47i+0cDF1dbLAohx12Pel2sjmS EIYQVqF2h6TH8+Szho6ijPcMcVF6S/02ijFFq2+kzLpRJDgB8JmB+cizIGu2BfIMVcukAGFAQRsN u9kmW7msSsgpkLYL3mUFgd2S9tQXgNexe9WYSUw/b4hUIUU6REyVYBXgSDZTueykAYZ/52uFZDBL j9+qzSPFqOUhYksTzRlp+hgq921AZQFtTAKgz4T++J7FIfHrwi3lPlUX89wclWmqNXMwd12zuPte YbwtrKNLf4ru+eucGNusMsdWQPdsNLUSxzPUMangcsTTt9xLqvNW0UxOMXU3pFsgX+MZABqZj6Dc rbas17vG3RC5BWqolQcsUpj1oMtujmY2lYr/tivktsTlK+CThr+qktfyLJywg27Ft3SWP3o1cffE QJkydqKlm/Vxno/6pQXG7El1p5OPLkYWW0mtQcVg406GpPnDT47LyF81PCUWOHFnRiLGv9pc4t7U S8PYDWVuZHN0cmVhbQ1lbmRvYmoNNTc4IDAgb2JqDTU3NyANZW5kb2JqDTU3OSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNjYgL0ZpbHRlciAvRENURGVj b2RlIC9XaWR0aCAxMjQgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNl IC9EZXZpY2VSR0IgL0xlbmd0aCA1NzggMCBSID4+IA1zdHJlYW0NCtnja3xUj4B9+3iLhWKjmNr6 dBZQhn7TehJAmN7OVyvdo+4KQxizCjJhNApWzeZhT68/AMDoJq0ZChRgwaVOtJykajZ/LdxBM3bn F7imj6rRh26RFzDLpnNLDAk3EuX45Nd9FBpq2IxqWAYWFtAL2ZLuZnNk1ncM1ZOy+9QtYxaABTiZ aemEqQBcBAV1qkofp4aKiJ+Wu7X1X3AyO2FAsE3BC8d83FSPnfjBTzyT4BjiOGfBNLzG7/m/g0KW Bg8IHc/z2VOwcha8vuifThCwuaFh7vGMWhhiW8Z9u5XqT9Vet9BxOY8TlO/bziLEi1U5pK17Xz20 SGX0//ZWO5PmglfOW8nCAVBoTYW5viUwpaEGo+W0YCXdBuja3UPooBoPsA69U2enwyvhfcMutDU4 sIX01iPTE2XdCc8uV5mibX2FIuSlHAQ2C/9pPkJ93fzCeK7PfXDLDXZtzInQXeN2PPEA476x0BS0 5r/+8jhSKBPAXbDvd6FprtD5yAE+86jzQ3HjAnSBm+5pKDr5cEXmUeML+csiNHAcgEZ0hi2A54SC fJX0C+sRkpcCpFRp4I6YKPJxHZukK1wk+1Rf5ti7PDS6IyaaiT7ZptOOip6dviyfNACbYZkDqkEd REyDOXc6VpYiAJXBmA0/NBXpkN+aazgZkQXU6oCl/nWK9KQF4lAhs2Bragcq3i/PHHV1QbWcb67S 6UOr/6pU6fFzSXdxyJtMzroYGq0fnJ+SqAGiqGISEoFt52r5BYLuNcq6ubliWNENZW5kc3RyZWFt DWVuZG9iag01ODAgMCBvYmoNNjA4IA1lbmRvYmoNNTgxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0 IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW02NyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEy MiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAv TGVuZ3RoIDU4MCAwIFIgPj4gDXN0cmVhbQ0KT1Va4YDngJEwJDaUlLVIpeH0JnMzPEoLoD8KTeRf irqdfAs478xMUehE/9C5gn1HpGTBkCiJcODdnfNNZDqadapvBi78/UaOnNNRX3oOQA2HgFJkAvWv BzZYFy9AaKS1mIKZp8qmIWE+9yRG4mqfIPPpbxBuugQ8uUnaehqgOIdP8RpuKKTeRSBx2BA9eaGN zq30f/P6t53yd6soIj5DrjWMqOnptATovEY896PJYcRcn64qC/eOAJv0YhiixBxVNgul2K09+8RL hnzLCzB0WbTAjJElPdpP44GbfMb0RIgI/11iDCbokC92mdlrmAsTKWD83GL5VqNz4YVoIMDYEVOX uAYReww/z9eKGTI9Roi6ktpByz5WkguWzXjxWKXjWGY3G9YilWj8ovBoJW2AddXK8YZ9MOHwPpa/ Gftux+1aozBzgnrs+uejo/7UajV5khgqzjJ3TAH4OjMh8J6o9ucYHBKdSICJUI+TjODOoAFmIZty xOWMKYOYaKb4Eu3463MIxnG5vMORsWW51uzf9zqpWlatedYd+oPz3FvP0FdqU+FV1BbSu0PhDHzn gRAQTEOOq76OYPEwTTeizoygWHp+eQtlQO2garqErqZEBp8nKXuGq3gLfP26gJoC+sZWc1OOta9e qHxhtQjgBzDxzHKGLH44CX6WEDvOUi44ZM/puXMChFBDR9RUr/mfVyNQRy8f/DCzYle2FgCbPWdn 8Z1rY7HfMPdXKg2euMKDSlw1PIofT/jT81qt2taVD9fmE0cwwpr11qiQbjhhle4CbObdpDh9Lg4K DMXxnm8yFScNZW5kc3RyZWFtDWVuZG9iag01ODIgMCBvYmoNNTUyIA1lbmRvYmoNNTgzIDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW02OCAvRmlsdGVyIC9E Q1REZWNvZGUgL1dpZHRoIDExOCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9y U3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU4MiAwIFIgPj4gDXN0cmVhbQ0K79TvNrkncFocwdyX 4qyjabkuP3y5WYQJgLM1WmJKLe09IfKiLhWsVU27OXKegePHD/U+uUsy/Atro76o/t575x/+Yk/i kvPu3IbKQ7VmDBd2+B8ZExOgnySXqtBYe44+Xy3rFxZXU745BhGNPCjPP6WyuoF7kzkMN8d9Pvu6 JGYgb2GTCpoNJhZXkACWmxQOwC6rkSZWJdukcbmnq5Ed77yCcK70Sx+AW6mskv/LsMUJ2jlDbWMy ulAPJuPj/DuMfw9n3AiWbOse/L5IqvAmVRINF+AtQX0BSLk1dCYz1yyvghfClT/EX3UKuiAJgeFv mdk/qGj82jAeZIKfjW8hiaNiLlmQQtK2jw3/AVXKLDv2NJ43f4Xytf4jQITYVw8xfcAR2C6yMOGx M4DoEUruK/tV3rzMqO7sEsExobz4LkyL6Sav/wAqwSsjhCj899m1jUtyQqptlsSL3tXQtnFmg9aS KWeZi2dAzxkWmAWb2kskBgs0ZxhPsDEA5s/N6sqJHGVbOQvlb22E+TYOmTm04AmJLoZIqZbT4vQ6 QgJUEqKteoPgqFGUEapH3N26VcXSNLF6/WQY7dIpIa0Oa/c3P+4jFYjbHdHMRMSeHr+RQ1qB39dw MDd6fx53QnkblT7Cv3d1GGJ3y96qTpvxppVOb4dCef2Cng7GtIpI0AIk7cDD3Z6n352c9VdTnGYg 0RJgKSNUWhZcM9+N9DFhQHcds8gZPx2emgTPDWVuZHN0cmVhbQ1lbmRvYmoNNTg0IDAgb2JqDTYy MSANZW5kb2JqDTU4NSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05h bWUgL2ltNjkgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMTMgDS9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1ODQgMCBSID4+IA1z dHJlYW0NCpafZX2sL+QXLYl/zcokIR8WSiOmJ+92niUPb9Sz6pKWrvYMNcGiIipAn70Ae9yCGSyZ 6rClVpBS3XWm4ZTTXcH/SF7z/w6mV7D48RE1YqZePsNiU7Kp/ITesMFNfjOKeQztOGNaJUcZqros Ve3CVXdWuxETLLpyX0Vb8eTrz8hqv1TweqeKV3BjtDtzZN1wV0ulOMIaN2tMxn0J+VlSOke4Em9P BOXdYCZe79PCaCcEoRbJqXB2IYVHxcAsgAPJJ6+Dr7NHdHV/vM4X8+8TAL0VcVt+3gldKZN8t0Uu uqBc1plrwZpPenZ3i16glMdumTDGsKXu3s7t0oAbp7pgD3ThtHEOPrdhnCOZoY320OzAtewGkfbg mTJZKr8PFSev0nX8vo+FHGMb7Yoy3uLYwssK4G6pWXU977gNT5uDXNpkyYgeDVcnRhyXsuo0OEBF hkCK55Glmr2aC9OuVzkL4el2IC2ooNSbOj6Y0qCPqEO5n4s0HQWmhuRtEuoG4WnQ+6fdgQXlcYVN AHRZ7pUkf//189f4ToSdOkX/uqI1ORHm/RwN2xl5igS1DuptmniCQEsY4Lyuh1W7dGBym7xLY/Hw 5wkhERY/g2nBa+1ktW476eT5TNvSeNnZebPouFw7X3hn6pARJFqjSsWak41seMS40wxodZh8yE4K N0EqHwANACNEEeNm5E9j0BStUjDtzc61XN6W0U24XyIimr/0Zb/ZOZ8oZnRz5oYpaF9cuYRcH42U BQKmT5OUnFZ6ZCIimXt4hB1RyD73suWjB66rWnxv4rX1FlgxyPcYMJ6uZGFBP4rGu+wt4YZCcptY Hg1lbmRzdHJlYW0NZW5kb2JqDTU4NiAwIG9iag01NzcgDWVuZG9iag01ODcgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTcwIC9GaWx0ZXIgL0RDVERlY29k ZSAvV2lkdGggMTA4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAv RGV2aWNlUkdCIC9MZW5ndGggNTg2IDAgUiA+PiANc3RyZWFtDQp9SdKe4yQIFy3gg+2iT+g7LVJ1 RZp8KfBxloiFw0fxzvwgioU5hia7vwbSPbb8/3jzCNsLsJghYBqxPboiz0vOydo5UeW/Ub1OYC5Z TuRJgSrGGZ80as09/TTkQav9VaeVZvVXiRr7xrujIqaDaiVvSbmD7TbfKMX4ZQl0XsLy0MHZNgPn AERe5lCsptXcxkTps0j8jAvRuPo+CFa43NLOWVs+qvdr+T0b/FGgYEQbGmDeBuRHOUjUBTCYH2t0 78HZadKp7j1DDf9y6JazpCK6x+jOoey1fI1196XmBli4s/og6UFI19B9kJhc6lA1P7P0t47BTWUG eMGj0kjq5tNsaRyqciUDaDmODe0myukNBB4g6njzmjiuxruqaRPn9G5IeBtTVlifYD/fA0E3EQKM BIwc8bWNuDYy/rFIcUvicimEoUU46rYKA0/Oa7F7RfQGHHtdFM7gCowjgE0slbyGcew7pIrstunO CtoZ5m7qbxSTkPLAxpAl9pGHJV3kXad6r1LyLvKF5l+qTbdC+BrEmEFruFRIE10qvhXDF3TP3j4a Yb6JsOro7D1rD28CjLhyvkhONnO3FTM720UKBwlqv+eB7Q4FGCCkjSWvd+ncDvdPR+Gr/QIN02o+ 7hL53aa4BBNX7/Z0PkcA0rPakfIMQFq91eVdXD7olXjxCpyFvPnXe/Dvh1V7XFy4RYrBrvhDKdBI yw5Jh9wOwVKM0rs2xal7ALOyciboyh0NRQAivKNuI0gud/GGM1wFbXZ4zAcRDWVuZHN0cmVhbQ1l bmRvYmoNNTg4IDAgb2JqDTU3NSANZW5kb2JqDTU4OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNzEgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMDYg DS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xl bmd0aCA1ODggMCBSID4+IA1zdHJlYW0NCslcNknUU/uJh0isee6mrdsX/LgYCQJ3jxltwVzJQLK7 +qJs+ahBJEbbaR2PhumndWyOOCBwulNt+Y7gf1FRc6dDqPn1JIBHlBL0dpPGiFm2hkVWPQeYZC6i I0knX7sb1aUkhgjpTYEUtd/DfNM04PauEBHM5+WAAObDC3Ig7b1Y1Fnpfa6hzKYwvR8agCH/71rO 2RJcOpQvc++bB5CUeEf8xkuY5FEfQ3Fbypps9smSr3ykM0NM3dUpohPVQJccg/D6gQKzbUSVk/0D zEaGTVqn2KczjvLVF+5uSwGG0NdTioS9HdDrL+DQx0YZfIxUaTq4u9+LGVyYaTH61xZ2gOvKy2QQ 5bbi9DJHEmXWhrzUW2dfurcEbmeB/S/yi0q1Subo9bSA5HkN8Dq+PMmkXOoNVGjDoibxAm4HZKCy PIZeNXTJEWxngIEpOb/CR5AiwEcqb9yrdwNP+OexPUuj2wWiZzIuB3AAm7UK5ntsPFb0+1IGZnw5 bytvWVchAHzvCQds7ML+ACAziSE0JnljXCiFmZ4urDUz+Aqbm60Y9+JeTKg11rOvrkcDzIZocuBC ws/pfVKR3nHc2agZrcjAMmLNmjfyHHPufoAvitJnqCRydqfnnjYPlZ82QVW/Lke7xQ3xPeEfzulA mXhj9+QG9QAWn3I/OjuHbIS9EAZTtmCHpRzSxAMrCDWt8CK6aMM2e4cOSoKSID2ntDwBlZ4mqULH 3En3SmXCu3mOrlCclgW7n4Ew94YoufR6FlJEYA38DWVuZHN0cmVhbQ1lbmRvYmoNNTkwIDAgb2Jq DTU4NSANZW5kb2JqDTU5MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2Ug L05hbWUgL2ltNzIgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMDAgDS9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1OTAgMCBSID4+ IA1zdHJlYW0NCohqa3MFl2PFY/uu4WdR4rZClz5Mpf6nk6qJiSA3WwHMHP7/xkHlDjqFQjtWUbNM w2nZAjd1jPM9O/jWZoOrD1D33DAWBRwWRbeF3TteDoXwd5AUDgJQBdKcOzEmnjF54qpOHcDVyw9V 4ujEJFz3sfia5tZe8S10ooBGDKq/XQ2/stU+iG3SvyKn2X2Muxix3gefgUTDOSK0/g6j7G8LDhkq ql/zWf/a5XAsW5SBxIamsq61mE4Qbgyxxx9RIWbZTUYkLyeEnqpyM9Xidht1TfTxZwyV2kuFGt9z KyOJHf1gG598V2GBPuPPmzMhC3I3epzfzmD+bRmhSsI7kRFvIDOZk6ogrwRW9H2sYFWUWP7m59iJ v4pqsFkIHIe+LuAa2eKiOswPQ8d0MzN+jqO+Jaouhi0ViQDQMTQ6bDn9kbTH8FzJTYo7R/mDwt8Z 6jrU7c69xRYT1k70/8t+YW5jGxFGeduli/djDMbEnU1cRGk9TKKbRBzzzKhsLHpxyYXhAecGMH2P mPwnIdxtYVIyi8ZPhv9DlHs4FILuEEcOs5Yi6kMEIE63QsCCxqQk7crMEE2bdMDJZxbbUBDGkdxt mXT/JUejaSJh1SF08tbGBnV75lBfmmvvKRQJKd8K/y7bT1x2lYAS8l4Q1TAsj1A3GIiM1YpGgasS 3xrLNRst1q6o2cLh+3bX9JznZbNO15tYQW787VP47ADyAowBPoXZMnyBecvLKhL9V2sydOL0Xfw8 /XSHgpfr/QjV+dmLM+0sQLr2JbYZ+rijtw1lbmRzdHJlYW0NZW5kb2JqDTU5MiAwIG9iag01MDQg DWVuZG9iag01OTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1l IC9pbTczIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggOTQgDS9IZWlnaHQgMSAvQml0c1BlckNv bXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA1OTIgMCBSID4+IA1zdHJl YW0NCrptAePU+wh+tZW1+HDqvwszYBfhQ5SixlDkGLgTlcv2OxK0qn/mFqQA83OoEhMpoDb3jO3d TNRuOqrc1MxI3qv8gSWoEhDWF1t4spT6+ENHuzO524+7IAQ8Q0qFDj7/Sse2PerT71pwQ4kiDyII HR0eRGAOfxvKo/2EuNJuzi68taWbxKklSgNFdsE1X+/Dlzdi5gk+k8MxHlYiBMjNiYnG5psfO0He D1z471iyYt8jvLs+6V+m96UbbzmpuC8zkdoohSKfKJeriHGf/pc3zOxWj6p/MsIkZA8W5Nk2Z4Rl GrUwS1lzA2L+lej+tH9AeP5npCtAs4spNFbMyFJiopcyjiD5FfJ7Jh+/t0zLGQTDK8EI5ZvkiezU DPWdlInC2aURlKiv7mnrZVhJkCP6ALU56BlVA4EGuM2vkqO3UE9FK+HAhdc3khaEKx72X22MAqXa u9q0eY82kvDbH2JzrQcS08kszdCcQjlYoQciDGspx+eQW2JIx5Lu4bJD5CRHI9MgaXl4swnWZNiX mBy+BK5ODzqW1yAHEgw3EzMzCIO2xWjMekIBu8vqXycMZngv9QrCHTOCUakwxTJQjdqNHgY1GIIO nFFPqoHkeSGmBjc2kBaNHWTSoD/IiSWcxZEg5iAyzzyuFda5R5xiL9aNq2RUwTCkaLfzgg1lbmRz dHJlYW0NZW5kb2JqDTU5NCAwIG9iag00OTQgDWVuZG9iag01OTUgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTc0IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lk dGggODcgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VS R0IgL0xlbmd0aCA1OTQgMCBSID4+IA1zdHJlYW0NCk39NVyR7GB5vpYqiYgUfpGxlUqwprvEfReb 97OnTVebHOo2U38TvuNFHIWgd7vL7ckIG+BY8BNoBISXC0iS4p3c2MKLzeyiveuzIWXq69yRvViO OLnPDrgJbWz4yJ3AH4IS/uhu6hSmoEYw7vYbUtL46MV9j0zjS/Ob0y4wQl1rkTkquYXDaJZVNsps w7yS7TcXuaX5CGVOqptHn+v0ddp/HsEj8s64126uCx9xo0vU3cTfWzA6FZ3YDh8FQ9eehl/HGwG+ rQ1hDoLvj/oml4MjG14TOzaIpx+xHWY9uwdWB+k5iHARTcoU4/aThYiyMVMQDbxX/pY3i3cUuZpG ekKznY08An2K/c4MZVC7uxiEQ9VSIJBtdpFQSJiY2R4Vxf6V+JQEfZ90rSBgt6/02shPE7wr9bYU H9bCeJ8cTSDyaeCai5E80N4i9f/RE1Olf3A9dlQH1d6UMa3XBks/enbdelYzhTfd3PverMJJZEzi svyEf4VE4Jsr+yziM6MkyFCcp42TZ6TRjucx7KS9VK7Op9fStbFSlOymAUNqeLQBpkNy2il3mSvf IKjbpeH4U9IMMWwm6RMCFbDXhDDQCHIe7O1R3RoiCFosbdmxRJHAQ1o4SH+bsJceT1OxVGz77xmT cw8Bf81fshRduFOIDWVuZHN0cmVhbQ1lbmRvYmoNNTk2IDAgb2JqDTQ2MyANZW5kb2JqDTU5NyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNzUgL0ZpbHRl ciAvRENURGVjb2RlIC9XaWR0aCA4MyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0Nv bG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDU5NiAwIFIgPj4gDXN0cmVhbQ0Kep485RbhkQsg CJA+TjCFgHlqsixhETIfM6GiN0KkpSrmSeouHDyVzPXBCSFtX+y0U50ajZumXDkrf1Q1fGdQ/rr4 nTFH5rEsUL2P5TQsE5Me99CtxDgglMMxBnyb9TpBdyv5YFTTQYglSGE+mQVy0tGdWaOPPWzil4OL k4J4l+RYK2a62GV1OzhN5g0tC43zIUkSL0PSRjGtHgWQJkq1FasBw6ortAPvqP+KSW9HGxxuxbEr J4Q4zZL2nZiJTs5JaFPmLiNMMcp45H1XaTQAnaVA8ShO1Ky8HHVCg8LpvPb3NJIzVu4GqKPbJOB/ rCkOg8jGhaCTCp3jCYdnT0eAOvINRrHmqaCM7QzQ66Sv+xvfk0zvjoJ0bkf89pGQ55yZxRRhoPr5 8jNfAGnvTv0gGrZEB4YZ3rf8LF/2CiaJv4dUf5cATSyenF9HJqvWHB1xJ/4jRXgc7ALWljmn9u8t VtUzReHQQImSlv73C83XmR+wddFUndeXtynBaQNh61KtPctbahRTR0lrO1ewYT0x1DtCNLuI89XX imEOC2xICPNjn7fI5XYsWGC5KkhL8ED6RlTeuXtviBw1qdh7mstLdQwdH95ReZaaMhBz/J+02g1l bmRzdHJlYW0NZW5kb2JqDTU5OCAwIG9iag00MzcgDWVuZG9iag01OTkgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTc2IC9GaWx0ZXIgL0RDVERlY29kZSAv V2lkdGggNzUgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZp Y2VSR0IgL0xlbmd0aCA1OTggMCBSID4+IA1zdHJlYW0NCpIo0N1xlx9W6JgLdMaMdkarr1FzUqC6 XRwEFbLdfoQ6l388z7kgNWDxwnBaKftqENu7+QpRLcoJVbARZNyuN/T+b15OaCNMtvusAnLpiE7W DSb9JBGtptR5Ftw35fk04jWJWHGtVN22+YrM/03EeuG555sFuU30jyd8JayfzzKfZc9oHbV52wYM mPIFGLCDdFAJRg0ckGdLWVv/ShWa6cGuJ+oXgCUhDMrwB27KLkdzzhQamPizAFKoWnLlK24+Y2vG ciIoNWY+cwpABjTV4NLXYgNrMwfKTTPaRwKtvDI3dh/TVhRl7uQkG9aUsN11BgXF9plO4ifGbOb3 drLerumBBQqcyU00dFv+pLd8K+QwKW68y8dHjDfuSKvNh4KDgotjTKJHyKgUtNZKU1BmtokTU+MO wVLXv6/zbOP2zuNriWL4qpCKlEiqvuGJhS1tciolLA92N6l90f4HlpIC3GXMA5TVULJFgCq5DLew HvDlkMq9AShbRV5TIkzq5OTeoWn8FTt2+F3JP1B9ipfxbpel/uFAHq5MKKUXIG4FGHTBo6b71rna hBQete1d3EL7BYuPHyYbDWVuZHN0cmVhbQ1lbmRvYmoNNjAwIDAgb2JqDTQyMiANZW5kb2JqDTYw MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltNzcgL0Zp bHRlciAvRENURGVjb2RlIC9XaWR0aCA2NyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg L0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDYwMCAwIFIgPj4gDXN0cmVhbQ0KgxlR0BY1 R2wX/jNM+8INDI9d/nkkZP3jIoW0BEKxBIR+RuD7drpDvB/Y6j0545oXTXQni2j19pSAj60o4nmI /zwz3rvpiXW3EaggIduIAgUI/E3FY9lrKnZRL6Y1PukPbVz6Tn+rUikVpL05fVyk98aQVTHHs1xd mmOSbG82wjLwGtp6qKY3OBblaTYQxoh9S+xQT1qIj5ysYhOHEy6qTWSVVV9Rt4MhRhrjz8g2Xvko 2nQNxcZ9UUnLo8gZmEDOMDZkYtOd10bSZENtFZvhJHnQxYWxTw0Rz/rq+FREn2jwIuhL9O6PTe9e 2N2GCu5joEKLQYNHnXZ+ScrCTp4D5peqDdN9fbBAZM1UItMgpbzA7KGVr8RuSbIabk9WvvlAD7Z5 KmKZnk0CK1nWRgXKZSDUwcPrdGbiAtq5IYAx58qaEGJjMwigeinabggEiM75+yVYVjpUBYDpaKRV 54ndQnQXRDNQLj1Yv5BwjnJuNAlhELJYDLf4L5ggUw1LZOdr+TR04JKM5B7gI7R198NQ8Lbbbkoa DnuFQzge2m52aX8Bn6VrZTkNZW5kc3RyZWFtDWVuZG9iag02MDIgMCBvYmoNNDMyIA1lbmRvYmoN NjAzIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW03OCAv RmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDU2IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQg OCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjAyIDAgUiA+PiANc3RyZWFtDQpj+Rgr 4zmDNTU0J2InMn+t7AT43zY04UJMQOdjDn4uF/0MIBqsKQVbiUKFkyiz9hWLzocoqB4KetYE7WrW qtk1pW6zkBr5PwrFN3JcZHyKqP6dfI4m9cpV9LkkOM9THOtUjR504/2yyOG9N8qKYbXkqE7Hh6DS mlFZdF4byM9vAAB0dPp/oxhEAmQYeiAw6YzVLKfE2ABUefInNgQO2iqbsowQotIHf+CAsJbExfUv x1qwnkOPoa9dh4fJps4+D0mI73hN7KI0QMQfXni6VVTEPDUASVMCcS78C/tS9/QJa0hgXoKLDj5M 9vqPM4lklmFD1MTWSp1OABXxtFnj9XD8MJUwDMpLhJK24mKHj7FNpOddMPfHAJ0exGaaq3BNGJEy nZhHeMhjnJ5deuDF/71tDnlGG3XGrVpPl3Xm6QYEFoEv819Qkxw8wSTPprBitPJPFHWQwSr6h0G3 6L+lM8Bval++qFXqhVum7+LWjRkph1zKLvVrswXVYD93zmHaDFmQHQhs3Yf8gWl8XRua5QkzEpCf NL5RIFtZt6HKLhI4vFtvAq4GeTDibpfvKrcVgcwNZW5kc3RyZWFtDWVuZG9iag02MDQgMCBvYmoN NDI3IA1lbmRvYmoNNjA1IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv TmFtZSAvaW03OSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDQ5IA0vSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjA0IDAgUiA+PiAN c3RyZWFtDQoowznyGSPZVZuXcO+AYNXJgwYjoJnbgNqVfHvgKxD9jjd2I1116EFiezkAfGnMqR6i 0EDVEOK1SjMMGSIH1v0igr6xqumjJ76aZSIC65En/59F9DZY5JzGbGKSVJC+W2HuZUWM4uWKH4Ia fJIYR69exnbghq7KdcX/OWTl50HdUwEaJhQnD2B8tdAIqUpN1TcVbpELsP6mdzHtR6nNygseL577 Ozdyy2nPveXw1Ihnd5Uc1BVM89x2PhL41Tq4gYyVQQoXDxv0l/7alpsJ84+pxQu/uTCDEkjh9nqD 1O1AStYKYI9j1pT7ZmBDnzU4FlLpD3iGVVzVJb0B644A89gEzItk9nlpnnY7R0Gm/1J0U1fnzc5E OZ+Va7wi7PtUao/H3wSKuzDuOrUMDkPiB6w3yelt1t8g2ugIoa29N5ml9+QvbF5eD38Rwo3jgedj OmkEgQ2jx5AlevVzqSq70WSlf63HlFz1dOdW1i1ZQmHsJ333b5UVUvt8v8gb1jeetzaWA4i7RYGt S2lu4c16TBhhSz6a3lpkQCsARBL0G86w7Yg09RgXTAHy8JELDWVuZHN0cmVhbQ1lbmRvYmoNNjA2 IDAgb2JqDTM3OCANZW5kb2JqDTYwNyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltODAgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzNCANL0hlaWdodCAx IC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDYwNiAw IFIgPj4gDXN0cmVhbQ0KlOupQBErKUVcbwFngv8ZIg6waVPthL/cpLk5ojWb7gzMfKRowS8mdYcI 8/bsV67U+Ii+ry8uoJ3xQJ+tYMCpB/OJ7Tf3FEXT+NHI91LdLWBHCody1QAjhZaXUjtRTkg6SIIp cEqdNfeQUJqU2S9kwneb/hSnsCpvnBOUp8DNjxn7lgiTh+WuxFuggvlGHb1TGXMAeIYNb4cv0piF NiS+M5dUZ3XNofZS8v6debioIWjFj4DqzplEdW4ZUAl2IM8xwwW1hLlBttY569dmmLRiR20VbFQo 369o0YsatKkBjZ8urVFN3U1fZsKiyVuOvdme3wzT+W/ZKiIMFeu3NQltiKH1GgFw9v0jQ3HQzS08 UbeiZqHpWX0N1VlwNt3Oxaydm+lrW3zpf3QJ5mi2KauJsEmPRoU28PYd4dTgwuXxCGugDjT5O1Ol SIBlDgOcF+sCNcHAcUnuW7iV2y+VFJztIpqgE9wNF86wsGGhojIWBg6+glKCt2d1oSD5DWVuZHN0 cmVhbQ1lbmRvYmoNNjA4IDAgb2JqDTQ1NSANZW5kb2JqDTYwOSAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltODMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCA1OCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDYwOCAwIFIgPj4gDXN0cmVhbQ0KNLZ6w+/jAw0nBUTk5hzBqwYU1vxGabqxGn3Y /b2verKqhg0FPDkg2gG7BC5yw2pXbQJ0OmLrGfxrdLqT+POIki/8Bhbr2GRSXvYLEBBu45/6Hz7g KMDLgArGbajEBy2KTAU33qmk1tzKdod2fkN5umPevhYb9KPiiufFa77AJ2wvH+0uxQs2RSXaukN0 BbFJNl4HMMh4mcIgYEBfjFAbB4PyKwzJ0NKYQBV6ZKVBsykz/Bgy+XBSEUSXsrkY+wimeqJWE7PD XUSrIPRzacLgzkDfAn1efHacWl0U/IBTOewEcXvCVPC+4vHvdRL8xSWM+bcKOlIbpAJtuO+yFYG7 PA4S3h0/BogLVpgsi2hkJsLlLW3Enn02PmrFn6MXyOiVhRIRpUa1oFKctbQqpL+UnWtrgK0XzAS4 M00mFuoh9iCkVMXOU7iC7WDazBdY1J0QcQsYeAiLbJVv/X3GJ/KG5QVdkslxBiMvat4ckRRtoome s/M+/O2y9/kd4ndqyex9p9qGcDUi/EhJj0IMhoodtPGR5vGpfnP27yuhncifPNp3v2wmZAwFm0cS jEZFBmTACfSM5MjUnMjgD/gGmWW+4GhDvsCuASoNZW5kc3RyZWFtDWVuZG9iag02MTAgMCBvYmoN NTA0IA1lbmRvYmoNNjExIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv TmFtZSAvaW04NyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDg3IA0vSGVpZ2h0IDEgL0JpdHNQ ZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjEwIDAgUiA+PiAN c3RyZWFtDQrtovgrKbMWCnwPyqhWmcMb1lMf95qxRFLHUpX3RCDiDHcL95y/8WyX3SX0HygQxAj+ G5ExRXFlYmQdsyuqDSm5SzOS4zP6AX8tHOYPOLjR74S2dq73bEgAtK5JSq0mZ76B6QXgmfBOt6Hx jpTHZncb7A818tUJwUBDNRkRGTpQ0F/wWRP3kxR6yZFiGOy7U9yiotD2Pl1eB4Uxp3IQ9K8qCHww DmI/WtunNfYx2OX4kwhdcDVl4B8nGw0t+eKmHh/uC2osO6KmXuPxeg/Kei0VxavJk9D4WPVq0+vD 6U/cZmcISpY0Mihl4M/puz/5m8LrhBYtM0I9zgv6qyyF9pXu6yAQPc1VPvYm5Ox635Qo6dOu9AEV USC9ipaYsp541Wf3qkRIL/1XxK5gKs3xYFf+oaU5S1cGtU/x3PJMrTnvjWR1a8VFoxLN139SJ4/q E234gtzsePiTbw9lp2J+RwRVHPpf+vXfsu956yGG+e5RLtZ01V6hsjv5I2Xq4V8dKVsbQhPEWFoI q9flbrguqfbNcnNmMSuGb+6e/vzDzS8R2kmIJ9xW8l9dxyvHXzB/3O3ZNjO47bzWOxYDC/slb0Rf VmbNHYcN1eO4Ty8zqB9tL/erl/L29jglfaw0dD0wUIR8ttPTJrqQ2LZm7ST0r0gfc3fX0lv90IoN ZW5kc3RyZWFtDWVuZG9iag02MTIgMCBvYmoNNTQxIA1lbmRvYmoNNjEzIDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW05MSAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDEwOCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDYxMiAwIFIgPj4gDXN0cmVhbQ0KJ9fHY3xWFshzShguA4An3Z/ul23D egltE3J/+QoQVMTk1Ej2Y+/1Wy+chyGrwXom2tXvIs5uBmL85nYdrp20tG7OZ6MzmmouIwU923sh MhDDW3rvFXXWzqbejh1bOI9RN23AM8fueHthzsROWXSLvIv2dvGdpwL73UXd5V6y8Dq/Uxc6Ljb/ J1VYPdPQgJ/3cTkqM0KGwtkdzglr/vDBKlu7VagTEkQy/GvL/0zRHhP7yGR+QwCLBLZck025ypp2 zdbwwXTt+pR8E2OECZvFDfl1uPTw1prVb/Tpaa8a6lkKm7W4WNijiaS1cuIjmQEYQUkQXhktWTuo C7BYnyR8xHrARQnsgAFlIZc0DpPfnxwrS9C3VgzNSbjL5os6qdqteBLm3CzLJKN4CQAwZFOdJjoL 70mVBGtUKkunHuC9I/V/PQ+f3eVLUANq8XoHNpak8BHIUIY2NIQYee+UtMLIXLlDiD/qOjnvqSQo 8saFI4Wq+wcEwo+plQL3W+FPHZUc0jjQtbyolpeA3sn5ZYsWihrjhDzMGdCn9DyCFZ4HiR3qPyyA 3Pdp/aSMHposGx0tI8iJGqloBK8LCM1EqcsQcou9wytZqxJm2BkAdWoHuuV9wHt/cqYbDuk0+fyM qOTlLh0YsBN5W69TNXLXjEGXebtQdKDd9OVSP8O+rHxFPujtfQ5SaP8ffgVMuuvEfTA1nPzg1f3C 5zIho3VFVg1lbmRzdHJlYW0NZW5kb2JqDTYxNCAwIG9iag02NjMgDWVuZG9iag02MTUgMCBvYmoN PDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTk0IC9GaWx0ZXIgL0RD VERlY29kZSAvV2lkdGggMTIxIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JT cGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjE0IDAgUiA+PiANc3RyZWFtDQpN1PZHHDBCnIzV99hi MfRiZS6GFBuF5u7TRm41vkhDhhMcr3mjrlhv7msWwCfMDCpbK5B0WS/VTf9mQEcGtAEKRizYWrbx +5hLh9HiTarR5exxN1kXfPTeXtKmrVy8LV10OXnAyinm8pjan4PIVP1NWlrfIabxbWM/EljFibxj t5LZywnzHFGgHmMEB2PVzZUvsKlzQqcwwy+wU+MQZUJR6iCBKRBps1GlTvgtehf6vVc9SXV7PDi9 HZcFjTDO4DFwDZMeHhFbc02iufXvBXIqgLoYXnI5TQA94hylUiDprKUY2x09+ArWbSCaixIDOq87 3tNj0Xxb4ntr4vFPkLw/C3V274EPnNuqmvgHEzMFY5ukUk321HXdU/Egi3hPYn2cHTb11n5yCz8o dbAv5yN6U7um24yaR6aXCWKyJFdGhsILDs781RfnyN3nTzU0Az2etxWVYkffEXq8NnjEhZnYis6j xInmFFLb9+9oUbKhjsUemWSaYjCL0EHlEKy/yl1b0to3DmhAwDNFTSryA9F29yVx3lLYADjWzZP3 Tv/J39Y9khyRotvodoJo8xROxtyJcy3G44Bo8ABYBuGH69ijsqZsIzRZKQx3HtIzqytIDRS5Wizx Oxw/E08n8Jqge5p3avxnjuBEyRcajP8cKCbby4yetCwYL1L0wwh6acvcVee7iD3/2yg36edod11g hlcJltjF/5t6ca4Od2W92JmEqd/oHIsExzpsPdlOqeRlG6Ujd2klGy8LanmKTinFk/exo/ohD9PX cY9aMLL2MXnfKKpXdTvbIIRgqPP4p4Psk2q6u/TQo35OscJFVK6twDQXTPO6f9y3mSrs3SvFU6IX BDlgMUEEPG5RwfLbYiJIH56RQU4YOkQNZW5kc3RyZWFtDWVuZG9iag02MTYgMCBvYmoNNjUyIA1l bmRvYmoNNjE3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAv aW05NSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEyMiANL0hlaWdodCAxIC9CaXRzUGVyQ29t cG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDYxNiAwIFIgPj4gDXN0cmVh bQ0KjI7ui5YSqQOI3+P9j5gAbis2a95mvl7EZ/29dlQlp+mht9k7PWE3rDSPxkll0LiVjkrktbpP 6CtGj0uccu6ceDjmbfPcOuW+sc7aqzx2JdsI6AahycewzSW2LEgpZ6/BOxkJwCYDiGWsDFI0IWdx hBas+KRw4do5ZO5mNsarc874Xin71k24XUgrnCkkIu+HWs7nweVedQyAwqlV0xbqd1F0uu3g1YYP Gjjj9/3/rSAKFbeXihnpFM/iv9VH7H3pSrUOXwupVfaTL+SU2auSB/Lxers9dVpyvoSy6ziKgr76 CCdIIs88ScWOMEsHyDnryGRrex8yS657MDahpcnQHZTR4dgmrCPodeneYGDnYFzjZwpjqS5EtfmV /v5/Oax8YAocmlEVMpVIABoTZMQxhyXe4VvwRSqYo+NhEWZ4qGl7EOvEgopW9wRDMXw/6vcRtbaj mLLgOt/OMT9cvwWedYFS1Q5th8dYJoRhx/6lt5XjCwAVFTqBDj67I43zqO9MZCcHnlk5StYiInY0 U33gmFdP2j3PItA+pQxLSCAUbuf4agP+zU9UxDiL/+tnrkbd3I1Kq0jcaD7/jqBaOT4/t835cmPS usKrrpIO0QdV+2Oz7DlbNpc3y/26UJ93RvK+1IRfTdBxq7CAf/OQYmVzlbwG8UKcZt8s3b2uyliv h5T8ZoFtYYxd1g0w4ORRZlQk18+qd5iFIGZfOdWXz0zACjJFISzjlkf/evgs4NgG+Gs8LucYDCTm 8OJ0w1KquvDflAJyw24/WT2Q1vkMTnEA2IDddq0FmYxTlIxSuBLRp9kU1AoCUT7TJv3ecDKSQ9um niJBt0PeDYV8h5BKTnloo1+XzaMBrEERL7sV5Q1lbmRzdHJlYW0NZW5kb2JqDTYxOCAwIG9iag00 NDQgDWVuZG9iag02MTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9O YW1lIC9pbTk4IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMjUgDS9IZWlnaHQgMSAvQml0c1Bl ckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2MTggMCBSID4+IA1z dHJlYW0NCo/7w+rSCH3y7WEwWu7HOu4BNnivQzMcNGjq3X6ss58zqHthUtGgwC6IwIW+6E+QwZRr gCCMaoa0mQ1Nu/2slAWc3cnFhUthhAIo7YpT1gPufHbQwbBRMLsJIjk7rKPV8rvOt/IklPxkEEnl 9yYCQH7kKUMnvHEjl71E78SqSClWJRinYHCKTKk57j37PuBB9hnVAthes0UYrPrea7JgDZsQL7rx 5+qGyQtgOefJJMh74/0eFWlAjcywWs72mlhdbO9MzMTJTJrU6bKsIUypTf8OKFX7fza9QXnE1Fnb YmQGhdy3a8ApKpbGWRMbSDGoCrEsVu+7uOkvGV/MoA+ydVfFuEWzOzV1XrqSmQRK3omo3cq2a2hL BAwhziikTVdte10fiCb7Srh+zv+pwnXYIgCWkY3swbXycitvQaTpgHg+aI/Aebg6FITFK6pZFWO/ 4ZmL2FXe0rGfJisJrcsc7OTaKBy3yHXuYo5J04I5HYfsyj8LsWIvepWU3rts8z0CD9ScCdNtA74W Hw8696YJ9xIInhdMc7Uc5UXItGdGFx6YfriGxswtNEB4QB9RV5kduWftQu6DqLsGDNMEqQ1lbmRz dHJlYW0NZW5kb2JqDTYyMCAwIG9iag02NjEgDWVuZG9iag02MjEgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEwMCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dp ZHRoIDE0MiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rldmlj ZVJHQiAvTGVuZ3RoIDYyMCAwIFIgPj4gDXN0cmVhbQ0K2nDlz4NuB3BH9DARH0+bTTVC/sJPncdb TxaXnmeRt3E4DLxURDaA3NLF7IvS0L8N30Gx6OnK/6+Y0OnOyRR/o8k0XFuCbga4Ou6gEKjMkA61 qOuFPoskYwFm/M3V/oUEfRQoC4dMwMyv6Y7bq4aeWTWmH1+3F6ZuMao6MCgU/GZbUQsj22WavK9F M5y6L20D9y+KG5ONCrYvM+fFhNUgCtVhSLifUAH72FEQf762gZSwQ/KczHMhbB3kv3x/Vt52eeLe Mfoq4qfapfTlFdTYKUTbFvBIJ/GY3fMNKcZqpjv4S3NJAGptBcibxekp+798fAMnCkYv+3Q2KFyf lvz5fTt5erXKU1AMYS9y5Qfzm85GbIfnqGy/HsliDApyV/yTcu6vnoNMC3QM6gFR0NHW48Qv5oEW LAmIJzDYVLf9K6+kVt1tlOpWA7RA/6qrWgeAW5B4bBv6kkUhzwQYkh6LUFYDEsEg4IKwIQ59iv7X 8UjxfguzK9ngTZDl6EjSW8ToElZtjHFXmbHRrdB7bnJVtk9iJWGG3ulBqmbcXxwwH/WI/40LcVRF ZFRR7CRCWszIYVybJq0Pf9lBXQKlSMR+5gA5hPIZgCAHNY+pO6Cwp/9sZiCHkQYJhrHDu1CyWDHH fUGs7k34+w/cRaWPgq3aP03WEx1YcuZvs6NMvvT2CUgeEvF673d8KEiLxfHO6fNIp3fDugZstleJ GCS31EUqlP23zpTjun3VQbvz5cldrhKqvTffrMfggzJzLcQYbOUpELo+iNMakQeqpxD7PLZyM2IC HCgCFm4zUo7gz6KjvwC/VtarKSuDMoLD4nIk/jwFsxAZH0D3HEld/hD599BiV3BuufQ/NRJ+2Dj+ PWPnV0gv+Vf9Fw1lbmRzdHJlYW0NZW5kb2JqDTYyMiAwIG9iag02MzQgDWVuZG9iag02MjMgMCBv YmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEwMSAvRmlsdGVy IC9EQ1REZWNvZGUgL1dpZHRoIDE0NSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0Nv bG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDYyMiAwIFIgPj4gDXN0cmVhbQ0KbvONvhSmMzVu oU7edKxezXWcJibQBx/Wr0S5Yc02ulSqykll+im/2smycwQJ5gYs7Jw9eO8UvZ3nrSPtnh7l+SCW 8vLkm3zjdjErqiHmEeAGuhXg9OiwXCBOv0LDkF/SBd5mZbU7m2kmP05a/MlMfmuDvDckte8RzqKM REjs978ZBhedj1jJgZbHShVXNpFdaCSHOVnbFghKJ2WpnHejd/p2M8ggPqOhtUdGuG+6XHG6SwMw dcqelZkaLvZcJZvWLe3sW+N7Pp91J/HVc9lXzZMOrbooliMM4ARMmOKGDEa0zYi0f+0n0VpUnHd/ 9WjmnR/o7mLVLLIZqyQlUqM/2jQ39X9hE018L6O/DFalRJN6ejqUPEzB4D8YgS//skzi2xAfFnMk 1/fRbKKMLWI4xbadPs5or6h7p/1UJsjArRSVZRjkbUJK5NsIGTJvWMIuCRykSqQ45+Gd0FVoXuj/ W3Z6YfKHNmKcV5zwpmpslZ44jrBCIakaumYuOfwlgz8h7PrueyupgjZYLgdWSwAIiOy8wz2vXC60 6twsuTlNQkQ7bLzwkftrLT980nzJ/VWM8GXGTOQD5J0aY1uJM3eaj9yu4lz8xDsSRd771kZbZ4wD e/ynuGsX1G5B9iIq8qtsyz9ZysBeEpklOgC4Mk5AKhq2bKK4/LWwS3hWvJKChobqe6HTaI4NkmwZ 0a3Y4ymzESQqhURb3YUrcwEQjZWi9mm+RT+WoujrF9KoNkisQ58CZLNfPrCSMiN+NEAwwkrl4oEL VOdF7vcQt1xhGqw8LI3PowYS9gCDz/I0w0Q2btVX0I4v+/+djmQlmNA6jOJjYJa5eP+M681S6Q1l bmRzdHJlYW0NZW5kb2JqDTYyNCAwIG9iag02MzIgDWVuZG9iag02MjUgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEwMyAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDE1MCANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDYyNCAwIFIgPj4gDXN0cmVhbQ0KUOjcjHMbO9nBljpTtP8//eyTaTh7 44NawDyG8oZR+Ha7n8+K8I+u81uT8HtBUCu/623K/G9z9bQJ47eWzw+xeElBEqb/mYS/gSwnRkU0 +DCPwmkFPN3+oxUI/Xamoa8ByOFAqzXUoSEtaekr6zXnPiVTMig4nDcalCtPST68YMnfs9o5v2Ej wII1PWmc9vLBn8ulrcoyg4c2rjEQqvtrmgt9USHoi8hcJUcJ3G8tLsVG7lca7UAC2ZQXOahTAgU3 sobtH2d4yQLbKmkAGUpAWLv7bbMU0EzWgl9YyPCdi4XyMeFOZPYXMvPKojK1jkxM5DZZ+WeSTAuA GW0xn/LNVxyHNeLVs22KzYkXOSZZhSZl9iJDA6o2hmcozy+o7K912LJlQi/ppq1PCEl+bmKSyIDW 5gCAG34CTwdsoKVUC1ijqPHNrINN7WiywCm6pZop2GcYEO4kIIQai7HnEFetN1G1cu3DjIQbzfvh G2huf/mwlBREu0kwuelal1pL5PWlVCEfkNsvXLOmIuY2+jhQy0BYrH0EYOBSjL+0dupjSYOW4Bx4 INRu/OUhCDLrVTI7JegOf0tmHSiikYD569weEqBsnE6BINVpPpS4SIcE0HOtV4oUJ2f1krI6d+Z7 cTT19ccTUNati4OXXhdjUmbIxmKXSqYfkbs7Ubz/S4+K/F7kRBvUp7vu+Y5MvhFHdgBnejaJieMx leM56svkS/8xfA7o67aXQbEaUjJXdvWmhArCex8SUprVrlRNS5rZYzB/QprzKIJ8OR1zp7jNAIIT cHTyWo+mGmOSQmii9MIpbg+2m5yY+DFeynGi7tThGTTDZc/cfamAm1INZW5kc3RyZWFtDWVuZG9i ag02MjYgMCBvYmoNNjY4IA1lbmRvYmoNNjI3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvaW0xMDQgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNTIgDS9I ZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0 aCA2MjYgMCBSID4+IA1zdHJlYW0NCkzkU8CGDKUOX0B7ScQKsNp49BpGEtr/f1kQZpjl7uhysint xed5RkeJBVJTAb2aRQJyLbj39Zc2R60F/yctNhTjPZZsqVFQbZCKiKeCvRB2BozszrH7xUqijeJH qA1T/JkJMkEAZfieW7LZS49alTS71IDsKeiaR9N+6LqWI2SxDQFTZxaAIDvMb6r123Z2rqx9xfi7 r45597nxn9WInQb0BrgNb8URJPIERBYnPjR43d99SMOXx3wH+BWwEIoVRHr85YxpHHT3NnGTPeRt VdZALM0gmdk6yeWHMIzwY94yEwtQ3z+jPePvat4bZhF74u+zc83EPIoEH5gpV87pDqLVV/rvy6b4 HDkGavTn5TwhJIaR23i4fs2bsTr564BQms5hWGFQCvgPdyCsEK+bwuHoKHT+NW51NRTlDp9IPoto g0/DZKsa9UfFdFGsNPgh7m/cFbXJTm9tztjwZfY+TVC2cp4aro/qDTDpkOzSCEgxXbsBeOZuEOHc UPH0XmU7TC7M7dyYDxgH54RHooFFHy348LD5DcfFHtMnNZEYkUc02wvcsFy/5TjXNVF/qXGc/Sud V3gyXk1dnSaVHlJaJBh6rGLzD/7UbLgEQHQVrCf1Hm6XznmeMkCP0c+U7Mnhsr51bEZPoe8VLtGw Zsf/xd6uuqtTeVjUqG0xSx6jVubmoMI7+vUL3gwdKhz/oNlxrlQ4zAFzxoMi4DN2s9gwKRTMJElI BT7BbHxiZFpghHqppcw5qtZABkeEXmT56Bz9SOrrGASOax9qe1895qIQwQ5AYGn0q7AfSZ2sIphJ Lqd00PnrqUlA/On8QQwjRjyXjqIy3+FI0OihtltKfPtv6tJ0J+qC1vMOJe0YFVnRf1UKq6SANCcd hVAWuhVPDWVuZHN0cmVhbQ1lbmRvYmoNNjI4IDAgb2JqDTQ2MyANZW5kb2JqDTYyOSAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTA1IC9GaWx0ZXIgL0RD VERlY29kZSAvV2lkdGggMjkgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNw YWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2MjggMCBSID4+IA1zdHJlYW0NCtYf+NQtPYt9DZiC1poa EpOljwsxEDKR0dnBW+ddcHf3zPq6lT0GvCPaMXX8fACyrN+dk+do+bq2QtsYUZKv3oFoV05JJoak NxVbaMjJiYdSsVPJGJCA70cCN8Fj92vJhMoJg5KbWwgNLhW4I6WmvyT+UmBsNKB/joNsNAEEu5rF nvWjfVVMYunmC/IfHdeSmDx9cqwA8AUqR1R6kyg1hYzL/z8sUNiMA3+ihFAC3VvzfAbIA844+caf R81/IXOFCCU7FgtFoTf7IPozY4Vn5CgcRlvHjRIMhrC0jX5wIj1tDUmdaDpm5QjC6MW+o2UyvK/K zRpHhvKMI2dGxBOxzOFU9zgydjOs8o2gTogT4+htYY403tRjTPk0vgq5u93iT8iBLy4N1ZPZOcuz djBJ1PTsr0dafY73bMt5Dx2UIAvhrrJDftQPWQFWe2pEDqpKTq6Itv0bXucDyeCYftVDWfz2hRxM HBvHUp1qlLiuLKCpW4FRGAh+Qdb1gohQeXNMS0Owg7fD7cXkAa6AabcE6tP0S/2In3N5ysNSz1+3 3ciDvKVuyaFoymVE728PAN8sJL/cdWd8SePVY7L7iT6arH1A4+40ayCp9jbQX6fg9i4NZW5kc3Ry ZWFtDWVuZG9iag02MzAgMCBvYmoNNDU5IA1lbmRvYmoNNjMxIDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMDYgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCAyOSANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJH QiAvTGVuZ3RoIDYzMCAwIFIgPj4gDXN0cmVhbQ0KvRtsUOOVZpwrPWxhqpdLFglDTrWz1ivExRhb row9/t6GDpGxc9NLvjlFSjsvO4sy7h/+hvaNRgSXRi6lu0iZ/8gAEypnKeAXP9ptPC4YcvINYXbH YTT32kkfyPfxqC5E6Lfmjq4Tau+c30u+std3xLY58AIlInm2M94RfL05w7o+kcUfoIjrhJJooUhN +qjrnk6uJdy8eQHgGRg9J+qAanhIpjOywiBfRqidZFWdpNL5hJSRQixcZ9yvSktNDeogpQNQX49w 140CQrpD7aD86iWodJsXTyAJtBAA9gQ1iFQLf60KazXs4L/8h63Kv1geIUxpTrP/7TQX8vpz+BfS 5L4Odq7PcBdfGsODoLVi/yIc02sFId2TBRLr+COTDvDE2BJG9zyMnQt4aLkWwlDUSzCKHgeQGWgx bU5IIrvuHgtC9WtHfkeGlRyQCq0HIsbTa6YPyGDbkRMqRw8Tn7N/Wons7vHiJZyn1+WL60ST+0Gd iNlgQQdi2hqdt8gRdSlMha85aCSN0ItsAvuSuQQ+4aKgXKQnzi7MpwEEkXyeKPIlPElvxrc9td6M jXQK2XBDqDyi8tl2WTtuUlIHX6rWPLeYTXPpFkz2NTCkDWVuZHN0cmVhbQ1lbmRvYmoNNjMyIDAg b2JqDTQ2MSANZW5kb2JqDTYzMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1h Z2UgL05hbWUgL2ltMTA3IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMzAgDS9IZWlnaHQgMSAv Qml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2MzIgMCBS ID4+IA1zdHJlYW0NCoocLHG1+YioDY/pO4uvNp0+tvFmaI5gfbuo1A6sVWaqbGY+7h4UHn4Xab/v 7Fs/jVcNM6tEd3mdXpnVaN3tqJIEirlWa4Q5JNwrjCnp0E+TWutae127Aiu/6+m26+ST2wP605EX V/t5SvAdajuEGm5yOwo1pwLP0NUNdVS2AHeDh8Kptn7WLrzHYZ4S62shPTvH4Az2UsBYNKt8cjBs rvK0Llk2l07KmNPxvVicBDTrcqkvpuIFoAUgILRAI9ypnVwhbX+2LqH4lx+nUrsCOZU2iQmVAGGh 0Y+7d6TV4DC2x8gNCoTVfLcWUQTMBWxU1z06jQe+fn1waY5aI5sCWRUau6FpSjF3BArEi4XzRoRR kVkj472ZCvAY7jF8HzwPfzO2jWpb4NL+kOA1bOiWDteqcpzoB+zDszvyw0Ej66fd6dMnF/H05XVq CJ/XVpegBPUxrc7GgIJBzwg5RMzr4LyybOZ1WckqaZbKo5+hhSFgvN40X3TWOjCmKyV3FbcIw2u/ bYr8od/DSFm/RKVmjnmbbQIgNl6CjgrHlRtnU5iSoDjwEupSff4eRaMrdcPXixbiaLneq85VVAZh GBLNYg8EDsTeMoGJoGoHx0QZDWVuZHN0cmVhbQ1lbmRvYmoNNjM0IDAgb2JqDTQ3MiANZW5kb2Jq DTYzNSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTEw IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMzIgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVu dCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2MzQgMCBSID4+IA1zdHJlYW0NCko2 GmpBfSLTOwUHgWusj55x2F1XbVz+2KUoKkhbQ0SCr1OW4HBE9r5Q3DbUNTy/QRRQxwEb2qmIiiAt 1MAgSiTHBOjb6LFLZG7ehWpozPUIHhQKMmsMV+KV1UgVgcbpoBfY6FWegzVc/CL+FKtI35N7wqlb V36l9wGmtrtRPb2x/5qNmPNqiCL+8vtG/oMVYks1H+XhByzKMx3h+FCeWsMeDDaQtY0dDXlCK3zO B5r3tJWvpCl8x96Oovtv0CgNYEYFNOZZtc33o53fXN/PyWMUzdSohYifdEpx7jc2ADwqljpPHnKw UKnxGOxSWxJ4EUuabmhorSOOIiYagN+g7sRpLt2Q/NpXLCQSJ+1F51GuSwh9mQUfRQZfWTt8mAUB gFH2af64mvYG/wD4XkmHVJKezlic0BgOMFk7U1vN8UdLRr6rgxiFvcrnvbhSraChCJutv+50Fd+V Q00srQiTiDEXy4Kvrrcx5Qb4QX/OB2ZchBdChFJN0cszQiEH7nOxn4sBz7GvamZCARwWQt9VkSjY ZaZeJYOkaQcMaCJxScwUNdNFc+nmoP3kjJuJXfTzjuXpqgFpIswkINikQD6jUJds2auGwEUib5+y eGWcCpuAY5B691xNc7ENZW5kc3RyZWFtDWVuZG9iag02MzYgMCBvYmoNNDYxIA1lbmRvYmoNNjM3 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMTEgL0Zp bHRlciAvRENURGVjb2RlIC9XaWR0aCAzMyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg L0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDYzNiAwIFIgPj4gDXN0cmVhbQ0KrGPNXw4F UEVIx8aE5c6dOAp66eUyNkX7t78XguQx2gLSOMBRGMEkPkEZClxkrhKIKqkPWYw6QyLCj63mFV0x SmDqz1wo/E+va0f+dwgILEMisOjpxvSfygEu8xJjQFAVMYkjxoB5zwdNYWij2LL2iMTxWMDq4ETa ebecsHvmaEr/Gvy5oHvv/ZAMsLh56A3zzgYoE8SK89dm+UkCjOTtZV6MHQSuM6eOkqCjVxCu2AXb KTh0/RV8C6P1aG1uQwfK+wX/gtzesyx+Kl8BjbsHsASKKNV9/n/xi6yJfiug7ewsVnTfKnDL9QZ2 CuXyflUsBlvRBLDdnAAyIhMeUNNiCwChh+EXmrSMnV/aW2XA1UINLbmEelp5dMzLC+cVRUcsCNmh yZP4YyPNNve/S7xp6HoKisRdcl4JJpemfJ30Gy+Zpdg+szYMutOrG9qIFPynnV+ZMR2xWraQvLPY DWso/Npz+Tg87pp9PLwM+FYAP8ukrmBRmmISSDD0GfeA1X0dESk2yP9zxyH6MczNGVShy3FDg93C cROklLXY1Z2VhmpeGVAagWIrmWI8GXXh+PXaBHS4gFOJqM28F447/2DBe4vZRYBtIjZBe75xR9IN ZW5kc3RyZWFtDWVuZG9iag02MzggMCBvYmoNNDYxIA1lbmRvYmoNNjM5IDAgb2JqDTw8IC9UeXBl IC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMTIgL0ZpbHRlciAvRENURGVjb2Rl IC9XaWR0aCAzMyANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0Rl dmljZVJHQiAvTGVuZ3RoIDYzOCAwIFIgPj4gDXN0cmVhbQ0Kk9ChTRKPAlFGb2kgbZVBeEYCsXWD nNzBj9Wm+iUQDvCi1eccoHUyPpIFMZR/7T36bGLroewSSOLxyPAYOFCjY8I+jl+mX0grN+uLgRci 3WPKMJDAqO+TnLTajLCYcLSevNKZ1iIbriSrWWlp02m3lO0e/yPzjbQhRSMbbQHyhH1WsP1JJKwp h+mQmLdHdlqdLZ4rCBPfWMrZrfFc765zAs+r4GxPVbWiAD+EN1oxNS2hKHbvKX6KxeiKab9bq9Oe Z+SE/MY/JfwNePVNnY2gOlX0ysykuqfqY+z+NVphEBcF6rMQoAvN9cJcUytFYZtac/uNNDh9Qacx Q9qqaHst9vXwNPtsbV5Bp09wpeCbzBptfTsUvwyDwQuSiOjw2Bn6ycmeJLUDtTtrAFwdbwvZsjGT HgpuDZ/VzMHjtl1Kjz/hZ1YYs8QtFv8L4Ymzmq9f2jl8XWRMDUUwUFq2ZLB88uE848iJErdbMpr5 reFVeEJqeRn+3ayESXkRkscMMKCtrdscXxuwm4zT63LnRHZAjIoCz2FrS0e01RLJJAEgOr90c8fl H7v8ItTqQ9mwBc58QHWUpvEQ66DwyJVYJJk7PvLWfseBd2N3jCNYJ6gNZW5kc3RyZWFtDWVuZG9i ag02NDAgMCBvYmoNNTE0IA1lbmRvYmoNNjQxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0 eXBlIC9JbWFnZSAvTmFtZSAvaW0xMTMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzNCANL0hl aWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3Ro IDY0MCAwIFIgPj4gDXN0cmVhbQ0Km8WfmQBZ9cBP1SJyLQtoVlAsk5cHh9YygYd5t5JF89CZr/q8 MTnVOwXCGLmFVN0CleZ8I3sLJABjzBDBUlx2BuHoKtRhzEUEioyMX7iMTYqW/36UwKxxqjZDOwjW 6fvbvxGA99Var6bnqm2i41AHXJUbKNKb+UYo4d59mPWBr3QTOnXe+9ctzI7sDac8NbFet+SUy9qy xLFSNtyZoUZhuF5N+CyJHlaA6Tpb6u86F92/1LpEpB4lGfWoqNpPyg5MNXz0YnRQcak2JyBFVJBm cKYmJvJuWBrq0AlHSUz3tST+diAHYRWlPBBlBPGsZnk+UX/e3f6NlLsIjLaH1NYloK00k8W07o8e tiX+pTZrg6h19zkcwbHx9SNXZe6gMYc8pC8vZvvzxwOa8ASetKcVsnOzU1z9ZPYAKlYc3p1rIo51 SpxGhdtC67Ta4BlHIi8LAsoDtaNwP2eLhQSwRaD7dwEK3DtTvMY72eDI1X/TtW+lJAJ7cVqGl7zP ljVWsk+ZG3ikCvNGs46OxlsxkZ+JeP1ykIvJRnzKClaJZwnOSw5835pB9fVuEqsaH4Rc3lNOLDVc 9eqeXCa7yV2Wf+XHHpf5633+JA1DO88dQPXMY74L9I+EIZczit+Hcv15dz++aPnfD7y8OLQrylnL 5ux4YBRXNwVmZzTrIWQRqAV0rm9CZQ1lbmRzdHJlYW0NZW5kb2JqDTY0MiAwIG9iag00MDIgDWVu ZG9iag02NDMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9p bTExNCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDM0IA0vSGVpZ2h0IDIgL0JpdHNQZXJDb21w b25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjQyIDAgUiA+PiANc3RyZWFt DQrwB9NUStFUXcJ/dJaJWKn0w9wumLQU46ZSdT+WTQoTPchY9Iza79pFkbGiPOpTsaN1UCE0Eeog NN9iHAeR0FRWoVcguNI9man85+fQeJYDauEg/TZ/qNAaN+UxNN3LJ9CsR7ZD8r4fyWUDc0xAz7h3 KRu70pAuuYpcOCwm5v5D09ub1gXlqsd1HuWiNSq5zjZsKEr0Sr12z7j3h0xNlpLIABuRLJOEMymr FrighpLnvb04Sav8gI2rG88uVY7bbUOmwlZ5+XdWlxy5yR8VOehSuSMYErAsahvtVDfjsTnnvXS1 JtYXKND3SRLy5FKxUO84pF7wiHb+DpwERXcLpf1LXieDbuku/lGF3vyCGALq9YZlKPDoPIU/Q/RO O4iVBjJF5+jQoBKd1dbEuTd5RzSeiXAT2/Hg2TpitWWZ6clK3E1VTLG2A44qDp8ZsSBTkvG0JvSe +XzZS0nNxbrsHXVAn69nIpN3ibXxME2pu15haxcpW8MD6oWWb+51q3bgSAJ7ZD8h6ZUQX2/NloFx l51gjOoNZW5kc3RyZWFtDWVuZG9iag02NDQgMCBvYmoNNDEyIA1lbmRvYmoNNjQ1IDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMTUgL0ZpbHRlciAvRENU RGVjb2RlIC9XaWR0aCAzNCANL0hlaWdodCAyIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3Bh Y2UgL0RldmljZVJHQiAvTGVuZ3RoIDY0NCAwIFIgPj4gDXN0cmVhbQ0K23r8tfR5pPzHhAuX2UHP pBMsbz2789Px5Tf3gkF7kk+KthuO9O+NR50fCpoQf5WOFQIJrm1kmcKZ0SluoO0Gx5b/G0YFM6AJ kUXmmOYaOyqtqaUvJ+FuDgK6ALqZaRHLGoOVPexLhwl2ulmsGPGzYK1HuVzhFT/kf1cAEpRm8FG3 vQ1qhwIPU9idcBz8rrMjf8T9Q5N3u6JuRYjr0KhlAkSr0UU/SuWMGrofeKLIZUYTSyNvlhecAxnk yXYILFweXSqW+LNCjhOsVLpn26x0AaQq8Iji76hFKx/2jw680rQKknDb69MrsxuJmagjAAEBWjVz dqjgE2aT+zy9ymKv4L5nhQCRL7dJ57dcXavs10ITXo/l/c5qsMvHxesn5y1tRaZ1hpncY6XfFln0 p2Tf2kiSTghEK6pHLHy8q4/XLGK2PLNJDBH0OC7H1CbKKEgfCQ5rS7Duvubi0LAkk6pmQkM/xaYj xjeCmwNHqD+trDHmPPY/uJ8JQDhx+96mFaXtgjGeYKElnkljhohSqMZTWbvlGS9k3joNL1XLBQ1l bmRzdHJlYW0NZW5kb2JqDTY0NiAwIG9iag0zOTAgDWVuZG9iag02NDcgMCBvYmoNPDwgL1R5cGUg L1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTExNiAvRmlsdGVyIC9EQ1REZWNvZGUg L1dpZHRoIDMzIA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2 aWNlUkdCIC9MZW5ndGggNjQ2IDAgUiA+PiANc3RyZWFtDQqGEUW/egv5asabb3XcTiQ6+yQirRFT OQFhZNDaw6L0BpxHznOgPmnftqqBsWKUcT5wYfphEH9oOsn2qzYLIK8j/NQOzdhSOnRckygquc7P l1qpJZeLU8Fpg40XnqUP+cmbvY6EKdf8O09fDO6GGFKC9TpXIngCI3ULSsadIQsSTtY9i2E4PmLM R5YHLQ2AqeQxsbB5HCPLVpgQ7AP5PKy+q4MMbhdeBjHj8FP04wwTZR2iflvWBTsk1bXWQX6wZo0H UO9YtuI5SuHk+4wAg7NrRM085xSXKIv17t8/K4lJkBE1GziI4SqvyQnyB1ZL1/dfVfXi2+xiFe8l D5xE0iXjTEaezwVLHpTEqXhXr051bAJDJxIi53vj7Ye9lPMPeTjTW32/XZBXEmbfjrTMRUaVagha J5vQ+t0vPCoIWPQg2ztTOXlh6XikLLQIK8CvGH7zloSoGeymObjWjqG7dMF9ZZvUxJFoCYa+6KL4 AaMKUVpRLeNARVHZH/t/Fe9XcGGz7CoXdG8NZW5kc3RyZWFtDWVuZG9iag02NDggMCBvYmoNNDU1 IA1lbmRvYmoNNjQ5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFt ZSAvaW0xMTcgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAzMyANL0hlaWdodCAxIC9CaXRzUGVy Q29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDY0OCAwIFIgPj4gDXN0 cmVhbQ0Kp+dqEsUDZ1WEbaJNkf56WeRgJwOCvgVhoqgtSa99zJa11AUBB4gDLfmbeaBFgQe49sDb xwP1M65Joh+wFvgnwEe+9jk+Q3VJV0qhtSNsIXiFmBrO5lDfXX6+8zqUBbC95nMNcYPceFWDODJs 9m6Jm3BH1n0qg1TASI1dFOlhA34aZoBasUJWBott6rFSYar/6QWjEZm8FGTpyaDmb4kdNuL4TJru UoWkqujJ7FcNF65SCrOmzlZUshCC/RNqCeXRp5Ik5d95+g3JJ9jkoswxjSuxy+rC/jdlr6r4xgr6 Op1mz17ORtws2ogG3e4nu88sQTt0s2CgdYsufGxAsNMQEvQGgyShE/JAHm8ZSeVfOf1RkGnHb8nj 9NTmpx6BzIw+Lf6lwmOcy4zD0vgMfJlHce/d6t9U6tJL7DA0+lrJd+Gk+82az91pN7zIdrJAaaVi P7V6YoRjs/OqhKZ+wmAhJ7R9ha2DvoZQFWPQl0JtcZuFLlgUFcMxAVgTvVb772RbOeKyDn3/G7Am uomtVitVjxxpnRwtvFJs+v+cj6CXVqtNCFs1ib95JQ2G8gaAF908+j1zwT0c3qZ1dUtZvxphHD+A 307SDP4NZW5kc3RyZWFtDWVuZG9iag02NTAgMCBvYmoNNjI3IA1lbmRvYmoNNjUxIDAgb2JqDTw8 IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMTggL0ZpbHRlciAvRENU RGVjb2RlIC9XaWR0aCAxNzYgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNw YWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2NTAgMCBSID4+IA1zdHJlYW0NClagrcoOIX1S7Q+S8SAw oXwg166z8o6SP4IRrlnbS0+4HGfYketmzYwe+WJeNkBadGFtrFP3D7HcjmklnybZVNvvuFKOE5oq ytZLOoK9Bgh6UCF56sBk9bNZ80Ks8eMvcAMt34HmDh9Ia0c5fcNwWcWw7iM5TbeaJnJfLdJM22hK L/ytyzmG1jEWXvpqfeWFzgOhObF5RGFL6Wg4ad/PJsUHNxov35z9+IXYQiP8ej/KT7GYnumRoqCZ 9IKMKdapitYbFx4H+zvovnf5SvY6CZNUSHGJTDNw2md12+kwhpmQU2k1n/FpsDA9SopSYu4BCZNg 3TouhUi1adAYpdj2maq5hfwpIyjawBgJ59G4bouDoSh+I8Qg3V0D731GLepEf3dXS5gidYGdk9M5 5ugaNPUBeFHmb56bz5mNwnS6azz3VrztlStK+tcvLPl5QlDYr4nC1HZ/VwM6coIsmPPGBAd/B3ej 3E8jPHFEgTQaboXgKZOJnN/TSmvFD7rAHXm5yH7rN3fIIpwJRhtUD12eN3iJ/dnI9y9zy6EYogNl nNJTJ3xcbs3F7yB6IC0LshF67K59r21t/lQOy87f+EioWA5oSJ0xysBH9x38v4La8Pyjy7J04QER ywfm6xLcgBCYhS/g3+mgQ31JVAwK5k08p8LdkuKwZY6sdAmnQlU412nXLRrCRK5kpyFBNivYG2dM 48I4iIOAedM2F6DZG5R79LpVdrLTkViWq59aMDsmM2j7Zss9NT7v71sbN2ZlYPX6Qg4T6XGawyjk RHcXA1UB51u14ooSnIKt0RH5kHUug0esoQS91QjxzJsYRHNLhI0FK3ioYQ1lbmRzdHJlYW0NZW5k b2JqDTY1MiAwIG9iag02MTcgDWVuZG9iag02NTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTExOSAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDE3NCAN L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVu Z3RoIDY1MiAwIFIgPj4gDXN0cmVhbQ0KpahExD2t5woOIp6hakuLQw8ziAvGMca9q+288E6pICLJ wgwKZriUvPGao284q7uN3tTbn/qulgNmRYOGqe71mnhCj9zeAOUIxO0HjJGVfiwOUfPzPNWHvGaP EkzLyCJIkOcxqAg36c6ssyfg9BJeQC32zU0MsaoNz9mqqbF3rJ45SU1qz0mhZnXS0GinzkDVhb05 G2SW5ByoY7UvwiYQUxd156qQOEVQ4VhP5dtyV7wAM1MBreeJRsBc2IIi3hzBw5nC9T+g1paKB8k/ C3BePG1rf/2Bt9LEvppNISjeCkZOZ49dCbDmus8eetjJP7+6RcHfhP02BOYnAHIedWrpcRAKhpS8 p4KEmhGnxzTu/HIwWUkjGwyrAkZ9HVA3gT7eUZYzjw7Sw4D0LsfHSUe4VDPdEKfl2e+6DLikwI56 divFG0g+7rGxqx2B/24vZ3FL1M7gjOARnCpIGtRqaXUcB0MmXvHjHtvAiQjhzF6E8T5p7nQVKgu0 h5rUpdax2tkuC3ujV4hc7OWsYDTSq0Ea0jam/2VcwxNZ7x2KkRRU112xOgURXMqfJN/EOC5uNF/V FRvheXBgCZ0JjZ9I93atgj+jPCGtvMwO2OXqM4mE+6uX09Yydy3iYS/KuZxn75PD+CS+56y4ZUPm G4TjgfotytUs8CdJlvQOfWVN6wt6fjyBMSpyS0Kg/bSpmtsGWUl2oUclHpLfEwF5a5ZCzp3WKWFt kIAXV3eq3aFASQ9d4U+d05O7Jr/6t8qn8cnZiyeFmRyizsYYpx9hk7FMwPW5xVRoTi7lMeF7OnyV mMMjOJuIjNpYpeMi8x8NZW5kc3RyZWFtDWVuZG9iag02NTQgMCBvYmoNNDY1IA1lbmRvYmoNNjU1 IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMjAgL0Zp bHRlciAvRENURGVjb2RlIC9XaWR0aCAzMiANL0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDgg L0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVuZ3RoIDY1NCAwIFIgPj4gDXN0cmVhbQ0Kb+Gtqcem fkXNxCKMxt2snuv4N94T+jq0z86mV4oJ74lk7Zxkn7Yp0GRyE2osZGBEROY8gvAE/uzuANTnWlGT Td5jOqLquZyTo4VD7y4EJ0e1+w37Q0vZDpw+XHgzbs1Ka+QXP8ZjZreFW6Vws3QNRVCiV4pP9yiz cLYfiL3iNcwGqUfL/Rq1gTKKaOmvIdQnXMhlkxqZIUakwZfymzMy7hL1eaQEkCjFJhbvZUB30tEx ik7Wg8O3P3aprXL0rXjxIxJFSpfrWHmxez270osnE1cOITLtGIbCAICH5nL9EETPv5T1kn2BkYtY i93jMwyce6CEXPCxXFj8noBN/ChHg0ISH6fgD99GIbvskFAAPE20z5RvM7sYdQ2slMnLPyn2gEgM jS7EtcxLm32WaUbtJED1YbQmKi8YUDgKIuWqNPqBKgnOUljKT0kAOzGV+fI2wBVyjPPRCklXmlbS Dqq2y8etlp/0hmQv++z39VhGYLK1eoMJqVRClwXkD+iGMAFh9yipGfihTb7V09ZAwVNHR1HIFsAZ 5yM5CByJCnk5ftaKRtp6ponr30MoQ/x4ghJyp9v+tDbRcEe7avt8cHujsfUPk+5k118xbBUrBy6Q 8tLNDWVuZHN0cmVhbQ1lbmRvYmoNNjU2IDAgb2JqDTQ2NiANZW5kb2JqDTY1NyAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTIyIC9GaWx0ZXIgL0RDVERl Y29kZSAvV2lkdGggMzEgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNl IC9EZXZpY2VSR0IgL0xlbmd0aCA2NTYgMCBSID4+IA1zdHJlYW0NCtKMZHPQaoNMbhjg/4nEx87H R6YZ+7Q7S4z0iJ2Azn4KubksgYiWtMhmaZpatLpE/JHyAeyBtgGgQu6xSgJB531IE3iX+sYbVxrJ JapIT+4Sy6RWu3/X1dHfQFr+J5yp/p9F405LzvobsVBwwO9KO35llb8IjKYn1j5YFLs742JlHlc7 EIpv8nKQPSzqq1SLxV/8Ncg1XJVqdZtvZDYxEQLEsevoWwMx6QJVMdDX5cRt2/ghTgMiTad/xz6O w+nUB0I0Beat1O4Tini2H0D2x57V5nae//V0OHIXanykN84vvlve/TDD3EhKnmRFaYbPyOqcLv74 zN0xMPPeTI1yy988SdzvMRWEqzXgwkr/zuJcPelnKZ0Vr3PS1K7Lg+fvrxWn+zpNPr+RXJWAmFuk 7On46T2hG6RyeBs3U68R7F3zbvuFeSgQjm6gdgAD52QMAkerRTawxLP3XP+S5xbtBRwGjAxt5QKf vkilElphBK6tp7+vAEneccjrAZaW1uMAIAIBg5iPFWAv+TRQ4/KAXurE/HSrkhBvKbNw3plTKHkb R+zkH649eawNSls3W1bAn3zG+hGTLhFt6mwMxwTizpsfXebRlDZZK4U0dsnILwp97b0NZW5kc3Ry ZWFtDWVuZG9iag02NTggMCBvYmoNNjk1IA1lbmRvYmoNNjU5IDAgb2JqDTw8IC9UeXBlIC9YT2Jq ZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMjMgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0 aCAxNjUgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VS R0IgL0xlbmd0aCA2NTggMCBSID4+IA1zdHJlYW0NCq2AAon1jlX6kYOIFtS4iTwi+ljb9M9ACQFp 0L895rlnRj1lglwBcELMlKWslTJmBjPwjoL26qY/Ddw0KZ0nzxkcTCRfh80oXYvbnx3F9IfpGzyv 67zUNTwzgmdBeMyj6/TIvV0mLlNRc40a9ueouSMTtgky0LpDUQOW2uKj9QgyvVQ31eODJqjdd63k dDPrtr53d+Uoo1rwwitcglHNDAx8o4UvMCgQ1nVbsLWOI83jVvHUdZvpXcacK04LO+kMLuWrKiGp HhROlEUiO17eNHzS2lea2nVYW7QbTcUSWGN3um6SRgJL47L/Q8lBBqdbrtTR82Ga0zGCu9Q1Wge6 rLo9Fc5t51xZfepA0lIrtsLvyCNjOZBKegj0OZSj4kfyonudBh2R04kxOMZHOCMerUppF3bNUmu6 i1joTQ2m83pzd80cafTdhcNhfh/CgaeqwBN8Ifb+CG6wbogsij/3bjC/1+W0SwHk0wX4UEen/5hQ iUvdiMt8TyZx2QGy+Rkeon2U8Kkn1l9d3JgmHA+EdKwtaOLmsaFlc3RdhS1OSYeWImr6q3m4uIyw 9PWjmlqw4FyFCHNMgvUTPdZDArVq4oOBu3SphLfQgrV9spywyHkabIJpFVIzV4DSyvFjtW17pJN7 2B5mUpTD9BnAcOVbIHj03oIU3f4/LUbD8IWDTJTwf2G+xsGEnxMNtL362onrm/awDEd0+qEMx0n2 3GwUsrI7T+9e6vR1CXrFUIOpp5wVFYrFXx7rG8bpbpmqvYbXPOiHp7A7zlyIIEcfLCCYuR5Eoj3l WpL9oTD5B7uTh1Sm9GtBpDP/apudomEYe039ryUD78QKPsNhPc65aWZkO67hCl0pizX7OgDIywVo Z5amoKkGGW47G4W67iUlpvHpAC+luZ7sXBjOD8aYn6EXHX0hwtD6+kcKDWVuZHN0cmVhbQ1lbmRv YmoNNjYwIDAgb2JqDTY3MyANZW5kb2JqDTY2MSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3Vi dHlwZSAvSW1hZ2UgL05hbWUgL2ltMTI0IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMTY0IA0v SGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5n dGggNjYwIDAgUiA+PiANc3RyZWFtDQprl3FlmkSfYOxwGTbeLGh5WxYVz5HHkHH6nmgJ3fAHq6mr oKXPNfxFGwbDz/7bsAewDXJLPQnhYV7L7fi7eUJi/XZ0oY2fGGb/bYKeB1a1s+KsX60FyJ5+QPaE n0LF+CJWELLyEBit//MuOlJTTD6K6o6U5SLygvihBqJZHRJQtoJnoog+tlI2pIxzvDZ7/+ZUzHP4 9gNStSkxTLEuF8DWwEPSJd7EGY7NNooBby5ZFEPYqHBftLCfNoouk2zS9QmeeQ5KppsWbN+7g7XH FxNcSeQK/jibqdjiOCxckOHsU0Mse8SZK+a0ehBemefoWcEAA2W2hmnK7lLaUjG7MnTxkxflvDjU NSRM9OIGcX0Pta5EmD0XII3A51mCX7OFUQHemS8GUJpS7KsdbENBni1aBBwB3Pcd7SN5+GrlQG4P GUnUtNu7L42pQGd0iQ1WzTkFumcdumm+7aIstHj5XMz2Aj6jSYQ7HcGsAryp00nmuwAMy49u6+xz b21ZCPn5Sgxok1M9qXG5mHTk/0wS+HyqRucYNuFKwfTNlYgEv1pub3/6679MKvTv6GsJHmBcWTsv 6md68/7IElgl6apkIIIGqtOA9ZxP/C1v8YprqbGvPrhU3XJCBVbtRupOLo40MEM5SJXg7WzLemVH zaoVPuLTbkQpmGyA2PmlvCJ4AhRgGnLxPcBNZcPMQ62HxpQr8Cupgla7v6T+eEkfctD/j31c2h1p Tvb9W92w/PYfT+o6VwKFPN8naMkQlQkpvVcrwpgtHrK1y4MQ+4il9z4cCxqiwcAUc5YR1hldmqyv ydYxfLOLQegMed1t/bq6eLmRl7FRPg7+Eg1tyJm72jGG8LAqEaD/5tPPLR95/Vdr6LVC8aY6u3Ox 74hAGdiKcizHVHOmDWVuZHN0cmVhbQ1lbmRvYmoNNjYyIDAgb2JqDTQ1OSANZW5kb2JqDTY2MyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTI1IC9GaWx0 ZXIgL0RDVERlY29kZSAvV2lkdGggMjkgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9D b2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2NjIgMCBSID4+IA1zdHJlYW0NChhk29SvZO3v E7TTtEu1VIkmHNO6O983sehpRqQx0wYxTZ3V89VLNW1n4ZYF924kM6MsS0t5Yh1teIcIDMOFvbRz eoPPmcn6WPnAMoihvhfRVJ8ILuU62BRj2vR/7CpSPojaLOL6TMpTJqrwISaqhb4qUi2/1oO0P7YI m3j3gfeVYbPdofa0lGNgAY++DQo8B9OSoXqib4XUkNBmKcUTEdnHq71ixcwCYzY63wHVAgxC6pEl oS2tTRe7tsXzQA1MGlKM6QL9DXQO53an8Ic7r01RypnuqYE9IKWte9+AaGU+4fOOP3/67hM+tCcS Pr7wYsEJVO2SkoGHT10+DW4pSv8CXjmTiMsJBXL+zPZFMSUNJ095fI58CYYN/twdrGdgUdDNV8eY y09s0GlrYQoU/+3g27bdPb2IX26zPLYyAOE1bToZHtTU8LQ1aGcxy686ExSeiqKVXK9jQLtxeLUa S3NT5iWQdiZP0/eFFt2r00Nc9w7KjW44/Vjws+ajATyIdSLu52QdPhAm5VSrwC757EM3YAbwPNJ3 Mi50+62v5RcLAxgcB+/3ktg6ICFXegq89tL8QHMpS+lYDD7SXz196aavW477Fe+Qd/2wGg1lbmRz dHJlYW0NZW5kb2JqDTY2NCAwIG9iag00NjggDWVuZG9iag02NjUgMCBvYmoNPDwgL1R5cGUgL1hP YmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEyOCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dp ZHRoIDI4IA0vSGVpZ2h0IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNl UkdCIC9MZW5ndGggNjY0IDAgUiA+PiANc3RyZWFtDQq79yZgsui1KhnKdLR9QY3y5NjTp1dLUImZ iyuWx+3t4AJmcr8r2Evy52BcOGOFfaFSaNu11YCSt68eQAK/9ZxBtW8xtlSIcphRUjDZBcAS1/TJ VUZWXMnN/foUDe7BUkt5uBcJAfFbY7uK/cK40zU9oiZI+2ijo+3KqWxCQY0YaMRNGCrvSXNU0P4X C+dU7OjncUpKrwxLAKIyZv1dvk1TzCrfewOfnFHU0OArqpSdP1oMxhzh/p0Lb35He5lGLt6ME+KA 4hklmOej9mrYhmletyo0lkwAiVDsVCKRI4uGJDhqJvIoqSdglHjxizz4HuGPz/zcS4j490EUafRc XL8GZi4UaSAHpB/dMVa8nSrBywvKGl5vKeFuF4M/kSQMz2R1itoPaufQ14U49LpReoTSqSVOqJMS RTeU6HcDeE+5Giy7EqPL4sWAkfq8sXRYImfElldTtt1eBK1x+UIH+4kLIu0UyfRUZezV+zRxdf6V /dGe4JNNw29iXqLp+GCvLBQFuJn+SMrxf+DLWBUz9jxjbUsSRXA6LqQfLHVxfS8oqrCDxOIPFAwu 3PYeP91WT52UvnNtQACSiiSzC6UUKeXM1Gi5eAniKYJOCyIXie92tj4oev0NZW5kc3RyZWFtDWVu ZG9iag02NjYgMCBvYmoNNjEwIA1lbmRvYmoNNjY3IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9T dWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMzAgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxNDUg DS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xl bmd0aCA2NjYgMCBSID4+IA1zdHJlYW0NChmh3FrgA28zRgA0Oh4ZfbaQp6BwvIm0EbI++rV6ACHM szrFfxjidRITf3WuEZSC70TPlisiEwhNujA+zEon7O84gWoHQFgNUAsLuqUo2ElfO84oDx/zexMp dgFJueIOQbZiMRVyZpNWm74gbPf2D7kTF7w9fi8w++18L8il2e0l3Leplh31caHMEqthMxUQmUsZ Bgxw69sDDVzYteMQq7jjvBw4bA0MLLiPVB8/m3rFOXf04Psj6+Sn+bJgdeS9xUPTolnWFF+pG2zB lXc+SNdXrhq5IjulGSgf6xOaVG4iv9lJwpGx1vknF2nIXaO4KRzVC6ggxljbloQoYOgPd+I+VreT 1wWLwbX08Cf0R8+7T2xZNKU6o98krUVAsZ5D8KQ9jMOyzBd52Sb4630ZOv8I0ZpuCDjZuYuTMSQa RT9iZ6DGuOwaEYd7ad2tkKsfISOt1jOy6ZH6AU+K/jjj4x9SJd4rK8bUrgIOmOjh8kQVvrxHslt/ Wpe8V14+DGAA0vwJ5QXOSxrh0gNFK7T7w9Rm7F4V+FOnz2ukTv+FsRdaW7JFy3CVT/p8IO6Ks1Ql k/5LDdVXpO/QJt5J9SW1z5//f1S4x9QO9+Iqk0S5vQ4vNjygTALDzLpiHLl+cxNrwh3Bkt+qMtvA o81su4Ytv5NyplkNlcQ2AWVkzLfRk7fGbYqomBIAAQrg1tm14t6V8gXCAdaWwuHTwSxPt38IbtK2 ySrhAI0QRHQc3iRlRoSMVt22UmPbQ0DPL4sY7EmkcYqU2X85IvF1XdfsXzY+86fu9f0KkzS9QYd0 mBvSdFQbhiwNZW5kc3RyZWFtDWVuZG9iag02NjggMCBvYmoNNjEwIA1lbmRvYmoNNjY5IDAgb2Jq DTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvTmFtZSAvaW0xMzEgL0ZpbHRlciAv RENURGVjb2RlIC9XaWR0aCAxNDEgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xv clNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2NjggMCBSID4+IA1zdHJlYW0NClquySrGaVZslD/d /0Iy9tT8wRGOpgQVnjFWxlAlP3i/pUS6NPa++BSwhMdaeuIQHaOlxVKDRqSop5O3If+XFVnvwxQO NX2khyJZnUxJYMUdddIRi2zV3Ql2TK2uoIMYTOYV0mPHEa/Fp91ncy2SKP8oAK0SJ37+D+LxvJ/n tXQk+YjZKdBHwsti+zyFlGdUBSNq1I/JA62mVyu82tmwI3FxzbWNfX3WkbF6GVFR2HCsF7mPe6HI eUN0cxjxY6CpqygyHP4jHtsKssOkHxSjGoDHXODz+ReXNsWfrIUz6g5Hae6olk4EKOULy7h4TGua HjJHn36xPVFpIwkKsxbvlZOp9nkILS+VIOJ2WmWYFbkKG10246W3yUBBCUnYFiogaEdWJXaeGoDz uYLzq8A2NwRZ5876p1njSVUflv83tX/GyZFfgD62Ar9LBBwGwXzEZzYregOXoFDoZZtAqlHGBAd+ CfSmpJJvhzd5qYHtGnbW+zvS8Oc7uRakvQ2A2btm5GSrYH0cIV0seVqE72reZ+kicg6GiSdMurbj 9pex8FggqOPVBuj9MkLLLgPjqUTHkE+M2aBr/gj6wyRl5FiDqfIm0lsiBal1kq2xKydCir/YcnqK Qy5xVxotOnn1whxNAiRbrdsxIsKe0QdkMlZ3Wznn0b2R8NVifVWrU/Ct6m+BojoL4vJrslBI1I9O yFqzdklDrPMr+uyfuhyS7NZ/1ZJiuTj5T31L3NdWYeFbIWyfl+O3XkysfvHAfXCPNp3I5k244O1B QSx8Ct1oVYw2Y4qFc1zhKM5+y6tDp2xD1jY3MV4NZW5kc3RyZWFtDWVuZG9iag02NzAgMCBvYmoN NjAzIA1lbmRvYmoNNjcxIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAv TmFtZSAvaW0xMzQgL0ZpbHRlciAvRENURGVjb2RlIC9XaWR0aCAxMzMgDS9IZWlnaHQgMSAvQml0 c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2NzAgMCBSID4+ IA1zdHJlYW0NCoxVtsyokafgfQwxrKD+fKYIKZ5REqESj6TZQLxUAiFLXbxjzQd/CoXWBZ/d3CI3 DltuZE7N7xaOZWDMS/DpQ0oqJFA23ZartqDTSMsJWNrd4nLOVXoz0GxcZ7YzP2dZ9Oqkjr7d69cC vYNfeYeW4sl7HuWtGNWofZJaQdzx576C7fOvAzOlzRrO/l7GdzMSBttiztovQDmpeA/2iAsMQsZC zaFNPCA5qEZvA77wGgJX7HlzR24oydR1Zn/h6ty8hBS/Uy41W6L4HIO4RjlGVCE+IstDWBcJVaGV nFZinaS7Nj0Jn9ZpizXCnUnFgFzG3eV5OhvhsHvoAZe6WOsg/mAEXBveK3PH5eX+26bGx0LnB1Zx MQhfQZRFWY0zTzr6hcAiJNLr7FaRpmWY0xfODiV2mNqqldkPQutzG75+zCNMRBDLnnOegmbi/q6/ c4vOStLWSDD0VaASM2uW77brPbHclhlCbaDzimoe6VgaHI/WprjSI7qz9UV2HoqDZ8UV07hs61hW MlFNvl6TvV4gH8T6/IAv6bbYdyrLkw/T091lmVBYUafNcsYYvUM2ZyCSctlyq5PVLKNJ8Z36rh/a Jj6H13lYUjKXjB3oeABMuSdG+gOcsYRwB1J45Ft8QM5F6CUehAxFl4o2CGtti2zjXDXGZXuomq49 gmBOnhzTn2zV/s+P9N2vruZ6D3f04TLBt1CN+/E8FwcioH7Il2sU1Mtns3FoD/i1UtF6yMpFofsX OU1WhlXpp0iKDJ/SW1bmaZZWJuMBuUaBQen8RXErAulFGHXw5C8NOJI1/Q1lbmRzdHJlYW0NZW5k b2JqDTY3MiAwIG9iag01ODkgDWVuZG9iag02NzMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTEzOCAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEyMCAN L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVu Z3RoIDY3MiAwIFIgPj4gDXN0cmVhbQ0KFw64GmwAKUGQNQ8g/2wycIMSAEDBsppP0Cz+iT1X3fKr J+6B6ikqHtrokZb4OrDo2qEQJfD0IcH48MWZy+Cl7nG9z2H2Pkqb7INNc0bAITvb9D2dq8+0jh7G Gf5IaCi38QbU12J8ZhxuLrCMVyorA2hztemkD+xftIoTVC49eOXzontkCEFsd8ci2dGbwESrvEtS DGvpH3SMgup67QAL3CEw5xrvCosH5zGjai8sKh/wjkSUzWdsM4Xp+Z8uaK3yzr7v1HdYrAlItGbd 7pGJWpuJwL+QIuKT/RTVp7PjyjL/DJf0rJxBN5uQU1Zz0idc9LZLXLBp5Dyo2lYa2hREh+I7FfU+ EeaZuwB8lUdF3blTQaT+qQr5Nnate8gkRzzgQafeLE9OtIwu6hd7AaFXuP7WKL4LywuKcy1IqX4D jbsm3HNoIZ3QDrpIxNUiiNvYp/kPlOYIRiOLhFkqFZYNlzbRmFxYYsDP4kwyoGwDM1xfhoGbk/zo Ig9tWLR5SRjbR/k+rUJ9Gf6oA4VjspdXutOAl7bFQTvCpVGaA7t1I7Ixt7r2ISJcthxYrWslle3n sbPoML9nhLZy4B+CmYRh0EpeeNvn2nTiqn0QYDI8bA9zup0U7oEXyxxrRZfGD0UpeFXu+sMhkKNb FywnftqQjsm9cEb2wz9Ly7ahizITWR3X/RaerXr+eFntdfb0OOUeKhPwiHBPd/cumdkE/bTc3Vrj gKqb8uBaKx3nqhwIkAEA7bSrMkMmG3iYDnCoB8zKNZ8oNT0UkJ/BOyEkRw1lbmRzdHJlYW0NZW5k b2JqDTY3NCAwIG9iag01NTUgDWVuZG9iag02NzUgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1 YnR5cGUgL0ltYWdlIC9OYW1lIC9pbTE0MiAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDEwMyAN L0hlaWdodCAxIC9CaXRzUGVyQ29tcG9uZW50IDggL0NvbG9yU3BhY2UgL0RldmljZVJHQiAvTGVu Z3RoIDY3NCAwIFIgPj4gDXN0cmVhbQ0K5jgdWxtaY3ZLzmgKu1/DWXD4T/J/J51eJeChNkWXa3VK 8N2JR+znINhl04yvHP5d0uCxhPGyYQMnesmx8eL8ONU7/tx671LYX3rT4SNPq8muwC10KU0FA6NR QZwpAfNOClWiFk70ybOF0A3T1Hb9j67oAJRuHOn0BZz/zH+16yTgDytebEcZxiN4bI1lxdYIFSu3 iL9k/AT/YfnVIqAc9xhp1gp1pt3QtAKJqcK2Z8V2fQ/TmySkLIapyrz9Gl8OesRMoChLBGwkG+b/ 09ere/80rZd839bC4YqJhweOUdXwPLSEL13RquOQLU8FoS85bt/qNacxHqDDOMYAAKfpD+YnnJ9u I4hcc/taeudBk4cA95dMFTc86gZkuvSUi/c+OjnEYU8UpO/nwwDprS4VAs5UHmjrLU+se26Z45zH oKAaTpb+mSSxUsSDGmktlZUAb4Mf0r4AaUkN9m8DK93rVU75oxZnnylcwE8O1JryE/blkx6rVjPt hdf55VMTbSnz5+Xt4FkiAnO5OD0LNZDVGYLfoNKDDB28KHppKqppxaTPFmovWKSrG+ygzmjpI0r4 oZZPcnoyV7xXK5GKhKh9wQdM26Vinyz5jSm3JiLdruOitF2M3oSmxn6b/g4qPi73oTksxVLosF5R jS0yi8gESpdo5w0YNJnELSTeoz115glDFSFrOH/aTFRASCZWZ3LRFMnmU8Rk/PAS/sfsMQJM/zaG omo4kZYEv5FIDWVuZHN0cmVhbQ1lbmRvYmoNNjc2IDAgb2JqDTQ0NiANZW5kb2JqDTY3NyAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMTQ2IC9GaWx0ZXIg L0RDVERlY29kZSAvV2lkdGggODAgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xv clNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2NzYgMCBSID4+IA1zdHJlYW0NCsXoo+a1vvXe7gPl b+dMzSosLVyllGlZ4YjhBQiXwZmoQy/AaYDWliUkwduUF2S7YzQ1QNJ0TJXNP40BwJdKBjfSU2ed W/8XG0jITEJZxSI9vrcR7ETyBwt9MYWPQ7vv6Xqtgm/KPrL/QdRsA3NH8d9I0A/6p+YodondDiYh ihJCkH+9C3J919ryxllnA3Z5RpXiOcgQeor8j47Fn60NKHkNO7xrQEqXPN9AxVS1/EAbJafj4DBw xOuoCXy8yeuRVGN3aQcot6VPUuqQ9IgqctPNocn6dung+Tlo+Re3UpxDW8yX++FslmuLxDvP87IC 71XGoKxpniWR+9JXN8TKDjif3ljQTDqLPVjZ0/1B2GeJ1TCqyf+CEQkPSA2JygOMxFfDZ/WVHv1B kGszVQqXyz1d2cBwgil2WLXnq/HhHQpI7cZnJWd+tJzR83MN1Sau7zRebj6LrGF7egl0HX7bxu0l MRH4tW9mcz1CLxj706uzYfc3dKZBWCEOxFbEmZ78VQl6p8dgG9ZMx4IDMrSx5DEskOgp+rmocWp8 2J00SeQJs1PTrT8nuE/j8MooFvFxhzXG4PQRlu2neZjraIWZDWVuZHN0cmVhbQ1lbmRvYmoNNjc4 IDAgb2JqDTQyMCANZW5kb2JqDTY3OSAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAv SW1hZ2UgL05hbWUgL2ltMTUwIC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggNDQgDS9IZWlnaHQg MSAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2Nzgg MCBSID4+IA1zdHJlYW0NClvzI9ayopD8HMekq6enAM3lW56Q9NSMlctabqlRbd3ZXO1HlZS2vt71 RuQtuXQ+gXzUYsUkCcuXf1CiPav7pxWAOKyPyUqC0uVRCuD9iPn8stOo5Ol8RtYwg8CClKokrNfU 4PfqyQzduh50QdPm7YxgX9FfhZN1GFWPq/ASqqfYH1Qo1AApbxUtn1Towslgz/5jrrjVppj0w8UT XcEmlk3Jf6+qst9rV/rrJIXK+qtvGEqEEkT1kAcdxq536VWTG4zOvuAcXi0Bmrmsb7Drz/VAVRjt 41njw7NFU9cuzkWY8SnKQXeTMfsLaUbUT0CtdA6SQ9E0GxfEEfYaFV6cB+FktnHc1aCtGGQmLVSW rm07oo/9vhFt4ORpyf3BXUo+yEiDEUkohgkeL1vvLTA4aHxfyAS+W3iJ1XcJsdG2wXqwahOUR5B/ DiA0o/8fPyBox8STFLgBsh0U2gU0Cxr01tGSgvMN5CGqRUYWByqo5cHuda0g6RMZLEh4hLRrPRjZ XlCO+ZqKgUEpvXYi8hYRqyKq7NMZlaEB9X+0BFuJnoEVFzHXRw1lbmRzdHJlYW0NZW5kb2JqDTY4 MCAwIG9iag00NjAgDWVuZG9iag02ODEgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9OYW1lIC9pbTE3NyAvRmlsdGVyIC9EQ1REZWNvZGUgL1dpZHRoIDMwIA0vSGVpZ2h0 IDEgL0JpdHNQZXJDb21wb25lbnQgOCAvQ29sb3JTcGFjZSAvRGV2aWNlUkdCIC9MZW5ndGggNjgw IDAgUiA+PiANc3RyZWFtDQpXffyUBvQJYHDMsNuLuv1lqd7wmOB5HHFZfqcLS0xHs1uYa/RjHLD7 WrrXRvVRAHhs7n0GvSedI/PXQgmtxfYnL8jv5lwSDsIC+0saCE0VkD9E92Mtls3/PgCkFPPANQBb MWwqU06mnLOx87BllpCHu6ta6y/SXVKffDM7KHGDdaRZH85A0WjdDpIcKaF9HKmoxivhELx+Wsrt VvUOS2bcy/E1GlhwyaagrIhWSaLK/pP3IsuuEWdmJhGaqgSMibj21cqPGCGCLqGbVbEKLbC+LdDT GqoPkoB+JvjXC8rEnG4uswXqDBtThxA4UUYfaTEfNu0Rzg1VxaPOxlHTNkALj7O5pHJwKzYQpzI+ 3pvm8Y8SyNwhbIrUPOX/P5GAl0XPl7e6OhSky6+80vniEtgJIqRErqIdJ4H+1vDrYC44tpqGndeN U1QIg9MVX/n4MRWzm90HSkO3gl3U0nZenXhxQl3Z9vZCRfzuk7KZDgXASfpfOwft046f18m3N0PZ LrhXEgaDdajP0odDZznaJyxCc/bCt7iJfG0iP7oydhsO2AkY4Oh49dwdekn0ojrz+ErkxIVyEmvS YxWTRvfIeYP3HmR/MiK6SdOkEKzODWVuZHN0cmVhbQ1lbmRvYmoNNjgyIDAgb2JqDTQ1MiANZW5k b2JqDTY4MyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2lt MTg4IC9GaWx0ZXIgL0RDVERlY29kZSAvV2lkdGggMzMgDS9IZWlnaHQgMSAvQml0c1BlckNvbXBv bmVudCA4IC9Db2xvclNwYWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA2ODIgMCBSID4+IA1zdHJlYW0N Cqwuv/uBsRPhWyWMxN91ya/NxRllBovylMU3cxiIDOCx7K5j6VJaa5igKGQsCkbSpFGRwRyZSfhL umHPy772TVKB/8Fha4sGDl9Sb5QT5SwZ/oKeAkQTTqfgXkkAGBiAqtVGDyKKV80QcnbNAPTg3pd6 oNb6yMMqS/TOZ7z4FvVTUqwYrW7vGWykd9RaBoXHL9Y3zO/4c1lVeczZgVoGfJsF55xZQYbfhcP8 hINShTFEtr9cqWpDOB3psVmSNt+EZ/09rRwf7NiKDKUmPGhEuexQDjm7FFgMXmfe8KlD8CKUWLX1 uP2v7ZqlbVL+3SwvW5hjNvBj7TDlq9tVQZbMPwcpBVunMtVcyws7L4ASxhUdgAqR+5eleX/2ovDp plrjdZ00jY1ICnizItkm5YED/xZdBOwaBKfw5ULZVORY1QVjncdXx70ZTLjw+DcNTIKg29wZeVGa 0GTimge2EE2yzCTixXyNBH1zQvNcv4OoxTOULnOU7yIoobR/rioB7DF50mActGonXPjgA7esO8y2 /x1a3sKl99N9z8SFl7cKqtTIerVmBFhsIldtkmF0NifWXQIvXLSRU8ZqxeCqYxWMxaNL7PMbDWVu ZHN0cmVhbQ1lbmRvYmoNNjg0IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4OTAgMCBS IA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAgMCBSID4+IC9YT2Jq ZWN0IDw8IC9pbTIyMSA4NzYgMCBSID4+IA0vUHJvY1NldCA5MTIgMCBSID4+IA0vQ29udGVudHMg Njg1IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNjg1IDAgb2JqDVsgDTY4NyAwIFIgODg0IDAgUiA4 ODYgMCBSIDY4OSAwIFIgDV0NZW5kb2JqDTY4NiAwIG9iag0zMzAgDWVuZG9iag02ODcgMCBvYmoN PDwgL0xlbmd0aCA2ODYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCg84yDFw 1sraCYAMhtlVP+JJ0ecYkckluTOhnlVZI97KykoxUWFj3wnFMW55nuxxnLShaTsE9N2cmukrh3G4 UzEzLBGmeLu8qNOViFP+kuQQaF7vwYhAB7p52ZZMX57uC95P4SuMIDA1CxbBPIlFqrtbCnhkBsBK JwyNa6HjI4ddlU1qOV7GRH0pOuaumYwAscsvJdhjnsJPz8AWGj9UTB8rNbi5lPV93KzkRFrg5xGM 1mtbFlqbF8czW185bjOC9PUNy526D7Lw/xYYDBi0WoxkaiX/7bkvzv6EG1/2MJx46Kmrt/xxVEeS vor6kX4G8o8HLG1GhNLhEl2qBc9K4a1BdDe1V+KBssUfGaK5emmYqWNn4QkzSIW68Mu7kEuMYp1R I3/4ngpgQHyl1aRFOHmPXGl2H7iPsH/Pg40jJOkQDnNFImMs/N/5uQ1lbmRzdHJlYW0NZW5kb2Jq DTY4OCAwIG9iag0xMjc2IA1lbmRvYmoNNjg5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggNjg4IDAgUiA+PiANc3RyZWFtDQoziU+HSImdfMRGKuPuy7m1GCfgSlKOyClLHpKA mIxPyuG8A/UhbSUfaC7eJQqdaiRY0koGXpqDzs+Y7wyPNjoLakMFVy5Cjl8e9Z+UnxNr/25kzPDC cCbTmJ4hGYbqUM7YtGu/WnBXDHv8MNJVi7OFPKTFwQ59kK4muHJp0AO46HDo2GG6iokMWYCiBvtS F808FlWChFUgRDLsOZU4bNqUAHlDhR4/8FWECP6Yhr/wRTtLis4JDDIMBVRw0msnllO42xIKrWzv dxCClnIYmhJqiRZXDzIycXdxFD1OAa3kCmW6GaIuiMVXjeTNTNedLAeV9nGmHeD4unNUtMzbqlEz tx5Iv0zw6E4wFZBs3fJp1vvIXSBf5npklsheGZ9Wj8+tANcv4U6D0+Klxgijvux9x0Zawo/4+Bib HBDdl4u4Cw553jo2S557XzeQGuhCFiD78SGx4GX2wpr6q4nLVzbNrbQANZTxJN0KDw8NhYUFvf+j XmgrY35tTNjclS3MhxZadWIOiAlz58bYNmm5SyrYX8Dy41noOglEdJbfktSe6uEq1iqQjMkWGNoA x7wjtnP6dIENkSvXMEL4RwV30CtPhnEEQWlWdrRAK6KKZ2saTvu5aafbcPGwCUjB5b0eMnZC8Cpz +kegFKawwlnLq0WoDbo5uG1dCliL330+f9dXX+jEJ4jyylhtYXZVm0+hZqPBkVfyRobIpUJMVIFW uoh6M+T0uHmWyVUuS0th/lrGgdmb7dU9mOomjsJBUYRsk9FXHGUxuCneMef+f++Gr+AkQVbQcxz6 SLZCmDAVujP+vfSmYAHT5evtTugxw6bvL52Giks3zmv/DtBg5ggQqELaTX15lV3Aa1IsE0O4OnQd w0rRmLYt7acO8z0p+H+Apfwrd++ldyoNYj2HcmWMYz4XvummQVQCWt+NMkqLcSkp/IunR5bb0l65 jgV2mhb6NccJk5k9JkkVCrRBcKtpVwTXr9HllTXBheNwmi+CHys+dzd/yhV1yEBcwo4FL6bwzVpv +6/p8vCDIdP1Xo3RfgUNYuoZfbHmnPJzbeCaBZHySkxPiUHdi1qEVSFGfNUKEcj0hiKVodmj23mu R3mHDqaslrJkuOQra5k2lZLy8w4g835nU6UETd4SuJR8L594HrbI1I/q69dR2NIBt45On1FnF4zi 4lvntcmbEvux5bHT5d68wq2ORcGo2x/Kzj4LypTmptW6VjnkpP4jObEbIpzvg0Lh1ruMjAunax1l +h7nQ010QERsKdqGwsUUC0AccgpOPN9pkLGiwTl7OVnoqYomSv+zbPmd7r9nAsbUkXTAQeGj3a48 Nl8drNbSQYzgi1nc0owFKkuN5zsE8Xgx/SX6SECQen+LhUZqW+jFGx6TcHejt+jYcVPBdnkQQwdg G2V62D/AjYF/vER9A+qSTlXO67qDfEUf2+nRq0/+Mw+iWy5wm07AIdJGdoiLFJmjCiLK/6g1py7X tzH5nAzm0Odw2FTOleK5EFrTaosJUs/1oJTNVsFq+O9FZWwKcv5XUZRsv8ZCq9mQZOmli/7AEvsi micPbQ+GUT+BfinegDctii9ycB80TxJLV0r3+ALIwyrqLvE0okOWNkK+nWiJ6q6K1KzsGANcJKI3 QCxAAHP0B79t06ZKHVGgD0vTRl6VVRTlIZsgRPAYpBdMNWO8+afS0S+A1IRjwSsFN2epDWVuZHN0 cmVhbQ1lbmRvYmoNNjkwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4OTAgMCBSIA0v UmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAgMCBSIC9GMyA4ODAgMCBS ID4+IC9YT2JqZWN0IDw8IC9pbTIyMiA4NzYgMCBSID4+IA0vUHJvY1NldCA5MTIgMCBSID4+IA0v Q29udGVudHMgNjkxIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAw IDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNjkxIDAgb2JqDVsgDTY5MyAwIFIg ODg0IDAgUiA2OTUgMCBSIA1dDWVuZG9iag02OTIgMCBvYmoNMzMwIA1lbmRvYmoNNjkzIDAgb2Jq DTw8IC9MZW5ndGggNjkyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQrFRK9R iN0kqPjI4a11821OAPWeMX2Ka7+oPFnpGar/SuwK5KJCA2K3MqvpHtIvL37qjGj+Wz9kENEF0eWJ 9LrGUhJNtsY0t/Q8nj+RJ/iPZJT9QYprqZYA74ICszf8KQry8Ccf+GuvvHbjgNusz8gf/jNTBSIv HexOezIVNiRAXVZ5/3ecsSnwZHxEM0of+scdTEtfK/IdyoDxr/FmnxM2wVLtLTy7c79au3MoftVD pPpBbJwYbBiM/EYqol1forKnsZsysYAsmHKpEVVWp1INsRZOH+Sler+54/v1BI1H7SGKwKrZO4LJ rC95n1GGdlI7wh0Pz3NY/FX4AfEjVsWU5lDkUuh5mtTmQsxgH7HBCGvRNUGKR3uFPPVDxNXfHYv8 hexf7pPyAEQoM5P5TXgPhgmclZR2TkQrV6QOIvVO8cfu2XybKzUJsXANZW5kc3RyZWFtDWVuZG9i ag02OTQgMCBvYmoNNTkwIA1lbmRvYmoNNjk1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggNjk0IDAgUiA+PiANc3RyZWFtDQpN9C5a7npNgsCiTMbREELEdz1/1AWzCAHVGZzX TcSr2ZMrlhvhiP+g7vKjdlJvsW9vJs/Vpi1CqgcJFjvKM5ZXC64Y2bcffF4Pt1K+pdV4YX8WWwxO w6+H0jQGIlxYjQBPZ8p8PvQyZJz1S8oR3YCqwXnz+lzCZS0CqvZ4a3TSNiDcnSyVkWri6ynyyqNj bz17O1qjr7aYjSI0OHDyVrV7mxqlJ1tCKfl+YH/sRKtepuZ+5SE+mkD2GIWn4ByRCbLdWrPCsMhf YYkTEQNhqxsRkiILUYWWIHGcu91kehSqXAcn8fQvcDnluPsKfHfn7vpPcX/esOPBtw62iSNCnX9C 5Db1zmTfKncFrDMpRBSDEoUTxLSs1iV/29X1HEGa7k4eGFc+o6nzNYNCN6w45Jj5eANuGNYZXnaF fqi983hKqVmpXUYjYKVj/XM4B8qHWUjg9koXtOLfvUEdRoj316gROBJPoc2TG2jcGAHR64ZhZj21 n4MJIhpbTuMHBqFv5+n048TkCegxaqvYAt45fsnzRIp2YNoMI+c8WlWLC84NWQP1RshuxAf6SRND kptBE+hSh4tw47wAeC0Gs8PAeMHwia/VSelGBZYzSoxv4pqqpDTV8hMk41+vaFEUfa+hpIXFTviX /GDaahsE6+0TKgt7DK/8EcjuHjlAwZhQdqaZay9qeUru8gml/Ld14j+vVN+ie6nqT/yuR1TnYQyn 1lJqMnEoNKEvq0k4cpi2z2r7b9jysDUlsLOIWLvDY3h/Y425vcXnazkpY6NRYeCPlw1lbmRzdHJl YW0NZW5kb2JqDTY5NiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkwIDAgUiANL1Jl c291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiA+PiAvWE9iamVjdCA8 PCAvaW0yMjMgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDY5NyAw IFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSAN L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTY5NyAwIG9iag1bIA02OTkgMCBSIDg4NCAwIFIgNzAxIDAg UiANXQ1lbmRvYmoNNjk4IDAgb2JqDTMzMCANZW5kb2JqDTY5OSAwIG9iag08PCAvTGVuZ3RoIDY5 OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KIGoPPZWmvQIj4m8ZDIps8IrW lGDT6U993xgIkpnNVr7mvMK6wtf+l3tsDROVL5StOwgWnBCwwU/Q2jiHtDbYASCvtJhUXbAG721x RfKKzDPKhSJoiaEeTI9E9iJ0wMqBi4+UM84MRb/c7vFCP+BsvJRTFrI0/EgPMQ6f/aosCQx2NBt7 8Z7S2cc6JdNJAIWaAvpY9STyooSwJPkrZoG2Ug2WtuadCyQ02NW4RgYJ7BAy40EeUGyATOFEqxrq BAvriwVRfDsvlbKUOHWqGP6F6bLlIKgypfgXGY8DquSwkIC/4IbEv6m/uboYcu+uz9d9KE+3Y/o0 kTolesE67lmF4lf/mV8TNqak5quOXHin8tUbBhWhu3vsD+rJGWRNVSary/LdAsnUYPjikTWDeT8t xXrCubvuBiMtBz5DxUmVlQguQ2PULrWmk414DWVuZHN0cmVhbQ1lbmRvYmoNNzAwIDAgb2JqDTQy MSANZW5kb2JqDTcwMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDcwMCAw IFIgPj4gDXN0cmVhbQ0KyT2862uLY3A0LYatSxo24lkAeeNgArbfL4v/BhxeG4ZDqQpryiXMSuIi QKGbTFqjSzWcMtHzcefBYC7CecDsbqRsI5r1HEJhlvGe3AhyAKO76+PDRDHHJLzrxnX0+LzmKlkk B+BWWXoZCUBdM64iNYD7bBoo0AAZMoavuDZbqiYNu+x/+V2DwYDWC+NDmLlU1VUXPG/OYIZc4zWW /4MoxzFT/uWlM5BOQwy8qkirK/lBkgC82B6XIriGvK+AphR3f9cbn3uqFLYL27Q77e4nULynxLcp 6kekAaUCdU46g0wrCKZNP0+oUVlYC21A9ecHy9Sc521Jo3zTj8IuBf+MVcpPB8mAW/gLfoflgXPQ ob8jPAAi6zYx9z8QfoW8D4rHLBzm7Ar2Jf27h/yDjkfNgtAMCrHNkLstSTRJROXQts31gXMSCHVT 3NRKTJZ8ly29QvJtquSudsQNL2RhxItOwXe8C/j7PK7JWWv+t9hMesrTyE7AYExGUAEJatREYuUx 7yyctP5F60gh0VNCmT0M7YxeRjyqm0KBzaCiRDobJQlDG1KElg1lbmRzdHJlYW0NZW5kb2JqDTcw MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkwIDAgUiANL1Jlc291cmNlcyA8PCAv Rm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yMjQgODc2 IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDcwMyAwIFIgDS9NZWRpYUJv eCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+ PiANZW5kb2JqDTcwMyAwIG9iag1bIA03MDUgMCBSIDg4NCAwIFIgNzA3IDAgUiANXQ1lbmRvYmoN NzA0IDAgb2JqDTMyNyANZW5kb2JqDTcwNSAwIG9iag08PCAvTGVuZ3RoIDcwNCAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KblhSuR8muq+caW988T3dXXk6Gc8ps8SN2VImByBT RnbrsSmOFK0/QkN5r92JAMhCq+94rssD0RddIJe7Z7wzpEo5KejlaaDktwtTlEYCmmTjUZ1pC/Sh 5ojGP65qc1zNiogNxgLz0BtoFkw/F3kJ5bZfxKNL+2ucrbUcUF/GJR6/WUqPS775ykO3IhN6Ti8S CUe9xgByfPZXMUpnvgV9ZtCnkIGk3J1GsQt7UUcqDFvioEnWWDJ1gclW/GILpJ6j5vmSgNf6mrc5 wnHPuxeNGn5Fcbei9AYB0v4v7qWdFFcNqzASWfHvgFdJxPcWjbceRVtvq9NdGnnncu7TCtbMN+82 /YnQYrWMNEgvf3T54XVWLb1KDb6smMgZFoKp5lnRNXJIQQblMTf1AhxUqfLUujwWKjD3qz12S/wl rBbQgJ5y3PJJM1v6DWVuZHN0cmVhbQ1lbmRvYmoNNzA2IDAgb2JqDTY5MyANZW5kb2JqDTcwNyAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDcwNiAwIFIgPj4gDXN0cmVhbQ0K tLLPEp/bPo9GWBIuFi3CrADp++5HfB4lb4jT9aNvBSRZlxC+s4hmIdNbq4zWuHlGh4+RxdE9a8VG FVCi59aNg3UODASkkU2gJbnJME8bWdPgesYeu3CzyKlajyWErMqRRJleSBqhnkqe7qfVnlKwmH9I C5eiEDQO1d7M5XGjN4yu4jShxiPOu4o3gsK3tpKguG2jKcCEqPDaoxdvDjdlDVK2KiDP6X0PJIAh u04HAgoT5Pbw/YtG/36k1zUDUUMe86nWp4yvvYCAKWngjSUx3kIY8vkt3xbvs5d9ytRBTMEs6PQM MPcrsTMJFEUJxrCzn9Y4c7jqqDNyYi+DR91dXfJQAi6NkGSBZFZisV5BVKYTveHIE/khh17c5QjN IfVv4BnYZbrdIfwXmyqhDjRbI3+CKrqBarUy28Lk44EILHgMLRRNfRYn/Mmx3QhCNYXWiuOuR32O QcW8db5AXenfoVsANpz7JxVY9t0SotNrqbTlN84Cjm50uNyis37iHE/U3S9iYZLX15pLHkeulMJ1 DbS/hxMEPbbX2fWdPaHyjbVBmTLaTWmb4ZNFBz8VYKzIMFz8hkYj+aD7uHpdfr+lBOB+FXyKQRzS jcxg4D4yXTPitdDaL7bcAWZYq3LKPNf5tWiyB85/BHQ+zP605BM0XzcRnR9AqBiSaqJzfYJIfhL1 BQbT5vKCq1TV1ADtf++swRqOsmvUcsk5mrHcxP2dfQbgjcDgmr1Ezy74RTqOko8dgI1blXEwI4/L zxTmwhVZJsP0FNigs9KmYzKrphNZfdVTR5exF5pH98PLNyUdd6hw6jXEtN0RWT9ul+PjHWxst4pD 7ErY63NNwu1kQut46GVAbebfpwhuTqQ6YfCmbI4JwWA3FSz8KiRCJboFgnIRCt7IeetMQx4481LC I/bAigGOtiUvDWVuZHN0cmVhbQ1lbmRvYmoNNzA4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh cmVudCA4OTAgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAg MCBSIC9GMyA4ODAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTIyNSA4NzYgMCBSID4+IA0vUHJvY1Nl dCA5MTIgMCBSID4+IA0vQ29udGVudHMgNzA5IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIg XSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNzA5IDAg b2JqDVsgDTcxMSAwIFIgODg0IDAgUiA3MTMgMCBSIA1dDWVuZG9iag03MTAgMCBvYmoNMzI3IA1l bmRvYmoNNzExIDAgb2JqDTw8IC9MZW5ndGggNzEwIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpr39j8D9/7zYW4XShpGZcyfpQYFAyTjfXZIx5ELwF9nQ52tyabqPWmGo+/uiSf klb1mB6ldrJFTQ+RJ6/nTw67wrYRYZRDG7qH+s5+IMVSJPdVxkqOak1UkAwVwRtXgy4ACaI3w+0z 62rFj1cUNov/gwPfhdkP4dERmME17bNQ7Yzv6CuSj1iHwYvq+WTD/jp88gv7OvnFeWvud7Bf+tMU M6m2Vj29uYdbPN+rE+a85l4A8mdFmPtgnOkXne0Xr1QHMaanvULgEZzoGboIZv8sA9Ur5psriS14 pkx5sZJwrkXsMmZfzNYRpt7BBb23IGouc8R0IhG4GdQd+6gSkKftSwx1+l5D347++uYqj/IYwTvI 1IbYUVHXkGFZ8wzQ8QRX/H9NJ2cS6rex6hoMVuU9bJW93RjVPPdUV8H8vow78sH5JJYOCI4NZW5k c3RyZWFtDWVuZG9iag03MTIgMCBvYmoNNzIzIA1lbmRvYmoNNzEzIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggNzEyIDAgUiA+PiANc3RyZWFtDQrGXWCxWRyhGavi2re9+5Df sG8a07SVNuRWe0HmWA63FN50RqQPcDrgTuxvQj+TTfKRfGlUe6dXl3CS8tmvDItmwnjtX2haSmpJ Cku//HqoZ24AFxIn8IWJ6H2r7tNAZ80Ut4qohRNL9zSOaXNH+avU+R4M4QXCcZ44FlV8AzVgCv9Z lBcryFp/F1lvuCN54q2JKcosL+ynk71p/BuOipyjrE5ZLbtLXsO5H1rxfSN+WCiGj2r5CbQj9VDa cyd6qJPPh0ANW7hV388yKmbCEG3DrXfgTGoLa5h/ER5AthytiP/uy2fNmg4WcrpYtuDVCfes40Ri vwZ1KtU34u4UVyxKU4ZpeDLgtpYd71/roopJZB6NVCYgk/pBL/n1p6pezMpQcpQ5V0lfW1kZRRWD JEejqOOooLxvSTgwc5rAVGCT0cVxmxw06Vo7S1yg8/4/yxOydTmFR8ujd+lUheTC61PqbnX6XjQ1 +mgbaau26V2kthHNiyAXucMZiTSaXfKG/5xmJ5spW1pzX4Bozts88/csFKyOuPEeZTj7vfdTMj+c 6vpFcGkm+TzlSRF1xWB1Erjk5C++8KcLBhjZCkaQuA+x1aHahCWkrCyx6pG3VAhuS6Km7PhQja/y H1Gmw5kxh1332dtMb4SZkq2eliWcqzBIDHzJACc2k7JePsVhKtJzopnROAnxleiE649HntNAn2xM 2facJsgZxKngZkRoqQDW4rUdeXtAoSE/ltLJ0JsqJC+3+JPHzY9ofnYa2lR4CuYGhngXJweTvZqW ZsXG/hfOQ1bNC3pF8e//QQLzB3+Gf+ItSliC4Y79g51oYixpJOHUUuTjqd3KMrM2ZUlihhaPWi6X kqURlkACYUmBBLTqlR95Pt/l+Gzsp12kGtI8azj7Yr4qtTCjr436tZ9ccLhx4P2lJBrJOUS+X2o4 nZidOFwcroDUfHBeC9Bj71Euj0Rc16oNZW5kc3RyZWFtDWVuZG9iag03MTQgMCBvYmoNPDwgDS9U eXBlIC9QYWdlIA0vUGFyZW50IDg5MCAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkw NyAwIFIgL0YxIDkxMCAwIFIgL0YzIDg4MCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjI2IDg3NiAw IFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3MTUgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag03MTUgMCBvYmoNWyANNzE3IDAgUiA4ODQgMCBSIDcxOSAwIFIgDV0NZW5kb2JqDTcx NiAwIG9iag0zMjcgDWVuZG9iag03MTcgMCBvYmoNPDwgL0xlbmd0aCA3MTYgMCBSIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvBASCTc7cXxweIU+37uEVyEShy8qGczKn0evznR9WVv hSWB9EXlgZynpLjBWXNPjmYxz3ihPbgWPcdf7x/3tEGaxH1RrwAEx7gH8oGVPSUvnQsb6kcj4Wey rdOLDuYgIRCoNRR0mK1t87x0AlucF0oGfHIIwAtLgObuyR1bglDifdCAH2wJiFts7Tb6rYX+EKTI 6Xyq9NSxPXMn9SCbpq3RXeLmTWaq6y+Jj/cKir0UuNuWk1aQ1KHeOcfZnBXbY0VQOgUzSvwIJ4ed LuLEBmwmq/TXXp6kQGynMIRPak4nEy4iNrFVI9sdDoj+Yuzm4CSFdNlW2SyRNa0Xo+4eaNWj3P8V uyIEdQYaXMfJhDEKB4jy0Stlgw3w9JzFCJAfFVZw8mcdBrPgWWOgFoSbi82LYRHDoD6KlVYirCXa Te4/9wBPbKSyKg1lbmRzdHJlYW0NZW5kb2JqDTcxOCAwIG9iag02NDkgDWVuZG9iag03MTkgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3MTggMCBSID4+IA1zdHJlYW0NCqQK nYNkru8Egcwj8moibaOMEYQaVByAgnj3qYwU+5wZmP/23wYKU1M6c3nkBj+PYjC134eR/9LYrxvB HBxopdHR8+k4q9dYarGINY0a7dlA+troHmsGmSXc7SlwdYJLLE98fkYpOXc5eQaDX65+r+CxS14W i/UoOu8OKqSDq5ERE57z7fq9makd8n7DQfMj4jHiaXzikgKX8o3qTmGs8QI6S/KiiakAyYNElmQZ 1FltobFBOuX7fdD4b+MKUiG7XqQ5zAN7bNtM3gkdWL8K/6QZ9HiWBNsp6KloLPZFIzidNMhLnE9W QJoFOTuKCipjvtwzYrc4NnQIaCXdFBVW8Kv1ZW0DjlnF2WInEtxdAOHWlj31i401Jrf5x32LxIgg 73c2V9gtmvc9T3HxGo1D8S0QRcdW2HIUsgNHWZJxCxKEVwnOnsT/MOKELyBlvWl0zAuylClgQGLH 7YfrF3dNxSdXvHqxQcA2ei6qTmkFICoE3NanXznZI9v/vO0TvCJWup8OGJSszKgWhNRHbzCCr6Z5 YLSfNzg9C/6w0iY1LBEM02Ktxa5fmIzWqt0oMAHLNzfmdmCv4FzJFcCn3bgM4WYDK/KF63zkzTEN P3mQqf2a4jc2HHKNK0OxolJvjzYLOkNhVESKFTzwkokCCqnNfeFOFlS3718mFRp2wKhYVU4OvPyU fQdVOaXhfI4JrG83BeSDfxBLNF05/yKgCwb1UN83BsimT4gOPGLNo/vQKYUTpTwcZy6DTd/swZ3g kT/y/kNdew30YfA0sOl58bepfIgxoSTi6y/DACH+WogXVCCD5xNfrZDe9e4nIaA2wRCgqRmAT2x5 8Uy1MyEqAhn2pthhk2ZuzDc4BmkNZW5kc3RyZWFtDWVuZG9iag03MjAgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDg5MSAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAw IFIgL0YxIDkxMCAwIFIgL0YzIDg4MCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjI3IDg3NiAwIFIg Pj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3MjEgMCBSIA0vTWVkaWFCb3ggWyAw IDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag03MjEgMCBvYmoNWyANNzIzIDAgUiA4ODQgMCBSIDcyNSAwIFIgDV0NZW5kb2JqDTcyMiAw IG9iag0zMjcgDWVuZG9iag03MjMgMCBvYmoNPDwgL0xlbmd0aCA3MjIgMCBSIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCmcTMuAfUErj3A/oPwBbxnTEWsBP/1LiMf0mwPBLnI83u8Xa 0WEM7jhoL7IVImrEcrmEI2Jb+it853igSj7u+2++0rc5Ef4GQgeo/RYySNJlEz54ChwflWPTncTm BOgpCjKR0u/NldOkdd+W8QjUM+gl6NkGkUtqcJNPWwR6YRvxcleJiGD6Pqe8BZJ6ClENUDxj+g59 lwkbCvgjr9HVM/NKoxGbk2aWcfILX3lu7VV/DKYeq5yxq4nyzbfH615AjzuZAqw8lyHbP235krZy v7IVPe/zjieJaQPkRFcydA6tbO4ddTeImO0/gFC66ltzpol6QMBJP8moAfNBmOIVXl+g+RDawC3/ SVnN8XLp55W4PVYn+434+ypKpW7ttn9SUaQ84+asVMsI1mim/1Ze8MNFuVQeV87jezSCLdiVVcxP SX4gVaKcsQ1lbmRzdHJlYW0NZW5kb2JqDTcyNCAwIG9iag01MzggDWVuZG9iag03MjUgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3MjQgMCBSID4+IA1zdHJlYW0NCoJ076mh f5fxGYVRjho8C60WuieNXQXTgOIOSyOenyVxcazsNXnlMnlEnH0y0fITZJUGSxXzalJJL/ky0TZQ NUXHwLlI7O+6maayt/r6ieFAAA7jzIBzWoI6lcDqWgRW+V95V8+NjOcicBZv+MeholxksDNMqSOM SpxTCQoXamHWZuTNZYpDeQQCoQDTfWNydbYh/0Z99aVmuwtQzPDl3epuo37LI+XjmKOh4ADZhZ9+ WEXsNYYivjR4Sdu0j/fqoADdFHyTV3CJcjeQ57Rqz1fjtgPLX0/wH+XjW33k5N6kZMHHb1U0BR7Y uVlf0aSxj7CNpVyL9wP9SUuOMHpq0g6kxvckL2sSAhGP+SUJDyB5i5Rvp8VNLY/dJ0jPFpThhDDS u5CaX/5I66MtsktGkHO01ufMB2nQJDVHTb7h07jDnNUGP8tAeKNygTwhq9UQC9BsEI1zIMIa0fBE oh3NOr/QQHHFKqe5kszuk/mxwK7vyPbzAi1yCl+oP7QoLXgLwTHUPUOk0K83vK91i3PRGRkg3+6T ZkPMLPZU824Pf3Mdza78D3f3izkOTZsnwkrKaokmL9ugbl+VbG5wnvld83eEn3hfDzWxYhRVyrvl qSBia74H6CNMZSjSeyMGuqT3GGHht6ZOHz1ZzD94c0kzHiAXoCaeq1aBiXXK9bEp3s0jWbBATvpy ax+hMV6IM3xf5Ts4gTCwFFDjDFsNZW5kc3RyZWFtDWVuZG9iag03MjYgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDg5MSAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAw IFIgL0YzIDg4MCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjI4IDg3NiAwIFIgPj4gDS9Qcm9jU2V0 IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3MjcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag03MjcgMCBv YmoNWyANNzI5IDAgUiA4ODQgMCBSIDczMSAwIFIgDV0NZW5kb2JqDTcyOCAwIG9iag0zMjcgDWVu ZG9iag03MjkgMCBvYmoNPDwgL0xlbmd0aCA3MjggMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCodOgNoUmkn7YzV7eLsxVjsoHmqaOJYHPa8G6P/gSRvfMip8Pu8W5DkfrRgavzR7 EEvXvzKC30lElHCu/VLLVdkInrUY5rhkn0i4uTcfaxaZx9REcMSHEjNKpybkmXQs4CGXZr8dVvov IOodRcTGBjDo6esXM/ircS9LdpdGemwlbdcNbXhqKyNTnglHruNVM3tUeGwzEn8WLhvEYesClcYA waYr5a0HsiXWgkTy1mkzsplHAj9I3dZwJrcFzA+V98/sbteHHlFVZC+h9SR5j5B54PriuLdmZkk/ nnSxC1iZ/hwfo3qWgLZf5g+jkf3N4SZl0XxuBJIWapKDsBavSIqWEFgBQ9M/s6Uttu3gydRdixIA wTzfM/HOth/VjqNqD2m451Sijz2nKTWAin3g4xtoyE18vmEYtxpx+M0JxoZAgpjNU7wpDg1lbmRz dHJlYW0NZW5kb2JqDTczMCAwIG9iag00MDUgDWVuZG9iag03MzEgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCA3MzAgMCBSID4+IA1zdHJlYW0NClAD6YV3/TG2SqM5TVQhriaA 5NVYFwAgWwX5YLT2zpstZy6xfJP8A7yJaJZLAWM1kHiMB86UrVnW0PVP7g/+rrDSiGDg6DoBH2mr iKyQwayBcL1c5CVMovnkO3Ljwt4ONgN8hZOzs4ZX7FFT3gjBqF7xztwmQkdfyo9WgoylaxBc2MNI 2ASfTHvi4aaYcdhyN9d6qWV/3vb6Zseqmyol2pmXUEoJlNwQT6fcC2N7q9wBeF1YCNEXZ6Y6NaCN 0iCMrIjQon/8Lf+qbVd6wlzc95w7DPEOHkzmNn7nsBFzJBvf+W11Z8+WfC3IJeY8rAtXrN+91g5c 5gK5/fbgHAzplA7XdLaQhaz5UToGz+5wrQyDeKvs3At3FN2WCU9+z5pR17v6jVH86synfHwOQQWJ Fl2rvpPrkZuYRMSKRG1uO2+US0mcZaE9f4IypQ8qjlLSMj07ZvxvI6qAgwNDUzhphaDARRrW2qdU awerpPx2PJ5e2f7rzkZueMP8vqGq2hf5fFLCh0d3wZzIdXveOR0HrzOx5FozqQ1lbmRzdHJlYW0N ZW5kb2JqDTczMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkxIDAgUiANL1Jlc291 cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiA+PiAvWE9iamVjdCA8PCAv aW0yMjkgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDczMyAwIFIg DS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1Jv dGF0ZSAwIA0+PiANZW5kb2JqDTczMyAwIG9iag1bIA03MzUgMCBSIDg4NCAwIFIgNzM3IDAgUiAN XQ1lbmRvYmoNNzM0IDAgb2JqDTMyNyANZW5kb2JqDTczNSAwIG9iag08PCAvTGVuZ3RoIDczNCAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K5cLaY5t5VpFef2h80jDVGAh8TofT eRaOBtJjgXIMQtuoet8ORx8m0niQOL9Yek5yUTI8VATkYbdHV9mfFcHtvNcD09t44q85bagCuBgU KmqumHpznWYsMSt0rm/XoG45KRHm6K2MStIuN0fwhHqzgYtcpQV+MNJPv5pl0EW5xVV99zUKC1+l uMR77+BKsgoKWB51KgacIhOyG0pScoYgTIlyNFhdOxr1wiKUPn/R3OlxYmG+/LuBQGH/r8sQTxqH K604cE9bGXM/j0i5nwwR4C+eAMGzy5pVmuorgUO57V+iPwk6HSpgD+OYsTgWGdqANQWE+i6CFqzL KC299+JAnxLWskVig9JX8CFlsgOKdwPTG2oyWsQGDPlnDih5CE4/3jXsfV/ZsZIqn+W4vnaMOyhr pj07l+RPhCkOHf3LFF9z7j/dLTUvDWVuZHN0cmVhbQ1lbmRvYmoNNzM2IDAgb2JqDTYzNSANZW5k b2JqDTczNyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDczNiAwIFIgPj4g DXN0cmVhbQ0K1vlvQ3AByaPxj16vpup/N6dU3ztmtXvYu13CdyHESLjEdY4qxVIymNoiGN1lLWKI NZmEfXb9E9DiOTmeyrTRJUViVEHFNSVCOvB2peDoouCIU2iyC21d/v2tpcAXcgDjug74CaJytwIx /oeuNGHZrPQMPchC2SjQ4XpuTr6JcGCP9EvRc7ZKDYzti5kkRe9ftnQZJRvbqj1slDtFtb0rl/im J2WoheqNVBNUNBxCT0FNaUL/9EQ0puhtB62UIcNYhbtfNi2i+gYjXz+ptHIDINmDQ4PeRrUoWMtN cIkpN6wbbPCUdy/fadyxGuAJ9a17EJWHuss53UuIwl37mWXZfT/LuXZehCVjZ60nU/0g2IM1C2MZ 1E+s5YTAFMUMkmVazFoDhnNeON8ihiEinQQWhQeFWwzEgGDkvhtZz2jTCtOEHZ8vmOVeN1K77q// L4iBDo3wd2T0HeaPItkBQL9k7uXFloSzVigvmXqjRygGxREVC3RoMDyuJxUQBM4DB69nF2vydQ1U uouLuaXub7CEuZ3WoGLdnepZX9IxO2dTe1pVLwOTCyeI7/1Sh8JNaIIDV1AK6F1uGZ0bdxPLNGOz 2IHZWD0ie7+RSo8zDryt79wkkj+/Q7rQMZ612lPJAqyOPtElr8NnhZPfqRXDgEnTSew6OQKqBRHl QyOhGhGxMyc1WFioDnfSNSMZ/gctmEAAKZLH93/p8ogVlhA61Mm+nu65E4BKpNuA1mENAAGiCyB1 WlyEWwV0PWdCAK4lPGbonVGRzvG63Gdm3otmQnprDeDwas+pEL9JCKLCDPvs13+8/KdPwz9kI1ne KpqeRZm5Mb/PYgc9rv56XiQNZW5kc3RyZWFtDWVuZG9iag03MzggMCBvYmoNPDwgDS9UeXBlIC9Q YWdlIA0vUGFyZW50IDg5MSAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIg L0YxIDkxMCAwIFIgL0YzIDg4MCAwIFIgL0Y0IDg4MiAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjMw IDg3NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3MzkgMCBSIA0vTWVk aWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUg MCANPj4gDWVuZG9iag03MzkgMCBvYmoNWyANNzQxIDAgUiA4ODQgMCBSIDc0MyAwIFIgDV0NZW5k b2JqDTc0MCAwIG9iag0zMjcgDWVuZG9iag03NDEgMCBvYmoNPDwgL0xlbmd0aCA3NDAgMCBSIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NColtbRkmPR7YAkMuMOxQ5u+AkjXYqraEFF6/ ViS9wL3GiKme3RPSe1w4HXFg57wHvCAvPg4uk6AbxBR0koom4YdTW9lJJXs9IjmYuQrtQe3O+EpW +mLHMlWBgvtbZN6wReXkqZlazucIt6RTg6MBo+CYzGahIpdadZ19LUv+y8vQPqwBx4kFmyP1mtqG /XQ7+3SJFOe2/j9gDL3J16k+HgM8v5eTsBrZxk/4hVObP32IePHKCRQlTh+YUhTvsAybsayUb1Cx cfeoPwV1kuP5lheIrePyb9q5RZk1rurendqOiL2AEAg92Ulxeag7c35qn6xpT6F/znzJWiVoVqPt G24CemF2xwkn6WV4aMAD2/QgmFA06zvKRy6w+qk3y7HLWMhRsxrj/6vu1l/aWJD4swJhM2F9rzmk oXzgNsdPUCkz77j7KOM1GQ1lbmRzdHJlYW0NZW5kb2JqDTc0MiAwIG9iag0xMjI3IA1lbmRvYmoN NzQzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNzQyIDAgUiA+PiANc3Ry ZWFtDQrQLP2NwMCQ586YCmZS6EvOVSZzAOPZ2cFm2WEaMEUPs35GEjVcQRGWAzs2gBnh99z+VxGW pU4WSpsU0VZ21yi2xglwJG6b2h0AsjP7nBBmSdP8g4mxDgLi5DV2NrxXSwaooJGoOSmhPriQG3PV pAjwHXigEMNJkbjz3O6ommhjUblXzXsBkiuzAUzOkdcVs+1zMHNrBQm66Iiml9q9bOB/CsVRrNji gvBySdwxF1kvvawh+xvD1WO5j49IdKjBRA108qJaLz2G3UA59cdLNOaV9hvH8uLPHT5WikdWRzcy pfHArG0Hx++cJuw4s1aqO3xW1zUKGpLzm+6Olo1enGqbAK/qACp2EqhFF1Ce5cUiz/b+LezvkFkD R8lOcN+hH8oMt2+UMdAGL/dywpUMz57CHhFs8VGhT1tlRF2SlNIFIP70pNyxc0JPOUJ5qGq9Tzqu Mx21cHKECYViDy0Z1VoKyPBtTFpopI6dBuSa3WJX6IyzhRf3+pullwmhbdq7jUYav7nNPIWxCeSG hSvWavstGsfjTk4XWxYUwLpBx5lK8eOcmnH33tkqZ4E9nWp13A3OcDGCJaztVpGOW+w5wOGc7bvi fSYnzdVCK4yfXPmf6Wq1K60kF/RK/fGWL02c+UlrgVpXVvGibpwtYaAlx7LyIoBFLBEjOfhIrz1S Z5W8OBtx527jP4pW3m0P8r3krW4mpc2rVei5r3llsnNvXrpukNWgxUfx0Zz5O65bdcWAW49QUqdI p9U4M71FYWbJYH4q0XXF/beZOeyrPBMq2CVs613B1PwXULOWvzGkyxwpH3jx9PuI2MiLSHHPeTFl cz7K2t7WSoFNSL6/+ArbmvYWT4dLzovOKPbToLHk4Tj8vYDmy8k758WBV0YlqTD2Ow4r1FxNMyZI 5MqHM7EwJGI2V8TgcaLkwOP3DNg381ITT4x+Khd+HEm97DFkfFvqX2NqNqKAGH3uQNRKAye6bBfU NcaKLtWPUG56fPpQi/BKnT8YgboSVMPH0uQw3tA0YXmgUtMlTwMRZhVr80+MCZQAaIoA7dRTDMgy 24KM5c4gG3+y3RIPtbVlMmb7fPmCVL0wsPykqxEl+6iqqrQCrZ5alRs2PUVI+Yi9UJugVQRppVXg p+1wwnTI8Sx09oPKjb//RFtoNBaGFN1hiGzDgPnx2ijo/fptpJQ/oolKdokgxqz6Mma+KB9jmhKx dwEI0IErJQlL/oHzcQ8tRLwNKxWr53d0n97olA9pYXS5/oM9yITQjZSxv/tds6F+L8EARbIySYAx ShLAaeIZHoU1FzRaGHBohzs10COwu0Sa7TopBeXGUIwuKUWm1X0NGrd07YmjqZDPUpxAZuploC6a 8/jZ8KG/szLdQnE+T5wjl80mnE/wig2aiezUXaPySOXNVhjweLbCOjt4GUm+em19Yv4BWyZib3gS dLj4csGn+fJsIUh4wLsDLkQ8u+nwk4rCHrfm11nWRRdS3yS/1aEBa9Uedy+GbaRlA6sqf6lDtPz1 6nkWX+53NZVHbPjsuRcnSH6U3fAwzM8g8zKsl1yGxDTp0nT9S9bwJd3qSg0IFUTbCM8PNHOAcCLH JxEg3sPeJqGLv9Du1AMmn3Td9Aro5Da15+jmLcGQKwnJkSANZW5kc3RyZWFtDWVuZG9iag03NDQg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg5MSAwIFIgDS9SZXNvdXJjZXMgPDwgL0Zv bnQgPDwgL0YwIDkwNyAwIFIgL0YzIDg4MCAwIFIgL0Y0IDg4MiAwIFIgPj4gL1hPYmplY3QgPDwg L2ltMjMxIDg3NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3NDUgMCBS IA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9S b3RhdGUgMCANPj4gDWVuZG9iag03NDUgMCBvYmoNWyANNzQ3IDAgUiA4ODQgMCBSIDc0OSAwIFIg DV0NZW5kb2JqDTc0NiAwIG9iag0zMjcgDWVuZG9iag03NDcgMCBvYmoNPDwgL0xlbmd0aCA3NDYg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCvjHzMCkLh4tgdNgTyuMMZJ66w9d Z+EJtcTx49XIMwZHvXVashj7Bkzwdzq4XfjFHhItIa72WcKfrhPCdtM7ZVCntxUygAjVx1w4n0x0 2I5YqumahMjud5c3XVnnXb2BGcijOVNl+IPSK/DYWuXmtXtR/WRtDeZFkBRN/LeHZYCVyUh4R6dw BMD7fwOgYqlil2UUUpHDXriTsnY+TJHMpDdNpS2wCsFxE3ocXy+kdIKIsJEYwwf+w23olwL30YfI osPvpa/nyokeXduaPoB6tDFh0KkW+d4Ni6Fu2hWPNazoXDhb+TndH5vj3wsfxAqbVpvNUSqPEALV TNV1sEwYlHJo5ZlBT1+P7O/bUM+Gptc97O31pa7/cUaFP018mabII3tE5whLxFZovYgFKgxBEg9r K5uFexnhwRFjUx+yjPo1+gUervgjyQ1lbmRzdHJlYW0NZW5kb2JqDTc0OCAwIG9iag0xMDg1IA1l bmRvYmoNNzQ5IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNzQ4IDAgUiA+ PiANc3RyZWFtDQq8qNqraIhTvaOpl7cSg3HJWrjMiLiw+7U5feLZDfXOjixgybCY4t1JJfnWeTDz GliFO8WD11b1hMoKhtERSR40EnOH9uvb/yI0iUC9N/qbU1FAp0eUH/It8bl1wzgZPzYE7ZrBNFah gtTKV1Icw/5sV+YlLkXejKLPDvBKUUzsGmnNRnBRVw/MjLlxONZQKpfTBQ6boedltwKjWIz6oOH1 LK/eyQXpk8MqKsYYnb1AiGx0TqZLNPlfRZneBx9Ny/la7iQ25BMjE44oxAwlBFvneNEUmDpmPDN6 R+U2aHFfXPfExs7k1b5uxOkontoDmpWy8WV5395o99hjUe7A4p5l1kqcFEI9sSWho8hDgMfPTsxj mABHTRhjJIbQRkW1vybMYaEFmmE6HyRzGcruS0ZYqZqOcYRMfZoTuqMveAMBwTKV58xMxBQlZMu6 o9nudDGZYxBufOlSVl2x9ETWycX4oOU/QhIi+NRVnZsrfZzD9WE2MUdBnGdcDKAmEHWZAuo7yzb+ 0CTWnpwmM8P51fPM4j5/PbQYDyNFW71XMsyu4Dc2Tljcdh1RO8x2jfWtg8RJQVKfTkfFZ5cKAnLi OV2kuc6r4guRxRcKpGz5XQaQEZxYKzpzwKFPFxOejKxo4+CgVKm28sZROnaKNnSG1HG8nivmg6EQ L3NK2c1Gmei/f9mula8kAdGwhFyPhJ/7PITILodDbj2k8AYiiLoF5Uw1iAXzG1Bpyry4KuN86qXu MuIj6OCgsx6X3lw9Ya1HY+Bn/D/wOxvY2iMckBjuufhOgvnINDecjgBmalzLezEsx576d+UzZn1v sAeyqN8bInurqdJgSL7pkvgjZ/PO8H+iX7VzZve8P1pMrR9dsQcaBgh8N2E25N7gwazCO4+/3Df5 QkewfDbQ66AbM9iLLIC8p0jKoTDUVLWHQvu6UH9IAKB9lr+yiW5gsXaCYHRnSpLR8/AGxqGT0Vut 3Z1SOj/WAulhKafysNS95yjtSSyM46TfVJ4NN8iEgsUq+1+hOTgTrYOGxxVYwkP/718LJjp1j32S 3q2HZYwE5fReIF12ne7PVkG0+r3ECHA0FTG0if1CeUNN7vcl8BQfdmEKOY69PPTqY8oWq8VhnOzM zJ/qdxOiQNh+INmsBIVFF5FPQu12FtzVncoglPTcFwitnqsSaw2mHmiH2H6iEoMrs2noT8kEF4Ej 0PspiLPn1hczPKy+hmb2oTGxY6Wyud5qQeGeHRQDj9dIQgulXobUxAKB9cAGlmU309gEfFgfcNGt +T+584PpvozgFJF3ruIPKTSwjgJadMrTNd4hCeRGCQWQOSDLotgZAAVknsWZu8rQF/Ni3T3CNx/g GEi4501vGLqSgWP+tUEVCuB0/bJKJRIB/f1iFJHcfUiKxIIYKIji6VANW9wYTQq1auTTDU4L7tE7 Pmnw5fCyH8VkPMNkeg1lbmRzdHJlYW0NZW5kb2JqDTc1MCAwIG9iag08PCANL1R5cGUgL1BhZ2Ug DS9QYXJlbnQgODkxIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMg ODgwIDAgUiAvRjQgODgyIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yMzIgODc2IDAgUiA+PiANL1By b2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDc1MSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUg ODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc1 MSAwIG9iag1bIA03NTMgMCBSIDg4NCAwIFIgNzU1IDAgUiANXQ1lbmRvYmoNNzUyIDAgb2JqDTMy NyANZW5kb2JqDTc1MyAwIG9iag08PCAvTGVuZ3RoIDc1MiAwIFIgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0K10cBvZra5qgWfjXW79rV7/aFYdxl/zcsoUW5KyJJBpMAPjkckl888Fxn IPa3RzLzq+PFfZH9ImbXF7BQpsR2xs3iqz0a6uWGWvMtMZtfVttVoAwVg8ZtifGoLjSAEBxNOprh l2LcNP7mowraF7wG6+u7fkCkUldGeKNmfILmglv45yz4A0O0TT+xaQUbZza2pGiEAx4OM8S7Kfqu jmCBuCCMo5HKpH+KDCbk33EdJDeUIZFj+5kKvr/z+smb35o3FLoN18znx+teH+5rnKqJqpRJIGBX dWJiFpYbI+05i0w2pQPwKKwulGLeqPhBm5Rz9BUTMPY+ueNi8JEdBq0yVtAhb88cEQwuSaNTe185 wKBALVW1MQud2FOQumtGmoj5iqDSMp9Npjb5WV6hQ71a9cGCh154IVjkd4Eh9H52PiZZ/m3RxgHH DWVuZHN0cmVhbQ1lbmRvYmoNNzU0IDAgb2JqDTExNDIgDWVuZG9iag03NTUgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NTQgMCBSID4+IA1zdHJlYW0NCq7J3urCUTsMegA7 a9qrEmnjYRmUxqYUKjbWFxxATJHg/FnI0dDqLjMwhaKk+IIYyzRsQpi4g6h10msZAQOlKH/pF8l8 sJjJX7WnzSyh+M8bLEVZtqIKVlCcEx3Xb6wa7Va3W1K3+ujDo/A4VfJOZC/pT/5LCl6zsLZ7Q6AL EohC2KWsKt66Ad8UsDX9o2+D15FkOyVTOh0Q4faSJ3+WCoNIQohyy9/jXC3erTycovzYN+IB/5Lc 4n7MhXHjbCFzKC/O6ps4TBLp1nKBi0TqpQU89OmOQZJQ88CB1hsKt252wgzFPs4Y9fspRGGUhYcD SYJUhz2SGmk5bZuQIShcWIqERm4BFrPND68mAKNV/ysz5T8Iu5HV8hikjhQPeTFsR0cSNkRo1/17 DvSm+BR/Zj2+IsvxCULMuH4Ek8IOKd5p5sjYPQLeL6ZeNG8OhCQx+I8Lz33UXRi2i98REnAftRPF TFoSTsJSCbqTqsI+ttyBjQNIBVcD/mFbuTIcNA29mfAy1LAtrk/44K/6dornYis4+PGqpbAjDesi HLso7BCk5Iv8AVSdfdLdPimdilfGsoOObYR5FvuUJo/ptvLji5V+4rSMKpEd3k3kIglzejD05Yzz vXjBWEleRenN/SJw4Sg/P5mqrxPkcLqt8w/OlJTxbUcCeHZhSGeFU1GPG9ETPbozL2CbXrSQOdzd um0DJmwqYSLAE11mppBVTSrYGYHbBh7WZFNWffVz8PhBLa6ZSKtLjRDceFXXrY9/URaeag+6vA0A xgDanrsKow09oKSOAcyZ3fZdGBgogjSD9EYQXnjtI+q37uIoTNnc0WVaVP0Bu95jEQ3US1lsJVgW 5kMnxvBu2z4E8dh6oEOoMPpmVdwLKUcCZ9UpV6uxeoUbweEXagd+0sbkNBg+8XKwpcVP7EhjhTRl MC4FNjP4opJQ4bxGd0DtWYctNoqIOHEA+q+SctVp7LghedXOoOUGVNh4V/FqHdBKgEZBOwDgmo9h HGVE4cwael/Ia+/QXj81xb3fCU2DCX9VefN/OoB5aiIfTWuHDiNDKDc2u733MHYcOOWhWsWK7Sjc FgU8pJerei3oD8t7g70ZgEcMDnl2a6SSnMBQU2IifNyVdbGifSDKlVkL2ERA4y9tgqddhYCFdSY/ jRlNn+Hy77Vm0sD1sieCO7p0yqrZc3AR5MYClzaA5rcWLl2RYqGllOsujLlrocAAKilC6B1h3rFr De2S2oAn4eltq2jm/RWpA2lZAozqfQdahf2upsFgU/D8YGd0rzrQKTD4Y5KPxgV3a9RdmD1WUnV5 Rs052bIQd2luz+lvgvH9GCHcV7B0yw4b/UM4B9cZW/5BUpTlIgHvZZ4DVjbNkHRs1/9+h3+ziQn6 9KCLj6wpYPYMGGvhDVZyD6pmG+PIjGYeotn5u07f35Z6HmfUVd1XuvSJE/CSC5crP61J53vOijw3 uHwTFfqMM4kiSQHEuSaeL/w9zmvr/2oNlEvIcIxjzRDaOaUorFsuo556zACMrcBXDWVuZHN0cmVh bQ1lbmRvYmoNNzU2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4OTIgMCBSIA0vUmVz b3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAgMCBSIC9GMyA4ODAgMCBSIC9G NCA4ODIgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTIzMyA4NzYgMCBSID4+IA0vUHJvY1NldCA5MTIg MCBSID4+IA0vQ29udGVudHMgNzU3IDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Ny b3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNzU3IDAgb2JqDVsg DTc1OSAwIFIgODg0IDAgUiA3NjEgMCBSIA1dDWVuZG9iag03NTggMCBvYmoNMzI3IA1lbmRvYmoN NzU5IDAgb2JqDTw8IC9MZW5ndGggNzU4IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQqHo4bJbzC1qes5S8ZTILx2V4hez2gv/8/pr0bjh7XBFFPHl7Mb/lNEsaJRZ229NYM3VspT A/HGF9hqXhsaM/Q+aZtE2UDUtnlQK7v7V1zsRo3B+I8ge+NTsKCpKlB+6cC+MK8rUNCbDuLsKUyf eKJe4xgEDijI1ZKgd/bX/Uci4jWJNW0cUvqaCQ6RFrmytMaQkzyyL8TbIaAbLsRzdTPm5WjTbuyz J5ZCsPSrCrCUaD8Fe1vmL5KyVIQtAwZU4WaSFORWms+3EN6m2Gz9GavZLtzlqGwJxZ7cPWxKPa8n 2uBjZtPWNyyieBGO3gFYuSAm/y0B2PD+FqzXzvX7kcwEBMaXRqaIW197LVevce4h6u1L+ppCp6lG iwXo7QeCcCEEiC89v300F+JpJ6mxJllkSiyRSl7bN2+EUPic+knF4Bq8OjpW8a4NZW5kc3RyZWFt DWVuZG9iag03NjAgMCBvYmoNMTA0OSANZW5kb2JqDTc2MSAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDc2MCAwIFIgPj4gDXN0cmVhbQ0KiXzL0ZaSWiCqJtnobXVI6rT6W+jM kpCnV3hT+YoCopg4WQwK4luRTcgoWBP7eZHHojKRc0LLQkjGVqKmJKGrQTrleCHsPkAjGvU2D6h/ iEjRrmJM1XpTBxbdk1KtEf9CWBUp288RCU7achcNXxgIt+WuBa0KeOQGIDnaD2si158v8i9flzWt xPR+m8EuJYEf76gWFds1lRINAarc7e6VO+CeprDlcD5zY9GebTSSgAnYtRvzzGSAWUBpUNkDxQUO TCuSXKiw2IATACQDUUImv3SfxIKoH4pp2ohg9+9zuzyp8PYbOCtQpx3QkiMK0Ba82CD1e3Rt4l6u HK0onTYR1EDETJmKg0SchKOwEh7cESMt3AmjHtITuBWUXPm1Mo+H2AYV9ZlNihsfmNkjL1zgC9Vo JqBNKGcKNDmuUhxUPvvVCb+CSwiqj4tuXdSG2vGIFru1UEwdaabaCFkYmuCw/RXrHzYsBRZ7SR7r Sf5+AJ8uy7Uu+GHHphQ1Uy23N6uWlxy85EcxeWU5s8B0K3BygkbUp57LUSiAf+BCEwCjKbeP7sNy EJUdHYtg5lLhMW6h1wt46lFmgzZk0Yzu6MEyUhZ/FHUqz9uv/hb+4AYNzHeJTONGc2LwS/RAkcZM EDl4oR5ldXJDt5Q/nAY1XoMgHIwKM8iRqBeUbY02MRqLFBZwVZeg4aq+YI643tkYI3+ULZ5JkhgT HMeb3QpX1gbtN9p9WIsSGh7gyxbOs6B8v24Y32TTldC83ZAIKd0vhUMiWrZfNy5JFxGDNVZcH3of 9c/u/m7AqogwZu3NYOkEHLT42uxvd4aSAmH5YjO/F3RwakN1nlBlAg4zFKtFORErmStfoNpNd+cf 8FmlPsWMz/DijsQHoP5Sq3YeVfY+G4wUFaWjSINZVIj5BMBjugjEPw58KZr8igamghiYul7lFIuT 00bz8CsUJCRKY+lgWnUS9egfCFVpCLjgvbhlXSMbigEIsKZQlwFMZ4JMIiw2YBfjZrIN5xY6n+Fl DWP3u5Ck3oLGkgvSh/nSS4DNVwedr2eD3Ghi0SVPrbw8U0y4xsacfJ0jZ8tx1wd2OzSxmznLnwsG l/qmSJm9azGZ7of2C/qLPf0U/Pp5vtmkmaphav6hRGYODgQOdupjbDm6ej7jKnDsC4/2nZ73YXq3 WWKs0sTovOLtP8qQTB3Ou/ikMYEBJeqeg2dyOrG/ftfGL/o0MxIuDn09eJBiT61gs3x8KAtLe/JE MwbrYStgGbHClDNpm825uOHkGvgvcEQBlsDX3rm/Zh6d9BCAHmv3hbm3yBtnkCn5I3bgkfOOmyaZ kEyFXS+8R5EoUl07Ah/1HZkA+woStBpAPSse4qMz+G2xvhrmq7GEpIwr1PfKp/Nw5kTEGz9D6SQZ a4wNZW5kc3RyZWFtDWVuZG9iag03NjIgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg5 MiAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIgL0YxIDkxMCAwIFIgL0Yz IDg4MCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjM0IDg3NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAw IFIgPj4gDS9Db250ZW50cyA3NjMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3Jv cEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag03NjMgMCBvYmoNWyAN NzY1IDAgUiA4ODQgMCBSIDc2NyAwIFIgDV0NZW5kb2JqDTc2NCAwIG9iag0zMjcgDWVuZG9iag03 NjUgMCBvYmoNPDwgL0xlbmd0aCA3NjQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCmHQ3utqbJKz5nTkgoyPDLXIJ3RWKRNwYg2IhZlsewYsHgpABysHvNcIpIK/hfEkWh+GQ4rD r+4j/29IgqEYw9WZZBWXQa8ArrDs21pcAq1aJuDQibehd5WzueGTditoTM20fRxxUz1zFYK7zX6i 2CM9a+6mAbviiYriNxn/A02KXCZMYvEe7Y+MPHaIIEbtdChWhufdvD+C9PEWcbNCS0FMKTZZQQe1 Ubm8OgxhGdGLoMDpCXt0YLXtNUrqnSmesC/Xs6/xnpRYcLsz+bvY0EmRDmfTBNMO//kebLgDJErK 7n8D772U0Iy+A9/emk5uB45xHhniVxqGRE+UqhxctmieSQkQgjZL5LLNdH6bxu4Jm6SAUx/8K7UQ rxMNkVMShLOAynqTJXKEr8AoREYKa45QwNIVegREif78bccB+SfqwJqoEFTOQg1lbmRzdHJlYW0N ZW5kb2JqDTc2NiAwIG9iag02OTAgDWVuZG9iag03NjcgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCA3NjYgMCBSID4+IA1zdHJlYW0NCuqbB9fI0jaO4A3t+b7MQZk47ZgHZbiX c3WQxXkJ6mruG/PyvVul7I7UVlZzzAec2gqDAbF5Sm05pBCzvRw0qxv0co7fjbLAwhf81OlNO98v 3vK5wpOc/sSEeuEBmfEAyiXyNXGWPBcrQZTuksIt1f0vJ5grLjovb56qbiN34rqlrnneP4fOoUkz QRcV/Pq3WNqIK0JzYKCjMMdC4Wi7uctHUBPtsBA0WD+hjvVZ4++vVgWW5V0Uv4ML9YkUHLB685kv FCJHoBpoV2XkyT07azDMHwA5nRMt94etdhk2kuzogiYJXfZrtHsRoqn0pUkqsBuaCrA+R2Lv8KM1 BkpLJ6tnFZqw6HcrANTiPbMN8YpSGPNNwL627VhD7MIQ4ovN9Mir5X/evkNSK29dyMzivZYlTQkk ueDcHliEglQwbI13XAig5GMZtjYbVzIBmzybUHr9ZWyxF32UEyK29L9sJ3hcGbS+nTXGPxsJ4mp5 PYeGufJWqC5aVZ/Vx/lJTri1FqxAFCDvTgRUvi3K9gGUglC/BZWMkvL5Lkg0ZnaCOr3+JEUJBG/F xym33CnT6JSHzfrUoIi31sdw+PWQ+Fhz8AAo5YWmnMj2AS0Z+oRv0EuC0gJiLXD+0yjBe00XwlS1 IqrldEDjzKxYbRZSVt67SB69WVEkpMPDsmB3GodURrMj4i9P3vt+iEDdxT4h0uu/lSL+emAR5zA/ LctQK2kLK3vsfFfHB8WyCsFVsGJwY03vQmg6JgEN+4CPsrdbmCjfsPfjwmXYepGdWqiDHgW4If/F LVIQp65w9NfxWwM5csdlog9UgWsiGupdlEK7+x5s5sFb9NZj4dYTG+9FnFkV60b0li4n9clMMbRU 3dckntgGAl/4/sxpyNf9wtTwYK8ehPsFm2L4SKWtsXD2WsWjWgmPxg1lbmRzdHJlYW0NZW5kb2Jq DTc2OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkyIDAgUiANL1Jlc291cmNlcyA8 PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiAvRjQgODgyIDAgUiA+PiAvWE9iamVj dCA8PCAvaW0yMzUgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDc2 OSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIg XSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc2OSAwIG9iag1bIA03NzEgMCBSIDg4NCAwIFIgNzcz IDAgUiANXQ1lbmRvYmoNNzcwIDAgb2JqDTMyNyANZW5kb2JqDTc3MSAwIG9iag08PCAvTGVuZ3Ro IDc3MCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KoeePW3Rq66oDmHy1zPfe Qy7lxe9s1CwqVKB8+kcumiS0ZJHxYKJoY0+ZxTtZ4gJG3jxO1/e2whxpKWpIMz9ujXsupaoLD4Th NQNvpjq/FwSgUo9oH8MoDsjKimx10k7nxVBjzAYFG6yy48Cx+vO9fCVI42ybuKz/yHmVcZbN2tSp dIvzLwsvkrSWkD51CsZFocpOZ7RgtVKt/258cgpiMyhqmtMPOVoaQLxxOE0rpdZU2hS31Z9Janep Jg1vP3cyLxPoqMw9FhaOwMcXoW8Vk0kVgf11kObge6N24IC3jQ7HMZuk7u8IEjGB2v+kk9mnYoVo Gxp4x0cAsAdyBfP3fFMYuYxRWRn2OIJQNh2TDeUAkATLXmTZahBDVXE0qZ2Tl/7gY0M20JaYJIHt N9RuHZ7ySzRIC3DtzKL6wvwgzPY6nlnOwTJqDWVuZHN0cmVhbQ1lbmRvYmoNNzcyIDAgb2JqDTkx MSANZW5kb2JqDTc3MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc3MiAw IFIgPj4gDXN0cmVhbQ0KqMQgBXKkeiXDxyl4qML/Iqsd/+uRm8sGGNZPcADliyus+LZK1IFzYg1k 7sQkPyq75ResoWF0Nj0mdZ1cI0PHMoz0+EJF5OyEU03bYCUSq4jg/lhmxzkZk2PR1KYbYid66m5w 8CHlnhQRU8uJlDXgcmEFm2JEyBROnE1bpEFzq0m+n4r6ibE6oKETyx/vbIOTtMGdL+bR5IMblRZz kvp9pAQqHOJsBmZd3VJmr6iFQxaXErr3vlRC3tLmRYm9xjvk+Acu4n7z5JQBcSdW0HtDWdhjMNU2 ANJQ6swMGJ3z6/5Y/i4gWH23EIJ5xQFrn9BLQPvwniTpY2kblOVoKwfH8k60XU95dR+glGgkT7YF 6r/LdRk5YJGxUysNWfLSiCZq4WCIcJpq/pVWoRVnK0MjOG2xMwN+5n4aF4zfyLWGRQS82cirTMFW jYKsDTaiHLzekvt1E2ZCG/P4zFgkxN//aLSDOTmBjcyXT7AWvzz8KAfpU9FrEXtIM5BosalIEcac XUkOXDoWVjcnb8BYzCixZ6WPhK0OEPfT0DOGwUiOaelmjTYG9BN0+dLR5+NNmIw0093sY+e+MMr0 f0j9asH7Km9dHUnJNwhD9DeSrz9raUu8EisqZTpeRoiqQKwdpi0JVECP8OO/Nu7wX8DN/IPKh+2t lzjVK6D8CObzbd6YouuBuyfZTlA9c6JSxd3e0/QPrSK8p+IbXydhWgk06dMCYWmC2uEyq5jRvNwJ tOPKeOTl3TioTH86xGLWDhuhdRqVDBnIFg0dVsWOt/JKrjMbkGGnquVpLEEAH4PCFEd9U8pUpYQ2 ad1lbDpto3ivR1Xx7oFjXGCGO18xLsfUTheU/Zgjzny7shAG2QeHPlYVOhruwL9QNomwdREubgNO h4AZUBz1srsurOXIB9gqNES2XHgyYZEoE6KX4W5SInE7JAO5NWTvu0kEE4b4mU6onDiCMCOF/BDt gsOUe5wVRrelG9Eqxf2nc1nlvkItFt+FrLCYkZO7bLPfLrIxB8P3QhbWHiK3Y2xgbhIE+2pOkJNw YBUpVoHuWoeBGhSzb3/4vzkLDmvYwuW6rwuJchNI8+9lqYnhByLMufTcZfXtHd7LITRnKMuEEh1g 9/KU0TPD36/se6nnROJtOG3QBB+hs17d/G7GwURxrG/YrRZQnboqrR19NXJlh+W5rfWAyhMvl0Ar QNGAByQaUpdr0FZm8GQNZW5kc3RyZWFtDWVuZG9iag03NzQgMCBvYmoNPDwgDS9UeXBlIC9QYWdl IA0vUGFyZW50IDg5MiAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIgL0Yx IDkxMCAwIFIgL0YzIDg4MCAwIFIgL0Y0IDg4MiAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjM2IDg3 NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA3NzUgMCBSIA0vTWVkaWFC b3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCAN Pj4gDWVuZG9iag03NzUgMCBvYmoNWyANNzc3IDAgUiA4ODQgMCBSIDc3OSAwIFIgDV0NZW5kb2Jq DTc3NiAwIG9iag0zMjcgDWVuZG9iag03NzcgMCBvYmoNPDwgL0xlbmd0aCA3NzYgMCBSIC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCu+YR4fOr8uLx2wj3UQA4MXlV0yCHYZ8HL4tkdjG CSC/9ku9+0My/anWOuRgNpjUuXa1l9C4kuBxB+LQelpIS2AKhrsSVkyO1Ly3CypMT3Gd8B6n8OGA vjzQBs0tyxtO4ozvMCYKPFiCiGf0axXc+/Rn2JvyVV9Z83Gyh8R694PtmUHE76xISpfqmxJ9PvpS 2uohX9xRo2uIGR85PA8Pg4CSTDxngMaSdctWvjkVPUU5Ywe543ebge629yg+fUuE4whTw7NntFP9 0pIqy7UvxMTqxM8sX9Hetlurquaa0akF/fo1Hccv6HzoIaqJUWE/0aaUwwZKgiKnKiprIpoOz7NB T055d36NAvmOv/8FCw+WSgnrwAwFXJjHhM2HIY53XQ+cfv0Jf15TC0KVbfTjMkRx4KMAR0hqB32H sKavFik/G4jrrZoAnA1lbmRzdHJlYW0NZW5kb2JqDTc3OCAwIG9iag05OTYgDWVuZG9iag03Nzkg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NzggMCBSID4+IA1zdHJlYW0N CubFOD5dUFZBZWFLVTb7OM2xDB0l/v1oZwKl7bp/CtpMPuV5in+QY5hBMCOR153QRStR2+ZhvM9k fkWz8Tt4RCs/YaUt3OWExuoMiQfyNFtWSEpTnl+eoeGbj/69n+1x9mrUPa/55VA5q9gu4XQTeTcp JaBP9IXs+OdNUVLLvisq34KelVLTWc7L9SNISVOLHf3eMYIsPHVPACct8jMPawrsD/1L7LqdXgIS h32Nvq6eANMnRrDIKXE5y4ZdBnWs9nNnVkagk4u27m4I8f66cBja1B7YxABgLmAeGYCVKbawQIxB enAb8U40vPYw1+9nHBnlxlcu7OrMcwfsCHM64kgTpsY6rlR6rNkqabtr8C/jgvT+AJauUMH6/19O G8bBhNPucI6cF25UyvM7/O0NmeSJ58jnr2PVOLMFMOKJIuq+S0Sx90Qwnam9A/1NFFghJ+Rl5cGO 2r7dh0ilxOVfZTqwFP5mHNp8wZNxSWa+cNMY3l7BEdij6fPoGh0zXsCEGPD84URCfE3aiMmqFLof M78YXr+0YPRYfriWw0tWpcf3cU/VPbS3yx6khTKtsMAIq6YMVdMiEqojKBxgoFlEgaxgR6qFvIDF 9i7tBqoet7590S6FB/BnpiFK+yAbQnt4xKrZF1hVqE4lqj1uLdjQdpYzz/7BbUYcTQihT/UuSh+8 a6wwo3Dd75vcxV+oRfrHTS0zfT94rbgt408icbFQuu7FCXjAXig3ZwbExO7X0sy+UdgFWSrbSG7k pgj0MphQN7ozGY2UREZ1E4O1F25rU6EBW3P5OEznSg4ahBQbO8C0I8ph2Darl7DqRV2JyTwkx9es HqjBrlvbXZPFBq2reakxPQG7At+hxghGGN7UMMcVp/jKqlEq6udz1aUVayZGrSlK7fhT1I4CADgE uLRBSVNgyPF3wqT0IBzLfL8vjSXtiw0/Z7+piiBvqSONTP6PFuVRjaVpESzSuEX/uNXxtLpn9CUx dlo5MrFCPqfrinLcUTTMZboUNvcrbXf1beP55T8y2bfRZN029ep6Z+WQJ/cKk4DI0ce4LF3Ujqr7 VkNI2/ZR/KymnPkXP5jEeO0J/Vn7RGVeeRM88PNFJ5uCKdz/e6HjRqyHUZo7FXRK46XJD/trP/mL nxOQrbanjys+jU4F0vVkNnVIlworIXtsGtDkorYVe+PTWEYyRU5w5A3pivZKheA2Smc076FqyvOX NzX9+50ncOAmocYJCut/LCeTieDXxppU8KpMWqLZ9VFVOYIK7bBztDxS5nTTvshn+Wijo6fACTQB fH5RHIrhOi+N+34qKP/57QAJMhQbj2lJ+Wbuew1lbmRzdHJlYW0NZW5kb2JqDTc4MCAwIG9iag08 PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkyIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAv RjAgOTA3IDAgUiAvRjEgOTEwIDAgUiAvRjMgODgwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yMzcg ODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDc4MSAwIFIgDS9NZWRp YUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAw IA0+PiANZW5kb2JqDTc4MSAwIG9iag1bIA03ODMgMCBSIDg4NCAwIFIgNzg1IDAgUiANXQ1lbmRv YmoNNzgyIDAgb2JqDTMyNyANZW5kb2JqDTc4MyAwIG9iag08PCAvTGVuZ3RoIDc4MiAwIFIgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KdlLxFsTuxEZwG5AvxTMEncNS5xpaOUisZOim ORNTHDh6TvSIWxxMoV0EmS2dVNtUyLhwIjdhaZQ2TluCIUgmt7TV+TXg93EfLeGoCgD5mdPtpt3k jtFJ1XqhTkDvUSx6Uov9oGb8ivcb3+mDBNw5EnhMNTMSnqwHw9smIWQnrmgQaraMb7H6rWF5Rl6H Gt23AKA62yRoM7Cp97bnAQFGXquT1Dykja8t9XVeY5O8v+zT+3dv5D7n0SH7zczxIJas/oWh+6f+ n5xtDYm4l4/Kgis9blwhSi/dGl9sejificqZMFdKULBw10tf2eUhtvz/QDMKPY26G9C97S1rNMWn 16KHpbsl+vZBBZInIIZhsvUgktZrAl6uAbpqXgje2hu+po1joUFrBxVkvyIL4YfEEM5tAvINHTrW UCftwbWWZT6T79uTYSGsDWVuZHN0cmVhbQ1lbmRvYmoNNzg0IDAgb2JqDTkyNSANZW5kb2JqDTc4 NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc4NCAwIFIgPj4gDXN0cmVh bQ0KFzkJY5LS42fTe02lfehq/D56n4gimClFUkogNZxNxDqDEzAWOyUwZXWGCfehhlwu8592Rbty oW4UVj1/uFkXc2NZj29dI6VeYNyuxFR7fXq3kB3WDWA2JHLDGOt7ouHEb7A9kKTBbyRJBPGtXlmE AZ6DrAjv9hh6C1Gj1RnqovEIP82DQ+yD7EVociIEInyJKW4hgayvd3tnAyk1cjVnaqbWib/HTQ78 9AAKTEUc3bwRFwXdFOenAYSNLPKmlOdc8AwwMUz4yHnhGWu9KVoOrEn0UQ3mo6kUw0CJyn8waqh9 Ox3SguU8C12Vm3KmdcnzLZEb3VmfTwzBCgy14bSva69akZ2UbXlYR6Z3a/wbf+o5Z/U6fNMShAaE IFDmRmif4faapWJBsiHsOkykMIHv8Ti1HM6KfAQkM90SWY3FnZf5cz8nwlAVyRZSTXRvylqw1MH4 Uwjs2KoDmsG2M4qq61x9lvnE6oKr7tZDrNbeMGWHHmYMVSBGfSkHNgGssNoGoYBbVQtqdQhtqQ6o H0/KSfC+ZOEJ7bLkkxtxF6HeA7iLH96GIw3QdTdgXvXDA95IFkU3caDiPvuFwhZsLbaXb4gJrXTw uQzJ7OOuZB0LQOPrCu99OeIhdq+/KjqH+kTDuP267NUrtetIDlQr9RSgCSVF+LpV0If7h408lAbb cN3cIM3ys/1juEq3Z0GxHocYcoPkKcXiTbbJnHMPb/qzuMxJ2Dv1E3l4kQzw8wb40TZLQalV/E1X dph//rGWvO/zZhZ84xXiYPm6IpeSiurMxitHzdLd51liO+lj+fsJfpc/rh02q0PxD0wZbAM0uj4j +Vf2GtnNPhGwkW+AL0rCYvDIomrS7e70nlOVqd8St78IXY7UFsdohOz5l3/vrfdVAwDP4PDvqxsJ jluGVQ9CTaRNKuohcnLcac3GmM7+ZoisGqibCx76B2DTz5ppywTt4y174qC9hqDWVzu09yobruys Cp5+azXC+sYYpjGTZ/4V8PG/rB09LkHOh4AUcgaRYdZ6H821k95xtNmn6C3fiZx4c/JSgMn3sPQ9 zLNoGtKPRoi90HEXlzt88XN4NjdAONb0Yr5si/VkErl8WfNZpJztTlm37kB9y/tiuCLIA/bNawJs oPga90zf/Dr3sxYJw4ppAjQ1h3XkhQ59dq1l+kJlo4Fxgj9670B7F75zg1v3aW31PHrRXq8d0OvD m8Iz8r8gPzEG94IRpxLEag1lbmRzdHJlYW0NZW5kb2JqDTc4NiAwIG9iag08PCANL1R5cGUgL1Bh Z2UgDS9QYXJlbnQgODkyIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAv RjMgODgwIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yMzggODc2IDAgUiA+PiANL1Byb2NTZXQgOTEy IDAgUiA+PiANL0NvbnRlbnRzIDc4NyAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9D cm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc4NyAwIG9iag1b IA03ODkgMCBSIDg4NCAwIFIgNzkxIDAgUiANXQ1lbmRvYmoNNzg4IDAgb2JqDTMyNyANZW5kb2Jq DTc4OSAwIG9iag08PCAvTGVuZ3RoIDc4OCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KO6U7txz7QIG+M58dc2RyS84efEBkfDkwyxFpXgVjLVjzO5ZSF3PSES3Jxy1S/VQZFqNp sIAKj+U6/UAadx1FLAVkh9pekfigapa9xqqzOCuEKndUb5Vly3Omrp1j5vD4zp7OHvG2et5mUXEo OJyqQFpvnmvHt6U5AEF0sTtXiBOHtnouU9u1jFbvNhu2gpw9Doxl7bj323Bk5Dmn6NOF/yS9giAG c/L2N4hqvEP8kjegXjXjl2XvGTQfwPmP8Znms3TSkluTjq5mou+kU32nFSHQW7ESQUKjbxcYl3oH EHvAcbU7zRMweSkp11K/3SXpvM1CXhWif3lbCBth6MrCE11kQkqtrYOYhxIt7PvIXGjgxaNyU1vJ 65gFg3tNMQEoxe0zMkFH5XqNreyhd+6oUmQoQ/gsnVyUCjQf4d5/MbbRRe215rueDWVuZHN0cmVh bQ1lbmRvYmoNNzkwIDAgb2JqDTU1MyANZW5kb2JqDTc5MSAwIG9iag08PCAvRmlsdGVyIC9GbGF0 ZURlY29kZSAvTGVuZ3RoIDc5MCAwIFIgPj4gDXN0cmVhbQ0K3mrX66lZQc+4zf4cbKSar7DDDmKb ZyDpwmbE/jn1SZcu79kNQiUFRD15Dm35bTOPaw69MwxTHD9mgLhWvYrhYAxxdZCG/c+bk+Z0jnUu R+FsPXLETfvRykZAiUK3BSe/ngFYpXrmU7MGwHF/U1gONXBze3J0f6t2wA8TQOKa6XoeuLe5PVo4 al+IHGJHgVWu+vcq2RZk9780oZMk12C2ib9FNXPJjOnXO/HHDVplVd769kCmrKjIKA9d3oCzF+Fp GT/Ms0gBL/Vn1Odt5cUpzDaHl2l1r7NnyX4qm6HIrRt/9Ja++yRwr5yFaIwOIQO4mrJ3D5miM9AA 1j97O4aJzSZ1tyIGg+Tdpd7eHqIvLPouCuHQAlPImFt/Y3ln1WQU3J9oiDTuEuldQQmxIW/xnOvY lEJapt1S5GvgVcZv0E8qkT2LOgEBfYdVgV3xaPZag80y+aJ6DCoTmWpHZz+yBPdbeoDINjkcfsCD aPuY1BqkYbcdvacA3OAxT0izSqxTrFRw3L2IucRV3bPAvBTFVBNkJlNdEvXRifGfuuipDwLT1eQV ccJQJ/T9o16/dfIKR6Rd1ZC9c6XvwBFNwPCaryrpjp6aQf68AKNA5i52QxzFLcJuKhbqS69SDzPy F3OuPlSdQU+rTOJa+RPctrKZ+r3GqdvFN4aXYZDC2ytvdLj6w8qHkkteHwfHmDsGHuStrJe3A7Ue NlmhojRtvurN+arHID63OJHQKg1lbmRzdHJlYW0NZW5kb2JqDTc5MiAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgODkzIDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAg UiAvRjEgOTEwIDAgUiAvRjMgODgwIDAgUiAvRjQgODgyIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0y MzkgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDc5MyAwIFIgDS9N ZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0 ZSAwIA0+PiANZW5kb2JqDTc5MyAwIG9iag1bIA03OTUgMCBSIDg4NCAwIFIgNzk3IDAgUiANXQ1l bmRvYmoNNzk0IDAgb2JqDTMyNyANZW5kb2JqDTc5NSAwIG9iag08PCAvTGVuZ3RoIDc5NCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KEx2+2jgDAkDIWCTd2mP7KLJdZCIXg1rK AbcQZVtzQrttc3/nngQjdHkCx8juNjWhfmEHr/EWMfslCNJo6maiI78gVZyP2wJ6nNk4XHmxQ0LU kKMsOGt73sQUpSNkyF0MRxTLOtavWlf1YN+94qc9lfrsv7/tLi5IhRRukChy0+wdBMmjABKtStyM +snxSykExMPwbhpiwRfTlb7+Jj/i+1MNGRHddf0XShISCBD+dwZNBRlIGbjctTAhYyvqgN+yDTTg KPuhQJQuyUTFfjJxeTMs7asQYssVdh+Aw68sx/mfeSYAZU0E9EHlIGDpjFGMQnm6OAp+guBwbmVi sECzbyVhLFC+Z0hCnLOQoLWTWa98+GXTgQEatAFFWjKScl+RTvlqw37iVe28zf1Z6yxwmdh6sRk/ iMIswVQPxF/MioWBPt/lzh9oDWVuZHN0cmVhbQ1lbmRvYmoNNzk2IDAgb2JqDTY3NiANZW5kb2Jq DTc5NyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc5NiAwIFIgPj4gDXN0 cmVhbQ0Kr4GpC+Br7wd3VaeHAV0VkkBuxXiu6pYcqyU5amMZ9j54Z0ZszImahN39yoni2UDVUjk5 83zCDUkgDdFNSyTIKSm7p8bGK/h/SqVJwXHgSnuPsVewBkPRNbeuFhdOwGAjfkKXk9SgLTLB0sAx 1U+KU9M8Hnxl3vQu0zKl99LUudR17PRzv/AgrGQpXdqFfTfsYkA2EDMQ0eS/t0zDuSAdneIDS3Qf L64uTcGWjmJqn7ZQpOc4EazyNo5k38GwGyhlJEZRHHr0Yb2JyBpw+c36CY3PU8hrx7B7ccaeZKUB YQqVP2fbkP221HDqG5lQ7Fo52+hZ425LDQZGpHueySrppi80cttStgxuRsheJp3TO+8j0r2PakzE CmmDZ/h7kHKZ1SWQe4t+fNt2JJZ+TdIWdezhDeZAAY7r8b6LZZ+hC223PyVdi9l3rnM5fMRqY9eO Dnqiy9+QwRJwDH+Xq/DgdypBONTpCF2vsQTxdtUR1RqzI0n1IZ7yG43bnAY/V1y2Ej1c7Y/s1tvc nFT7pfkgDH42UXqevNgXgoVCbfoZsA0AKZB8uhtftOrINqS7q7LVgR9A+0ln4OkvR7IelNgWLXzp Wq5fEH3fR8ISJpHrKBg59JSrphVOecg8XeF8KIAjPsP0E0uVxxpRnBIFZYu1O7cSJyJbWCzYmQZx 1IE0r7YeA3U6b9L3i5q7ia5+uRuQdkzXcetvwn+ZaXWLXLOb1D0il3kwDX5SWSs4Hs723k+AUUUe lCiCKGam6uHfXGCCw0UttC8gUfqcDBRIZMtwqUCL92JY6zEIs+p1UEAxrU5KpKOYkUPxCu3lMNug wb71adhsmH3HfEa73gi2K3bd3gKhd7OKPOG2/272/PZ7+ieaTitGBtkLwINTrjzv6VEH+CKGHg1l bmRzdHJlYW0NZW5kb2JqDTc5OCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkzIDAg UiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiAvRjQgODgy IDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yNDAgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+ PiANL0NvbnRlbnRzIDc5OSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTc5OSAwIG9iag1bIA04MDEg MCBSIDg4NCAwIFIgODAzIDAgUiANXQ1lbmRvYmoNODAwIDAgb2JqDTMyNyANZW5kb2JqDTgwMSAw IG9iag08PCAvTGVuZ3RoIDgwMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K +wVxPjLwX8VrUM0puSjyuQcukk1GQ5nDkzLGzO9J7QoGDUp15+5GFjpYgXO7il0GsnEZBpCoaxwR 6JBJUntYkEqmmHEdbovSkqcLiVQi5OerX+kPcG9Vs3J3rPhXNMnFtmJujf/f52L0ltk81eeTq9Sy i2aO4yL3durHV/+TZlhAGS7gTkGXw/w2EnGa3yNiKpmdj1qahbNoEbf13WWX2LutEhc+2mF5Tv9g IglBezTLrAni5L8PHIpMpXCa04PMYVZt375XeZVK60/SK1hLivZBkUABdQ+hUOJvE9ALoYRCioZo dnGn76tM0fq7hJO/NOq3c+BptsjzH/MCeQ7erhSsZ4xVNIXwH5+PZjCNAzryeogG5bKukQ4GdKxv GK9mqG0Q6JJGfoxOopCH3eGFpvcytiqGKuhROH8UbRMd2qtfTc8FKpH8DWVuZHN0cmVhbQ1lbmRv YmoNODAyIDAgb2JqDTExMDggDWVuZG9iag04MDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCA4MDIgMCBSID4+IA1zdHJlYW0NCkFfZtAN3G/HS/rX5JVLS54nEknw39ryoVZw B+yi9RrNlxQJrYcdRMkfuoy5ajkmRibGwaWsqLgFCyCejGoixXZG7GEtVQJg7wt0dQXXD50jmb1E 90Rf1sOr8mqcdfEazES0DJcxt9XtIF7ddsFKD1uzHD6Z6RhfJSAzuZCB0vesdh3X3rXBYCfyFavW u+9EEFvzlpSriHrh4+ZZ2PCXUeHZc9BPLDWBuONLTMCvpJe++2JrNAw5JCQbfaOOJF6Z5l6qZM2Z djPrEIZXyQy2priqxpzUBFUqqdnjz6m/CULd7Xdrl9ll3HicwBLXUyeQcrpmOhyr6+QsX4xNfIC/ lSBAguUHUa3vSkAwlV1/V9m5oas3d3lloZNEKGrPZQItY8giEtkOmUUrf2c8Rxq1zpi2B4Z/+oR4 V/r1s3BgKemYd8DLVKb525S6LybouYCBLQY2r2gQa3lWM8NZGN4fuy8F/d+CfXtPMZJ7cXpjeWiY J5pUFirBGeMyERy4YYiKQm/Of22xQZporMI3em96I1rCMA6P4NDmLqF+mUWLcYKvwzNWJB4FWM3n OgyFx1hUBb53pEy3f7N9JFkOElCjaYmxzAxTWryIFh4tb1JpFRbd4aHmBN1EaDNGCWiIJEDuLHjX +H7rMaDO+vjrq4TGO5O863VcTreffV4ohPQJ2R3OeRGXnpSguiSmNxgNv+JMJtq/9iqRs3vaBRXv 0Fb+jqds+didkziO1COiEuiXEjzMXWwCuNWYnU5SJB9sRc7e3rlbeevzwVoa3mkP4/lz9AG0YLWO 7FhJ/OwBY/Pb1c35hSrfJGpjWfp3N2iyB2WYhktM7WjvjaoynLPk5fxCs0haehhuE/9zyaVVvyKb fQfAe4Mp3Zgwh1iK9D3Y1oQvA0fsM8x9FnAAX32r2Up8DOH8HDYnvGxdTPH2dC63ByCoGACXxGEF XP+nbAcgkMtKvKeP5fL06yYVKuDYTAxdvdCz1IvEvLbN+RxOp3qv5DlTdpcBTJBr0zOZ42D8zXkB 2yPZ6Yir6Mp3nYN2yQDCk9sMfTMjsN/RHijDGHMwlKrDlJSD5RG4fexlYoAAtYVQSrbWLFD8E/M2 QDPAabWPeDNkX5hme3TzGvTmRv4VrB5NkiHhW0hnSVffKH9myQh0CSQA8cqFTbQ50t9HJe5yZ5b1 peiAYSWnk2Lb529Nu9VTNjqtaNWcmYw8tycAmm5WvRADcPahMFU6hmfFuAQjeaIisYosMA393lpw dFvKPuNnNomTYFKCcwJERPgC+a7sUl89d4gLWw/3j/AzyYFlifXUdNaPmImT7pp0NJFGu6BcdeUs TUrTaeaB/4jY6DLxVcUESt1k7sPKx1hCaaiv+HQ880Ni3uZyE20cEfLom10yJp3ZAYlr9CD5qiQS 0E7Vks1FFvp0mPply15r07ZjRKjFl4emLnb1DKvNEMMJpVQ8rs4cpOBJ2i3vM1PyjkFmjMpVq9QN ZW5kc3RyZWFtDWVuZG9iag04MDQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg5MyAw IFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIgL0YxIDkxMCAwIFIgL0YzIDg4 MCAwIFIgL0Y0IDg4MiAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjQxIDg3NiAwIFIgPj4gDS9Qcm9j U2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA4MDUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04MDUg MCBvYmoNWyANODA3IDAgUiA4ODQgMCBSIDgwOSAwIFIgDV0NZW5kb2JqDTgwNiAwIG9iag0zMjcg DWVuZG9iag04MDcgMCBvYmoNPDwgL0xlbmd0aCA4MDYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+IA1zdHJlYW0NCrCJnYNHtvOhp/xo6on16yWQlsEOsT6PLNrY+cCcYo9heUb5yZ31UKJEe0/r tvSeG34bIR884FEp5OBWciIsQf2/npZpF6iy2DlkKw+DiDRqlsNykru446V2NFkmRAvfaUZ7FoPl mBVMiIsSw6XZEAHeMf9Y/eA4Cite5XnI5mo42ofy1pP7d5jkcWgWNXls6G54oLxu7Pjw0YqaWGhd uamlG4j9QVwqxVTcwe1oaZG83U7Dngu8q5S/AjmL6YD99ZumxdR/5dvVMVexlUG2THETFgHBJ0cY lqh1wG896PNnTioa5CEc+kY1H5xw2HwQriaH2DTin7STwyu6Y0OJBXdqmaXZCbN54hlFgyHQmNoI kEw+h9B3WjjR4lj2v8r/TFk0S1gPQcaYSuCNojHP/TyoAPLVcknS4bsBM8ClXVaQToS7JGexvA1l bmRzdHJlYW0NZW5kb2JqDTgwOCAwIG9iag03NDAgDWVuZG9iag04MDkgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4MDggMCBSID4+IA1zdHJlYW0NCrbZ+5rqp2r7VYJtbaCS wi4RIQUh3i1X/SOpffzb/90oc21vLiQ2XsI64b/BNtnmsnmfsQYS0LCPZSgH4BkcfecQA02bQ8cw dLWckOPgvYffVdUvD5IBxt3634YTau1SxjoFxXrYpkTKeRTpZolBpPViMQ4MCg/DuotiyG8T+eXf piYXSyFRnzU6cRjGMIHWHA3k7Rmdz2k0c+MYiPmFU2orM532QvWeXPezKzaryh1nJbMsOUzm90n+ hrQ01cXtFlardSmGeeT4WMHz+SM2Ms/YxHYoYllI6+E7WtL7suiyXcUnOvF+6zB9mB6hzjWR2rxk bm0KksSa0fPAiMIxX0nntdiIbc1z2gX+8lmpnFxuWuUDk2sJikl9QJNie+pwiYfQv1jumSFnnjU5 h0kJbesArejcMY3IWuRt4EHtmnRyn+DqZ+vdmosfnd6XfxTc5s8nhR0Xs2K2vzRo0PssD+qgVT+M xpGJH7C7XVf/0QRTsiejLg13IQAOa8oLaPlmByyqQYLayI97Eu/0Kb44pbKu7BgoNb6eIftv3GI/ arGbQfLaMhqHlklLT7CYhKdx/wi3GJ4jbi8GZEHb7BFcT0H8quh6b0crSkXUUnzJetz/nmaXpPFC OYoHM4jKEHl8zvXxB3SzQ7fV3cNOEEOEXYh43OfwO/NriQGtuSe4PhJ7KCnxdh4HiFNAKVrG0KRP 8GAHUdTJgegYh+JwjzfsT/B0U2Iwm/T5aA5/+oXsJZzLQ+hbsAcPDV+Wh01DUtvxjUCSBx6dnAmt 97smo38Tmc5N6kmZnzBLkQ/d2+rqB65o+BmDoDpOe4vd5Lc4ZR0I2sR1lxA5MyP1GMgkkfnXNUeC Ur80mSUC57YSAK3gDznl613qglHfPkdzmFc7gKW98eIium39VkA6DVu7TZLTW8njkBAuc+WzT5HP fJq4RDsN8s0nZfwjpBiCWUf/z8BgwBqMETwyNP6pYFYPr7DuzvPA1utUDWVuZHN0cmVhbQ1lbmRv YmoNODEwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4OTMgMCBSIA0vUmVzb3VyY2Vz IDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMSA5MTAgMCBSIC9GMyA4ODAgMCBSID4+IC9YT2Jq ZWN0IDw8IC9pbTI0MiA4NzYgMCBSID4+IA0vUHJvY1NldCA5MTIgMCBSID4+IA0vQ29udGVudHMg ODExIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNODExIDAgb2JqDVsgDTgxMyAwIFIgODg0IDAgUiA4 MTUgMCBSIA1dDWVuZG9iag04MTIgMCBvYmoNMzI3IA1lbmRvYmoNODEzIDAgb2JqDTw8IC9MZW5n dGggODEyIDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQooAI/a8i+hjBpSDvy8 pKdgWGIyQj5SK+Kaw7Kt2lmgbMMAbcS18Y8cQkgSSxyOMWzhnKDHY4b4gVMW1+a0hlUho0NW+Tkr AWnedOHUDWfs2jTYba4ZosFTann/9SBgf/lhhKcwzVthmE0KL21sh/wL6DoTWzKG00r57XUMh7Ty UKAQdjX8FSc0VVWlDKutkZJbkwF5v7rd0Nkza3jyeF9kvdiGHMxIxeYKXqE99Ch7NHGYa4kSr/Da 9qT1Fpgoe2CYBI+V9uLBhI79iW1JzSon9+MxKEzFd3eOxzl2wcSlwBDBBLmZDif/6B/G2xAEdXd6 Pv8ZXGspkwSnaka6c83d723QwruBuvEWWBaD4wcoxDRylsQLHE7TJ/HDrEulgqaX0Lt/xY6PkL3C J8xv2Uwo/CYySzhwCBPejH7+CrhsbheVmpFEhXkNZW5kc3RyZWFtDWVuZG9iag04MTQgMCBvYmoN MTE3NyANZW5kb2JqDTgxNSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDgx NCAwIFIgPj4gDXN0cmVhbQ0Kv4vUXyLtvpLvSEKnjHKuZ+qJdU30HXvWyzkWFOlpJfOC4z41Oirt JB2jYmiLA7CtHC2Yqv4vWrSTABiREOxBQxIS8wuRAT1r5MIWM6PyexXZw41cYqN/OnVRsRGdB4Ov 6eLKILyvKwhgIuZ8bzobbZhq/k6SzqqIvgRE66+LWljNju56ISWpsPF0bpqt7xTgPxRqiQpC+k87 UEx/xF9nLjEM2st7KSTHMBq/6fRUose9XwnW2jSlKW+iqa/YB9bFdqwkgriY4vk03m4ixdThDfqg F4xPNAq7t7mpU9qZmmxuSKlL5EFYtjlP7vG1zTMkr5FhrELjmkaoFDSjw+K5cPTJ1tlxNb56HGFP KcSDBMVoA1ISI9QgxRFJos5XebsHKGBdXuAhhnAHFz/TpsivSsJIGUFs/HQ80MWV1BTUODwOjpQG Ta5ZNwnwullA5rnfOHyo6Ly9d9pY4RKNeFFw7ZvhTW3rWsr8muluOmBv17max2tZjx/ziKWzvct8 Ltzv0pDq/ecPhozZFlVrY0gDgg8MC6CIlW0QW0lnN+YhHmLmX7xfhzoZYPt91UUZmjXe9SwNCdB0 UkueuKfTUivB9lWCJLk1ojdzVrvxyxG4QHLkBsekT/prVd4y0OtvhVvME6k7zzLn7W36LXZqLYFE veDXXp0JQOBzT8sI2CHcTTNoTEgnb+Wl+AvZj+f23i4YLLCLODYRQgppoGaqHY9MNd2hxMrvqyvw 0hebShJChYJe4ABugNsnMUFExkoIVQqxoKpJMzRJdVoiF9PiDTche2nSrKY1BrAE0dlfv2AEd/0e hJ3g/QNQpktdL/QVcLZ53wPmJ+kwWNwtg7pymKRaaq6ArN6skShMInETf9a5pSuuZfoifjqWbjCD AoCgckSvLVk5835Ew72DsBXHjQRpCuOzGTsT/0XDDwxBBSDRqjqNWdIYu4m2sRliq8ET++He01zv I9PWpCXuOci69NQF9XL8RQ92rK9I3OzrCkRNsnlFYeRwqW/xrrsyIZ9vnQYeZtSTv3f3Ysz5Aj8v Dex+uWsxJbFmMokyTQ0Hw0LRFb3hE6VDjYwoif9JoCRrSqqxWiDk6DLR44EY/OisgafEwWiCQY3h Z77YU9u9FPjnPm3J72lAb2aWxkDDsZ2sa8KlJmXoTPA6Tf0Qfp2gdt5E6louSQekMTXfkHYX9/Xp +vmR7+ummEOAskrM7EmWDgVUjQJHxmpRmAboesh0o3g+ZDOQmXdJ9q149SAc4pFxRtLlaiBJiVNo wvGm5qxFOBoFb4w9vpx6xD+EaQY1AF1srRXdkSC+MwIdDYGwXhUjBs3iesT0+k+kK16hP3P56TNy DJzDB3fNBYpbTUDuwSa6QtuenQPCC5HPrzslnrhyKcKHc6tgFW9iN2LYTWmvLQLU7P+I+ip8fI/y eL6MIDRtZEOXBKgbGqfMyMuCYjIhm1O6bIzXLFtl/YcSqymP+Qq2VCXQbJ3okYbP8P8QTBUhPc7R j9+GHYxd7rs2VqAPzuanHQISdby5tPYNp03xK8pMc/qOVdfTEw1aTLI5QyDEXqDPx5kKVjxzjg1l bmRzdHJlYW0NZW5kb2JqDTgxNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODkzIDAg UiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjMgODgwIDAgUiAvRjQgODgy IDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yNDMgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+ PiANL0NvbnRlbnRzIDgxNyAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTgxNyAwIG9iag1bIA04MTkg MCBSIDg4NCAwIFIgODIxIDAgUiANXQ1lbmRvYmoNODE4IDAgb2JqDTMyNyANZW5kb2JqDTgxOSAw IG9iag08PCAvTGVuZ3RoIDgxOCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K vaQqa9slUC2jDs6zctdpSKkFpcJ2egoMhsdfQNfIhdJ7ak2e38Otg8dypEn4+6vYxD8ZvGYaFZLr pKE8TRTVo7zyW2arCpcQ3Jc34UpLQp3s825ZAQVf9oswAfEe7hFq18LucluZ2EInEWSvCxpcBrqL XawFGxrUV+hoejpJikaEH6HBnP+luw6eFknMQR06F0D1w0RHdJif3bMpQYhSZeV/5k8npiaKmyPd qMOliHRVU1H2nF0maa7PSVZ11XxBoSanf0D42vpdgcxks8hexJ/zaWSNzk3IQBNN5KWMNeFLlH65 jxtqh2TyJEWxAQsZc5Kt2wW8WZ6UuDD9SyO+i4716RjvpebbIg1NCCmjRs2YOBBfuS41Uy9wP+ra sywhhlmF1Bd4DqlA4bS5E6Xy6vOSWD/RVWYFYsrjHdMEEqsmQQK2ltclDWVuZHN0cmVhbQ1lbmRv YmoNODIwIDAgb2JqDTg0OSANZW5kb2JqDTgyMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDgyMCAwIFIgPj4gDXN0cmVhbQ0KO1Vje4YewPApQSp04pW9zlwKCx5Im61t/da0 nmHY0lDUrSh5+yVnZ2H7HIggc0Wa6xd58LtwUB4PGlTMesroksnGyPXUEduxPfnfj/iPGdqYybGJ rseX3zr5ceEge7L8hBD9p92pm4AW+PS1B1n7Whvxf3TmkAYLBlTc9Bv8vr6ELm1uoZPL5SLPRSji ke48WgEWXzS8u6jxFKVOEhRSejlrGDGVYwPFw2rb8Hv6hHeKOdAjItSl3sy4J/jGILDzNdz8z9OI f/oN0AZV+O1o8BmJZuh7Jm7xDzc+D6wH4I2JBqZ0WXs75MLNWdzWXf/8PUP69+/1k6ICXCIpPatd LCJ60exBaDwbzsZIa1OnSiVgnFjY/wl/LtX8dgg1aAn9MYCtT3TfNISrjqJyV5d/eBBqM3Tt1Lv1 XvXqlyHYYkkUYHXTr1sS76TuwjxqW6qHGCkgaBOo0BBwnXdK2I2X4Xm9mkJUgmQEhxKC4yoTHl1r jTZJaPuvJcK+Cu9Ub7m2gE3RwJrFaP6Fnvi7TFLDetdF0FM/5A3BxY+gtylBFwmsgyk/DnezjBVE rybHRIZKKmneb4RxqhftMYXBGfVvcpaXR/O9j97wJq/gu3Qfu1olRdkWxRE29tfoGN8aUq64FEhJ SQiJc7aXgkQ1Cg2y7+lP+j+lq9voUBipefOMWHCwKoEI/Oc/78hUwth848XFVHxC85wTaO6bOBwf hAbT02rNo/7YZI3CLTwSyBE4dXzaB3L7MoCREMVp0MKBWHavb6HnOyrNy5pulSIdm6cA/V8V20XZ 1PIlhvLfiircm/2Hpbbedpodle7sTndUORNaS42dyxUnk54HVB4ftLWQJ3JO+UVD40ONvkqN1ORj AGs333Eux74sfSwpxIN3YK0WzVc9FaxVrT1/BbGTtOt2xbSqM2odzDSjP/yeicOPTl+d/WmwK7XM Uv5Hsy5q6tbOAa+0K9OhPmbEKZkyo4EDcgqXn6TAo/HB8bzyPo9D74nTLg5K7b/EIw0SFfsNoiq0 qzd1X/o0p1inl35ifts5QVjZF+j40Kn0ew5bYK6hmp0woQpdnOrroO6QV021kJtVt4cwfpGSOXqS PA1VdXYqSk8i6BGnRRiyVYT7BcTB1K6IDWVuZHN0cmVhbQ1lbmRvYmoNODIyIDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCA4OTMgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5 MDcgMCBSIC9GMyA4ODAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTI0NCA4NzYgMCBSID4+IA0vUHJv Y1NldCA5MTIgMCBSID4+IA0vQ29udGVudHMgODIzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4 NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNODIz IDAgb2JqDVsgDTgyNSAwIFIgODg0IDAgUiA4MjcgMCBSIA1dDWVuZG9iag04MjQgMCBvYmoNMzI2 IA1lbmRvYmoNODI1IDAgb2JqDTw8IC9MZW5ndGggODI0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29k ZSA+PiANc3RyZWFtDQrsdzrk46Z/ee3GH6sWYHlzH1aJy9ZaEmLHl5SdgoBixdCuYOjLdZhHc3iV Bj3xz9Jwuj2jaAcUDq38hW1FEAE6IUHVHHSEqg+jCLF95/+d2MNVNFTnS7KkhOa/24fRNgozibiA IdvDYvDzDWKY7ZR2ucduVCS8qdeh2Su9YMpg7lGNO6PsU9t/hiYvAIbf99vZL/DcLEIOtlhv8SmI pzAfg7Mk/lM4wog/MkltnJEj+eML4ZcbTWCmPt+C5CspHyMkOhuP2Q/RwrBynfO2ImLYFnD1WHlF XLweFZdV4hBrlyfnMJaLpFN2AI9/OK5Uq+trzNXKyQtiYK4Ve+ocMTZYOk2Jx2QGqumpJYmY8n99 SUFE20ZDxzOPFRB3KfdaAksmbQBezkIMvK82AZ3KkqYnDJdciDKR7BNwwZ43efM2dglwhQymwQ1l bmRzdHJlYW0NZW5kb2JqDTgyNiAwIG9iag05MzcgDWVuZG9iag04MjcgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4MjYgMCBSID4+IA1zdHJlYW0NCg9ESF8VpGchXnzSNIsC 71obUagaQEKMcqN3dZU1Y6MMnAT9pO42hvU2NZ6altAlGoRkT4aDLM4tDK6u8yBk24bUP/t8U/VK SwPZy0s71A4BJSw5UKaDnlkQc4PeSFs7vpnz6NABQPp8sll7GL5dENb5FHFo1s35g7ZqGFV79Ssf cCHNJ0fVKnSnSaiGu0C3Wl7H2x5I+Jqe2M757fO0Z78zyGIjsjVsRhbM9OOZ78YcFzH0w2JNfW/s TUb4FFSsrAXyKRuGEWbjBFJI1rmKS6ipthpjNvdwqlMqkLSofVdDWBG4a6HhvnR9eG6E3Es/Kk2a AVSZUJ8Pzakrwlx1zw2gB3YHKPZo54FB0LKjP7LUdOyIq1LEwKqQ0E/K2cKZCpAcGdzACgpY1S8i JQ9vPYr07OdqRO24KjFd8LvAZQ45Qar4YX+CYPI5TPp1NpUEbjroL0lj+8R7R2AhBhxYLurNkUaS Uo/ysC82lSntiMhlWushgmu4ZzBMtt2NOkhWSpcWNtOAhZ3ObD2zeFq/4PI5y+D8T6uFMkMWsfg9 9M0kbHhPxuGLioEIht1hoOGWC4ftb9fg8tmy8knLPhv4D33Rq90MT0aDqllkSiaxNCJZ1J5izAH0 /Jswa8uf2pEfJARKuw91/b2rrLmJT80zSw5RCJ+Kd8R81HBEOTwKSkhmax6AMuz3TSGYnFMjtTSI lCeXBxMY2zGxkaHjEykB/76TPAQmKX8acmm+6tOK+BToA+S3aw+X4BsSlD7gtOJ17bD+qtiBxZ9S Cyg5tOPqjlMUgFFaNpvNCxe46861zMtk1yODHL0KDNWbQcJkGVGNb6AtUy/+8EHtAkKwQSI7Tduf iruL2dko7+8RArvOE5TnLvRwTs4eLiFg7wbQpS9gmGcBlIXSLqr+STqoqQn+NFOAkaGNt0HopBra ASgc2KlJVkFL8W7KMy9+ySme5tBPLVbaEkH2+fd1InM2JpKjxtkAr+MbzQStbSjeBV3zPtFdvKJM 6c+PFQhAL8iSNitMDyimvjHVPyJt6PBr9WiTQfMvqxPek08Z8u1TFWSLP+WmamtkXtyuSJ7ZFn+b HJnSKpHVyXA9Zq31Ff4CQvcz7064UAw+O4FZb7bQ84bST5evhqnAkDzCEAl4Mj0o2zGPj9ZFgniN XGPfiRgdX90vg/NgZYBDBUvdn1ha9RyBO+ghrit3x2OzOe0s7rk3CqnmTX/+GFGcEFhO3Uo15PDS 7ne+dOUUkmtcAswNZW5kc3RyZWFtDWVuZG9iag04MjggMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0v UGFyZW50IDg5NCAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIgPj4gL1hP YmplY3QgPDwgL2ltMjQ1IDg3NiAwIFIgPj4gL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRz IDgyOSAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4 NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTgyOSAwIG9iag1bIA04MzEgMCBSIDg4NCAwIFIg ODMzIDAgUiANXQ1lbmRvYmoNODMwIDAgb2JqDTMyNiANZW5kb2JqDTgzMSAwIG9iag08PCAvTGVu Z3RoIDgzMCAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0Kr0Zq+rptdt28nqd0 7pbSQNksio4QAtRH6iUgqPjgMK8Y6XE0NdVUgbBQCICWjoZD8zzXqzNomL0A4Z0I6IjGO0bR/OhE kNE3Y99zUv92sncoJ1mmzqpYJWJR0Srj18UeseupW33VUymuLzZqDAiApm7yjPLnQHS5B9mO3UxF fpeop0Tu0K6wPxI7bXmjVKcf4NbrD/QO3E7/v4pvC6ndrA6/awXo3nzn2FYH9LJI6/oXYrl9wjKK Lq7zOKXADA/hWlILHiIMCA09fR9OlqxvXLg8KhAZ35MSsNWHKg7R1toUmUtekgSmNsccwGYlfiqC EAWfKjWH+a3SFrGG+GqsLr03AUkvVIHrkB/3cs4P9rm0vC2AlLPaXe9gQASO+Rjq82/2Vgvymv3r dnr5gq1MSwGfLJJFsIVdMCC5jYIYLIs3aOcxiaINZW5kc3RyZWFtDWVuZG9iag04MzIgMCBvYmoN NTE4IA1lbmRvYmoNODMzIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODMy IDAgUiA+PiANc3RyZWFtDQr498qiyqpBxUbl/m5CeRzJkCdLBqAKyiWnobdtj4n4X4go99inE5Kt TAbu7IzNHjhY6jWN3+P7g/vucomra47TNqiYWQCDtHBBVg5YqU9SvrJBkFOJWvKXwzkus1C3L/HI U34URYzi6kZ8BfAkydaH596oaUlXqWkMl0RoTwOIL+BV/KeeB1DM3YZWZhtBRMyY6MtgtelMDsJM MvrlhgLC4REIBkqXxGpFmqgQB1fDxGQkHI7hsiUOLJn+B4nntPRyEjvpq9uFUTNxand48LLupV7G lg1gsplqS6N/WhQMvnpHmqMIJYov/QZNxJgyiZ8ga93z4NtPArTALDwCrBmP12oLD9r1JWKRQGUu 20RQYRwb+HwxpGqc4l/95HU22JBuhWUJp7Z6og2I7Bjpufa7AiPSI6Tz28dohUCz3UgbV6TzcipI xxooluyj5FwCKKvFA15X3WnVlF1nImvPMs9JlF4QGrip/CgV50NVgkdoIUjJMlrYLxDZ4QzxdvLj tIM2YE96LmyWYDDKMpzmPcYK8IeOreHb+M9pFukpuOQwd+T91ejlH4C6aU+eOu7DWbZfnL179m5f oqAz6yr1hn/VnNTQmYSJuu6LAgDTQ3rII87soyU29NGXsm+cul2ujpP5S0m4gpeOOQISgzN8j/4A 87jTr5ecy6KIPdpeOM7DKwrDUajhog1lbmRzdHJlYW0NZW5kb2JqDTgzNCAwIG9iag08PCANL1R5 cGUgL1BhZ2UgDS9QYXJlbnQgODk0IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3 IDAgUiAvRjEgOTEwIDAgUiAvRjMgODgwIDAgUiAvRjQgODgyIDAgUiA+PiAvWE9iamVjdCA8PCAv aW0yNDYgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDgzNSAwIFIg DS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1Jv dGF0ZSAwIA0+PiANZW5kb2JqDTgzNSAwIG9iag1bIA04MzcgMCBSIDg4NCAwIFIgODM5IDAgUiAN XQ1lbmRvYmoNODM2IDAgb2JqDTMyNiANZW5kb2JqDTgzNyAwIG9iag08PCAvTGVuZ3RoIDgzNiAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KDDp29MDvZruPHaDTD5BFZbV15xoJ F07i2rpz6ziSWcm6pwCr8SXvTl8/pcOXl3jyGhS4JHqYyr4Vx5BLfs2o/A92W+i+XvgFXbnx7Lwm FGAKZdQ8sGsXxde5vj/bzn4DyD4rzRF0U3LKG1OLgrR9UlDfOW0s2K81T+TJ32+m6oTWTIEzRAC8 5B6HVa2bMjG1cyUw3ta22/xRvOQ9g+6Eb+r56m/D2jncBt/i7ou34xWneb9pDCqYCGg6diS9rvcN ku3Pr77mb8zqXlM8aYhUPajAjgSI4QC7WPJdOTOcyIy0HGajASw3OxAj4lcokLxieMeW4+v28s5v E3q8etzTqIklzJU/2cqtdL+TiMxqOLL/bTERxohK4NF7XYUBWZKaP0BpRM2y97VUpAeU14Dcbtwu 2FCZVsy8yQOhWkW4vcAWjRXGNG4NZW5kc3RyZWFtDWVuZG9iag04MzggMCBvYmoNMTQ5OCANZW5k b2JqDTgzOSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDgzOCAwIFIgPj4g DXN0cmVhbQ0Kj2S2EIP6N65bMeuyVDadhr4JdCDXfcVAWRcOLV4Uy0MAPrOaOcnP6Bpmzqfqc90S qWFqcwd6UHRIot43JIpMTitE9ZAwtziUMEynueAKOLKKoT7AYnavQVcwycSN1/tRh3RRENWmUR0a GRTb95gyUdQH0fuxyxf7LMsTg3NCzCNag4EFE3L2JPT3lA09x9IgouRfRyCTf9HZlKJl0BL/eJwY f/ZGUmUbL3c5y65W4SqnMXuzQoXSJFvtYZSLYAQmHDuvYNfpxlWjgZaG8rHM0BM6NIwyIi1afrco V9rAelZ/50MDLaJInm7PMPqE9YgYZPSBCp+KTeEGAknQobS9aYroUP+uP7XOVb4bt8Tbn92UXdMP LT38sOCkkS3LFsRaRDB4gtguz7+H/bDX7f91HZluQESKaIWdWuVfJxjtM3pVGOeCNdOvoWVYz6uI abB7lVdrZXFbnPoqkkziVAy9ov15wNHiSzGA5cBv1zKGS70vJG6HhiRSIxX94RVhN83a6O3wuIgg VDwxPx8il3P2TwkHr89A+PZxTZ5PVMDQ8drjYNZ1wFXGfokv8ts3veMDLmd+cwsoKjpvaWuHOe8G QkU0hgtM6/ON7pOWxXSdP1AvlyqeipPFB9Xi6VMqckEAGAKDN6F3fIh37WCwEQbuI0IOs8nvkfOH sG+alzGzP3MesrOsH3Zhvzub/YtD3DtUyeJt1SPW0W1qTvd/6t8eu2msb6L2Ab7FBy+ZWTp+8es+ pAv7KgG6O30CvrzuArrR80+6vEn7FQRIT7jfYrUf4w+w4460o6kBz3CB+SgJBzBeR4imx+g+6JuC ITaz1VRmwyG3Rv+ujwLS29GfAR/BH6lIpMGdtyKT4+9NpKsRAolwnI+pshiMfpNfobdmGTwPz9k8 sy1zlAnaH2gsw7+F2nhPmPb/6IZQoUJDNb60oouXxYvLmuy/z4P8IRJ0YjNkjd9jmVP0tJ87dIWZ 1s9ogosvt7U5HPvcPD2hCBmK06NsZVn5T4W+Yk+lxcRGcrqvoY38e6aYFzHu1/wwOGg+1JKAxFCU GOUVsqFKEsLu3vKn01/LjF4c73PFihoLsLGQWG9I3bxSYnAkMpU0TRl4wSbPRKLPAN9YVcEw1jTg MrzbvJdeczBVMgnzdPztuzFRqeFoogvIj+BaNLcosFYwx8d5ZWpPHIv9iqobQXkgP3nlVyvxOpiS N7P7rWy4tblZX0Lmg4YVIvBvLtfOSFgOCKi3gDlkTmcMI23Tub3CtVlhFlJc+FAdm9Ii6h/PFqp6 wPf5qPARpLbB3NaFLilRHu3WKFAc9MIgls2vgvQ56UAE6tgISAX7pU8z1ZR6IktrpzEOoREoALII cwnJd/V49wixvE9tqEAkN9u+HHyZ75V2R2HZNkIWRNqpvfOOxu/hKQeq0HBRypDcK5YrMBYcW1ZN flDJxChXN+CYgw60EjuFs7CZPJtWp2eYR5Ucx6qIJwD1uHSrQcRO8S9dTuJ06omd58PetUI1BLLU xnNgt64hzXrY6XxCIfe+13lx4OD/h/C5a4X/FIq/vO5krJjT2OVP6AJmme8Mb70kx35PdsIoGjJO K4VCXh1YjbJUtf69AwpBcr1PIG2qq8F+hPi6yqDQNUquAOQMXrgOm+l9l9J8oIkyq9GgX/DFY5MG NdZedzMkBuHJ8G6Bft+M8za4xL02OWFkeHDR1N7YiaKEuIVOAeNFZLjAfRhZ5jWowHsJGsffidqo ahluppBBMc4VYi5ECo0UMneCumoBHP8cT+JMUmBPxSeF1BlBIUNySpFuf3ll69My2KPuVm64oYOf +UNiZ4SpzzX7MItFNGwh/w8lz8R/Sm4OdaClRmAUtLv+R9J9bZheT4d0wVAbJ0HRcOKpE+m4RSLB tLBSbfNqWYOSprUlDdN/KIINUM6czP8LcXftFSYcUsG49r/gwTiN2weg/+eJv8EugVQvhaLJDe0Y +lnjf/1qoefvufWWqprzUtwQ4UDJxcb0Hw1lbmRzdHJlYW0NZW5kb2JqDTg0MCAwIG9iag08PCAN L1R5cGUgL1BhZ2UgDS9QYXJlbnQgODk0IDAgUiANL1Jlc291cmNlcyA8PCAvRm9udCA8PCAvRjAg OTA3IDAgUiAvRjMgODgwIDAgUiAvRjQgODgyIDAgUiA+PiAvWE9iamVjdCA8PCAvaW0yNDcgODc2 IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDg0MSAwIFIgDS9NZWRpYUJv eCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+ PiANZW5kb2JqDTg0MSAwIG9iag1bIA04NDMgMCBSIDg4NCAwIFIgODQ1IDAgUiANXQ1lbmRvYmoN ODQyIDAgb2JqDTMyNiANZW5kb2JqDTg0MyAwIG9iag08PCAvTGVuZ3RoIDg0MiAwIFIgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KZGCODRdCuMe8Xr27XTkTWaDTKQoZ1+IEkS7mdmfh Joq3dolhyG9xzmdpgz2jRwit8fdL/llfWExttvz8+89sHV37Iokpu4i4Bygtk3vrtj03NJl2UMjI BPRNDkANPiu2BdYdljJ5JFuZzR2Zg6hvfF3H3FCgh9cRjHxYyCIHayVGzdjsKlpERm2Qp+D9D8xq 0taH9Z040A+Bb0gZ4YdH0JpeIoAzdNMnoBLCndpwlJqVN+7I6mnLIv/iLy02rP2FhUpMQ4KM2/ud ANFBL7oggbqvWUha7bNghvcaXHcmFGpwNjbn9aveKdNu+fecfASq1ewUfETYptXSjnR4f30sykPv 1zEuYFfKRQwRmTCvoR2sJ3GNRRrZXfK5PoAytI2ufh2K+Tjs98qtTucdp/sQWSHfBOKqih5Oae+7 jPco2Hlhf4SKlZYNZW5kc3RyZWFtDWVuZG9iag04NDQgMCBvYmoNODM0IA1lbmRvYmoNODQ1IDAg b2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODQ0IDAgUiA+PiANc3RyZWFtDQpG QP818uxhwhrv/3Ak0v9bPRKALxAxruLZk/99VBBBmN6slINFaQUrd0/MpUIZHp7gT7CyOFCJ5kNT xaYpsGDntqkSuLy0R/v+2QsOQ5oD46GwKSAwJyxuT7k229sZj02nzq02F7vNIXVOlz0KmaIxfVvK edprVQyvqA1BcPyDPbw4vcIaVVdSIwRSISjBYxDREqDeSlHSAwIj+TUd3wFJGGtCKqhs1FjT4P0q +zG4PixMF2L2+uGiRpyPfp/05gjbtZXaZibCBHMqNnM2sZgoyAiDdLlcxHIKvJcd7bnoRmhqIBrp jWVW5LVvY9PwfJjAnHLR8LiNb7ElRNxczNhpsIYP+g8LNpkpwtKyjQxhsqVMnXJMH+3NRwKMGrYJ fqM8/fNxbwtoNlyLxgRZ/1lywN2b1DfYQ+/U4vdlmpHvBKsyntlPHf0PupBLMiCPaKDbTlE0AWEU Xx5NH9yyncrG5CA91dQjCLr60ATWntSf6iIsPI4l05arwNbDRHbB05K3ryDldMhbvmRWTgfUdu5u 9p7pBmhwzs+dof8gnFLPL5U6opwWMzccTFpv8QYuXTzIHg8lLWdX7reei9d7Zo11aNxyrWqfi3nr yCmqWJNUIjxRj3ADlWqp2ftiMk7roY8w+aGgbA5HHEtWl3SuKRmw/8IgICLA4fC33eRZx3kXcKD0 d78pC/SqBEZBx0a4TJsukvmRjGjInffVstYpuqoohn2tXFdIKnns/nj+K80OQrA6vIKoJIUBclSW k+hGtYj3wNd1J32RWlYXcoaK89ea5Guq1Hmig2dnn0guPIQ6DZ/2MS3NDNPOapT/x2mbOdVci5SU 9tLf36MD0KQZE8qDEXL90yLjZu/D/jKCVEudZuk7mih4BV77hQEXEVbolSD4E9xa3DmHKwPCerA4 7nLaqb62XW7NQXkXn2XMNw6j3tWUduUZDeliYTPMmD9Ouf5iZtFsW4qQalBjMnUrxzg7TyzG2297 0uDXVmWngpv01B7SOVwnY2C9VqA/zPxhp1V47zBWFQ7owG4KkVpQhi6ZdyXzJuned6MHfnpgbwr5 GXAzhdVlR/SQgryy8JprSIiv0eB9fXCCE6MJML3Am4Y48tMNZW5kc3RyZWFtDWVuZG9iag04NDYg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDg5NCAwIFIgDS9SZXNvdXJjZXMgPDwgL0Zv bnQgPDwgL0YwIDkwNyAwIFIgL0YzIDg4MCAwIFIgL0Y0IDg4MiAwIFIgPj4gL1hPYmplY3QgPDwg L2ltMjQ4IDg3NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAwIFIgPj4gDS9Db250ZW50cyA4NDcgMCBS IA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9S b3RhdGUgMCANPj4gDWVuZG9iag04NDcgMCBvYmoNWyANODQ5IDAgUiA4ODQgMCBSIDg1MSAwIFIg DV0NZW5kb2JqDTg0OCAwIG9iag0zMjcgDWVuZG9iag04NDkgMCBvYmoNPDwgL0xlbmd0aCA4NDgg MCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCsK9zPFMI3Fluu3xXNwflxtHx1w+ sNHk2L7RzzCAWakCGhJ7pTRqS0vCTK1tzrQN+vlt9BIMZ+j23djPnv9hWJrel7LSWvKkIx5BPlcV 77Q6Lyj+w5USbATIuvXwng5ZJhE6Ao9R8Nu0j0bDX+2W9KjNCrG6iVEam/GL8p6hDSiQkSWjLVRC M/Xb2dpaD1HtRk+izTUolkakfwCdadY8t3iiCbUtleVcFZ8ERqVExuSZ8YeW1nO/F6F85NYzk6G2 lOAhnnn4u9SLePl6bBxgYqUEk83Td9HHtW367yk5JXyPWA3zZ6X+gEpmikSPQd/tB+fBjXvXT+5x 2Qpr+C/c9FqCApAOfGJjHE9eTw/fEXIrPHCOAw85BmNE9SwuxzNkVbG8xEDB16yAI0fWF+Jcl6F3 xs4sFf+SIPssB8KtUfVfi/LsjeHSOA1lbmRzdHJlYW0NZW5kb2JqDTg1MCAwIG9iag05NjIgDWVu ZG9iag04NTEgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4NTAgMCBSID4+ IA1zdHJlYW0NCuuvxF7YuoimTs+ettW+z1PfQgqgJV8Q859tuXccEnAA2QBZVj4JR5htYYv5yoY2 pxniP7llcei9bzia4+R3uvjvIjoTlRYc3WsBFNwS/Xu5YE3zj+jhlKP/6IQXPghfG33XD8jjtuD2 MjtQ73sfc3HYq/kBY6Lc52A+O1TLbeWqcgwQmXqfjRnN0TwWLNHq6leWSylGvgidO8O5deZZsKHF R83G2V+BXok37f9+7zgeaSWri/NIL3eoawoCgovCEHg6WKCkFS+UYpNMXjC9Eid2HZWM1xHQ9mXL BDCTnWMnO4NLU4k6lL8vs9yyqEY9uscGZWIc7XS/YixLRJUDRWvZExk0HNBJys8ASsYZzmdWX+vZ 5FZPl0+JdkCx4Q9W8jE+NuGT5h4dUOaHM8aCLlvbCvE/1KBac9qqNnQpZ1lvMAATnLBGzJ6cSmgS XvMlVdx5WsfbU4piV3xzPlDlG9yEa8HI0A3bJxstCYYQuccPYQs0a1TtCeYNNkkPZTS+keTHsygD LVwZdAE4wrseHaY0Vy19YnnUNVZYlpR86E1aPmBDDPU5YqeOkFlv212Wmn5fbyFubeMWKXEcxd0j RGMrtu7KfhVp7IF8cLnd1Oqz1XS7mrORS5GnX6SYkaNCVyI6w1zDSckanFwVfACN8VF7BzPv7ZHS QbxllWmsbqTz4vK5xK8djaeRXnImmxXoFbA/WW6HMmbqoNBk9+7xxGKv1eCX/AS0A9iIbXwfKlFp OHbKnv13F4KFQN/PeKk2A5RyCd5hJmqVvAisy5MmONfoJneBIu992cNagUBHUN0gShr3JX1rej32 UsllAqQAPYDhl/XKv+LXKAfSD5Nw8jehK2PhsyDSq3dRtBVAQQHIpUfi1vGiQylBuYgFdsjE7hjz iEwT71VMWN0LhaK/+t0htJ3I96//tSVACjP+IaU4AkC8g2yvNpOuFew/Du6gYpGN4TgBcyuaFjPI duGSNrPHSNkXEQ2I7nCewWKV4f96MQlVdB/TH7xYzteyFmch6wmj/9PvihwR6zcm4ggkDZhEx+yY TKcMgG4a90pV9Lwn5/piP/WWb8PrOP1mAx8fCXzKnkwAx2OyrIUq24or9enq4woIquHDpi8S7KFi FHA/ST6uWQfRoAkJvPZALASWNjACkTlaTAUYnQh0DQupNnlzvNWbfvEDJ7U6gwe+A+uATbDmM8bo jsA5hNDLO31xpojXuqOcu1dUAQFFrD8SPP32GZjneaaMqDsXE2pYBOi2tciO3lIm5uZ8er3JAAOn AWUIDWVuZHN0cmVhbQ1lbmRvYmoNODUyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4 OTQgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250IDw8IC9GMCA5MDcgMCBSIC9GMyA4ODAgMCBSIC9G NCA4ODIgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTI0OSA4NzYgMCBSID4+IA0vUHJvY1NldCA5MTIg MCBSID4+IA0vQ29udGVudHMgODUzIDAgUiANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Ny b3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNODUzIDAgb2JqDVsg DTg1NSAwIFIgODg0IDAgUiA4NTcgMCBSIA1dDWVuZG9iag04NTQgMCBvYmoNMzI2IA1lbmRvYmoN ODU1IDAgb2JqDTw8IC9MZW5ndGggODU0IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3Ry ZWFtDQr+i7NE+D9wgzRS1x9eyxr1jmi74caP4jhGn2KESlUKbvCXQIBWa8fpmx5KmLpmZpe56520 kYGEPXW3aeCxpapu8j9k70cgKeuPA28Id5c0sWie51BPJTOMihSVCezmGNWUCzsa1qLOXnYAMk2o PXgXdwmdkDs1CQLDkGXufjsp0ua8FlwyOGhxl5dn9oSFLgedf28rgzUKkr1Q+vUoZAaMivkxA1rd 0IWKr6UuvAaKIjvFPjEn1WqLuCyHappsn9fePE+VK5xcnSP5hqZT44+nyyjM8DoRIYasmA6ubTX3 QkFhskAlB5Ag0CjoLqtRhhptnoPmK6DmCxMSPehIJ0CBIAjft7u5hfv+3YltqsQmyvmClNqMP9CY Yj/Auid6j+sTjB1MVc0z845cn9GL5iKqSKwrgEabrs0VW7FVLr8aFzsozF65sw1lbmRzdHJlYW0N ZW5kb2JqDTg1NiAwIG9iag0xMzY2IA1lbmRvYmoNODU3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlIC9MZW5ndGggODU2IDAgUiA+PiANc3RyZWFtDQpPnPGsLLTezR+oZrRhVUe+GJ5JjKG0 F3jEXhmMFy86gzjVEdYBsRGy9/OlZpxqpWfrGtx+D+rNLNo5obHDB4gM/69VcTz4RpwOeiO0f+xO xPJ0lPDnR5wr1iJ05TUCTvkWLOj2qX44upH2zU1VwAtjfJ7aF9SMnf1l+cT0TDUXVBQ8t4vHatP+ DrWbsMPhXPVwJvVRESo0sAwL3tHPat33djQvlx4TEytwJQNY3EFy6ccJbSuKnSPrO2j2FX6cM2KM rbhWtYj+fqTo9D3LME8bHFwF702deNyZXsK7pm01dCq61ALOXvOJ6vkyi/4mDa6yX62kpxgJCitv bwHrCSooz5mzLOQUOor/lgxUY5GS4Z6oh0zncphzEsDutlMMIBM1pCgYIIUiHYWjSspae9sYnFJm 9VWRSZc2RtTvSzBggiZy/0uxBV1znmoFlVMHnQnqAFR2OgFlpx944ELs+OINa9zxGSTnc4Aif4zb vgonkh5ksGkwCEcB0TaAGvpIgEs32j3kIst2lLxpG/HqLLCP8Nrd861PibW+TtM1jAXNvZEDl336 ZB9Lee0IJ8RRkdufALcIrEGlLi7EvmHh8InRye2xitat75hMBnmmakkz5lF3krrrc3jQivdiWOoC 6lP/t8DJz6xVsEeQroWRgW00+oEcg4rjvR8YaStlAarCVhutScXDXA8gLLWl05rp6NeWin5KtgTi GLc/vuYMLPtdQ6b8v/MkcoQRhj4MSTbNTGVS6IgH7N5UZ9bA/Bn4cE2Kt4dgQqv2pG5mngToi7LP EIVmRDHbbluxcZM3+sXXHwYwiS+jnr/JdeskWZW+an7oi/06uEviN78g7UqHwhqbIdfrjhHh9dTx LWwZmrmbxi/vfLN35NGByur1VT1eDFa3+KPEjgtdlUrlHlJ38WnND1ZWXY4qN+beIhGu2vQ7sHDU 9VNwhNmrChgtZ0EPqGwNhVnvZM4aUpp5SG0cH0naTdho4PUfK+wppc3gkaXCRLUda3sw4Gi14nXu UQS4CUwtXezkdEnhTwNp7bSIQhoH/stK2Ncg7c0QjrkNtxJFiubPO3rZlJgM6QM/ROT94PQKVpK1 XuC8zr2YnsGLT8Y2p1JKqKtsWW3LdgOo64WAAxHr5NlzuLeWO9YEofUSpXfOqFLMnCT06dUNe4lV 5WdREeCMIptokHZzlX8ScinwzMyNRdPquOywHeTP3RI9Hr/ZHAG1Jd/zE6aNqTJM2SnPowit+SKe A4WH8MfjTQFRXQnx1XOSrhfwOZjkZu9XLPGFXFpR6UJo3yXFnAkxdXZG0sWD92AnriAOEy5KKjNT ZwlePGraB5250pCFejbVjp+3UuzAPPld78+DQ5SIo/5x10zrRffNhOsov+BDFIEjViqGuVr2V7UY 4JvAsYo+KmHj7BEDO7HLyA1ppF0MhkobBepMA1mQ2YRWg/QDIwaTaghNWYQCUrY9/obCXLUNcJhA OgsLilVufxYnNXJh1xDaoIB7Ptn4VJbd+7pKFnArovBhJo1/4AkCOJRVWVg96TzGY/1Rlz1dAMvh 9YFUEZasipj5ypxp0gbVFD1i0ewbzv1zRTWF/uyq0HLboQ68JgeLjAAIGatCugzYP1K7qsan8svI jYxlOVpKA5/yowknOCejcm+UWUAD6vQsEFuV9B6WNRlLHJggLNQavgGIJOfsgDTxxSxLEv/tJ+SB bngen0Oyd6Et3wMkzYbzeVOD4MDRnBtWF8Kyr2JgsfC59+Bm0s4nElfyKPrulhS92i7eCdGC6TP0 PScRwjX3xclSKGNW+Nw1BKc6IqN5zoYa2Yp1v1sMMJjiDWVuZHN0cmVhbQ1lbmRvYmoNODU4IDAg b2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA4OTQgMCBSIA0vUmVzb3VyY2VzIDw8IC9Gb250 IDw8IC9GMCA5MDcgMCBSIC9GMyA4ODAgMCBSID4+IC9YT2JqZWN0IDw8IC9pbTI1MCA4NzYgMCBS ID4+IA0vUHJvY1NldCA5MTIgMCBSID4+IA0vQ29udGVudHMgODU5IDAgUiANL01lZGlhQm94IFsg MCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNODU5IDAgb2JqDVsgDTg2MSAwIFIgODg0IDAgUiA4NjMgMCBSIA1dDWVuZG9iag04NjAg MCBvYmoNMzI2IA1lbmRvYmoNODYxIDAgb2JqDTw8IC9MZW5ndGggODYwIDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQqvxrcsCH3yoWMKfgv/BXhGUAmJCZUf76ogHfz3rFASoB3u xO96dpdY0sUUlfQVcauWjR0H1vpo5HE5ai0/51dbh8VBG32g68SyCZdlg0pVTwTr91mvZRs3kggC XVNtHVCESQm/+aLYBJomJ9jrUG3bxzgiO3XjyC77ooU/6+DTMFgGpbVnf3XSdxVAobxhTtdWTGsG iE3x6hubYkIpqEm+oo/xMrrcoKvAkMpMnH+XxIbK+sl4WeBDSxunH0BJ+H+2Xjup92XJJGTWg/mA IgD9CuDK5hc6ygsZ7C1KcsNykrsl/R6cEpEta/WS56BOeUxjQP0DkwRRn1lMYkSDE0zmZrcNgdRR sLX4rSJayuTCtmcje7HF6vIllnHndGTRCWaPWVUOX2lxWFt0ycqqoK0Wa9tD9Mn1reRfQVMoTaVl r1LAcqu6oQ1lbmRzdHJlYW0NZW5kb2JqDTg2MiAwIG9iag03MDMgDWVuZG9iag04NjMgMCBvYmoN PDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA4NjIgMCBSID4+IA1zdHJlYW0NCkacLV1G F3QhLnEDSldRHgjA+QC4YMUkptuk7supMiSOldVjOPsGo6Ue5eQv2opXrBIuW5Uys//6ZCiNbk7E 3PNGdrwLU67Eluu+9j1VufpLzriuQBDxhANeVVIszk65NywWimWmAFqhxRFUbO9MjzuVIJILOJ/2 jt6UQ0j9VOaOqrsEK+vKc6DJ9oBYviHw1yELDyJuHsryFJ3EJcUfvqRWmdaakZsrRgm6RiO8dWSq lUkTHMya8zsuhgQZheqoXpFBnSsveedGpFypdwLpny0wCfO58T0IoDEnPer6L+RQyjXIp2vP8/Vg kixJTfqBByDya5nHV6GXlfDxS4kpgh1gPdG3fxukLSja8q04zyECEs0E2ELLPRfciVhNYBFa4suv 0gB3nquRfi67BU6hPynu5SO5mEBG9vu07dPg3PSraiig4maFmFcgmf3HOjtDFnXCZG7dSL3juoL8 zD0J3xcXvX8wrbviNs7XNePUtCvwMmE7alWZzl8lv9ihlvcflhscvI3P6wdDw/PZPjcM3GYsIQHL Wh4W83ufra+cRdyi7EkTaiSHDZjOzoAJ91hePjBf17MCohd2h34Qi2WWVNpzOU4uBTLLut5EXyhq 0Tvg+zZCwAqY16FtjxzYx2fU4D/5fMbtzcWwwAgqRMPVRL8eyocyroS07d52hyOlGb+HZ0/SD93J bFtYAWNn3lEtAdD4GiQLlVHP6k4+RITYXWK4pPboeg1SXdyQb1cN2eE3m0VcmwjXdLph2rB/H47K UWRizPVAyoh7Amxe2wk/mrTCFPrsdsLfCGYyt+3WhWPry2MVuOLvPl/CXBCP7vBz0s3Vecs3lBf2 m8fZFR6AT62/xsnV3b/tuwCyYMTkPxksF9s6sFqEdvoK3cf9cok7E5QXSPUEjC/XAPIzjAtXEViz GjiEZPaiEfNNCpFE6voNZW5kc3RyZWFtDWVuZG9iag04NjQgMCBvYmoNPDwgDS9UeXBlIC9QYWdl IA0vUGFyZW50IDg5NSAwIFIgDS9SZXNvdXJjZXMgPDwgL0ZvbnQgPDwgL0YwIDkwNyAwIFIgL0Yx IDkxMCAwIFIgPj4gL1hPYmplY3QgPDwgL2ltMjUxIDg3NiAwIFIgPj4gDS9Qcm9jU2V0IDkxMiAw IFIgPj4gDS9Db250ZW50cyA4NjUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBdIA0vQ3Jv cEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag04NjUgMCBvYmoNWyAN ODY3IDAgUiA4ODQgMCBSIDg2OSAwIFIgDV0NZW5kb2JqDTg2NiAwIG9iag0zMjYgDWVuZG9iag04 NjcgMCBvYmoNPDwgL0xlbmd0aCA4NjYgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCrQncRZAl93EKabrkAXUYErG6eV5Sn487Xl8YNvZW8MflkWMH3yozjN2NgD53akVaGPZGY8z qWugyANDbi6Ak6R9jWSRk5tAqz74tX9kQfMAdDGU0/NVvYfDw5mkAbClHSOolxqo5kh8wjaFuE9e GmWDVC9/OfQAWZ3bJ+DBoky72Sqsshg+LKMbmqNpKAcHsPrw0Rq+i9T9MttYdPBbl+IXUeTYBek6 tNpmMyGTkfS6I9IuH/DTIeIOnwGikVhJ8UfeUSxUBT5flaAuhpPScj3j74XEMYeYb69FfUFsbR3V 9tanR1x8mkF9bjF2ffwXmMYLmGA6nAdlg4wCoYbnVRY3NFLc7vkY1cuzOgn6Jx9vs4VZBe3CenjU q7Zrky/I0tNmt5PnY+3TfGjig4Hl9FRxHMiJUMnpc70o/3dPjrzThqQgjPFyDWVuZHN0cmVhbQ1l bmRvYmoNODY4IDAgb2JqDTQ2OSANZW5kb2JqDTg2OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDg2OCAwIFIgPj4gDXN0cmVhbQ0KRZ4m2l06Cd/aozwpGkGMKAMINch0818A Z+k1dKR1I+jxDYjXH3IHM2tWDxYjcvNSNFlP4fOpqvMSsZBsKgCxHNf+x1SIm92uTbetZIuGmBZQ KyAJky7ywPYYAT590PLDZtPuMQ/dsKoNLj38ee+vFjlNovxspaxWYKA7udfJHBsOuwaEr3Ckf+OG z+UJi2MIoP83S1hYI1t8nWpT6S9FSQ11lFPQQG1ihCc5RHAXb4FvwdM28fd6vtdPgfm8sWbGBzSK 5/UCzaHT0nkeoby2VgoV+xoCG5DVLuuQR92mNYZilssgKalbxXWMWuJ15G7011MlFsSmu/lrbguE ktZqzHc5wJTriIhNSAbx4oB7sJQbaeZjgXkGnkSJ1E2NVQHtfTuMex4qfCsLpou8wBeHqfX2ejP+ N28KpGsHx0Kch9XRam3KA6Ky0EpiGLbF5JRDLSj81UaeIfg5yl4ef6wfrZ5KuUJVHfKnyS/MEFf3 TDhZOM8ESecMBnIJbYbPsNIDuMMiiF80tvJEKuflyxFdmSElWFsy01GxjLbh1j/g3a8egUSfrwOf zz4dDe1X5Ygr0JNbwdhQIY+ReGfZfgcgcjpnO+OyF/eheZg8+sEbQXsoklzQFQ1lbmRzdHJlYW0N ZW5kb2JqDTg3MCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgODk1IDAgUiANL1Jlc291 cmNlcyA8PCAvRm9udCA8PCAvRjAgOTA3IDAgUiAvRjEgOTEwIDAgUiA+PiAvWE9iamVjdCA8PCAv aW0yNTIgODc2IDAgUiA+PiANL1Byb2NTZXQgOTEyIDAgUiA+PiANL0NvbnRlbnRzIDg3MSAwIFIg DS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4NDIgXSANL1Jv dGF0ZSAwIA0+PiANZW5kb2JqDTg3MSAwIG9iag1bIA04NzMgMCBSIDg4NCAwIFIgODc1IDAgUiAN XQ1lbmRvYmoNODcyIDAgb2JqDTMyNiANZW5kb2JqDTg3MyAwIG9iag08PCAvTGVuZ3RoIDg3MiAw IFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K3ovKFDSIvy7cl4NBb4HIQUSoyTw/ G05+W9eIlFoldmsz8hgNGkeSQHNXYiYdgsY7yetJsJopt+vgcMyiHSpIIHiX1NB1xoSemZ8qDO+W BKVRAxt4760CMQyZ5AvI+fEuxhfnECOXqHPhJTrwnIahrvNIY8kiEfjdAfW3t4TEtO/rN9dTQmMs 5ntkBnAe4ZffpWhjNycDbKecYlNBnZIBT2zf2uMkbvy2pw/9Gm5Qs2FdwKzNd7q9+2FBn8T2mfij Df5Suaw0YtfH9KdnmwpQwULSvExZnlQc5ZUPXttEfQJaHl1e5yOsIyv42q5akgtm27A3co78B5ts Nuuo0XWd4Tcn2XGbiSlWCA8bIupGECVCO+kV9X9OVs192P2faEIjMkBwqwgc6NC519yG7aSK7Kjh oz/BmiqHw82hWsjqwddiZx3Y/pUNZW5kc3RyZWFtDWVuZG9iag04NzQgMCBvYmoNMjQ4IA1lbmRv YmoNODc1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODc0IDAgUiA+PiAN c3RyZWFtDQpnYdVCR8tIo0JaiFLquhOwCf60GImCsWTjTesP71FT4zdNt03zm5wAMbj57ketF3fG nPxHZ5lSkWAcpZmn7jj0+92dgqXQWUgZG0kInaNU59eiGYmVwgBSc5VFjO1+UQ2G2sjB8nCnK+fX se4d0GfkSE+EDfVYbnTbv8b4dJjcomwO2u/k5EQVhrnRozCQpUaBzTEaJqe8/8Tl63Osy40jxlBa U05VSAQUxmnzACoS7zBeLK54OIeRMrfUjM8fESLrf8dai2hGcbBMIcGw4MxG3gU9gwUgIa5WU6v4 hLn9tkDxms6Tt0P8iEbmafdGoidbMY9mouSiGA1lbmRzdHJlYW0NZW5kb2JqDTg3NiAwIG9iag08 PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL2ltMiAvRmlsdGVyIC9EQ1RE ZWNvZGUgL1dpZHRoIDExNSANL0hlaWdodCAyNyAvQml0c1BlckNvbXBvbmVudCA4IC9Db2xvclNw YWNlIC9EZXZpY2VSR0IgL0xlbmd0aCA4NzcgMCBSID4+IA1zdHJlYW0NCmr9qIzmdm7UPYhh9ujT HS6CY3qNkoBFBk1jLpuJ0MPN+ZCx8oqxwPaw4oomT5XczkbjaazCxKhJwTUBIQ0UcON+96B5PQ0M yqPMkDGkIMyvIEW9fEl9D5gpOOzn8CTrgLisittxlAwGhPCUofABuyQLJVtaPdj5d6ntQp3uzCXq Kvsqr1f0FPL12mZoG4h1YPEbT2OwD2QZr8yQVDZQsyio41BFjZnJgxslzj25MBSdCEQlHZMGliE7 fXhzvMJM9euGZuWYlSbrALDInL5NOKWm8poLbcLswdoJ8ZpZm8Z6Fo0YF3tRQQAmaVdU9dZM2nMC l1B3dw2+s6Di/x8Lzeo4gAgD2pghDSyLid+CfSr768UL1ucw2Yh6W0my+StYTQS37GEma9qlKmKN n0LkRvvFkzzU6dJNj9CBsvNZKCVcSw8JtSC/LaOF9W1/1LJG33u9xiZhsImk5eKR1nAc5p8p8aqq tFpZ5KviITVEzXcSud/nc4n0XHbV4fkfCsyinC5ugCandky9yyOLRv8xnw2x2X3DTaZ0JQoIkIJE r3HEIIFxiLcGZWv8tXMhcNZhSOz5R5aQo6eOths+0TDY6Ivs7+P/qQg548LOJxK38Wwtz/X5nHLf WL9+FHS9aiLcVpyiw/AnIjntT6Poj6SX9zYdjK74LyU8R3IiA8fcyGmlY7OsKXiBBeWxfDNs/zoG B9jWJWmmkkwuFpqquna6M33VThsHbquOiOmgyFb7IyJbS1igDhnoTo9QcuQ7NkgAqNSR+JuyH9yx a1lk05LEYRLRGhCscAGzrsBkq0Z0+dsf30wWet7GAai0wmZXZJfDS5tJfU8yJVl1Y28Acs6BATWC L92wH7W/uzzwgPZQmlnTalWvBqym7xiq177ngQ7ILvhwGlGN1Csnl2xFOBq2htPiA3KYLn3z8czH y4OqZLdyKKk5ZSixXzyY3XiYdNDExkTZFLgwZ/4ZK5btion+mpWxI0CMabc7bkAFa7Y1CzdCuN1y v1MnisxCxWNsopuSuGyltmzFuz54jkyXwVANG2ckUoi0jRiZvIm8x/rOpkF+I4OvCZr03haYcSWM n3E27rcq9IeENCzoa5SyB7B0AXHlp8Z4iaiNn/hmnf+llPooaPVBCFLBDs7OQTBJuJNAR0IgC7P/ 8WgsQHFt+shAgR2j5l/Q8OdrEqA3HJMBHeeW1fgifJt/zLKXcB6U1C6PVow9Uf8zQ2yo6yOXSXWv KkdcELn0c+Jjs9RqmslBG/6IHIg9BBki1njc3wV/fBtftEQIyFPltN7bCh6NROlaD3WllTJyS/Rp Eb0GpEerDBgn2YRW4+QfFwPGcW66I7JKXIHRnbcGdpIqBW6j3jqv2xX3HT5opVmFL/vToXru1RH6 EJG62oKXGOXMI1jfqpyi2PVus1Qf8jguv54wykeMOAPQ07oLpcOggABYIA4bPlrECcCB77mHAipN ikTR+6T+f0O0rwmqLpWfwPmGPBlG7pgdrtxWRXJy6R11E932sX2AZe0VNyV7YaGnFnyuPZNLE8Rh b+8KaGRslRVdcm5OmL+f9D3/AY9qsksslqo0WbnGzopYeH40f2+ViwOkLMlsTZ44Zp7GB0Cb+ypl aTjOB37eNjhjHkWvb8rBz0a2MESBiqv1jMqzABWfDKw+3cpf7TicAutocYAhSO8GRYErJZSkdKra yd5yWmHoCek8wGKXk2NNsT4OKBlj76uKi1CbDCbZKaUSVbd42Ue/FG4ZL0RdShwWWUy4duRkmGDC QrTL9zqT9GOybotdWeUc8xh6aw0rPKenCEvB1xV8AayBe9RjJyhl+jFJ9qbEM7JbO8g/1jcHT/mK mdg+T96uUynJklchN+3hEWgQBFrGDJe+MuIyP7FnFYwlL7C3T3z5fdU/CTN+6qjfyDPiqIiz2x7x 7Bjr6RJP0+Ag+P5cPkHKWzBklzrkA6REBEaA0U82L8B3RfvaHSV6IpVFYxDSvgkgrzvgk5RV+FO1 3+vE+SLPNyu0MPSIRxG2mQxfCtl1jxMyHTSyC9c7p2W1z0ipNd4N1ZQ8mud2hsT0W5k+AE/5Bqc2 japkj/nCqewjgmKLFdDNOQrSj+HtebzkSExfwmq4mRZIwdb07MMVfDERkNqE+tSLtCQnCvPCeTIb oLLEfX2s9IGb9Q1zdVh2bvPTsOLic2yY3+0wWKl293aJQGuFJtQLzhn/OQ+QF+0mlZ/8pP5P4qoT dMVB8UBhg/RqPjK1QnwsYfOH41m97EGLCchF7o2UssP+VG4o51XaRdMKV80G7ycMQsekQ7o+sqal ovHaTHrDBT/2aQzXJd9ESRZyacbljUC/Hj9d9nNTE0lGFvPvor1JZQiB6wRG+NJ5YzN37Sjk/e4c OBWNoUbOlpIdof+WiFVCAbEKYve+tUk7fqu4dJG0Z6RSJV15t7FvKpbPOUK46r5t/jdQBvOSD3X9 xPprHPByn13Ud1TtWnv2q07Q4cMimiz+Qc7DMG0XfqvSufQLEtRE2BqEhvB5MWcvpfdFCXJDL6Qa L98j4bXXoFSx5X6XkJAACEOkvJWPEUzthlMIativqICfHFIRmFjx1MOcBIril8KdkqJU1wYs1skN 7fp3IOGT4P/gM2RXD2CoBQsmrRVaplFUUpIy9pWnQOBJgGekGh+fe78OJKBaX3TXtNwKckeMrI1V pdDCCzkq2NN5X3aSCbQq30a+QgUL086ah4qqlTJfyLmn5YhPRuEOD7A4C8A7/nV1TwmJ11ZjVsIA PixNqI9y86j4kfpbZdN1506bt2UUJn1PjlsZK5S6Enc3pKutztYEmaI0i1VZAEcEBHlceScrjmjv oscaDQQZ2EZ+4X9Hh1pNedc7uEmR2u/5iVl5pkT39I7LrZJ6qn75DVKa0TinK2Q5OW5LL/vMSl7v dvibWaMmkgj7J4mt4Mb86C5mHz5xHxp7K4ryXAS+E/yICYkVko+mdF/tT1E/R/+29QbiQR91j8kC nQN8sxbJ6uGUFqzKjwGtc6V22getWNd2nk9jQSrfdhJiPJ8DrUi0EBn4cosxcV8DSThtDJJ/hbER +lkGHsQgorWCEgjvNyDTzSF8jplZgD3aR9wEkYEPizS6RBduWp69oHzrd8RMj9ZS5T8DQRuWrWB7 Sgfksnhe5qDLtyCAANArBKR7l+ffWukkWtWuVQbFFaZubHjLw/kcXQfgCfFlpWAOjAOl9KBuGk7D e4k8wu9YNiDtnrAunyk+6K+UqZjHip1RfH4yxApk1jsZUuBc+Rc54ImCGqJL8Or9aS2gPsTQVlzP LHpj3aRYRwI2I2rb8MUhnIvUvzaFB8dWR2Xfkx4WijMVQ29WyBlcOvBh02VBgnIzvTyVvMOp7IXg HIgArZWpAxZByfX2pl1tA7+w7MSZu2MRkjVMPW8y+OMVM1eCqg1hO8u+ab5s83TwkumWdbt+iygc 4iQdenrHhmuOkLp9i7mOrpDyOpNUUIUTjtaxBaNyOilIhu3FBzuwIhyCAPscIfc6LRpUA2gG4H3g KzENlEn/J5twDuXXH8ZgRvkIRnRstAXQkoojmn7SuJSyETLvYWTKb3QHMa7rnvnUG8ythoqaGvNZ ygGyZxwAh8iRZEybtzEmOt8WMmHvp8sceZQQjh/xEAMN4IHanN0KDHcS4ApI3mBjfEjwzpQ0Q5Aa 0WPWnkIra+hygEAPw686SjLuEiJIJe17bNmIFYFO4n8J2hgnHGk9j37CwyeHjZ9FILdkCcszXxkr VAizuHfajmnEXulBi5oBjQgpuJ0zMGGCLCpFVCvIPEBO+uvaLuJRwvKcuU2CgCCMXENZc/XJwuIY 7pzjIIHqsgn1hEjsJGKy4SatKgxXPOQX/dhI8tVZJgm8hXJrWsjrBMYsPyJIcf2PY9blnhRGBn4E J+AWPrb7yjgbQr8OQyqQLR5Z98O3vFnQZV0OwTu6B9CCByuLRJ2x4Vkd9zWYkkMvbO6vVUd6ei4D rNpY2QO2qsdUX3mpoNxBvUgidQ8cuuXvFW3pspYRrKs/N+XcqxeYPYKW3LqebpfOurpZo+gN4tHA WujHgf/+lP60IiZXqWwvCpfKUd7WbttxTcdnq7AP0PRO1eRsqTXo/WMuAC+Xqka9S30VNLH89K20 NDsuoaBRBU6KxXFaGH9ysVHLVKERWF3Hye/HuBC5B5UHL11GxSmILk5DRDu0hqt9t2kEtamCKDd3 s0cKkV6NdyKxmO2HOA89a8DIJi8V4Pyw67FyZ1UUcsHsSD2sxpNh2UEMWqIB777YVthqp3UGdGuI dlLvoPaJNyXDe9bxCQgIAdeHzHs9Q4nIEAZBPE44pydf182ff9em6Y2aD/avwp9S+JaKy6Xrz8cf OR7yJImQySNH7oLioV0Zpk8mMLuUZnlRwrRnlARqn4lwfQh16W5iNlqyB6Gjw2SCzUL8Mg316pWS 59SF5oQdUcdgrr3TQOIKuQphY4LjMdESVS2n//JhQAKWCpFF4QhBEPP3vtijxSYKA5yo9bIKR194 xnkVKSmcwUCjusuwGj8U0ZDjZw92QCrcQ3ldlJzxfoEhcuQ/R1ySTtttoYQUtPoi83Y0+2H3oOWS 0uX5lJZzPHBol5dIBnW9k03B6Ws2bMOXcC337x1Q4QQs77xCplgCeFKWDDCvGhyYn8YoW3ur5FFA LJRRrA3aM26V2xSwMxd7hLfhmJVsG0mTF22E4oWHk6dtRhxmDFQGx+WoWHAcfrK2OmEy3nQ5nMU/ ibJYorpbGD0EjZFQOIYV5hchLCts2vnGbmiPLfxIgr7iM2m1vcUKKgMmDCv0tc/ib4bz6s4TxN7c BGA9xLND+WrCoTQ7jxouN61RtT1HvwlRTKvKUpp29oKaHPc31mc4MMaz02HCI8DKjkDyiNH0+Cx5 bAPmyybAEwhLQTNREfkIA+eFfogTERSCncYkGiL4xcPN7Ajmza96+lePqE9AzrlL58vFukdb4FV5 6qani9bkrD2axGtrPT3+PNyyj+8bILMC3jR38RviyBNudMS36aszKZsYgUlGqUjVTLtb3QjT9fru 0GharzGBqMeXZIK+EXhTOTI75l+YlWcjVafuU2pypuRahKF64c/Qh7b409w1+LfBu32jZd+Oomb3 FsEEj1HM+c4KAmChpImLzp8S28iqKKfO2vIuNS25qULzN06/0z4RfF2OFnF8hpuASKlvPDmxOIfC di2wfNk66d0wJ5Jpo/yCgoRzbzabHM8Ho+uzkFkAtCS2neS1/NPLXjnr2W/i0UDd/9zYjBoNpwwi Ji1+W5lXRqJ6hDIdd3UiTbda+z1I6jzfqbjWXA1lbmRzdHJlYW0NZW5kb2JqDTg3NyAwIG9iag0z OTc1IA1lbmRvYmoNODc4IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBl IA0vTmFtZSAvRjIgDS9CYXNlRm9udCAvVGltZXNOZXdSb21hbiANL0ZpcnN0Q2hhciAzMiANL0xh c3RDaGFyIDI1NSANL1dpZHRocyBbIDI2MCAzMDQgMzkxIDUwMCA1MDAgODI2IDc4MiAxNzMgMzI2 IDMyNiA0NTYgNTY1IDI2MCAzMjYgMjYwIDI4MiA1MDAgDTUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMCA1MDAgNTAwIDI2MCAyODIgNTY1IDU2NSA1NjUgNDM0IDkxMyANNjk1IDY1MiA2NzMgNzE3 IDYwOCA1NjUgNzE3IDcxNyAzMjYgMzkxIDcxNyA2MDggODkxIDcxNyA3MTcgNTY1IA03MTcgNjcz IDU2NSA2MzAgNjk1IDY5NSA5MzQgNzE3IDY5NSA2MDggMzI2IDI2MCAzMjYgNDc4IDUwMCAzMjYg DTQ1NiA1MDAgNDM0IDQ3OCA0MTMgMzI2IDQ3OCA0NzggMjYwIDI2MCA0NzggMjYwIDczOSA0Nzgg NDc4IDUwMCANNDc4IDM0NyAzOTEgMjgyIDUwMCA0NzggNjk1IDUwMCA0NzggNDM0IDQ3OCAxNzMg NDc4IDU0MyA3ODIgNTY1IA03ODIgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUg NTY1IDU2NSA3ODIgNTY1IDc4MiA3ODIgDTU2NSA1NjUgNTY1IDU2NSA1NjUgNTY1IDU2NSA1NjUg NTY1IDU2NSA1NjUgNTY1IDc4MiA1NjUgNTY1IDI2MCANMzA0IDQ3OCA1MDAgNTAwIDUwMCAxNzMg NTAwIDMwNCA3NjAgMjgyIDQ3OCA1NjUgMzI2IDc2MCA1MDAgMzkxIA01NDMgMzA0IDMwNCAyODIg NTg2IDQzNCAyNjAgMzA0IDMwNCAzMDQgNDc4IDczOSA3NjAgNzYwIDQzNCA2OTUgDTY5NSA2OTUg Njk1IDY5NSA2OTUgOTEzIDY3MyA2MDggNjA4IDYwOCA2MDggMzI2IDMyNiAzMjYgMzI2IDcxNyAN NzE3IDcxNyA3MTcgNzE3IDcxNyA3MTcgNTY1IDcxNyA2OTUgNjk1IDY5NSA2OTUgNjk1IDU2NSA1 MDAgNDU2IA00NTYgNDU2IDQ1NiA0NTYgNDU2IDY1MiA0MzQgNDEzIDQxMyA0MTMgNDEzIDI2MCAy NjAgMjYwIDI2MCA1MDAgDTQ3OCA0NzggNDc4IDQ3OCA0NzggNDc4IDU0MyA1MDAgNTAwIDUwMCA1 MDAgNTAwIDQ3OCA1MjEgNDc4IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vRm9udERl c2NyaXB0b3IgODc5IDAgUiANPj4gDWVuZG9iag04NzkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVz Y3JpcHRvciANL0ZvbnROYW1lIC9UaW1lc05ld1JvbWFuIA0vRmxhZ3MgMzQgDS9Gb250QkJveCBb IC0yNTAgLTIxNiAxMTIyIDEwNDAgXSANL01pc3NpbmdXaWR0aCAzMjYgDS9TdGVtViA3MyANL1N0 ZW1IIDczIA0vSXRhbGljQW5nbGUgMCANL0NhcEhlaWdodCA4OTEgDS9YSGVpZ2h0IDQ0NiANL0Fz Y2VudCA4OTEgDS9EZXNjZW50IC0yMTYgDS9MZWFkaW5nIDE0OSANL01heFdpZHRoIDkzNSANL0F2 Z1dpZHRoIDQwMSANPj4gDWVuZG9iag04ODAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlw ZSAvVHJ1ZVR5cGUgDS9OYW1lIC9GMyANL0Jhc2VGb250IC9Db3VyaWVyTmV3IA0vRmlyc3RDaGFy IDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1 IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1 IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1 IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg DTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSAN NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rpbmcg DS9Gb250RGVzY3JpcHRvciA4ODEgMCBSIA0+PiANZW5kb2JqDTg4MSAwIG9iag08PCANL1R5cGUg L0ZvbnREZXNjcmlwdG9yIA0vRm9udE5hbWUgL0NvdXJpZXJOZXcgDS9GbGFncyAzNCANL0ZvbnRC Qm94IFsgLTI1MCAtMzAwIDcyNiAxMDAwIF0gDS9NaXNzaW5nV2lkdGggNjA1IA0vU3RlbVYgMTA5 IA0vU3RlbUggMTA5IA0vSXRhbGljQW5nbGUgMCANL0NhcEhlaWdodCA4MzMgDS9YSGVpZ2h0IDQx NyANL0FzY2VudCA4MzMgDS9EZXNjZW50IC0zMDAgDS9MZWFkaW5nIDEzMyANL01heFdpZHRoIDYw NSANL0F2Z1dpZHRoIDYwMCANPj4gDWVuZG9iag04ODIgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0v U3VidHlwZSAvVHJ1ZVR5cGUgDS9OYW1lIC9GNCANL0Jhc2VGb250IC9Db3VyaWVyTmV3LEJvbGQg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0aHMgWyA2MDUgNjA1IDYwNSA2MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUg NjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2 MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgDTYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSANNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IA02MDUgNjA1IDYwNSA2MDUgNjA1IDYw NSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSA2MDUgNjA1IDYwNSBdIA0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZyANL0ZvbnREZXNjcmlwdG9yIDg4MyAwIFIgDT4+IA1lbmRvYmoNODgzIDAgb2Jq DTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Gb250TmFtZSAvQ291cmllck5ldyxCb2xkIA0v RmxhZ3MgMTY0MTggDS9Gb250QkJveCBbIC0yNTAgLTMwMCA3MjYgMTAwMCBdIA0vTWlzc2luZ1dp ZHRoIDYwNSANL1N0ZW1WIDE5MSANL1N0ZW1IIDE5MSANL0l0YWxpY0FuZ2xlIDAgDS9DYXBIZWln aHQgODMzIA0vWEhlaWdodCA0MTcgDS9Bc2NlbnQgODMzIA0vRGVzY2VudCAtMzAwIA0vTGVhZGlu ZyAxMzMgDS9NYXhXaWR0aCA2MDUgDS9BdmdXaWR0aCA2MDAgDT4+IA1lbmRvYmoNODg0IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODg1IDAgUiA+PiANc3RyZWFtDQp9sHLJ 56RQuXB3cHAtDxAO+hcyWQvMeosn46nKFes6Briq8Fzj204XJti6o/K/8iSG18ysnurgFsoW6BVF b9gRbu8M+jR5qCGBTtIIqqTruUWyfgfHUuySNsscgW1aP5nFH6KdERfJdCO9ScBdXk4cbv5MNOJe 7R2QyLTzYF+OZ6DdkzXz8efW1Td8R3r9UnkxyXWM585VMzmlrhqbMZxvO746vItqW5cbx5jZ3rDi rqjeKFM3/v7jLeT/THdTwYEvdg2MTuzsMFanPhl6jZ6tajWFZKr5dI6AMLfCVbhXekguuuDsA+vc vWQhdZ2IINOfBG2k+xGo8OiLllez9MrPW/js4nIJbTI9dWGsVRUsmwEMC6YhAZirp7q4OfD8OUo0 9Oez/98xp6kotUlfJUitQ8ZJy7ZZE+tfbewcZe0v41wLtHIjPjQcW4cJbgHqrfT6Xbxs5UrmVOTZ tr7edwRtgcsM5GZ3rTbzFFPKlkJz0CnYObSPAmD2Z7X39wsPsUKS9gi3gnh0ROEXJGDHYHH8yC9z Bkk7cPYX5MDZFuhE0Yvi/fxkCyga8Tcqys3/4gk88D80svS0LMZpGiNQ/T1zA/2h0c3zXZQZyk5+ tqTSo991n6Z4MRefHBWzWZS+JCn0VrOOav9zRfMpTfboByvIJwTRmXPNqQH82/nekYnF/ZkOHoMW Gbm/lmMB8NiZKSQSMKPJ4MxLnIHLy4w9QrygqBNDFRXApk7KQ8fNVRVHJcI3xSVEDyvW4jLXTtvA TGRC2qLvet4LcPIh+bduSQMxMMNLlqBaUqJr4CMRzgRLi72RGhRWq3hIoHXalr30/u/a7X3ZR7i6 HAsecslODrww0uGD2SwYLaNSSdAxGu2CbzXPjtwfpBSaF+wvfFDFlUM/1SPVtQxGsHAN4ayzz1Ey vU40rNB8+T/Hr0DF5db5OAiD2JXKwROruj3q/Zx2X2avaBdWm6PKPsA10ZiB8yAcU2zCrYDX1c6p VyHOsF4lz79d8WO5ysKyS078G+5IvfYx0RP90hIziYQgU6+QdyUzyGZVQftaXUgH90zTf2CR+C6g 7jwkFP4Xu80doKWxN6wWy15r54RWenFMUUsW3uNzG+Bls3IHzQPcPglQDt85PxEYxuGb8sGrjQNz 6+jk9xwSa6pWxRjX71zsUq/X48pROVqsombbalcdchpg5eu91jg0kbE412lBxt1aD73Q/rEVQOgy zWfQYfasbgmFnmknXJU3FY8I0umqydxSABZklp7HRljKUEumwuhV8vfBeXWP1hwF6lysWlTxKjLS BBUu8vgJgHrq0dAfA1O3u9HGPy4ZFTnMElujSPgfyIRyY6q2UU3kdV/S84Sw3v25+csJkhk+f36f 0aHU6bM31BDzHVGpODZlMyojB62mHcHnzrRaNWe1j8ValRxS8rbeZcoM2tcO3PR8x4DfJmZf+EXD 5hhCKmLbpDsmWHqcnfv/udqI6+jQ2JNWv0Akp4VzWzjGCuuyhvTd2RaBrhfhz9kKk7/io3jpqNAc qdu2GtHsjz5Y5hTRhFdsRIkLJCttv6xjUKbiNWt1DkQD4kcVorP46NtQBzx6vCERpKUAYUWlq8/D entB8apyUMaAtf5y8do+51S6F1uIz/yWRMw974lQGXpdvzgkZP5hMZ/LNOaO66JdzaAgqFF/Z1I3 y4Bdu5hcs/Qyh+fv15tzEy2XC/+U2bb3AmlrXDKn0dj24SoFtzT0fYkFhxj5HNhIMSBOKaE2e1F5 /pmFAXcuzGKj1nJnxuJEpwzt62EplcKNTz3yyAU7nyghqbezYfBZpJLFtDDbr9mZpcd7Eb//JIhw 3bGpWXCsb8mLR+043i3QFUAmhowCpTsGmxjXYQyWYfE0i7q5M4Hbaw+WlrG+gEdHMLITB568TVFZ rIRPohu+A5kM8C7B4u0PSEdxIsLVfMK+0NyTbL3MObAo2ohjTGRgrRyGr14vBNQs7txIme5wq4UG 8SBhA0GL35FCpznA9AB5+6B34mAgTN5dhaYC8PKGEkkNwtJx5uH8dcqT786apI7I/OR6Prr87pRf U1uCpqyvY+Mz0AI2KGkyQ5CjZ5Ggu1OW/KK31Lf4rHyZb3PuboEcNFXpjvqzAm1ISuuloiuXyyVD kzS91danmKRODCJ1nHTtHieE3oVtL/RE9J+MDJr9gNSuuscTu1MN8WP49+ErkQAHpwhPlMjbgYZ0 IAw0sjZ4MfrTr96l2b98snJajMJ4zy+LlGPaj12KEnb6DaOFjDvFV/bgnAk71Ap27Bi9hRR2fATk TRAn+Am1uUbZsLanaxi8dO6VKylMCcEbVPYkn1swiSBtzHfkI5sUnTbs1f/EuV/FLj6k1lJUVEVn 0vkSMpI3QBhuCU6k2t85up6D5El4TH+CDqF0vDzHA6gGzTjQ7kov4QYGuAq/9uFwfZrUFqFM3Bjw 8tiFeS9c/BCZfWQMttJYEUxJKn6QrbxN3z4s5t8M8DsGwsHaHv/Sxx8aVmn96K0WdYvBINE3Z1YW nS53BemoGwOnKnAXNAshCMRZz2Ew9cfSqZVIZxBq1xNGKUd0J77lJgtgKJ9NDG+P5jzFtLzS6jt9 YXhLne4YSjT7cwULQ4CTZWhJ368OX9uBwhBDWudvClM9W79j9uDnMn+GJhoaFMJnuXrWaOFgdoKJ JouD9N/OIpie7HEnKjt71a7rTBX8+J+hd8HBkOl7KlJMHZqIpHYfMizh+B8n4CT8Gv97r11iE0Pr /JK5uJM9D8SeFim8QVVueXrmW1bQc5svXWTsuoOn0W28UP+u6soNZW5kc3RyZWFtDWVuZG9iag04 ODUgMCBvYmoNMjA5NCANZW5kb2JqDTg4NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDg4NyAwIFIgPj4gDXN0cmVhbQ0KwwA+hscyeRbhdbaKYMkNZW5kc3RyZWFtDWVuZG9i ag04ODcgMCBvYmoNMTQgDWVuZG9iag04ODggMCBvYmoNPDwgDS9DcmVhdG9yIChuImxunxn47Mwa UfOiCB8da2jOoPRJD1xu3lBBXvJl8ebJhsBRPG/EUUd38NedBSGRHj/l+P+WOHXr97xmSx7hKQ0v Q3JlYXRpb25EYXRlIChncT0swFunv4gJN63jXw4CKQ0vVGl0bGUgKG4bQ0/QPMfEmHNo6LUeUEAu V/+OzgUwLulQXFxV9XSjytCQ0V9zTN1WWn618dhYBfUbKQ0vQXV0aG9yIChpKnl1lRi3y9ZOb/+4 KQ0vUHJvZHVjZXIgKGJcKH1zkgvjquh+QMuiBUtVOQWtwpdbeSrxAmkQ0Wnt7daUwRAQUikNL0tl eXdvcmRzICgpDS9TdWJqZWN0IChuG0NP0DzHxJhuY++kBVFXKQ0vTW9kRGF0ZSAoZ3E9LMBbp7+I CTeu4FoLBSkNPj4gDWVuZG9iag04ODkgMCBvYmoNPDwgDS9LaWRzIFsgOTAyIDAgUiAxIDAgUiA3 IDAgUiAxMyAwIFIgMTkgMCBSIDI1IDAgUiBdIA0vQ291bnQgNiANL1R5cGUgL1BhZ2VzIA0vUGFy ZW50IDg5NiAwIFIgDT4+IA1lbmRvYmoNODkwIDAgb2JqDTw8IA0vS2lkcyBbIDY4NCAwIFIgNjkw IDAgUiA2OTYgMCBSIDcwMiAwIFIgNzA4IDAgUiA3MTQgMCBSIF0gDS9Db3VudCA2IA0vVHlwZSAv UGFnZXMgDS9QYXJlbnQgODk2IDAgUiANPj4gDWVuZG9iag04OTEgMCBvYmoNPDwgDS9LaWRzIFsg NzIwIDAgUiA3MjYgMCBSIDczMiAwIFIgNzM4IDAgUiA3NDQgMCBSIDc1MCAwIFIgXSANL0NvdW50 IDYgDS9UeXBlIC9QYWdlcyANL1BhcmVudCA4OTYgMCBSIA0+PiANZW5kb2JqDTg5MiAwIG9iag08 PCANL0tpZHMgWyA3NTYgMCBSIDc2MiAwIFIgNzY4IDAgUiA3NzQgMCBSIDc4MCAwIFIgNzg2IDAg UiBdIA0vQ291bnQgNiANL1R5cGUgL1BhZ2VzIA0vUGFyZW50IDg5NiAwIFIgDT4+IA1lbmRvYmoN ODkzIDAgb2JqDTw8IA0vS2lkcyBbIDc5MiAwIFIgNzk4IDAgUiA4MDQgMCBSIDgxMCAwIFIgODE2 IDAgUiA4MjIgMCBSIF0gDS9Db3VudCA2IA0vVHlwZSAvUGFnZXMgDS9QYXJlbnQgODk2IDAgUiAN Pj4gDWVuZG9iag04OTQgMCBvYmoNPDwgDS9LaWRzIFsgODI4IDAgUiA4MzQgMCBSIDg0MCAwIFIg ODQ2IDAgUiA4NTIgMCBSIDg1OCAwIFIgXSANL0NvdW50IDYgDS9UeXBlIC9QYWdlcyANL1BhcmVu dCA4OTYgMCBSIA0+PiANZW5kb2JqDTg5NSAwIG9iag08PCANL0tpZHMgWyA4NjQgMCBSIDg3MCAw IFIgXSANL0NvdW50IDIgDS9UeXBlIC9QYWdlcyANL1BhcmVudCA4OTcgMCBSIA0+PiANZW5kb2Jq DTg5NiAwIG9iag08PCANL0tpZHMgWyA4ODkgMCBSIDg5MCAwIFIgODkxIDAgUiA4OTIgMCBSIDg5 MyAwIFIgODk0IDAgUiBdIA0vQ291bnQgMzYgDS9UeXBlIC9QYWdlcyANL1BhcmVudCA4OTggMCBS IA0+PiANZW5kb2JqDTg5NyAwIG9iag08PCANL0tpZHMgWyA4OTUgMCBSIF0gDS9Db3VudCAyIA0v VHlwZSAvUGFnZXMgDS9QYXJlbnQgODk4IDAgUiANPj4gDWVuZG9iag04OTggMCBvYmoNPDwgDS9L aWRzIFsgODk2IDAgUiA4OTcgMCBSIF0gDS9Db3VudCAzOCANL1R5cGUgL1BhZ2VzIA0+PiANZW5k b2JqDXhyZWYNMCA4OTkgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxNjIwNiAwMDAwMCBuDQow MDAwMDE2NDM5IDAwMDAwIG4NCjAwMDAwMTY0ODggMDAwMDAgbg0KMDAwMDAxNjUwOCAwMDAwMCBu DQowMDAwMDE2OTEzIDAwMDAwIG4NCjAwMDAwMTY5MzMgMDAwMDAgbg0KMDAwMDAxNzk4MiAwMDAw MCBuDQowMDAwMDE4MjE1IDAwMDAwIG4NCjAwMDAwMTgyNjYgMDAwMDAgbg0KMDAwMDAxODI4NiAw MDAwMCBuDQowMDAwMDE4NjkxIDAwMDAwIG4NCjAwMDAwMTg3MTIgMDAwMDAgbg0KMDAwMDAxOTM2 MyAwMDAwMCBuDQowMDAwMDE5NTk4IDAwMDAwIG4NCjAwMDAwMTk2NTAgMDAwMDAgbg0KMDAwMDAx OTY3MSAwMDAwMCBuDQowMDAwMDIwMDc3IDAwMDAwIG4NCjAwMDAwMjAwOTkgMDAwMDAgbg0KMDAw MDAyMTI1MSAwMDAwMCBuDQowMDAwMDIxNDk5IDAwMDAwIG4NCjAwMDAwMjE1NTEgMDAwMDAgbg0K MDAwMDAyMTU3MiAwMDAwMCBuDQowMDAwMDIxOTc4IDAwMDAwIG4NCjAwMDAwMjE5OTkgMDAwMDAg bg0KMDAwMDAyMjgwMiAwMDAwMCBuDQowMDAwMDIzMDM3IDAwMDAwIG4NCjAwMDAwMjY0MDMgMDAw MDAgbg0KMDAwMDAyODE1OSAwMDAwMCBuDQowMDAwMDI4MTgwIDAwMDAwIG4NCjAwMDAwMjg1ODcg MDAwMDAgbg0KMDAwMDAyODYwOCAwMDAwMCBuDQowMDAwMDI5NDMxIDAwMDAwIG4NCjAwMDAwMjk0 NTEgMDAwMDAgbg0KMDAwMDAyOTU3OSAwMDAwMCBuDQowMDAwMDI5NTk5IDAwMDAwIG4NCjAwMDAw Mjk3MjYgMDAwMDAgbg0KMDAwMDAyOTc0NiAwMDAwMCBuDQowMDAwMDI5ODc4IDAwMDAwIG4NCjAw MDAwMjk4OTggMDAwMDAgbg0KMDAwMDAzMDAzMCAwMDAwMCBuDQowMDAwMDMwMDUwIDAwMDAwIG4N CjAwMDAwMzAxODMgMDAwMDAgbg0KMDAwMDAzMDIwMyAwMDAwMCBuDQowMDAwMDMwMzM1IDAwMDAw IG4NCjAwMDAwMzAzNTUgMDAwMDAgbg0KMDAwMDAzMDQ4OCAwMDAwMCBuDQowMDAwMDMwNTA4IDAw MDAwIG4NCjAwMDAwMzA2NDAgMDAwMDAgbg0KMDAwMDAzMDY2MCAwMDAwMCBuDQowMDAwMDMwNzky IDAwMDAwIG4NCjAwMDAwMzA4MTIgMDAwMDAgbg0KMDAwMDAzMDk0NCAwMDAwMCBuDQowMDAwMDMw OTY0IDAwMDAwIG4NCjAwMDAwMzEwOTYgMDAwMDAgbg0KMDAwMDAzMTExNiAwMDAwMCBuDQowMDAw MDMxMjQ5IDAwMDAwIG4NCjAwMDAwMzEyNjkgMDAwMDAgbg0KMDAwMDAzMTM5OSAwMDAwMCBuDQow MDAwMDMxNDE5IDAwMDAwIG4NCjAwMDAwMzE1NTAgMDAwMDAgbg0KMDAwMDAzMTU3MCAwMDAwMCBu DQowMDAwMDMxNzAwIDAwMDAwIG4NCjAwMDAwMzE3MjAgMDAwMDAgbg0KMDAwMDAzMTg1MSAwMDAw MCBuDQowMDAwMDMxODcxIDAwMDAwIG4NCjAwMDAwMzIwMDMgMDAwMDAgbg0KMDAwMDAzMjAyMyAw MDAwMCBuDQowMDAwMDMyMTUzIDAwMDAwIG4NCjAwMDAwMzIxNzMgMDAwMDAgbg0KMDAwMDAzMjMw MSAwMDAwMCBuDQowMDAwMDMyMzIxIDAwMDAwIG4NCjAwMDAwMzI0NTQgMDAwMDAgbg0KMDAwMDAz MjQ3NCAwMDAwMCBuDQowMDAwMDMyNjA0IDAwMDAwIG4NCjAwMDAwMzI2MjQgMDAwMDAgbg0KMDAw MDAzMjc1NyAwMDAwMCBuDQowMDAwMDMyNzc3IDAwMDAwIG4NCjAwMDAwMzI5MDYgMDAwMDAgbg0K MDAwMDAzMjkyNiAwMDAwMCBuDQowMDAwMDMzMDU5IDAwMDAwIG4NCjAwMDAwMzMwNzkgMDAwMDAg bg0KMDAwMDAzMzIxMSAwMDAwMCBuDQowMDAwMDMzMjMxIDAwMDAwIG4NCjAwMDAwMzMzNjEgMDAw MDAgbg0KMDAwMDAzMzM4MSAwMDAwMCBuDQowMDAwMDMzNTEzIDAwMDAwIG4NCjAwMDAwMzM1MzMg MDAwMDAgbg0KMDAwMDAzMzY2NCAwMDAwMCBuDQowMDAwMDMzNjg0IDAwMDAwIG4NCjAwMDAwMzM4 MTMgMDAwMDAgbg0KMDAwMDAzMzgzMyAwMDAwMCBuDQowMDAwMDMzOTYxIDAwMDAwIG4NCjAwMDAw MzM5ODEgMDAwMDAgbg0KMDAwMDAzNDExMiAwMDAwMCBuDQowMDAwMDM0MTMyIDAwMDAwIG4NCjAw MDAwMzQyNjMgMDAwMDAgbg0KMDAwMDAzNDI4MyAwMDAwMCBuDQowMDAwMDM0NDE0IDAwMDAwIG4N CjAwMDAwMzQ0MzQgMDAwMDAgbg0KMDAwMDAzNDU2NSAwMDAwMCBuDQowMDAwMDM0NTg2IDAwMDAw IG4NCjAwMDAwMzQ3MTggMDAwMDAgbg0KMDAwMDAzNDczOSAwMDAwMCBuDQowMDAwMDM0ODY5IDAw MDAwIG4NCjAwMDAwMzQ4OTAgMDAwMDAgbg0KMDAwMDAzNTAyMCAwMDAwMCBuDQowMDAwMDM1MDQx IDAwMDAwIG4NCjAwMDAwMzUxNzYgMDAwMDAgbg0KMDAwMDAzNTE5NyAwMDAwMCBuDQowMDAwMDM1 MzI3IDAwMDAwIG4NCjAwMDAwMzUzNDggMDAwMDAgbg0KMDAwMDAzNTQ4MCAwMDAwMCBuDQowMDAw MDM1NTAxIDAwMDAwIG4NCjAwMDAwMzU2MzAgMDAwMDAgbg0KMDAwMDAzNTY1MSAwMDAwMCBuDQow MDAwMDM1Nzg1IDAwMDAwIG4NCjAwMDAwMzU4MDYgMDAwMDAgbg0KMDAwMDAzNTk0MCAwMDAwMCBu DQowMDAwMDM1OTYxIDAwMDAwIG4NCjAwMDAwMzYwOTUgMDAwMDAgbg0KMDAwMDAzNjExNiAwMDAw MCBuDQowMDAwMDM2MjQ3IDAwMDAwIG4NCjAwMDAwMzYyNjggMDAwMDAgbg0KMDAwMDAzNjQwMSAw MDAwMCBuDQowMDAwMDM2NDIyIDAwMDAwIG4NCjAwMDAwMzY1NTUgMDAwMDAgbg0KMDAwMDAzNjU3 NiAwMDAwMCBuDQowMDAwMDM2NzA4IDAwMDAwIG4NCjAwMDAwMzY3MjkgMDAwMDAgbg0KMDAwMDAz Njg2MSAwMDAwMCBuDQowMDAwMDM2ODgyIDAwMDAwIG4NCjAwMDAwMzcwMTYgMDAwMDAgbg0KMDAw MDAzNzAzNyAwMDAwMCBuDQowMDAwMDM3MTcxIDAwMDAwIG4NCjAwMDAwMzcxOTIgMDAwMDAgbg0K MDAwMDAzNzMyNSAwMDAwMCBuDQowMDAwMDM3MzQ2IDAwMDAwIG4NCjAwMDAwMzc0NzggMDAwMDAg bg0KMDAwMDAzNzQ5OSAwMDAwMCBuDQowMDAwMDM3NjMyIDAwMDAwIG4NCjAwMDAwMzc2NTMgMDAw MDAgbg0KMDAwMDAzNzc4NCAwMDAwMCBuDQowMDAwMDM3ODA1IDAwMDAwIG4NCjAwMDAwMzc5Mzcg MDAwMDAgbg0KMDAwMDAzNzk1OCAwMDAwMCBuDQowMDAwMDM4MDg3IDAwMDAwIG4NCjAwMDAwMzgx MDggMDAwMDAgbg0KMDAwMDAzODIzOSAwMDAwMCBuDQowMDAwMDM4MjYwIDAwMDAwIG4NCjAwMDAw MzgzOTAgMDAwMDAgbg0KMDAwMDAzODQxMSAwMDAwMCBuDQowMDAwMDM4NTQwIDAwMDAwIG4NCjAw MDAwMzg1NjEgMDAwMDAgbg0KMDAwMDAzODY5MiAwMDAwMCBuDQowMDAwMDM4NzEzIDAwMDAwIG4N CjAwMDAwMzg4NDYgMDAwMDAgbg0KMDAwMDAzODg2NyAwMDAwMCBuDQowMDAwMDM5MDAwIDAwMDAw IG4NCjAwMDAwMzkwMjEgMDAwMDAgbg0KMDAwMDAzOTE1NCAwMDAwMCBuDQowMDAwMDM5MTc1IDAw MDAwIG4NCjAwMDAwMzkzMDggMDAwMDAgbg0KMDAwMDAzOTMyOSAwMDAwMCBuDQowMDAwMDM5NDYz IDAwMDAwIG4NCjAwMDAwMzk0ODQgMDAwMDAgbg0KMDAwMDAzOTYxNCAwMDAwMCBuDQowMDAwMDM5 NjM1IDAwMDAwIG4NCjAwMDAwMzk3NjggMDAwMDAgbg0KMDAwMDAzOTc4OSAwMDAwMCBuDQowMDAw MDM5OTIwIDAwMDAwIG4NCjAwMDAwMzk5NDEgMDAwMDAgbg0KMDAwMDA0MDA3MyAwMDAwMCBuDQow MDAwMDQwMDk0IDAwMDAwIG4NCjAwMDAwNDAyMjcgMDAwMDAgbg0KMDAwMDA0MDI0OCAwMDAwMCBu DQowMDAwMDQwMzgwIDAwMDAwIG4NCjAwMDAwNDA0MDEgMDAwMDAgbg0KMDAwMDA0MDUzMCAwMDAw MCBuDQowMDAwMDQwNTUzIDAwMDAwIG4NCjAwMDAwNDIxMTUgMDAwMDAgbg0KMDAwMDA0MjEzNiAw MDAwMCBuDQowMDAwMDQyMjY3IDAwMDAwIG4NCjAwMDAwNDIyODggMDAwMDAgbg0KMDAwMDA0MjQy MSAwMDAwMCBuDQowMDAwMDQyNDQyIDAwMDAwIG4NCjAwMDAwNDI1NzYgMDAwMDAgbg0KMDAwMDA0 MjU5NyAwMDAwMCBuDQowMDAwMDQyNzMyIDAwMDAwIG4NCjAwMDAwNDI3NTMgMDAwMDAgbg0KMDAw MDA0Mjg4NyAwMDAwMCBuDQowMDAwMDQyOTA4IDAwMDAwIG4NCjAwMDAwNDMwNDEgMDAwMDAgbg0K MDAwMDA0MzA2MiAwMDAwMCBuDQowMDAwMDQzMTk2IDAwMDAwIG4NCjAwMDAwNDMyMTcgMDAwMDAg bg0KMDAwMDA0MzM1MSAwMDAwMCBuDQowMDAwMDQzMzcyIDAwMDAwIG4NCjAwMDAwNDM1MDYgMDAw MDAgbg0KMDAwMDA0MzUyNyAwMDAwMCBuDQowMDAwMDQzNjYxIDAwMDAwIG4NCjAwMDAwNDM2ODIg MDAwMDAgbg0KMDAwMDA0MzgxNiAwMDAwMCBuDQowMDAwMDQzODM3IDAwMDAwIG4NCjAwMDAwNDM5 NzAgMDAwMDAgbg0KMDAwMDA0Mzk5MSAwMDAwMCBuDQowMDAwMDQ0MTI0IDAwMDAwIG4NCjAwMDAw NDQxNDUgMDAwMDAgbg0KMDAwMDA0NDI3NyAwMDAwMCBuDQowMDAwMDQ0Mjk4IDAwMDAwIG4NCjAw MDAwNDQ0MjcgMDAwMDAgbg0KMDAwMDA0NDQ0OCAwMDAwMCBuDQowMDAwMDQ0NTc4IDAwMDAwIG4N CjAwMDAwNDQ1OTkgMDAwMDAgbg0KMDAwMDA0NDczMCAwMDAwMCBuDQowMDAwMDQ0NzUxIDAwMDAw IG4NCjAwMDAwNDQ4ODMgMDAwMDAgbg0KMDAwMDA0NDkwNCAwMDAwMCBuDQowMDAwMDQ1MDM4IDAw MDAwIG4NCjAwMDAwNDUwNTkgMDAwMDAgbg0KMDAwMDA0NTE5NCAwMDAwMCBuDQowMDAwMDQ1MjE1 IDAwMDAwIG4NCjAwMDAwNDUzNTEgMDAwMDAgbg0KMDAwMDA0NTM3MiAwMDAwMCBuDQowMDAwMDQ1 NTA4IDAwMDAwIG4NCjAwMDAwNDU1MjkgMDAwMDAgbg0KMDAwMDA0NTY2NSAwMDAwMCBuDQowMDAw MDQ1Njg2IDAwMDAwIG4NCjAwMDAwNDU4MTkgMDAwMDAgbg0KMDAwMDA0NTg0MCAwMDAwMCBuDQow MDAwMDQ1OTczIDAwMDAwIG4NCjAwMDAwNDU5OTQgMDAwMDAgbg0KMDAwMDA0NjEyNyAwMDAwMCBu DQowMDAwMDQ2MTQ4IDAwMDAwIG4NCjAwMDAwNDYyODIgMDAwMDAgbg0KMDAwMDA0NjMwMyAwMDAw MCBuDQowMDAwMDQ2NDM3IDAwMDAwIG4NCjAwMDAwNDY0NTggMDAwMDAgbg0KMDAwMDA0NjU4NSAw MDAwMCBuDQowMDAwMDQ2NjA2IDAwMDAwIG4NCjAwMDAwNDY3MzUgMDAwMDAgbg0KMDAwMDA0Njc1 NiAwMDAwMCBuDQowMDAwMDQ2ODkwIDAwMDAwIG4NCjAwMDAwNDY5MTEgMDAwMDAgbg0KMDAwMDA0 NzA0MyAwMDAwMCBuDQowMDAwMDQ3MDY0IDAwMDAwIG4NCjAwMDAwNDcxOTUgMDAwMDAgbg0KMDAw MDA0NzIxNiAwMDAwMCBuDQowMDAwMDQ3MzUwIDAwMDAwIG4NCjAwMDAwNDczNzEgMDAwMDAgbg0K MDAwMDA0NzUwNSAwMDAwMCBuDQowMDAwMDQ3NTI2IDAwMDAwIG4NCjAwMDAwNDc2NTggMDAwMDAg bg0KMDAwMDA0NzY3OSAwMDAwMCBuDQowMDAwMDQ3ODEzIDAwMDAwIG4NCjAwMDAwNDc4MzQgMDAw MDAgbg0KMDAwMDA0Nzk2NSAwMDAwMCBuDQowMDAwMDQ3OTg2IDAwMDAwIG4NCjAwMDAwNDgxMjAg MDAwMDAgbg0KMDAwMDA0ODE0MSAwMDAwMCBuDQowMDAwMDQ4Mjc3IDAwMDAwIG4NCjAwMDAwNDgy OTggMDAwMDAgbg0KMDAwMDA0ODQzMiAwMDAwMCBuDQowMDAwMDQ4NDUzIDAwMDAwIG4NCjAwMDAw NDg1ODcgMDAwMDAgbg0KMDAwMDA0ODYwOCAwMDAwMCBuDQowMDAwMDQ4NzQyIDAwMDAwIG4NCjAw MDAwNDg3NjMgMDAwMDAgbg0KMDAwMDA0ODg5NSAwMDAwMCBuDQowMDAwMDQ4OTE2IDAwMDAwIG4N CjAwMDAwNDkwNTAgMDAwMDAgbg0KMDAwMDA0OTA3MSAwMDAwMCBuDQowMDAwMDQ5MjA3IDAwMDAw IG4NCjAwMDAwNDkyMjggMDAwMDAgbg0KMDAwMDA0OTM2MiAwMDAwMCBuDQowMDAwMDQ5MzgzIDAw MDAwIG4NCjAwMDAwNDk1MTggMDAwMDAgbg0KMDAwMDA0OTUzOSAwMDAwMCBuDQowMDAwMDQ5Njcz IDAwMDAwIG4NCjAwMDAwNDk2OTQgMDAwMDAgbg0KMDAwMDA0OTgzMCAwMDAwMCBuDQowMDAwMDQ5 ODUxIDAwMDAwIG4NCjAwMDAwNDk5ODYgMDAwMDAgbg0KMDAwMDA1MDAwNyAwMDAwMCBuDQowMDAw MDUwMTQyIDAwMDAwIG4NCjAwMDAwNTAxNjMgMDAwMDAgbg0KMDAwMDA1MDI5NiAwMDAwMCBuDQow MDAwMDUwMzE3IDAwMDAwIG4NCjAwMDAwNTA0NDcgMDAwMDAgbg0KMDAwMDA1MDQ2OCAwMDAwMCBu DQowMDAwMDUwNjAxIDAwMDAwIG4NCjAwMDAwNTA2MjIgMDAwMDAgbg0KMDAwMDA1MDc1NyAwMDAw MCBuDQowMDAwMDUwNzc4IDAwMDAwIG4NCjAwMDAwNTA5MTMgMDAwMDAgbg0KMDAwMDA1MDkzNCAw MDAwMCBuDQowMDAwMDUxMDcwIDAwMDAwIG4NCjAwMDAwNTEwOTEgMDAwMDAgbg0KMDAwMDA1MTIy NSAwMDAwMCBuDQowMDAwMDUxMjQ2IDAwMDAwIG4NCjAwMDAwNTEzNzkgMDAwMDAgbg0KMDAwMDA1 MTQwMCAwMDAwMCBuDQowMDAwMDUxNTM2IDAwMDAwIG4NCjAwMDAwNTE1NTcgMDAwMDAgbg0KMDAw MDA1MTY5MyAwMDAwMCBuDQowMDAwMDUxNzE0IDAwMDAwIG4NCjAwMDAwNTE4NDggMDAwMDAgbg0K MDAwMDA1MTg2OSAwMDAwMCBuDQowMDAwMDUyMDAxIDAwMDAwIG4NCjAwMDAwNTIwMjIgMDAwMDAg bg0KMDAwMDA1MjE1OCAwMDAwMCBuDQowMDAwMDUyMTc5IDAwMDAwIG4NCjAwMDAwNTIzMTQgMDAw MDAgbg0KMDAwMDA1MjMzNSAwMDAwMCBuDQowMDAwMDUyNDY4IDAwMDAwIG4NCjAwMDAwNTI0ODkg MDAwMDAgbg0KMDAwMDA1MjYyMyAwMDAwMCBuDQowMDAwMDUyNjQ0IDAwMDAwIG4NCjAwMDAwNTI3 NzYgMDAwMDAgbg0KMDAwMDA1Mjc5NyAwMDAwMCBuDQowMDAwMDUyOTMxIDAwMDAwIG4NCjAwMDAw NTI5NTIgMDAwMDAgbg0KMDAwMDA1MzA4NiAwMDAwMCBuDQowMDAwMDUzMTA3IDAwMDAwIG4NCjAw MDAwNTMyNDAgMDAwMDAgbg0KMDAwMDA1MzI2MSAwMDAwMCBuDQowMDAwMDUzMzk2IDAwMDAwIG4N CjAwMDAwNTM0MTcgMDAwMDAgbg0KMDAwMDA1MzU1MiAwMDAwMCBuDQowMDAwMDUzNTczIDAwMDAw IG4NCjAwMDAwNTM3MDkgMDAwMDAgbg0KMDAwMDA1MzczMCAwMDAwMCBuDQowMDAwMDUzODYzIDAw MDAwIG4NCjAwMDAwNTM4ODQgMDAwMDAgbg0KMDAwMDA1NDAxNCAwMDAwMCBuDQowMDAwMDU0MDM1 IDAwMDAwIG4NCjAwMDAwNTQxNzEgMDAwMDAgbg0KMDAwMDA1NDE5MiAwMDAwMCBuDQowMDAwMDU0 MzI4IDAwMDAwIG4NCjAwMDAwNTQzNDkgMDAwMDAgbg0KMDAwMDA1NDQ4MyAwMDAwMCBuDQowMDAw MDU0NTA0IDAwMDAwIG4NCjAwMDAwNTQ2MzkgMDAwMDAgbg0KMDAwMDA1NDY2MCAwMDAwMCBuDQow MDAwMDU0Nzk2IDAwMDAwIG4NCjAwMDAwNTQ4MTcgMDAwMDAgbg0KMDAwMDA1NDk1MyAwMDAwMCBu DQowMDAwMDU0OTc0IDAwMDAwIG4NCjAwMDAwNTUxMDkgMDAwMDAgbg0KMDAwMDA1NTEzMCAwMDAw MCBuDQowMDAwMDU1MjYyIDAwMDAwIG4NCjAwMDAwNTUyODMgMDAwMDAgbg0KMDAwMDA1NTQxNiAw MDAwMCBuDQowMDAwMDU1NDM3IDAwMDAwIG4NCjAwMDAwNTU1NzAgMDAwMDAgbg0KMDAwMDA1NTU5 MSAwMDAwMCBuDQowMDAwMDU1NzIzIDAwMDAwIG4NCjAwMDAwNTU3NDQgMDAwMDAgbg0KMDAwMDA1 NTg3OCAwMDAwMCBuDQowMDAwMDU1ODk5IDAwMDAwIG4NCjAwMDAwNTYwMzQgMDAwMDAgbg0KMDAw MDA1NjA1NSAwMDAwMCBuDQowMDAwMDU2MTg5IDAwMDAwIG4NCjAwMDAwNTYyMTAgMDAwMDAgbg0K MDAwMDA1NjM0NiAwMDAwMCBuDQowMDAwMDU2MzY3IDAwMDAwIG4NCjAwMDAwNTY1MDAgMDAwMDAg bg0KMDAwMDA1NjUyMSAwMDAwMCBuDQowMDAwMDU2NjU0IDAwMDAwIG4NCjAwMDAwNTY2NzUgMDAw MDAgbg0KMDAwMDA1NjgwOSAwMDAwMCBuDQowMDAwMDU2ODMwIDAwMDAwIG4NCjAwMDAwNTY5NjMg MDAwMDAgbg0KMDAwMDA1Njk4NCAwMDAwMCBuDQowMDAwMDU3MTE3IDAwMDAwIG4NCjAwMDAwNTcx MzggMDAwMDAgbg0KMDAwMDA1NzI2OSAwMDAwMCBuDQowMDAwMDU3MjkwIDAwMDAwIG4NCjAwMDAw NTc0MjIgMDAwMDAgbg0KMDAwMDA1NzQ0MyAwMDAwMCBuDQowMDAwMDU3NTcxIDAwMDAwIG4NCjAw MDAwNTc1OTIgMDAwMDAgbg0KMDAwMDA1NzcyMSAwMDAwMCBuDQowMDAwMDU3NzQyIDAwMDAwIG4N CjAwMDAwNTc4NzMgMDAwMDAgbg0KMDAwMDA1Nzg5NCAwMDAwMCBuDQowMDAwMDU4MDI3IDAwMDAw IG4NCjAwMDAwNTgwNDggMDAwMDAgbg0KMDAwMDA1ODE4MiAwMDAwMCBuDQowMDAwMDU4MjAzIDAw MDAwIG4NCjAwMDAwNTgzMzcgMDAwMDAgbg0KMDAwMDA1ODM1OCAwMDAwMCBuDQowMDAwMDU4NDkx IDAwMDAwIG4NCjAwMDAwNTg1MTIgMDAwMDAgbg0KMDAwMDA1ODY0MyAwMDAwMCBuDQowMDAwMDU4 NjY0IDAwMDAwIG4NCjAwMDAwNTg3OTUgMDAwMDAgbg0KMDAwMDA1ODgxNiAwMDAwMCBuDQowMDAw MDU4OTUwIDAwMDAwIG4NCjAwMDAwNTg5NzEgMDAwMDAgbg0KMDAwMDA1OTEwNyAwMDAwMCBuDQow MDAwMDU5MTI4IDAwMDAwIG4NCjAwMDAwNTkyNjAgMDAwMDAgbg0KMDAwMDA1OTI4MSAwMDAwMCBu DQowMDAwMDU5NDE0IDAwMDAwIG4NCjAwMDAwNTk0MzUgMDAwMDAgbg0KMDAwMDA1OTU2NyAwMDAw MCBuDQowMDAwMDU5NTg4IDAwMDAwIG4NCjAwMDAwNTk3MTkgMDAwMDAgbg0KMDAwMDA1OTc0MCAw MDAwMCBuDQowMDAwMDU5ODczIDAwMDAwIG4NCjAwMDAwNTk4OTQgMDAwMDAgbg0KMDAwMDA2MDAy OCAwMDAwMCBuDQowMDAwMDYwMDQ5IDAwMDAwIG4NCjAwMDAwNjAxODMgMDAwMDAgbg0KMDAwMDA2 MDIwNCAwMDAwMCBuDQowMDAwMDYwMzM5IDAwMDAwIG4NCjAwMDAwNjAzNjAgMDAwMDAgbg0KMDAw MDA2MDQ5NCAwMDAwMCBuDQowMDAwMDYwNTE1IDAwMDAwIG4NCjAwMDAwNjA2NTAgMDAwMDAgbg0K MDAwMDA2MDY3MSAwMDAwMCBuDQowMDAwMDYwODA2IDAwMDAwIG4NCjAwMDAwNjA4MjcgMDAwMDAg bg0KMDAwMDA2MDk2MSAwMDAwMCBuDQowMDAwMDYwOTgyIDAwMDAwIG4NCjAwMDAwNjExMTIgMDAw MDAgbg0KMDAwMDA2MTEzMyAwMDAwMCBuDQowMDAwMDYxMjY2IDAwMDAwIG4NCjAwMDAwNjEyODcg MDAwMDAgbg0KMDAwMDA2MTQyMyAwMDAwMCBuDQowMDAwMDYxNDQ0IDAwMDAwIG4NCjAwMDAwNjE1 NzkgMDAwMDAgbg0KMDAwMDA2MTYwMCAwMDAwMCBuDQowMDAwMDYxNzM1IDAwMDAwIG4NCjAwMDAw NjE3NTYgMDAwMDAgbg0KMDAwMDA2MTg5MCAwMDAwMCBuDQowMDAwMDYxOTExIDAwMDAwIG4NCjAw MDAwNjIwNDcgMDAwMDAgbg0KMDAwMDA2MjA2OCAwMDAwMCBuDQowMDAwMDYyMjAzIDAwMDAwIG4N CjAwMDAwNjIyMjQgMDAwMDAgbg0KMDAwMDA2MjM1OSAwMDAwMCBuDQowMDAwMDYyMzgwIDAwMDAw IG4NCjAwMDAwNjI1MTYgMDAwMDAgbg0KMDAwMDA2MjUzNyAwMDAwMCBuDQowMDAwMDYyNjY5IDAw MDAwIG4NCjAwMDAwNjI2OTAgMDAwMDAgbg0KMDAwMDA2MjgyNCAwMDAwMCBuDQowMDAwMDYyODQ1 IDAwMDAwIG4NCjAwMDAwNjI5ODEgMDAwMDAgbg0KMDAwMDA2MzAwMiAwMDAwMCBuDQowMDAwMDYz MTM0IDAwMDAwIG4NCjAwMDAwNjMxNTUgMDAwMDAgbg0KMDAwMDA2MzI5MCAwMDAwMCBuDQowMDAw MDYzMzExIDAwMDAwIG4NCjAwMDAwNjM0NDMgMDAwMDAgbg0KMDAwMDA2MzQ2NCAwMDAwMCBuDQow MDAwMDYzNTk2IDAwMDAwIG4NCjAwMDAwNjM2MTkgMDAwMDAgbg0KMDAwMDA2NTk4NSAwMDAwMCBu DQowMDAwMDY2MDA3IDAwMDAwIG4NCjAwMDAwNjY1NDcgMDAwMDAgbg0KMDAwMDA2NjU2OSAwMDAw MCBuDQowMDAwMDY3MTk4IDAwMDAwIG4NCjAwMDAwNjcyMjAgMDAwMDAgbg0KMDAwMDA2Nzg0MyAw MDAwMCBuDQowMDAwMDY3ODY1IDAwMDAwIG4NCjAwMDAwNjg0ODMgMDAwMDAgbg0KMDAwMDA2ODUw NSAwMDAwMCBuDQowMDAwMDY5MTA4IDAwMDAwIG4NCjAwMDAwNjkxMzAgMDAwMDAgbg0KMDAwMDA2 OTc0NiAwMDAwMCBuDQowMDAwMDY5NzY4IDAwMDAwIG4NCjAwMDAwNzA0MDUgMDAwMDAgbg0KMDAw MDA3MDQyNyAwMDAwMCBuDQowMDAwMDcxMTM3IDAwMDAwIG4NCjAwMDAwNzExNTkgMDAwMDAgbg0K MDAwMDA3MTg5NiAwMDAwMCBuDQowMDAwMDcxOTE4IDAwMDAwIG4NCjAwMDAwNzI2MjkgMDAwMDAg bg0KMDAwMDA3MjY1MSAwMDAwMCBuDQowMDAwMDczMzg4IDAwMDAwIG4NCjAwMDAwNzM0MTAgMDAw MDAgbg0KMDAwMDA3NDE3OSAwMDAwMCBuDQowMDAwMDc0MjAxIDAwMDAwIG4NCjAwMDAwNzQ5Njgg MDAwMDAgbg0KMDAwMDA3NDk5MCAwMDAwMCBuDQowMDAwMDc1NjE3IDAwMDAwIG4NCjAwMDAwNzU2 MzkgMDAwMDAgbg0KMDAwMDA3NjUxMyAwMDAwMCBuDQowMDAwMDc2NTM1IDAwMDAwIG4NCjAwMDAw NzczNjEgMDAwMDAgbg0KMDAwMDA3NzM4MyAwMDAwMCBuDQowMDAwMDc4MjAxIDAwMDAwIG4NCjAw MDAwNzgyMjMgMDAwMDAgbg0KMDAwMDA3OTA2OSAwMDAwMCBuDQowMDAwMDc5MDkxIDAwMDAwIG4N CjAwMDAwNzk5MDkgMDAwMDAgbg0KMDAwMDA3OTkzMSAwMDAwMCBuDQowMDAwMDgwNTYyIDAwMDAw IG4NCjAwMDAwODA1ODQgMDAwMDAgbg0KMDAwMDA4MTM4OCAwMDAwMCBuDQowMDAwMDgxNDEwIDAw MDAwIG4NCjAwMDAwODIwMzQgMDAwMDAgbg0KMDAwMDA4MjA1NiAwMDAwMCBuDQowMDAwMDgyOTcy IDAwMDAwIG4NCjAwMDAwODI5OTQgMDAwMDAgbg0KMDAwMDA4Mzg0NiAwMDAwMCBuDQowMDAwMDgz ODY4IDAwMDAwIG4NCjAwMDAwODQ3MTUgMDAwMDAgbg0KMDAwMDA4NDczNyAwMDAwMCBuDQowMDAw MDg1NjAxIDAwMDAwIG4NCjAwMDAwODU2MjMgMDAwMDAgbg0KMDAwMDA4NjI3MSAwMDAwMCBuDQow MDAwMDg2MjkzIDAwMDAwIG4NCjAwMDAwODcwOTggMDAwMDAgbg0KMDAwMDA4NzEyMCAwMDAwMCBu DQowMDAwMDg3NzcxIDAwMDAwIG4NCjAwMDAwODc3OTMgMDAwMDAgbg0KMDAwMDA4ODQzOCAwMDAw MCBuDQowMDAwMDg4NDYwIDAwMDAwIG4NCjAwMDAwODkxMTggMDAwMDAgbg0KMDAwMDA4OTE0MCAw MDAwMCBuDQowMDAwMDkwMDEwIDAwMDAwIG4NCjAwMDAwOTAwMzIgMDAwMDAgbg0KMDAwMDA5MDgy NiAwMDAwMCBuDQowMDAwMDkwODQ4IDAwMDAwIG4NCjAwMDAwOTE2MjEgMDAwMDAgbg0KMDAwMDA5 MTY0MyAwMDAwMCBuDQowMDAwMDkyMjkwIDAwMDAwIG4NCjAwMDAwOTIzMTIgMDAwMDAgbg0KMDAw MDA5MzAwOCAwMDAwMCBuDQowMDAwMDkzMDMwIDAwMDAwIG4NCjAwMDAwOTM2MjYgMDAwMDAgbg0K MDAwMDA5MzY0OCAwMDAwMCBuDQowMDAwMDk0MjIzIDAwMDAwIG4NCjAwMDAwOTQyNDUgMDAwMDAg bg0KMDAwMDA5NDkyOCAwMDAwMCBuDQowMDAwMDk0OTUwIDAwMDAwIG4NCjAwMDAwOTU1MjAgMDAw MDAgbg0KMDAwMDA5NTU0MiAwMDAwMCBuDQowMDAwMDk2MTgwIDAwMDAwIG4NCjAwMDAwOTYyMDIg MDAwMDAgbg0KMDAwMDA5Njg0OCAwMDAwMCBuDQowMDAwMDk2ODcwIDAwMDAwIG4NCjAwMDAwOTc3 ODEgMDAwMDAgbg0KMDAwMDA5NzgwMyAwMDAwMCBuDQowMDAwMDk4NzI0IDAwMDAwIG4NCjAwMDAw OTg3NDYgMDAwMDAgbg0KMDAwMDA5OTYwMiAwMDAwMCBuDQowMDAwMDk5NjI0IDAwMDAwIG4NCjAw MDAxMDAyNjEgMDAwMDAgbg0KMDAwMDEwMDI4MyAwMDAwMCBuDQowMDAwMTAxMTA5IDAwMDAwIG4N CjAwMDAxMDExMzEgMDAwMDAgbg0KMDAwMDEwMTkzMyAwMDAwMCBuDQowMDAwMTAxOTU1IDAwMDAw IG4NCjAwMDAxMDI3NDcgMDAwMDAgbg0KMDAwMDEwMjc2OSAwMDAwMCBuDQowMDAwMTAzNTQyIDAw MDAwIG4NCjAwMDAxMDM1NjQgMDAwMDAgbg0KMDAwMDEwNDMyNSAwMDAwMCBuDQowMDAwMTA0MzQ3 IDAwMDAwIG4NCjAwMDAxMDUxMTUgMDAwMDAgbg0KMDAwMDEwNTEzNyAwMDAwMCBuDQowMDAwMTA1 OTE4IDAwMDAwIG4NCjAwMDAxMDU5NDAgMDAwMDAgbg0KMDAwMDEwNjU2OCAwMDAwMCBuDQowMDAw MTA2NTkwIDAwMDAwIG4NCjAwMDAxMDczODQgMDAwMDAgbg0KMDAwMDEwNzQwNiAwMDAwMCBuDQow MDAwMTA4MTYyIDAwMDAwIG4NCjAwMDAxMDgxODQgMDAwMDAgbg0KMDAwMDEwODk3MyAwMDAwMCBu DQowMDAwMTA4OTk1IDAwMDAwIG4NCjAwMDAxMDk3NzcgMDAwMDAgbg0KMDAwMDEwOTc5OSAwMDAw MCBuDQowMDAwMTEwNjAxIDAwMDAwIG4NCjAwMDAxMTA2MjMgMDAwMDAgbg0KMDAwMDExMTM4NiAw MDAwMCBuDQowMDAwMTExNDA4IDAwMDAwIG4NCjAwMDAxMTIyMDIgMDAwMDAgbg0KMDAwMDExMjIy NCAwMDAwMCBuDQowMDAwMTEyOTYyIDAwMDAwIG4NCjAwMDAxMTI5ODQgMDAwMDAgbg0KMDAwMDEx Mzc5MSAwMDAwMCBuDQowMDAwMTEzODEzIDAwMDAwIG4NCjAwMDAxMTQ1NzYgMDAwMDAgbg0KMDAw MDExNDU5OCAwMDAwMCBuDQowMDAwMTE1MzU5IDAwMDAwIG4NCjAwMDAxMTUzODEgMDAwMDAgbg0K MDAwMDExNjE1MiAwMDAwMCBuDQowMDAwMTE2MTc0IDAwMDAwIG4NCjAwMDAxMTY4NjMgMDAwMDAg bg0KMDAwMDExNjg4NSAwMDAwMCBuDQowMDAwMTE3NTY0IDAwMDAwIG4NCjAwMDAxMTc1ODYgMDAw MDAgbg0KMDAwMDExODIzNCAwMDAwMCBuDQowMDAwMTE4MjU2IDAwMDAwIG4NCjAwMDAxMTg4Nzgg MDAwMDAgbg0KMDAwMDExODkwMCAwMDAwMCBuDQowMDAwMTE5NTA3IDAwMDAwIG4NCjAwMDAxMTk1 MjkgMDAwMDAgbg0KMDAwMDEyMDE0NiAwMDAwMCBuDQowMDAwMTIwMTY4IDAwMDAwIG4NCjAwMDAx MjA3ODAgMDAwMDAgbg0KMDAwMDEyMDgwMiAwMDAwMCBuDQowMDAwMTIxMzY1IDAwMDAwIG4NCjAw MDAxMjEzODcgMDAwMDAgbg0KMDAwMDEyMjAyNyAwMDAwMCBuDQowMDAwMTIyMDQ5IDAwMDAwIG4N CjAwMDAxMjI3MzggMDAwMDAgbg0KMDAwMDEyMjc2MCAwMDAwMCBuDQowMDAwMTIzNDg3IDAwMDAw IG4NCjAwMDAxMjM1MDkgMDAwMDAgbg0KMDAwMDEyNDM1OCAwMDAwMCBuDQowMDAwMTI0MzgwIDAw MDAwIG4NCjAwMDAxMjUyMTggMDAwMDAgbg0KMDAwMDEyNTI0MCAwMDAwMCBuDQowMDAwMTI1ODY5 IDAwMDAwIG4NCjAwMDAxMjU4OTEgMDAwMDAgbg0KMDAwMDEyNjczOSAwMDAwMCBuDQowMDAwMTI2 NzYxIDAwMDAwIG4NCjAwMDAxMjc1ODIgMDAwMDAgbg0KMDAwMDEyNzYwNCAwMDAwMCBuDQowMDAw MTI4NDIzIDAwMDAwIG4NCjAwMDAxMjg0NDUgMDAwMDAgbg0KMDAwMDEyOTMwMCAwMDAwMCBuDQow MDAwMTI5MzIyIDAwMDAwIG4NCjAwMDAxMjk5NzEgMDAwMDAgbg0KMDAwMDEyOTk5MyAwMDAwMCBu DQowMDAwMTMwNjM4IDAwMDAwIG4NCjAwMDAxMzA2NjAgMDAwMDAgbg0KMDAwMDEzMTMwNyAwMDAw MCBuDQowMDAwMTMxMzI5IDAwMDAwIG4NCjAwMDAxMzE5ODcgMDAwMDAgbg0KMDAwMDEzMjAwOSAw MDAwMCBuDQowMDAwMTMyNjU2IDAwMDAwIG4NCjAwMDAxMzI2NzggMDAwMDAgbg0KMDAwMDEzMzMy NSAwMDAwMCBuDQowMDAwMTMzMzQ3IDAwMDAwIG4NCjAwMDAxMzQwNDcgMDAwMDAgbg0KMDAwMDEz NDA2OSAwMDAwMCBuDQowMDAwMTM0NjU3IDAwMDAwIG4NCjAwMDAxMzQ2NzkgMDAwMDAgbg0KMDAw MDEzNTI3NyAwMDAwMCBuDQowMDAwMTM1Mjk5IDAwMDAwIG4NCjAwMDAxMzU4NzUgMDAwMDAgbg0K MDAwMDEzNTg5NyAwMDAwMCBuDQowMDAwMTM2NTM4IDAwMDAwIG4NCjAwMDAxMzY1NjAgMDAwMDAg bg0KMDAwMDEzNzM3NCAwMDAwMCBuDQowMDAwMTM3Mzk2IDAwMDAwIG4NCjAwMDAxMzgyMDAgMDAw MDAgbg0KMDAwMDEzODIyMiAwMDAwMCBuDQowMDAwMTM4ODczIDAwMDAwIG4NCjAwMDAxMzg4OTUg MDAwMDAgbg0KMDAwMDEzOTU0NyAwMDAwMCBuDQowMDAwMTM5NTY5IDAwMDAwIG4NCjAwMDAxNDA0 NTEgMDAwMDAgbg0KMDAwMDE0MDQ3MyAwMDAwMCBuDQowMDAwMTQxMzMzIDAwMDAwIG4NCjAwMDAx NDEzNTUgMDAwMDAgbg0KMDAwMDE0MjAwMCAwMDAwMCBuDQowMDAwMTQyMDIyIDAwMDAwIG4NCjAw MDAxNDI2NzYgMDAwMDAgbg0KMDAwMDE0MjY5OCAwMDAwMCBuDQowMDAwMTQzNDk1IDAwMDAwIG4N CjAwMDAxNDM1MTcgMDAwMDAgbg0KMDAwMDE0NDMxNCAwMDAwMCBuDQowMDAwMTQ0MzM2IDAwMDAw IG4NCjAwMDAxNDUxMjYgMDAwMDAgbg0KMDAwMDE0NTE0OCAwMDAwMCBuDQowMDAwMTQ1OTI0IDAw MDAwIG4NCjAwMDAxNDU5NDYgMDAwMDAgbg0KMDAwMDE0NjY4OCAwMDAwMCBuDQowMDAwMTQ2NzEw IDAwMDAwIG4NCjAwMDAxNDczNDIgMDAwMDAgbg0KMDAwMDE0NzM2NCAwMDAwMCBuDQowMDAwMTQ3 OTcwIDAwMDAwIG4NCjAwMDAxNDc5OTIgMDAwMDAgbg0KMDAwMDE0ODYzOCAwMDAwMCBuDQowMDAw MTQ4NjYwIDAwMDAwIG4NCjAwMDAxNDkyOTggMDAwMDAgbg0KMDAwMDE0OTUzOCAwMDAwMCBuDQow MDAwMTQ5NTkzIDAwMDAwIG4NCjAwMDAxNDk2MTUgMDAwMDAgbg0KMDAwMDE1MDAyNSAwMDAwMCBu DQowMDAwMTUwMDQ4IDAwMDAwIG4NCjAwMDAxNTE0MDQgMDAwMDAgbg0KMDAwMDE1MTY1NiAwMDAw MCBuDQowMDAwMTUxNzAzIDAwMDAwIG4NCjAwMDAxNTE3MjUgMDAwMDAgbg0KMDAwMDE1MjEzNSAw MDAwMCBuDQowMDAwMTUyMTU3IDAwMDAwIG4NCjAwMDAxNTI4MjcgMDAwMDAgbg0KMDAwMDE1MzA2 NyAwMDAwMCBuDQowMDAwMTUzMTE0IDAwMDAwIG4NCjAwMDAxNTMxMzYgMDAwMDAgbg0KMDAwMDE1 MzU0NiAwMDAwMCBuDQowMDAwMTUzNTY4IDAwMDAwIG4NCjAwMDAxNTQwNjkgMDAwMDAgbg0KMDAw MDE1NDMwOSAwMDAwMCBuDQowMDAwMTU0MzU2IDAwMDAwIG4NCjAwMDAxNTQzNzggMDAwMDAgbg0K MDAwMDE1NDc4NSAwMDAwMCBuDQowMDAwMTU0ODA3IDAwMDAwIG4NCjAwMDAxNTU1ODAgMDAwMDAg bg0KMDAwMDE1NTgzMiAwMDAwMCBuDQowMDAwMTU1ODc5IDAwMDAwIG4NCjAwMDAxNTU5MDEgMDAw MDAgbg0KMDAwMDE1NjMwOCAwMDAwMCBuDQowMDAwMTU2MzMwIDAwMDAwIG4NCjAwMDAxNTcxMzMg MDAwMDAgbg0KMDAwMDE1NzM4NSAwMDAwMCBuDQowMDAwMTU3NDMyIDAwMDAwIG4NCjAwMDAxNTc0 NTQgMDAwMDAgbg0KMDAwMDE1Nzg2MSAwMDAwMCBuDQowMDAwMTU3ODgzIDAwMDAwIG4NCjAwMDAx NTg2MTIgMDAwMDAgbg0KMDAwMDE1ODg2NCAwMDAwMCBuDQowMDAwMTU4OTExIDAwMDAwIG4NCjAw MDAxNTg5MzMgMDAwMDAgbg0KMDAwMDE1OTM0MCAwMDAwMCBuDQowMDAwMTU5MzYyIDAwMDAwIG4N CjAwMDAxNTk5ODAgMDAwMDAgbg0KMDAwMDE2MDIyMCAwMDAwMCBuDQowMDAwMTYwMjY3IDAwMDAw IG4NCjAwMDAxNjAyODkgMDAwMDAgbg0KMDAwMDE2MDY5NiAwMDAwMCBuDQowMDAwMTYwNzE4IDAw MDAwIG4NCjAwMDAxNjEyMDMgMDAwMDAgbg0KMDAwMDE2MTQ0MyAwMDAwMCBuDQowMDAwMTYxNDkw IDAwMDAwIG4NCjAwMDAxNjE1MTIgMDAwMDAgbg0KMDAwMDE2MTkxOSAwMDAwMCBuDQowMDAwMTYx OTQxIDAwMDAwIG4NCjAwMDAxNjI2NTYgMDAwMDAgbg0KMDAwMDE2MjkyMCAwMDAwMCBuDQowMDAw MTYyOTY3IDAwMDAwIG4NCjAwMDAxNjI5ODkgMDAwMDAgbg0KMDAwMDE2MzM5NiAwMDAwMCBuDQow MDAwMTYzNDE5IDAwMDAwIG4NCjAwMDAxNjQ3MjYgMDAwMDAgbg0KMDAwMDE2NDk3OCAwMDAwMCBu DQowMDAwMTY1MDI1IDAwMDAwIG4NCjAwMDAxNjUwNDcgMDAwMDAgbg0KMDAwMDE2NTQ1NCAwMDAw MCBuDQowMDAwMTY1NDc3IDAwMDAwIG4NCjAwMDAxNjY2NDIgMDAwMDAgbg0KMDAwMDE2Njg5NCAw MDAwMCBuDQowMDAwMTY2OTQxIDAwMDAwIG4NCjAwMDAxNjY5NjMgMDAwMDAgbg0KMDAwMDE2NzM3 MCAwMDAwMCBuDQowMDAwMTY3MzkzIDAwMDAwIG4NCjAwMDAxNjg2MTUgMDAwMDAgbg0KMDAwMDE2 ODg3OSAwMDAwMCBuDQowMDAwMTY4OTI2IDAwMDAwIG4NCjAwMDAxNjg5NDggMDAwMDAgbg0KMDAw MDE2OTM1NSAwMDAwMCBuDQowMDAwMTY5Mzc4IDAwMDAwIG4NCjAwMDAxNzA1MDcgMDAwMDAgbg0K MDAwMDE3MDc1OSAwMDAwMCBuDQowMDAwMTcwODA2IDAwMDAwIG4NCjAwMDAxNzA4MjggMDAwMDAg bg0KMDAwMDE3MTIzNSAwMDAwMCBuDQowMDAwMTcxMjU3IDAwMDAwIG4NCjAwMDAxNzIwMjcgMDAw MDAgbg0KMDAwMDE3MjI3OSAwMDAwMCBuDQowMDAwMTcyMzI2IDAwMDAwIG4NCjAwMDAxNzIzNDgg MDAwMDAgbg0KMDAwMDE3Mjc1NSAwMDAwMCBuDQowMDAwMTcyNzc3IDAwMDAwIG4NCjAwMDAxNzM3 NjggMDAwMDAgbg0KMDAwMDE3NDAzMiAwMDAwMCBuDQowMDAwMTc0MDc5IDAwMDAwIG4NCjAwMDAx NzQxMDEgMDAwMDAgbg0KMDAwMDE3NDUwOCAwMDAwMCBuDQowMDAwMTc0NTMwIDAwMDAwIG4NCjAw MDAxNzU2MDYgMDAwMDAgbg0KMDAwMDE3NTg1OCAwMDAwMCBuDQowMDAwMTc1OTA1IDAwMDAwIG4N CjAwMDAxNzU5MjcgMDAwMDAgbg0KMDAwMDE3NjMzNCAwMDAwMCBuDQowMDAwMTc2MzU2IDAwMDAw IG4NCjAwMDAxNzczNjEgMDAwMDAgbg0KMDAwMDE3NzYwMSAwMDAwMCBuDQowMDAwMTc3NjQ4IDAw MDAwIG4NCjAwMDAxNzc2NzAgMDAwMDAgbg0KMDAwMDE3ODA3NyAwMDAwMCBuDQowMDAwMTc4MDk5 IDAwMDAwIG4NCjAwMDAxNzg3MzIgMDAwMDAgbg0KMDAwMDE3ODk5NiAwMDAwMCBuDQowMDAwMTc5 MDQzIDAwMDAwIG4NCjAwMDAxNzkwNjUgMDAwMDAgbg0KMDAwMDE3OTQ3MiAwMDAwMCBuDQowMDAw MTc5NDk0IDAwMDAwIG4NCjAwMDAxODAyNTAgMDAwMDAgbg0KMDAwMDE4MDUwMiAwMDAwMCBuDQow MDAwMTgwNTQ5IDAwMDAwIG4NCjAwMDAxODA1NzEgMDAwMDAgbg0KMDAwMDE4MDk3OCAwMDAwMCBu DQowMDAwMTgxMDAxIDAwMDAwIG4NCjAwMDAxODIxODkgMDAwMDAgbg0KMDAwMDE4MjQ1MyAwMDAw MCBuDQowMDAwMTgyNTAwIDAwMDAwIG4NCjAwMDAxODI1MjIgMDAwMDAgbg0KMDAwMDE4MjkyOSAw MDAwMCBuDQowMDAwMTgyOTUxIDAwMDAwIG4NCjAwMDAxODM3NzEgMDAwMDAgbg0KMDAwMDE4NDAy MyAwMDAwMCBuDQowMDAwMTg0MDcwIDAwMDAwIG4NCjAwMDAxODQwOTIgMDAwMDAgbg0KMDAwMDE4 NDQ5OSAwMDAwMCBuDQowMDAwMTg0NTIyIDAwMDAwIG4NCjAwMDAxODU3NzkgMDAwMDAgbg0KMDAw MDE4NjAzMSAwMDAwMCBuDQowMDAwMTg2MDc4IDAwMDAwIG4NCjAwMDAxODYxMDAgMDAwMDAgbg0K MDAwMDE4NjUwNyAwMDAwMCBuDQowMDAwMTg2NTI5IDAwMDAwIG4NCjAwMDAxODc0NTggMDAwMDAg bg0KMDAwMDE4NzY5OCAwMDAwMCBuDQowMDAwMTg3NzQ1IDAwMDAwIG4NCjAwMDAxODc3NjcgMDAw MDAgbg0KMDAwMDE4ODE3MyAwMDAwMCBuDQowMDAwMTg4MTk1IDAwMDAwIG4NCjAwMDAxODkyMTIg MDAwMDAgbg0KMDAwMDE4OTQzOSAwMDAwMCBuDQowMDAwMTg5NDg2IDAwMDAwIG4NCjAwMDAxODk1 MDggMDAwMDAgbg0KMDAwMDE4OTkxNCAwMDAwMCBuDQowMDAwMTg5OTM2IDAwMDAwIG4NCjAwMDAx OTA1MzQgMDAwMDAgbg0KMDAwMDE5MDc5OCAwMDAwMCBuDQowMDAwMTkwODQ1IDAwMDAwIG4NCjAw MDAxOTA4NjcgMDAwMDAgbg0KMDAwMDE5MTI3MyAwMDAwMCBuDQowMDAwMTkxMjk2IDAwMDAwIG4N CjAwMDAxOTI4NzQgMDAwMDAgbg0KMDAwMDE5MzEyNiAwMDAwMCBuDQowMDAwMTkzMTczIDAwMDAw IG4NCjAwMDAxOTMxOTUgMDAwMDAgbg0KMDAwMDE5MzYwMSAwMDAwMCBuDQowMDAwMTkzNjIzIDAw MDAwIG4NCjAwMDAxOTQ1MzcgMDAwMDAgbg0KMDAwMDE5NDc4OSAwMDAwMCBuDQowMDAwMTk0ODM2 IDAwMDAwIG4NCjAwMDAxOTQ4NTggMDAwMDAgbg0KMDAwMDE5NTI2NSAwMDAwMCBuDQowMDAwMTk1 Mjg3IDAwMDAwIG4NCjAwMDAxOTYzMjkgMDAwMDAgbg0KMDAwMDE5NjU4MSAwMDAwMCBuDQowMDAw MTk2NjI4IDAwMDAwIG4NCjAwMDAxOTY2NTAgMDAwMDAgbg0KMDAwMDE5NzA1NiAwMDAwMCBuDQow MDAwMTk3MDc5IDAwMDAwIG4NCjAwMDAxOTg1MjUgMDAwMDAgbg0KMDAwMDE5ODc2NSAwMDAwMCBu DQowMDAwMTk4ODEyIDAwMDAwIG4NCjAwMDAxOTg4MzQgMDAwMDAgbg0KMDAwMDE5OTI0MCAwMDAw MCBuDQowMDAwMTk5MjYyIDAwMDAwIG4NCjAwMDAyMDAwNDUgMDAwMDAgbg0KMDAwMDIwMDI4NSAw MDAwMCBuDQowMDAwMjAwMzMyIDAwMDAwIG4NCjAwMDAyMDAzNTQgMDAwMDAgbg0KMDAwMDIwMDc2 MCAwMDAwMCBuDQowMDAwMjAwNzgyIDAwMDAwIG4NCjAwMDAyMDEzMzEgMDAwMDAgbg0KMDAwMDIw MTU3MSAwMDAwMCBuDQowMDAwMjAxNjE4IDAwMDAwIG4NCjAwMDAyMDE2NDAgMDAwMDAgbg0KMDAw MDIwMjA0NiAwMDAwMCBuDQowMDAwMjAyMDY4IDAwMDAwIG4NCjAwMDAyMDIzOTYgMDAwMDAgbg0K MDAwMDIwNjU1NyAwMDAwMCBuDQowMDAwMjA2NTgwIDAwMDAwIG4NCjAwMDAyMDc2ODAgMDAwMDAg bg0KMDAwMDIwNzk1OSAwMDAwMCBuDQowMDAwMjA5MDU2IDAwMDAwIG4NCjAwMDAyMDkzMzMgMDAw MDAgbg0KMDAwMDIxMDQzNSAwMDAwMCBuDQowMDAwMjEwNzIwIDAwMDAwIG4NCjAwMDAyMTI4OTQg MDAwMDAgbg0KMDAwMDIxMjkxNyAwMDAwMCBuDQowMDAwMjEzMDExIDAwMDAwIG4NCjAwMDAyMTMw MzIgMDAwMDAgbg0KMDAwMDIxMzM3MSAwMDAwMCBuDQowMDAwMjEzNDg5IDAwMDAwIG4NCjAwMDAy MTM2MTQgMDAwMDAgbg0KMDAwMDIxMzczOSAwMDAwMCBuDQowMDAwMjEzODY0IDAwMDAwIG4NCjAw MDAyMTM5ODkgMDAwMDAgbg0KMDAwMDIxNDExNCAwMDAwMCBuDQowMDAwMjE0MjA3IDAwMDAwIG4N CjAwMDAyMTQzMzMgMDAwMDAgbg0KMDAwMDIxNDQxOCAwMDAwMCBuDQp0cmFpbGVyDTw8DS9TaXpl IDg5OQ0vSURbPDBhMDE1M2ZjZTdhNzU0ZDAyMzIxNTNkMmE2MzUyYTAyPjwwYTAxNTNmY2U3YTc1 NGQwMjMyMTUzZDJhNjM1MmEwMj5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN ------_=_NextPart_000_01C0D3BA.F6C35C70-- From owner-mpls@UU.NET Thu May 3 07:31:17 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19081 for ; Thu, 3 May 2001 07:31:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkf13224; Thu, 3 May 2001 11:29:02 GMT Received: by mail-control.mail.uu.net id QQknkf13517 for mpls-outgoing; Thu, 3 May 2001 11:28:29 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknkf13509 for ; Thu, 3 May 2001 11:28:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknkf00457 for ; Thu, 3 May 2001 11:26:34 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknkf00749 for ; Thu, 3 May 2001 11:26:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09298 for mpls@uu.net; Thu, 3 May 2001 07:26:33 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknkf13285 for ; Thu, 3 May 2001 11:25:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkf27145 for ; Thu, 3 May 2001 11:25:26 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQknkf09463 for ; Thu, 3 May 2001 11:25:26 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18822; Thu, 3 May 2001 07:25:24 -0400 (EDT) Message-Id: <200105031125.HAA18822@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-cr-ldp-03.txt Date: Thu, 03 May 2001 07:25:24 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - CR-LDP Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-cr-ldp-03.txt Pages : 15 Date : 02-May-01 This document describes extensions to CR-LDP signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. An RSVP-TE specific description can be found in [GMPLS- RSVP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr-ldp-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-cr-ldp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010502120455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-cr-ldp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-cr-ldp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010502120455.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 3 07:32:16 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19100 for ; Thu, 3 May 2001 07:32:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkg21079; Thu, 3 May 2001 11:30:14 GMT Received: by mail-control.mail.uu.net id QQknkf13523 for mpls-outgoing; Thu, 3 May 2001 11:28:34 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknkf13507 for ; Thu, 3 May 2001 11:28:13 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkf13771 for ; Thu, 3 May 2001 11:27:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknkf11571 for ; Thu, 3 May 2001 11:27:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09344 for mpls@uu.net; Thu, 3 May 2001 07:27:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknkf13454 for ; Thu, 3 May 2001 11:26:54 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkf06902 for ; Thu, 3 May 2001 11:25:31 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQknkf09539 for ; Thu, 3 May 2001 11:25:31 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18838; Thu, 3 May 2001 07:25:29 -0400 (EDT) Message-Id: <200105031125.HAA18838@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-rsvp-te-03.txt Date: Thu, 03 May 2001 07:25:29 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS Signaling - RSVP-TE Extensions Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-rsvp-te-03.txt Pages : 23 Date : 02-May-01 This document describes extensions to RSVP-TE signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents an RSVP-TE specific description of the extensions. A CR-LDP specific description can be found in [GMPLS-LDP]. A generic functional description is presented in [GMPLS-SIG]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-rsvp-te-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-rsvp-te-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010502120507.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-rsvp-te-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-rsvp-te-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010502120507.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 3 07:34:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19127 for ; Thu, 3 May 2001 07:34:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkg16478; Thu, 3 May 2001 11:31:41 GMT Received: by mail-control.mail.uu.net id QQknkg13727 for mpls-outgoing; Thu, 3 May 2001 11:31:11 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknkg13628 for ; Thu, 3 May 2001 11:30:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkf16748 for ; Thu, 3 May 2001 11:29:42 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknkf14169 for ; Thu, 3 May 2001 11:29:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA09420 for mpls@uu.net; Thu, 3 May 2001 07:29:42 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknkf13266 for ; Thu, 3 May 2001 11:25:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkf08908 for ; Thu, 3 May 2001 11:25:22 GMT Received: from ietf.org by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQknkf09384 for ; Thu, 3 May 2001 11:25:21 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18806; Thu, 3 May 2001 07:25:20 -0400 (EDT) Message-Id: <200105031125.HAA18806@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: mpls@UU.NET From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-mpls-generalized-signaling-04.txt Date: Thu, 03 May 2001 07:25:19 -0400 Sender: owner-mpls@UU.NET Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Generalized MPLS - Signaling Functional Description Author(s) : P. Ashwood-Smith et al. Filename : draft-ietf-mpls-generalized-signaling-04.txt Pages : 26 Date : 02-May-01 This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are specified in [GMPLS-RSVP] and [GMPLS-LDP]. Technology specific details are expected to be specified in independent technology specific documents, e.g., [GMPLS-SONET]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mpls-generalized-signaling-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010502120446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mpls-generalized-signaling-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mpls-generalized-signaling-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010502120446.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mpls@UU.NET Thu May 3 09:25:05 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22630 for ; Thu, 3 May 2001 09:25:05 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkn23836; Thu, 3 May 2001 13:23:09 GMT Received: by mail-control.mail.uu.net id QQknkn00823 for mpls-outgoing; Thu, 3 May 2001 13:22:36 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknkn00808 for ; Thu, 3 May 2001 13:22:17 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknkn01549 for ; Thu, 3 May 2001 13:22:08 GMT Received: from hoemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: hoemail2.lucent.com [192.11.226.163]) id QQknkn00148 for ; Thu, 3 May 2001 13:22:07 GMT Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43DM7X09872 for ; Thu, 3 May 2001 09:22:07 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f43DM6X09855 for ; Thu, 3 May 2001 09:22:06 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 15:22:00 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0C34863C@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: mpls-wg Subject: ACTION: Summaries for sub-IP related Internet Drafts Date: Thu, 3 May 2001 15:21:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk ACTION: Summaries for sub-IP related Internet Drafts ----------------------------------------- All, but specifically I-D Authors/Editors Over the last several months, we have seen A LOT of I-Ds submitted/posted which appear to be targeted for one or more WGs in the new sub-IP area. (ccamp, gsmp, ipo, iporpr, tewg, mpls and ppvpn) These are mostly individual I-Ds, that is those that do not start with draft-ietf- but this mesage referrs to ALL I-Ds related to the Sub IP WGs. In fact we believe we have some 200-300 of such documents. It is sort of impossible to try and read them all and decide in which WG (if any) they might fit. So in order to help us (WG chairs and ADs) to work our way through all these documents, we want the AUTHORS/EDITORS of such existing documents to do the following: - Before May 18th, pls send ONE SINGLE email per I-D to the email alias idsummary@subip.ietf.org That email should be formatted and contain content as explained below. Pls DO NOT send these emails to any WG mailing list. The idsummary mailing list will be archived publically at ftp://subip.ietf.org/pub/lists/idsummary* Since these are non-WG documents (yet) any comments/discussion can/should take place at: subip-area@subip.ietf.org But initially the idea is to just collect the data. - When doing a revision of these documents or writing a new I-D, please pls add a section at the beginning of your document that contains the same information we are asking for here so that readers of your document can also see it. All these emails will be archived and the WG chairs, ADs, Technical Advisors and Directorate will review them and report back (target is end of May) what we want to do with each of the documents. If we do not receive a note about an I-D we will assume that the I-D authors/editors do not intend to publish it as a RFC. Further, if you assume this pictorial overview of the work we are doing in the sub-IP area, then pls indicate where in the picture your document fits. --- pictorial overview of work in the sup-IP area -------------- The Working Groups at the top are those that will use the Common Control and Measurement Protocols that we're defining in the CCAMP WG. Applications +-------+ +-------+ (new) Hour glass that use CCAMP: \ | TE-WG | | PPVPN | ... / \ +-------+ +-------+ / \ +----------------------+ / \ | CCAMP | / \ |-----------+----------| / / | C | M --|------ IGP LSA ext / | control | measure | \ / +----------------------+ \ Technologies to / +----+ +----+ +----+ +----+ +----+ \ measure/control:/ |MPLS| |OPT | |RPR | |ATM | | FR |...\ +----+ +----+ +----+ +----+ +----+ The technologies at the bottom allow us to create paths and so those are the ones we want to measure and control via the Common Control and Measurement Protocols coming out of CCAMP. One of those technologies (MPLS) is defined by IETF, others are (have been) defined in other standards organisations. However, we want to focus mainly on the use of such technologies for IP. So for example the IPO and IPORPR WGs are assumed to be active at the bottom because we want to focus on the IP use of such technologies. Bert and Scott -------------------- The ONE SINGLE email per I-D should be as follows: - Subject: the targetWgName is the WG that you as authors/editors think that this document should live in. If you have no specific WG as the target WG, then use subIP as the name. the nameOfID is the filename of the draft, e.g. draft-xxx-yyy-zzz-00.txt - In the body of the email must have the following sections with these section titles: NAME OF I-D: Write it down as a URL so we can click on it to see it. e.g. http://www.ietf.org/internet-drafts/draft-xxx-yyy-zzz-00.txt SUMMARY This should contain a summary of the content of the document Potentially it can be the abstract. But pls make sure that it helps the reader undestand what the document is all about. PLEASE TRY TO KEEP IT DOWN TO TWO PARAGRAPHS RELATED DOCUMENTS A list of URLs for other I-Ds (or non-IETF documents) that you think relate, compete, complement or overlap with your document. "none" if none WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK Applications +-------+ +-------+ (new) Hour glass that use CCAMP: \ | TE-WG | | PPVPN | ... / \ +-------+ +-------+ / \ +----------------------+ / \ | CCAMP | / \ |-----------+----------| / / | C | M --|------ IGP LSA ext / | control | measure | \ / +----------------------+ \ Technologies to / +----+ +----+ +----+ +----+ +----+ \ measure/control:/ |MPLS| |OPT | |RPR | |ATM | | FR |...\ +----+ +----+ +----+ +----+ +----+ WHY IS IT TARGETED AT THIS WG You must explain how the ID addresses a workitem in the current WG charter as listed on the WG charter page on the IETF web site. If it addresses only part of a work item, then please explain if there are other documents that could be merged with this one to become one document to address the complete work item. JUSTIFICATION Why do you think it is justified for the WG to consider this document. In the case that you cannot explain how this document addresses a specific WG charter work item, then explain and justify why the WG should even consider this work and what the description of a possible new work item would be for the WG. Suggest possible milestones for that work item. Please realize, that new work items need wide support within a WG, but also they need agreement from the WG chairs and ADs, and even when they get that, the whole IESG and IAB must review and approve new-work items before they get added to a WG charter. Please understand that we already have a lot of work in our WG charters, and that we would rather see that finished (or at least be well undeway) before we undertake any new work items. From owner-mpls@UU.NET Thu May 3 10:36:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25787 for ; Thu, 3 May 2001 10:36:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknks19088; Thu, 3 May 2001 14:34:08 GMT Received: by mail-control.mail.uu.net id QQknks27083 for mpls-outgoing; Thu, 3 May 2001 14:33:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknks27047 for ; Thu, 3 May 2001 14:33:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknks12538 for ; Thu, 3 May 2001 14:31:47 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknks10766 for ; Thu, 3 May 2001 14:31:47 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13221 for ; Thu, 3 May 2001 10:31:44 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09374 for ; Thu, 3 May 2001 10:31:46 -0400 (EDT) Message-ID: <3AF16BCD.F38AE119@marconi.com> Date: Thu, 03 May 2001 10:31:41 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: A fundamental question References: <008b01c0d29f$c8501b60$77131796@sktelecom.com> <3AF014AF.BFEE065B@marconi.com> <010301c0d38f$7b94b060$77131796@sktelecom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Rae M. Chang" wrote: >> >> MPLS avoids the N^2 problem in two ways: >> 1: The LSPs follow the routing protocols' shortest-paths. Meaning >> you don't necessarily need an LSP to get from everywhere to >> everywhere. Only along the shortest routed paths. > > That's the point I can't understand yet. For example, if you want a > partial meshed network consisting of a set of LSPs, then why > couldn't you make the same network with only neccessary ATM VCs > (not using MPLS)? > Aren't they essentially equivalent TE schemes? Why do they make the > N^2 number of VCs? ATM is not an IP protocol. There is no way that an ATM-specific setup can know what IP routes exist. So if any auto-VC setup is going to happen, it must either be traffic-driven (which will not perform well in a network core) or a full-mesh must be pre-established. Now, if you want to go and invent a new ATM that uses IP routing protocols in order to fix this, go right ahead. But that's not what MPLS is trying to do. -- David From owner-mpls@UU.NET Thu May 3 11:38:08 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27579 for ; Thu, 3 May 2001 11:38:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkw28795; Thu, 3 May 2001 15:36:13 GMT Received: by mail-control.mail.uu.net id QQknkw25086 for mpls-outgoing; Thu, 3 May 2001 15:35:36 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknkw25054 for ; Thu, 3 May 2001 15:35:19 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknkw03254 for ; Thu, 3 May 2001 15:35:11 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknkw00388 for ; Thu, 3 May 2001 15:35:10 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21027 for ; Thu, 3 May 2001 11:35:07 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00011 for ; Thu, 3 May 2001 11:35:09 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 11:34:59 -0400 Message-ID: <39469E08BD83D411A3D900204840EC553095A9@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "Charlap, David" , mpls@UU.NET Subject: RE: A fundamental question Date: Thu, 3 May 2001 11:35:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi David Please look at my inline comments: -> There is no way that an ATM-specific setup can know what IP routes -> exist. So if any auto-VC setup is going to happen, it must either be -> traffic-driven (which will not perform well in a network core) or a -> full-mesh must be pre-established. There were protocols, like I-PNNI and PAR (PNNI Augmented Routing) developed long before MPLS started which does the same job you stated. And there was IETF Working group ION (Internetworking Over NBMA) also. -> Now, if you want to go and invent a new ATM that uses IP routing -> protocols in order to fix this, go right ahead. But that's not what -> MPLS is trying to do. I accept, For that matter, MPLS has learned all good experiences from ATM MPOA, Ipsilon's IP Switching, Cisco's Tag Switching, IBM's ARIS, Toshiba's CSR and so many trailed proprietary switching technologies. [snip] -> ATM's routing and signaling protocols are closely tied to ATM's -> addressing architecture. These protocols are not based on -> IP, and they -> do not scale up to networks the size of the internet. No David, These (ATM Signaling/Routing) protocols are very much designed to scale for networks as large as 'I'nternet. Esp designed keeping in mind with the growth of the Internet & addressing. But they didn't get (we didn't give) chance to let them prove. -> ATM is not an IP protocol. I accept! To conclude MPLS is making "connection-less IP to connection oriented (at the core) with the power of so many L2 technologies integrated and a single IP L3 network overlaid on top of so many L2s efficiently." And all those other L3 protocols/networks designed for all specific L2's are no more! -Venkata Naidu From owner-mpls@UU.NET Thu May 3 11:47:57 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27837 for ; Thu, 3 May 2001 11:47:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknkx25200; Thu, 3 May 2001 15:45:34 GMT Received: by mail-control.mail.uu.net id QQknkw26374 for mpls-outgoing; Thu, 3 May 2001 15:44:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknkw26365 for ; Thu, 3 May 2001 15:44:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknkw24563 for ; Thu, 3 May 2001 15:44:23 GMT Received: from cmailg3.svr.pol.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmailg3.svr.pol.co.uk [195.92.195.173]) id QQknkw23933 for ; Thu, 3 May 2001 15:44:23 GMT Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14vLH9-0008Dm-00; Thu, 03 May 2001 16:44:19 +0100 Received: from modem-97.hoary-redpoll.dialup.pol.co.uk ([62.137.196.97] helo=BLIULAPTOP) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14vLH8-0004hI-00; Thu, 03 May 2001 16:44:19 +0100 Message-ID: <04e801c0d3e7$d0200780$101a883e@movaz.com> From: "Adrian Farrel" To: Cc: "'mpls@uu.net'" References: <01C0D3C3.08AFDB40.srikn@future.futsoft.com> Subject: Re: Doubt in mpls-generalized-signaling Date: Thu, 3 May 2001 11:41:35 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk Hi, Srikanth, > I have few doubts in mpls-generalized-signaling draft. > > 2.) How does an ingress decide about the nature of LSP to be requested > (whether unidirectional or Bidirectional)? Is there any mib object for > this or is it by default Bidirectional if supportable. Yes! Watch out for draft-nadeau-mpls-gmpls-te-mib-00.txt which will be published one day very soon. Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com From owner-mpls@UU.NET Thu May 3 12:47:11 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29886 for ; Thu, 3 May 2001 12:47:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknla15825; Thu, 3 May 2001 16:44:53 GMT Received: by mail-control.mail.uu.net id QQknla25811 for mpls-outgoing; Thu, 3 May 2001 16:44:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknla25805 for ; Thu, 3 May 2001 16:44:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknla11901 for ; Thu, 3 May 2001 16:43:53 GMT Received: from rsys000a.roke.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [193.118.201.102]) id QQknla15921 for ; Thu, 3 May 2001 16:43:52 GMT Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 3 May 2001 17:47:38 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2650.21) id ; Thu, 3 May 2001 17:43:51 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4185832C4@rsys002a.roke.co.uk> From: "Reeve, Andrew" To: "'mpls@uu.net'" Subject: Efficient teardown on error/preemption Date: Thu, 3 May 2001 17:43:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Please could somebody clarify the operation of GMPLS-RSVP wrt the following. draft-ietf-mpls-generalized-rsvp-te-02.txt supports "Removing State with a PathErr message" (section 4.4). This is aimed at speeding up the removal of state. As I understand it, it works as follows. When an error occurs (including preemption I assume), the node detecting the error will send a PathErr to the initiator and a PathTear to the responder. The PathErr will have a flag ("Path State Remove") set which indicates that state has been removed, and all nodes receiving the PathErr will co-operate by removing state and keeping the flag set. Is it the intention that, for TE tunnels and lightpaths, the PathTear and PathError will remove ALL state, or do we also have to follow up with a ResvTear? Also, is behavior consistent for both preemption and network errors? For reasons of signaling efficiency and responsiveness to errors, we would like it to be possible to destroy all state for a LSP, whether it be a TE tunnel or bi-directional using 1 of the following: a) PathTear from the initiator. b) PathError and PathTear from an intermediate node (directed at the initiator and responder respectively) c) ResvTear from the responder. Is that how it works? Your help appreciated, Andy > __________________________ > Andy Reeve, > Senior Consultant, > Internet Technology and Networks. __________________________ > Roke Manor Research Ltd, > A SIEMENS Company. > > Roke Manor, > Romsey. SO51 OZN. > > Tel: +44 1794 833580 > Fax: +44 1794 833616 > > mailto:andrew.reeve@roke.co.uk > > http://www.roke.co.uk > http://www.roke-manor.com > __________________________ The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-mpls@UU.NET Thu May 3 13:45:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01599 for ; Thu, 3 May 2001 13:45:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknle05163; Thu, 3 May 2001 17:43:45 GMT Received: by mail-control.mail.uu.net id QQknle20868 for mpls-outgoing; Thu, 3 May 2001 17:43:09 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknle20849 for ; Thu, 3 May 2001 17:43:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknle03624 for ; Thu, 3 May 2001 17:41:40 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknle01393 for ; Thu, 3 May 2001 17:41:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA05991 for mpls@uu.net; Thu, 3 May 2001 13:41:34 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknle20607 for ; Thu, 3 May 2001 17:41:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknle01206 for ; Thu, 3 May 2001 17:40:55 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQknle29864 for ; Thu, 3 May 2001 17:40:54 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f43Hdbm14861; Thu, 3 May 2001 13:39:37 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (ch2-dhcp134-206.cisco.com [161.44.134.206]) by bucket.cisco.com (Mirapoint) with ESMTP id ABE15405; Thu, 3 May 2001 13:40:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20010503133942.0193c1d8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 May 2001 13:43:09 -0400 To: "Adrian Farrel" , From: "Thomas D. Nadeau" Subject: Re: Doubt in mpls-generalized-signaling Cc: "'mpls@uu.net'" In-Reply-To: <04e801c0d3e7$d0200780$101a883e@movaz.com> References: <01C0D3C3.08AFDB40.srikn@future.futsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 11:41 AM 5/3/2001 -0400, Adrian Farrel wrote: >Hi, Srikanth, > > > I have few doubts in mpls-generalized-signaling draft. > > > > 2.) How does an ingress decide about the nature of LSP to >be requested > > (whether unidirectional or Bidirectional)? Is there any >mib object for > > this or is it by default Bidirectional if supportable. > >Yes! > >Watch out for draft-nadeau-mpls-gmpls-te-mib-00.txt which >will be published one day very soon. This was sent to the internet-drafts editor on Monday. Not sure where it is. In the meantime, the MIB is available at: ftp://anonymous@ftp-eng.cisco.com/tnadeau/draft-nadeau-gmpls-te-mib-00.txt --Tom >Adrian >-- >Adrian Farrel >Movaz Networks Inc. >afarrel@movaz.com From owner-mpls@UU.NET Thu May 3 13:53:58 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01802 for ; Thu, 3 May 2001 13:53:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknlf22991; Thu, 3 May 2001 17:52:02 GMT Received: by mail-control.mail.uu.net id QQknlf22038 for mpls-outgoing; Thu, 3 May 2001 17:51:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknlf21955 for ; Thu, 3 May 2001 17:51:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknlf17820 for ; Thu, 3 May 2001 17:48:56 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknlf19334 for ; Thu, 3 May 2001 17:48:56 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f43Hmsn14907 for ; Thu, 3 May 2001 10:48:55 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA11258 for mpls@uu.net; Thu, 3 May 2001 13:48:53 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknle20051 for ; Thu, 3 May 2001 17:36:47 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknle09196 for ; Thu, 3 May 2001 17:36:21 GMT Received: from thalia.fm.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: fmfdns02.fm.intel.com [132.233.247.11]) id QQknle02645 for ; Thu, 3 May 2001 17:36:21 GMT Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id RAA29982 for ; Thu, 3 May 2001 17:36:20 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 03 May 2001 17:36:18 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 10:36:16 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18AC5@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'mpls@uu.net'" Subject: terminology Date: Thu, 3 May 2001 10:36:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Sorry, sent previous message prematurely. Once again... The definitions "LSP tunnel" in the docs seem to be somewhat misleading. For example, section 3.27.3 of RFC 3031 states: "It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. ... This is called a "LSP Tunnel." This is standard MPLS as far as I tell. Why rename it? Also, section 1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt states: "Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel." Again this seems to be just normal use of MPLS. The text implies that an LSP tunnel is a special case of MPLS. Is there any other use of MPLS? Thanks! Gery XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X Gerhard W. Gross, Ph.D. X X Intel X X 2111 NE 25th Ave X X Hillsboro, OR 97124-5961, USA X X Internet Infrastructure Arch. Group X X - Internet and Communication Lab X X phone: (503) 264-6389 X X fax: (503) 264-3483 X X email: gerhard.gross@intel.com X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX From owner-mpls@UU.NET Thu May 3 14:44:52 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03113 for ; Thu, 3 May 2001 14:44:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknli09966; Thu, 3 May 2001 18:42:41 GMT Received: by mail-control.mail.uu.net id QQknli16312 for mpls-outgoing; Thu, 3 May 2001 18:42:07 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknli16301 for ; Thu, 3 May 2001 18:42:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknli06293 for ; Thu, 3 May 2001 18:40:52 GMT Received: from shared1-mail.whowhere.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: shared1-batch.whowhere.com [209.185.123.82]) id QQknli07796 for ; Thu, 3 May 2001 18:40:52 GMT Received: from Unknown/Local ([?.?.?.?]) by shared1-mail.whowhere.com; Thu May 3 11:40:35 2001 To: mpls@UU.NET Date: Thu, 03 May 2001 11:40:35 -0700 From: "Lyndon Ong" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: lyndon_ong@eudoramail.com X-Mailer: MailCity Service Subject: RE: A fundamental question X-Sender-Ip: 63.96.78.21 Organization: QUALCOMM Eudora Web-Mail (http://www.eudoramail.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 3 May 2001 11:35:08 Naidu, Venkata wrote: >Hi David >[snip] >-> ATM's routing and signaling protocols are closely tied to ATM's >-> addressing architecture. These protocols are not based on >-> IP, and they >-> do not scale up to networks the size of the internet. > >No David, These (ATM Signaling/Routing) protocols are very much designed >to scale for networks as large as 'I'nternet. Esp designed keeping in mind >with the growth of the Internet & addressing. But they didn't get >(we didn't give) chance to let them prove. If you compare PNNI routing vs. OSPF and PNNI setup (Q.2931) vs. RSVP-TE, I find it also difficult to see some major difference in scalability. If anything, RSVP-TE has more scalability problems due to the refreshes, which people are now trying to fix. >-> ATM is not an IP protocol. No argument there :o) Cheers, L. Ong Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com From owner-mpls@UU.NET Thu May 3 15:18:34 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04592 for ; Thu, 3 May 2001 15:18:34 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknll19902; Thu, 3 May 2001 19:16:28 GMT Received: by mail-control.mail.uu.net id QQknll08970 for mpls-outgoing; Thu, 3 May 2001 19:15:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknll08964 for ; Thu, 3 May 2001 19:15:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknlk02174 for ; Thu, 3 May 2001 19:14:27 GMT Received: from mail12.svr.pol.co.uk by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail12.svr.pol.co.uk [195.92.193.215]) id QQknlk21374 for ; Thu, 3 May 2001 19:14:26 GMT Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14vOYU-0002dC-00 for mpls@uu.net; Thu, 03 May 2001 20:14:26 +0100 Received: from modem-40.allards-clownfish.dialup.pol.co.uk ([62.136.212.40] helo=BLIULAPTOP) by mail18.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14vOYT-0000uf-00 for mpls@UU.NET; Thu, 03 May 2001 20:14:25 +0100 Message-ID: <051e01c0d405$29fd3940$101a883e@movaz.com> From: "Adrian Farrel" Cc: "'mpls@uu.net'" References: <01C0D3C3.08AFDB40.srikn@future.futsoft.com> <4.3.2.7.2.20010503133942.0193c1d8@bucket.cisco.com> Subject: Re: Doubt in mpls-generalized-signaling Date: Thu, 3 May 2001 15:13:39 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-mpls@UU.NET Precedence: bulk I think the link should read ftp://ftp-eng.cisco.com/tnadeau/draft-nadeau-gmpls-te-mib-00 .txt Regards, Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: "Thomas D. Nadeau" To: "Adrian Farrel" ; Cc: "'mpls@uu.net'" Sent: Thursday, May 03, 2001 1:43 PM Subject: Re: Doubt in mpls-generalized-signaling > At 11:41 AM 5/3/2001 -0400, Adrian Farrel wrote: > >Hi, Srikanth, > > > > > I have few doubts in mpls-generalized-signaling draft. > > > > > > 2.) How does an ingress decide about the nature of LSP to > >be requested > > > (whether unidirectional or Bidirectional)? Is there any > >mib object for > > > this or is it by default Bidirectional if supportable. > > > >Yes! > > > >Watch out for draft-nadeau-mpls-gmpls-te-mib-00.txt which > >will be published one day very soon. > > This was sent to the internet-drafts editor > on Monday. Not sure where it is. In the meantime, > the MIB is available at: > > ftp://anonymous@ftp-eng.cisco.com/tnadeau/draft-nadeau-gmpls -te-mib-00.txt > > --Tom > > > > > > >Adrian > >-- > >Adrian Farrel > >Movaz Networks Inc. > >afarrel@movaz.com > From owner-mpls@UU.NET Thu May 3 15:25:47 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04849 for ; Thu, 3 May 2001 15:25:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknll27803; Thu, 3 May 2001 19:23:37 GMT Received: by mail-control.mail.uu.net id QQknll09934 for mpls-outgoing; Thu, 3 May 2001 19:23:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknll09915 for ; Thu, 3 May 2001 19:22:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknll23353 for ; Thu, 3 May 2001 19:21:32 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknll06612 for ; Thu, 3 May 2001 19:21:32 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13803 for ; Thu, 3 May 2001 15:21:28 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17387 for ; Thu, 3 May 2001 15:21:30 -0400 (EDT) Message-ID: <3AF1AFB6.14BFE11A@marconi.com> Date: Thu, 03 May 2001 15:21:26 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: Scaling RSVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Lyndon Ong wrote: > > If anything, RSVP-TE has more scalability problems due to the > refreshes, which people are now trying to fix. RSVP-TE, as documented in the lsp-tunnel-08 draft, and RSVP as documented in RFC 2205 have scalability problems, as you say. But the solution already exists. If reliable message delivery (part of RFC 2961) is used in conjunction with the Hello mechanism (from the RSVP-TE draft), then refresh intervals may be increased to extremely long durations (days or weeks if you like) without breaking functionality. Of course, both of these features must be active for this to work. Without Hellos, you need a short refresh interval in order to detect soft failures (that is, failures which don't result in a loss of carrier on the interface). Without reliable message delivery, you need a short refresh interval to compensate for any lost packets. IMO, RSVP-TE with the reliable message delivery extension, should be scalable to the exact same degree that CR-LDP is. -- David From owner-mpls@UU.NET Thu May 3 15:57:28 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06669 for ; Thu, 3 May 2001 15:57:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknln01642; Thu, 3 May 2001 19:55:02 GMT Received: by mail-control.mail.uu.net id QQknln13064 for mpls-outgoing; Thu, 3 May 2001 19:54:28 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknln13032 for ; Thu, 3 May 2001 19:54:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknln27167 for ; Thu, 3 May 2001 19:52:31 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknln29013 for ; Thu, 3 May 2001 19:52:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17097 for ; Thu, 3 May 2001 15:52:27 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28491 for ; Thu, 3 May 2001 15:52:27 -0400 (EDT) Message-ID: <3AF1B6EC.840E30C1@marconi.com> Date: Thu, 03 May 2001 15:52:12 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: terminology References: <4148FEAAD879D311AC5700A0C969E89006E18AC5@orsmsx35.jf.intel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Gross, Gerhard" wrote: > > The definitions "LSP tunnel" in the docs seem to be somewhat > misleading. For example, section 3.27.3 of RFC 3031 states: > > "It is possible to implement a tunnel as a LSP, and use label > switching rather than network layer encapsulation to cause the > packet to travel through the tunnel. ... > This is called a "LSP Tunnel." > > This is standard MPLS as far as I tell. > Why rename it? The definition of "tunnel" seems to be different in different documents. In RSVP-TE, a tunnel is a collection of one or more LSPs that are all signaled with the same SESSION object. (Session being defined as the triplet egress-address, tunnel-ID, and extended-tunnel-ID.) If extended tunnel ID is zero, these LSPs may originate from different ingress routers. The distinction is important because all LSPs in a single tunnel will share resources where possible, when an SE-style reservation is used. Colloquially, this is the definition I usually use. I usually say "tunnel" when I mean a collection of LSPs that share a common destination. If I mean a single LSP, I just say "LSP". But this is not RFC 3031's definition. RFC 3031 defines a "tunneled packet" as any packet that is forwarded to a not-directly-attached router. A tunnel is defined as any means for making this work. It then goes on to define three kinds of tunnels, the first two don't necessarily involve MPLS. The first is a hop-by-hop routed tunnel. The data is encapsulated in a network-layer header that gets it to the next-hop router. One possible non-MPLS example of this might be an IP-in-IP tunnel. The second is an explicitly-routed tunnel. The data is encapsulated in a network-layer header that is explicitly routed to the next-hop router. One possible non-MPLS example of this might be an ATM PVC. The third is the LSP tunnel. The data is labeled and forwarded using MPLS. If my understanding is incorrect, hopefully one of the RFC authors will be able to correct me. -- David From owner-mpls@UU.NET Thu May 3 16:29:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08700 for ; Thu, 3 May 2001 16:29:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknlp16668; Thu, 3 May 2001 20:27:34 GMT Received: by mail-control.mail.uu.net id QQknlp05628 for mpls-outgoing; Thu, 3 May 2001 20:27:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknlp05621 for ; Thu, 3 May 2001 20:26:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknlp13772 for ; Thu, 3 May 2001 20:26:23 GMT Received: from dnsmx1rrc.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQknlp04001 for ; Thu, 3 May 2001 20:26:23 GMT Received: from notes870.cc.telcordia.com (notes870.cc.telcordia.com [128.96.244.12]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA12263; Thu, 3 May 2001 16:18:49 -0400 (EDT) Subject: Re: terminology To: David Charlap Cc: "'mpls@uu.net'" From: "Anuj Bhatnagar" Date: Thu, 3 May 2001 16:18:48 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes870/Telcordia(Release 5.0.6a |January 17, 2001) at 05/03/2001 04:18:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk If what you are saying is true then what is a Traffic Trunk? Regards, Anuj David Charlap on 05/03/2001 03:52:12 PM To: "'mpls@uu.net'" cc: (bcc: Anuj Bhatnagar/Telcordia) Subject: Re: terminology "Gross, Gerhard" wrote: > > The definitions "LSP tunnel" in the docs seem to be somewhat > misleading. For example, section 3.27.3 of RFC 3031 states: > > "It is possible to implement a tunnel as a LSP, and use label > switching rather than network layer encapsulation to cause the > packet to travel through the tunnel. ... > This is called a "LSP Tunnel." > > This is standard MPLS as far as I tell. > Why rename it? The definition of "tunnel" seems to be different in different documents. In RSVP-TE, a tunnel is a collection of one or more LSPs that are all signaled with the same SESSION object. (Session being defined as the triplet egress-address, tunnel-ID, and extended-tunnel-ID.) If extended tunnel ID is zero, these LSPs may originate from different ingress routers. The distinction is important because all LSPs in a single tunnel will share resources where possible, when an SE-style reservation is used. Colloquially, this is the definition I usually use. I usually say "tunnel" when I mean a collection of LSPs that share a common destination. If I mean a single LSP, I just say "LSP". But this is not RFC 3031's definition. RFC 3031 defines a "tunneled packet" as any packet that is forwarded to a not-directly-attached router. A tunnel is defined as any means for making this work. It then goes on to define three kinds of tunnels, the first two don't necessarily involve MPLS. The first is a hop-by-hop routed tunnel. The data is encapsulated in a network-layer header that gets it to the next-hop router. One possible non-MPLS example of this might be an IP-in-IP tunnel. The second is an explicitly-routed tunnel. The data is encapsulated in a network-layer header that is explicitly routed to the next-hop router. One possible non-MPLS example of this might be an ATM PVC. The third is the LSP tunnel. The data is labeled and forwarded using MPLS. If my understanding is incorrect, hopefully one of the RFC authors will be able to correct me. -- David From owner-mpls@UU.NET Thu May 3 16:53:44 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09660 for ; Thu, 3 May 2001 16:53:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknlr09197; Thu, 3 May 2001 20:51:46 GMT Received: by mail-control.mail.uu.net id QQknlr08218 for mpls-outgoing; Thu, 3 May 2001 20:51:11 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknlr08193 for ; Thu, 3 May 2001 20:50:54 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknlr12708 for ; Thu, 3 May 2001 20:47:50 GMT Received: from tomp.smb.utfors.se by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tomp.smb.utfors.se [195.58.112.6]) id QQknlr24002 for ; Thu, 3 May 2001 20:47:49 GMT Received: from utfors.se ([195.58.105.103]) by tomp.smb.utfors.se (Netscape Messaging Server 4.15) with ESMTP id GCS1VJ00.133; Thu, 3 May 2001 22:50:07 +0200 Message-ID: <3AF1C3EE.517575EA@utfors.se> Date: Thu, 03 May 2001 22:47:42 +0200 From: "Loa Andersson" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Anuj Bhatnagar CC: David Charlap , "'mpls@uu.net'" Subject: Re: terminology References: Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQknlr09197 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA09660 All, I agree with David on the use of LSP. I tend to use MPLS tunnel in contexts where I have a label stack of more than one label, but ain't religious about it. Alternatively (and including the first useage) I may use MPLS tunnel for an LSP that I can use to send labeled or un-labeled packet over (through?) to reach a certain point in the network and that do not require that I do a hop-by-hop setup to reach this point. Traffic Trunk I would prefer to use for something that has a specific structure (could very well be an MPLS tunnel = LSP). /Loa Anuj Bhatnagar wrote: > > If what you are saying is true then what is a Traffic Trunk? > > Regards, > Anuj > > David Charlap on 05/03/2001 03:52:12 PM > > To: "'mpls@uu.net'" > cc: (bcc: Anuj Bhatnagar/Telcordia) > Subject: Re: terminology > > "Gross, Gerhard" wrote: > > > > The definitions "LSP tunnel" in the docs seem to be somewhat > > misleading. For example, section 3.27.3 of RFC 3031 states: > > > > "It is possible to implement a tunnel as a LSP, and use label > > switching rather than network layer encapsulation to cause the > > packet to travel through the tunnel. ... > > This is called a "LSP Tunnel." > > > > This is standard MPLS as far as I tell. > > Why rename it? > > The definition of "tunnel" seems to be different in different documents. > > In RSVP-TE, a tunnel is a collection of one or more LSPs that are all > signaled with the same SESSION object. (Session being defined as the > triplet egress-address, tunnel-ID, and extended-tunnel-ID.) If extended > tunnel ID is zero, these LSPs may originate from different ingress > routers. The distinction is important because all LSPs in a single > tunnel will share resources where possible, when an SE-style reservation > is used. > > Colloquially, this is the definition I usually use. I usually say > "tunnel" when I mean a collection of LSPs that share a common > destination. If I mean a single LSP, I just say "LSP". > > But this is not RFC 3031's definition. RFC 3031 defines a "tunneled > packet" as any packet that is forwarded to a not-directly-attached > router. A tunnel is defined as any means for making this work. > > It then goes on to define three kinds of tunnels, the first two don't > necessarily involve MPLS. > > The first is a hop-by-hop routed tunnel. The data is encapsulated in a > network-layer header that gets it to the next-hop router. One possible > non-MPLS example of this might be an IP-in-IP tunnel. > > The second is an explicitly-routed tunnel. The data is encapsulated in > a network-layer header that is explicitly routed to the next-hop > router. One possible non-MPLS example of this might be an ATM PVC. > > The third is the LSP tunnel. The data is labeled and forwarded using > MPLS. > > If my understanding is incorrect, hopefully one of the RFC authors will > be able to correct me. > > -- David -- Loa Andersson Chief Architect, Utfors Research, Architecture and Future Lab (URAX) Utfors AB Råsundavägen 12 Box 525, 169 29 Solna Office +46 8 5270 2000 Office direct +46 8 5270 5038 Mobile +46 70 848 5038 Email loa.andersson@utfors.se WWW www.utfors.se From owner-mpls@UU.NET Thu May 3 19:42:55 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15107 for ; Thu, 3 May 2001 19:42:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknmc19414; Thu, 3 May 2001 23:40:51 GMT Received: by mail-control.mail.uu.net id QQknmc19273 for mpls-outgoing; Thu, 3 May 2001 23:40:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknmc19254 for ; Thu, 3 May 2001 23:39:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknmc01006 for ; Thu, 3 May 2001 23:39:30 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknmc15128 for ; Thu, 3 May 2001 23:39:29 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id TAA00512 for mpls@uu.net; Thu, 3 May 2001 19:39:29 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknmc19057 for ; Thu, 3 May 2001 23:35:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknmc19366 for ; Thu, 3 May 2001 23:34:32 GMT Received: from jasmine1.ad.jasminenetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: adsl-63-202-10-98.dsl.snfc21.pacbell.net [63.202.10.98]) id QQknmc28810 for ; Thu, 3 May 2001 23:34:32 GMT Received: by jasmine1.ad.jasminenetworks.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 16:33:28 -0700 Message-ID: From: Vishal Sharma To: "'David Charlap'" , "'mpls@uu.net'" Cc: "'gerhard.gross@intel.com'" Subject: RE: terminology Date: Thu, 3 May 2001 16:33:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk David, I agree with your characterization below. Even the paragraph quoted by Gerhard from RFC 3031 makes sense in the context in which you've explained it. Namely, if we define a "tunnel" as being any means of making a packet arrive at a non-directly-attached router, then an LSP may be viewed as one realization of a tunnel. (Even in that case, however, why don't we just settle on the term "tunnel". I guess one could argue that the phrase "LSP tunnel" is a bit more descriptive, in that it indicates how the tunnel in question is being realized; through an LSP.) Although, I am not sure that any of the documents actually states things the way you've defined them (which would make things much clearer for us all). I still have a problem (and have had for quite some time), however, with the RSVP-TE draft, since it uses the term "tunnel" in contradictory and confusing ways. The following is an excerpt taken directly from Section 1.0 of the RSVP-TE draft: "Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel. LSP tunnels allow the implementation of a variety of policies related to network performance optimization. For example, LSP tunnels can be automatically or manually routed away from network failures, congestion, and bottlenecks. Furthermore, multiple parallel LSP tunnels can be established between two nodes, and traffic between the two nodes can be mapped onto the LSP tunnels according to local policy. Although traffic engineering (that is, performance optimization of operational networks) is expected to be an important application of this specification, the extended RSVP protocol can be used in a much wider context. The purpose of this document is to describe the use of RSVP to establish LSP tunnels. The intent is to fully describe all the objects, packet formats, and procedures required to realize interoperable implementations. A few new objects are also defined that enhance management and diagnostics of LSP tunnels." As one reads through this, one might conclude that this part actually uses the term "LSP tunnel" in the same way that RFC 3031 uses it, and in the way that you've defined it. However, as you've observed yourself, later on in the same draft the term "LSP tunnel" is applied to something quite different; a collection of LSPs that share a common destination, or, more precisely, a common SESSION object. This latter use is very specific and quite different from what one is lead to believe in the Introduction, and indeed in much of the draft. If we agree that the commonly accepted definition of "tunnel" is what you've defined (and which I've paraphrased above), and, if we agree that the term "LSP tunnel" is, in fact, merely another term for an LSP, with the additional connotation that the LSP can be used to realize a "tunnel," (which is a bit of a stretch, since every LSP is after all an "LSP tunnel"), then clearly, the "collection of LSPs sharing a common SESSION object" needs a different term. I don't know what yet, but a different term. -Vishal > -----Original Message----- > From: David Charlap [mailto:david.charlap@marconi.com] > Sent: Thursday, May 03, 2001 12:52 PM > To: 'mpls@uu.net' > Subject: Re: terminology > > > "Gross, Gerhard" wrote: > > > > The definitions "LSP tunnel" in the docs seem to be somewhat > > misleading. For example, section 3.27.3 of RFC 3031 states: > > > > "It is possible to implement a tunnel as a LSP, and use label > > switching rather than network layer encapsulation to cause the > > packet to travel through the tunnel. ... > > This is called a "LSP Tunnel." > > > > This is standard MPLS as far as I tell. > > Why rename it? > > The definition of "tunnel" seems to be different in different > documents. > > In RSVP-TE, a tunnel is a collection of one or more LSPs that are all > signaled with the same SESSION object. (Session being defined as the > triplet egress-address, tunnel-ID, and extended-tunnel-ID.) > If extended > tunnel ID is zero, these LSPs may originate from different ingress > routers. The distinction is important because all LSPs in a single > tunnel will share resources where possible, when an SE-style > reservation > is used. > > Colloquially, this is the definition I usually use. I usually say > "tunnel" when I mean a collection of LSPs that share a common > destination. If I mean a single LSP, I just say "LSP". > > But this is not RFC 3031's definition. RFC 3031 defines a "tunneled > packet" as any packet that is forwarded to a not-directly-attached > router. A tunnel is defined as any means for making this work. > > It then goes on to define three kinds of tunnels, the first two don't > necessarily involve MPLS. > > The first is a hop-by-hop routed tunnel. The data is > encapsulated in a > network-layer header that gets it to the next-hop router. > One possible > non-MPLS example of this might be an IP-in-IP tunnel. > > The second is an explicitly-routed tunnel. The data is > encapsulated in > a network-layer header that is explicitly routed to the next-hop > router. One possible non-MPLS example of this might be an ATM PVC. > > The third is the LSP tunnel. The data is labeled and forwarded using > MPLS. > > If my understanding is incorrect, hopefully one of the RFC > authors will > be able to correct me. > > -- David > From owner-mpls@UU.NET Fri May 4 10:06:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12747 for ; Fri, 4 May 2001 10:06:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoi00913; Fri, 4 May 2001 14:03:52 GMT Received: by mail-control.mail.uu.net id QQknoi26110 for mpls-outgoing; Fri, 4 May 2001 14:03:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknoi25650 for ; Fri, 4 May 2001 14:02:59 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknoi24079 for ; Fri, 4 May 2001 14:02:21 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknoi03272 for ; Fri, 4 May 2001 14:02:20 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44E2ma00284 for ; Fri, 4 May 2001 07:02:48 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA11863 for mpls@uu.net; Fri, 4 May 2001 10:02:19 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknlp04649 for ; Thu, 3 May 2001 20:18:30 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknlp23143 for ; Thu, 3 May 2001 20:17:09 GMT Received: from hebe.or.intel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns02.or.intel.com [134.134.248.4]) id QQknlp24218 for ; Thu, 3 May 2001 20:17:09 GMT Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id UAA00822 for ; Thu, 3 May 2001 20:17:08 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 03 May 2001 20:17:08 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 May 2001 13:17:06 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18AC4@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'mpls@uu.net'" Subject: terminology Date: Thu, 3 May 2001 10:31:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk The definitions "LSP tunnel" in the docs seem to be somewhat misleading. For example, section 3.27.3 of RFC 3031 states: "It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. ... This is called a "LSP Tunnel." This is standard MPLS as far as I tell. Why rename it? Also, section 1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt states: "Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel." From owner-mpls@UU.NET Fri May 4 11:03:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13835 for ; Fri, 4 May 2001 11:03:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknom09707; Fri, 4 May 2001 15:01:17 GMT Received: by mail-control.mail.uu.net id QQknom21935 for mpls-outgoing; Fri, 4 May 2001 15:00:49 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknom21650 for ; Fri, 4 May 2001 15:00:39 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknol11381 for ; Fri, 4 May 2001 14:59:20 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknol05721 for ; Fri, 4 May 2001 14:59:20 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18727; Fri, 4 May 2001 10:58:45 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01281; Fri, 4 May 2001 10:58:47 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 10:58:35 -0400 Message-ID: <39469E08BD83D411A3D900204840EC553095AD@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'mpls@uu.net'" Cc: "'te-wg@ops.ietf.org'" Subject: QoS in Shared Media Date: Fri, 4 May 2001 10:58:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13835 Hi All I have a doubt regarding "QoS in Shared Media". I don't know how much this is applicable to this discussion list :-) But anyway, I am hearing about 40/10(OC768) Gig Ethernet evolution. If not at the core, these technologies may be at the enterprise/access networks(?). Moreover, The QoS issue is especially interesting over wireless access networks as they are likely to be bottlenecks (compared to wireline links) and they are often shared media (e.g., wire­ less LANs). Providing service differentiation on shared media is difficult due to the risk of collisions between packets of different priority. * So, first, Is MPLS useful/applicable to these technologies? * If so, how the present singling protocols (RSVP/CR-LDP) or diffserv TE extended protocols will take care of this? As far as I know, classical RSVP is designed for such goals and ofcourse, present IP routing protocols also runs on such shared media, P2P and NBMA environments. * In a simple environment Ethernet -> ATM/NBMA -> Ethernet How resource reservation takes place and is there something more the present signaling/routing protocols need to do for QoS guaranties. I didn't find anything useful in TE-WG drafts! Is that I am missing something? Thanks & Regards --Venkata Naidu From owner-mpls@UU.NET Fri May 4 11:11:13 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13963 for ; Fri, 4 May 2001 11:11:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknom12400; Fri, 4 May 2001 15:09:01 GMT Received: by mail-control.mail.uu.net id QQknom01002 for mpls-outgoing; Fri, 4 May 2001 15:08:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknom00944 for ; Fri, 4 May 2001 15:08:10 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknom09608 for ; Fri, 4 May 2001 15:07:39 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknom18271 for ; Fri, 4 May 2001 15:07:39 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA07595 for mpls@uu.net; Fri, 4 May 2001 11:07:38 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknom25208 for ; Fri, 4 May 2001 15:03:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknom18633 for ; Fri, 4 May 2001 15:00:55 GMT Received: from mother.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQknom09089 for ; Fri, 4 May 2001 15:00:55 GMT Received: (qmail 18321 invoked by uid 104); 4 May 2001 15:00:54 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 1.748953 secs); 04/05/2001 08:00:52 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 4 May 2001 15:00:51 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f44F0p119657 for ; Fri, 4 May 2001 08:00:51 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 08:03:12 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C18@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: LSR MIB question Date: Fri, 4 May 2001 08:03:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D4AB.5643E480" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0D4AB.5643E480 Content-Type: text/plain; charset="iso-8859-1" Hi All, If an LSR is the origin point of an MPLS tunnel, and it receives an MPLS packet, it first swaps the top label and pushes a new label on top of that. Which performance statistics are required to be collected by LSR-MIB: The swapped label or the pushed label or both? Yours, Shahram Davari ------_=_NextPart_000_01C0D4AB.5643E480 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C0D4AB.5643E480-- From owner-mpls@UU.NET Fri May 4 11:40:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14687 for ; Fri, 4 May 2001 11:40:44 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoo28684; Fri, 4 May 2001 15:38:51 GMT Received: by mail-control.mail.uu.net id QQknoo13235 for mpls-outgoing; Fri, 4 May 2001 15:38:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknoo13218 for ; Fri, 4 May 2001 15:38:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknoo03715 for ; Fri, 4 May 2001 15:36:45 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQknoo18499 for ; Fri, 4 May 2001 15:36:44 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id GAA02593; Fri, 4 May 2001 06:39:42 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id GAA02537; Fri, 4 May 2001 06:39:42 -0500 From: "Vipul Sharma" To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: LSR MIB question Date: Fri, 4 May 2001 11:36:58 -0400 Message-ID: <015c01c0d4b0$0ee16900$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C18@BBY1EXM01> X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It is my understanding that both stats are to be collected to satisfy the LSR MIB. Each LSR is reqd. to collect stats for in-segments and out-segments on a per LSP basis. In case of a tunnel, it should collect stats on per LSP (which may be agg. in a tunnel) as well as the tunnel (which is a new LSP)from a LSR point of view. Atleast, this is my understanding.... Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Shahram Davari Sent: Friday, May 04, 2001 11:03 AM To: 'mpls@uu.net' Subject: LSR MIB question Hi All, If an LSR is the origin point of an MPLS tunnel, and it receives an MPLS packet, it first swaps the top label and pushes a new label on top of that. Which performance statistics are required to be collected by LSR-MIB: The swapped label or the pushed label or both? Yours, Shahram Davari From owner-mpls@UU.NET Fri May 4 12:01:23 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15312 for ; Fri, 4 May 2001 12:01:17 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknop14913; Fri, 4 May 2001 15:59:37 GMT Received: by mail-control.mail.uu.net id QQknop15648 for mpls-outgoing; Fri, 4 May 2001 15:59:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknop15614 for ; Fri, 4 May 2001 15:58:50 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknop07289 for ; Fri, 4 May 2001 15:57:47 GMT Received: from rsys000a.roke.co.uk by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [193.118.201.102]) id QQknop23526 for ; Fri, 4 May 2001 15:57:47 GMT Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Fri, 4 May 2001 17:01:34 +0100 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 16:57:45 +0100 Message-ID: <76C92FBBFB58D411AE760090271ED4185832D1@rsys002a.roke.co.uk> From: "Reeve, Andrew" To: "'mpls@uu.net'" Subject: signaling preemption in GMPLS RSVP Date: Fri, 4 May 2001 16:57:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Section 4 'Removing State with a PathErr message' in draft-ietf-mpls-generalized-rsvp-te-03.txt makes a welcome improvement to the signaling when LSPs are torn down by the network. I assume that it is intended that the benefits be obtained for any 'network clear'. However the draft mentions its use for 'certain error conditions' without explaining what these are. I suggest that the section be modified to state explicitly that the mechanism can be used anywhere a PathErr is used. In other words it should be possible to use the Path_State_Removed flag for any error and also to use it during preemption. Regards, Andy > __________________________ > Andy Reeve, > Senior Consultant, > Internet Technology and Networks. __________________________ > Roke Manor Research Ltd, > A SIEMENS Company. > > Roke Manor, > Romsey. SO51 OZN. > > Tel: +44 1794 833580 > Fax: +44 1794 833616 > > mailto:andrew.reeve@roke.co.uk > > http://www.roke.co.uk > http://www.roke-manor.com > __________________________ The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-mpls@UU.NET Fri May 4 12:15:35 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15751 for ; Fri, 4 May 2001 12:15:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoq01927; Fri, 4 May 2001 16:13:29 GMT Received: by mail-control.mail.uu.net id QQknoq06040 for mpls-outgoing; Fri, 4 May 2001 16:12:55 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknoq06010 for ; Fri, 4 May 2001 16:12:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknoq00264 for ; Fri, 4 May 2001 16:11:24 GMT Received: from web14302.mail.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web14302.mail.yahoo.com [216.136.173.78]) id QQknoq29409 for ; Fri, 4 May 2001 16:11:23 GMT Message-ID: <20010504161120.77638.qmail@web14302.mail.yahoo.com> Received: from [143.209.238.102] by web14302.mail.yahoo.com; Fri, 04 May 2001 09:11:20 PDT Date: Fri, 4 May 2001 09:11:20 -0700 (PDT) From: Srinivas T M Subject: LDP messages To: mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Is it required to establish PVC if we want to establish LDP session between peers in ATM LSR ? Or any VPI/VCI are reserved for sending LDP messages between two peers like ATM signalling? Thanks, Srini __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Fri May 4 12:47:01 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16640 for ; Fri, 4 May 2001 12:47:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknot09638; Fri, 4 May 2001 16:45:20 GMT Received: by mail-control.mail.uu.net id QQknos09678 for mpls-outgoing; Fri, 4 May 2001 16:44:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknos09656 for ; Fri, 4 May 2001 16:44:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknos25603 for ; Fri, 4 May 2001 16:44:23 GMT From: Satish_Amara@3com.com Received: from topaz.3com.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: topaz.3com.com [192.156.136.158]) id QQknos15384 for ; Fri, 4 May 2001 16:44:22 GMT Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f44Ggd319313; Fri, 4 May 2001 09:42:39 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.1/Switch-2.1.0) with SMTP id f44GiLk23443; Fri, 4 May 2001 09:44:21 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A42.005BED73 ; Fri, 4 May 2001 09:44:05 -0700 X-Lotus-FromDomain: 3COM To: Srinivas T M cc: mpls@UU.NET Message-ID: <88256A42.005BD751.00@hqoutbound.ops.3com.com> Date: Fri, 4 May 2001 11:43:20 -0500 Subject: Re: LDP messages Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi, Refer to section 7 in the following link ... http://www.ietf.org/rfc/rfc3035.txt Satish Amara Srinivas T M on 05/04/2001 11:11:20 AM Sent by: Srinivas T M To: mpls@UU.NET cc: (Satish Amara/MW/US/3Com) Subject: LDP messages Hi, Is it required to establish PVC if we want to establish LDP session between peers in ATM LSR ? Or any VPI/VCI are reserved for sending LDP messages between two peers like ATM signalling? Thanks, Srini __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From owner-mpls@UU.NET Fri May 4 13:20:38 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17389 for ; Fri, 4 May 2001 13:20:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknov15794; Fri, 4 May 2001 17:18:25 GMT Received: by mail-control.mail.uu.net id QQknov02408 for mpls-outgoing; Fri, 4 May 2001 17:17:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknov02372 for ; Fri, 4 May 2001 17:17:34 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknov05233 for ; Fri, 4 May 2001 17:17:31 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknov21556 for ; Fri, 4 May 2001 17:17:31 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00296 for ; Fri, 4 May 2001 13:17:27 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05715 for ; Fri, 4 May 2001 13:17:30 -0400 (EDT) Message-ID: <3AF2E429.22A87868@marconi.com> Date: Fri, 04 May 2001 13:17:29 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: QoS in Shared Media References: <39469E08BD83D411A3D900204840EC553095AD@vie-msgusr-01.dc.fore.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA17389 "Naidu, Venkata" wrote: > > But anyway, I am hearing about 40/10(OC768) Gig Ethernet > evolution. If not at the core, these technologies may be > at the enterprise/access networks(?). GigE and 10GigE are not shared-media networks. Despite the fact that they're based on Ethernet, every implementation I've ever seen uses them as point-to-point links between switches/routers/hosts. > Moreover, The QoS issue is especially interesting over > wireless access networks as they are likely to be bottlenecks > (compared to wireline links) and they are often shared > media (e.g., wire­ less LANs). Providing service > differentiation on shared media is difficult due to > the risk of collisions between packets of different priority. QoS guarantees are impossible over shared media. There is always the possibility that somebody on the bus (perhaps a box running malicious code) will saturate the shared bus with garbage, forcing everybody else to wait or have collisions. If you can assume that everybody plays by the rules, then boxes on a shared bus can coordinate their access to provide some level of guaranteed service. Token Ring is one such example of this. TDM- based technologies (such as channelized SONET) are another. > * So, first, Is MPLS useful/applicable to these technologies? MPLS is useful even without QoS. It allows for the design of faster routers, or alternatively the use of less expensive forwarding chips at slower speeds. The explicit-route aspects of traffic engineering work over shared-media networks as well, even though QoS still can't be guaranteed, which may also be of use. > * If so, how the present singling protocols (RSVP/CR-LDP) or > diffserv TE extended protocols will take care of this? > As far as I know, classical RSVP is designed for such goals > and ofcourse, present IP routing protocols also runs > on such shared media, P2P and NBMA environments. Classical RSVP's ability to work over non-RSVP links is only a detection algorithm - it will detect non-RSVP links and indicate this to the egress node. The egress node then has to deal with the knowledge that any requested QoS may not actually be acheivable, due to the presence of those links along the path. > * In a simple environment Ethernet -> ATM/NBMA -> Ethernet > How resource reservation takes place and is there something > more the present signaling/routing protocols need to do > for QoS guaranties. If the Ethernet is point-to-point, there is no problem. If it is a shared bus, then the operator should realize that QoS can't be guaranteed. Labels can still be allocated and used. Resources can still be reserved on the routers. But the line itself may cause delays, queue backups and lost data. This shouldn't be a problem, however. If an network admin chooses to set up a shared-media network, then he should be aware of these factors. If these factors are unacceptible, then he should restrict the links to point-to-point links. -- David From owner-mpls@UU.NET Fri May 4 13:56:38 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18058 for ; Fri, 4 May 2001 13:56:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknox03446; Fri, 4 May 2001 17:54:52 GMT Received: by mail-control.mail.uu.net id QQknox07367 for mpls-outgoing; Fri, 4 May 2001 17:54:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknox07346 for ; Fri, 4 May 2001 17:54:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknox22718 for ; Fri, 4 May 2001 17:53:25 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknox01640 for ; Fri, 4 May 2001 17:53:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA21620 for mpls@uu.net; Fri, 4 May 2001 13:53:24 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknox07207 for ; Fri, 4 May 2001 17:52:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknox19060 for ; Fri, 4 May 2001 17:52:12 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknox00201 for ; Fri, 4 May 2001 17:52:12 GMT Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44HqSa11962; Fri, 4 May 2001 10:52:28 -0700 (PDT) Message-Id: <5.0.2.1.2.20010504104439.02e2ea40@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 10:47:58 -0700 To: "Naidu, Venkata" From: Fred Baker Subject: Re: QoS in Shared Media Cc: "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" In-Reply-To: <39469E08BD83D411A3D900204840EC553095AD@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote: >I have a doubt regarding "QoS in Shared Media". many have doubts in this area. Fundamentally, if I can talk with a switch, I am in control of my end of the line and it is in control of its end, and we can make promises about what we will each do in our direction. On shared media, anything resembling QoS assertions or guarantees requires making promises on behalf of other systems one does not control. The nearest solutions I see to that have been in 802.5 and FDDI LANs, and I wouldn't describe those as having been "wildly successful." From owner-mpls@UU.NET Fri May 4 14:09:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18301 for ; Fri, 4 May 2001 14:09:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoy19097; Fri, 4 May 2001 18:07:37 GMT Received: by mail-control.mail.uu.net id QQknoy22787 for mpls-outgoing; Fri, 4 May 2001 18:07:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknoy22249 for ; Fri, 4 May 2001 18:06:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknoy02011 for ; Fri, 4 May 2001 18:06:26 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknoy19569 for ; Fri, 4 May 2001 18:06:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA23116 for mpls@uu.net; Fri, 4 May 2001 14:06:25 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknoy19819 for ; Fri, 4 May 2001 18:05:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknoy10333 for ; Fri, 4 May 2001 18:04:25 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQknoy16378 for ; Fri, 4 May 2001 18:04:24 GMT Received: (qmail 15740 invoked from network); 4 May 2001 18:02:29 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 4 May 2001 18:02:29 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Fri, 4 May 2001 14:02:52 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA30F0; Fri, 4 May 2001 14:02:50 -0400 Message-Id: <3AF2EEAB.7C913846@alcatel.com> Date: Fri, 04 May 2001 14:02:19 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Fred Baker CC: "Naidu, Venkata" , "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" Subject: Re: QoS in Shared Media References: <5.0.2.1.2.20010504104439.02e2ea40@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit How about the work in IEEE 802.17 RPR? I believe it will be a shared-media technology. Does that mean they will have a hard time to achieve QoS guarantees? Cheers, Hansen > At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote: > >I have a doubt regarding "QoS in Shared Media". > > many have doubts in this area. > > Fundamentally, if I can talk with a switch, I am in control of my end of > the line and it is in control of its end, and we can make promises about > what we will each do in our direction. On shared media, anything resembling > QoS assertions or guarantees requires making promises on behalf of other > systems one does not control. The nearest solutions I see to that have been > in 802.5 and FDDI LANs, and I wouldn't describe those as having been > "wildly successful." From owner-mpls@UU.NET Fri May 4 14:20:28 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18497 for ; Fri, 4 May 2001 14:20:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoz09178; Fri, 4 May 2001 18:18:40 GMT Received: by mail-control.mail.uu.net id QQknoz29221 for mpls-outgoing; Fri, 4 May 2001 18:18:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknoz29214 for ; Fri, 4 May 2001 18:18:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknoz06264 for ; Fri, 4 May 2001 18:17:41 GMT Received: from lysimachus.hosting.pacbell.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lysimachus.hosting.pacbell.net [216.100.98.17]) id QQknoz26386 for ; Fri, 4 May 2001 18:17:40 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id OAA19547; Fri, 4 May 2001 14:17:17 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "David Charlap" , "'mpls@uu.net'" Cc: "Naidu, Venkata" Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 11:15:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF2E429.22A87868@marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >QoS guarantees are impossible over shared media. There is always the >possibility that somebody on the bus (perhaps a box running malicious >code) will saturate the shared bus with garbage, forcing everybody else >to wait or have collisions. > >If you can assume that everybody plays by the rules, then boxes on a >shared bus can coordinate their access to provide some level of >guaranteed service. Token Ring is one such example of this. TDM- based >technologies (such as channelized SONET) are another. In fact if the transmission infrastructure of the shared media has the intelligence or capability built in to coordinate the admission of traffic into the shared media, it makes the life of QoS at higher level easier. The RPR(IEEE 802.17) is apparently marching toward this direction. At least, Cisco's DPT/SRP-fa (cisco's version of RPR) ensures global bandwidth fairness for all nodes on the same ring from what I know. - jay From owner-mpls@UU.NET Fri May 4 14:29:13 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18615 for ; Fri, 4 May 2001 14:29:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknoz24087; Fri, 4 May 2001 18:27:26 GMT Received: by mail-control.mail.uu.net id QQknoz29987 for mpls-outgoing; Fri, 4 May 2001 18:26:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknoz29973 for ; Fri, 4 May 2001 18:26:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknoz26285 for ; Fri, 4 May 2001 18:26:36 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknoz12845 for ; Fri, 4 May 2001 18:26:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA25562 for mpls@uu.net; Fri, 4 May 2001 14:26:35 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknoz29890 for ; Fri, 4 May 2001 18:25:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknoz20821 for ; Fri, 4 May 2001 18:22:59 GMT Received: from ns02.newbridge.com by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: ns02.newbridge.com [192.75.23.75]) id QQknoz16560 for ; Fri, 4 May 2001 18:22:58 GMT Received: (qmail 16704 invoked from network); 4 May 2001 18:21:10 -0000 Received: from portal1.newbridge.com (HELO kanata-mh1.ca.newbridge.com) (192.75.23.76) by ns02.newbridge.com with SMTP; 4 May 2001 18:21:10 -0000 Received: from kanmail02.ca.newbridge.com by kanata-mh1.ca.newbridge.com with ESMTP for mpls@UU.NET; Fri, 4 May 2001 14:21:33 -0400 Received: from alcatel.com ([138.120.51.119]) by kanmail02.ca.newbridge.com (Netscape Messaging Server 3.6) with ESMTP id AAA4230; Fri, 4 May 2001 14:21:32 -0400 Message-Id: <3AF2F30D.30F9838A@alcatel.com> Date: Fri, 04 May 2001 14:21:01 -0400 From: "HANSEN CHAN" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Jay Wang CC: David Charlap , "'mpls@uu.net'" , "Naidu, Venkata" Subject: Re: QoS in Shared Media References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > In fact if the transmission infrastructure of the shared media has the > intelligence or capability built in to coordinate the admission of traffic > into the shared media, it makes the life of QoS at higher level easier. The > RPR(IEEE 802.17) is apparently marching toward this direction. At least, > Cisco's DPT/SRP-fa (cisco's version of RPR) ensures global bandwidth > fairness > for all nodes on the same ring from what I know. I really would like to understand how RPR or DPT can ensure global bandwidth fairness. Any link or pointer? Thanks, Hansen From owner-mpls@UU.NET Fri May 4 14:31:55 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18664 for ; Fri, 4 May 2001 14:31:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpa29445; Fri, 4 May 2001 18:30:11 GMT Received: by mail-control.mail.uu.net id QQknoz00347 for mpls-outgoing; Fri, 4 May 2001 18:29:38 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknoz00300 for ; Fri, 4 May 2001 18:29:18 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknoz04546 for ; Fri, 4 May 2001 18:29:14 GMT Received: from philotas.hosting.pacbell.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: philotas.hosting.pacbell.net [216.100.99.24]) id QQknoz08083 for ; Fri, 4 May 2001 18:29:13 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by philotas.hosting.pacbell.net id OAA17698; Fri, 4 May 2001 14:28:02 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "HANSEN CHAN" , "Jay Wang" Cc: "David Charlap" , "'mpls@uu.net'" , "Naidu, Venkata" Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 11:26:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF2F30D.30F9838A@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hansen, This may be a good place to get an introduction on the topic: http://www.cisco.com/warp/public/cc/techno/wnty/dpty/tech/dptm_wp.htm - jay From owner-mpls@UU.NET Fri May 4 14:38:28 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18816 for ; Fri, 4 May 2001 14:38:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpa15726; Fri, 4 May 2001 18:36:37 GMT Received: by mail-control.mail.uu.net id QQknpa01290 for mpls-outgoing; Fri, 4 May 2001 18:36:05 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknpa01265 for ; Fri, 4 May 2001 18:36:00 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknpa14742 for ; Fri, 4 May 2001 18:33:39 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknpa05867 for ; Fri, 4 May 2001 18:33:39 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07919; Fri, 4 May 2001 14:33:03 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01914; Fri, 4 May 2001 14:33:06 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 14:32:54 -0400 Message-ID: <39469E08BD83D411A3D900204840EC553095AE@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Fred Baker'" , "Charlap, David" Cc: "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 14:33:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Thanks for all those who replied and gave good pointers. Fred/David, Some one pointed me to ISSLL WG with this regard (I thought this WG is also off along with INTSERV & RSVP) Esp about RFCs 2814/2815/2816 - SBM (Subnet Bandwidth Manager) Integrated Services Over Shared and Switched IEEE 802 LAN Technologies. I didn't go through these drafts completely but, aren't they doing in the direction we are looking for... my question is, why not RSVP for MPLS not considering these work. Recently David was asking "why RSVP doesn't have strict delay and delay variation control parameters like ATM?" I found some of the RFCs in ISSLL (2379, 2380, 2381 & 2382) have answer for that - Inserv has the answer for QoS in any media! Are these something different when compared to RSVP for LSPs? I am searching for what I missed?! :-) -Venkata Naidu -> -----Original Message----- -> From: Fred Baker [mailto:fred@cisco.com] -> Sent: Friday, May 04, 2001 1:48 PM -> To: Naidu, Venkata -> Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org' -> Subject: Re: QoS in Shared Media -> -> -> At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote: -> >I have a doubt regarding "QoS in Shared Media". -> -> many have doubts in this area. -> -> Fundamentally, if I can talk with a switch, I am in control -> of my end of -> the line and it is in control of its end, and we can make -> promises about -> what we will each do in our direction. On shared media, -> anything resembling -> QoS assertions or guarantees requires making promises on -> behalf of other -> systems one does not control. The nearest solutions I see to -> that have been -> in 802.5 and FDDI LANs, and I wouldn't describe those as having been -> "wildly successful." -> From owner-mpls@UU.NET Fri May 4 14:57:41 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19173 for ; Fri, 4 May 2001 14:57:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpb19440; Fri, 4 May 2001 18:55:41 GMT Received: by mail-control.mail.uu.net id QQknpb04207 for mpls-outgoing; Fri, 4 May 2001 18:55:05 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknpb04181 for ; Fri, 4 May 2001 18:54:49 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknpb24927 for ; Fri, 4 May 2001 18:54:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknpb17778 for ; Fri, 4 May 2001 18:54:30 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA29136 for mpls@uu.net; Fri, 4 May 2001 14:54:30 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknpb04118 for ; Fri, 4 May 2001 18:54:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknpb16445 for ; Fri, 4 May 2001 18:51:37 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknpb01385 for ; Fri, 4 May 2001 18:51:37 GMT Received: from FRED-W2K.cisco.com (fred-hm-dhcp3.cisco.com [171.69.128.118]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44Ipva19682; Fri, 4 May 2001 11:51:57 -0700 (PDT) Message-Id: <5.0.2.1.2.20010504114231.02f8c310@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 04 May 2001 11:51:18 -0700 To: "Naidu, Venkata" From: Fred Baker Subject: RE: QoS in Shared Media Cc: "Charlap, David" , "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" In-Reply-To: <39469E08BD83D411A3D900204840EC553095AE@vie-msgusr-01.dc.fo re.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk At 02:33 PM 5/4/2001 -0400, Naidu, Venkata wrote: > my question is, why not RSVP for MPLS not considering these > work. Recently David was asking "why RSVP doesn't have strict > delay and delay variation control parameters like ATM?" Ah, yes, MPLS as ATM-done-over... It's a common thread these days. I don't think the RSVP developers were trying to imitate ATM; they were addressing specific requirements imposed by the applications they were looking at, and figured that other control paradigms could be put together if needed. And by the way, they were not trying to address the routing issue, which would have been necessary to define routes for traffic that ensured specific end to end delays. They are trying to control variance in delay, not end to end delay, and they disputed the concept that microsecond variance controls were necessary to an application whose codecs defined tens-to-hundreds-of-millisecond jitter buffers. If you want to go into he history of Integrated Services, or of RSVP, further, I would suggest that we take the discussion private, or move it to the issll list, as it is off-topic here. From owner-mpls@UU.NET Fri May 4 15:07:40 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19356 for ; Fri, 4 May 2001 15:07:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpc18606; Fri, 4 May 2001 19:05:48 GMT Received: by mail-control.mail.uu.net id QQknpc14005 for mpls-outgoing; Fri, 4 May 2001 19:05:13 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknpc13292 for ; Fri, 4 May 2001 19:04:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknpc23329 for ; Fri, 4 May 2001 19:03:58 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknpc29845 for ; Fri, 4 May 2001 19:03:58 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA00237 for mpls@uu.net; Fri, 4 May 2001 15:03:57 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknpc10335 for ; Fri, 4 May 2001 19:03:20 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknpc15749 for ; Fri, 4 May 2001 19:01:02 GMT Received: from lohi.eng.telia.fi by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQknpc12789 for ; Fri, 4 May 2001 19:01:01 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f44J0eN18559; Fri, 4 May 2001 22:00:40 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.64600.180853.33136@lohi.eng.telia.fi> Date: Fri, 4 May 2001 22:00:40 +0300 (EEST) To: "HANSEN CHAN" Cc: Fred Baker , "Naidu, Venkata" , "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" Subject: Re: QoS in Shared Media In-Reply-To: <3AF2EEAB.7C913846@alcatel.com> References: <5.0.2.1.2.20010504104439.02e2ea40@mira-sjcm-2.cisco.com> <3AF2EEAB.7C913846@alcatel.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HANSEN CHAN writes: > How about the work in IEEE 802.17 RPR? I believe it will be a shared-media > technology. Does that mean they will have a hard time to achieve QoS > guarantees? last time that i checked, the rpr proposal (based on cisco dpt) had two classes of service (strict priority and best effort). that is clearly not adequate for diffserv. node based fairness applied to the best effort class. in diffserv, node based fairness makes sense only for the highest dp packets in each traffic class. -- juha From owner-mpls@UU.NET Fri May 4 15:16:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19466 for ; Fri, 4 May 2001 15:16:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpd21342; Fri, 4 May 2001 19:15:15 GMT Received: by mail-control.mail.uu.net id QQknpc25176 for mpls-outgoing; Fri, 4 May 2001 19:14:39 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknpc25136 for ; Fri, 4 May 2001 19:14:21 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknpc24533 for ; Fri, 4 May 2001 19:14:14 GMT Received: from mta7.pltn13.pbi.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mta7.pltn13.pbi.net [64.164.98.8]) id QQknpc17270 for ; Fri, 4 May 2001 19:14:09 GMT Received: from pacbell.net ([63.204.7.110]) by mta7.pltn13.pbi.net (Sun Internet Mail Server sims.3.5.2000.03.23.18.03.p10) with ESMTP id <0GCT00FO2QKZP4@mta7.pltn13.pbi.net> for mpls@UU.NET; Fri, 4 May 2001 11:41:23 -0700 (PDT) Date: Fri, 04 May 2001 11:50:08 -0700 From: Vinay Bannai Subject: Re: QoS in Shared Media To: HANSEN CHAN Cc: Jay Wang , David Charlap , "'mpls@uu.net'" , "Naidu, Venkata" Reply-to: bannai@pacbell.net Message-id: <3AF2F9E0.B25DB555@pacbell.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12-20smp i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3AF2F30D.30F9838A@alcatel.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit HANSEN CHAN wrote: > > In fact if the transmission infrastructure of the shared media has the > > intelligence or capability built in to coordinate the admission of traffic > > into the shared media, it makes the life of QoS at higher level easier. The > > RPR(IEEE 802.17) is apparently marching toward this direction. At least, > > Cisco's DPT/SRP-fa (cisco's version of RPR) ensures global bandwidth > > fairness > > for all nodes on the same ring from what I know. > > I really would like to understand how RPR or DPT can ensure global bandwidth > fairness. Any link or pointer? > > Thanks, > Hansen The discussions in IEEE 802.17 are still continuing and there are vaired solutions that have been proposed. The fundamental premise is at each node in the RPR ring, based on some bits in the header the add and pass traffic are scheduled based on the QoS bits set in the header. Also within a RPR capable box or a line card, the traffic is scheduled on to the ring based on QoS. Vinay From owner-mpls@UU.NET Fri May 4 17:34:38 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21219 for ; Fri, 4 May 2001 17:34:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpm08517; Fri, 4 May 2001 21:32:45 GMT Received: by mail-control.mail.uu.net id QQknpm18655 for mpls-outgoing; Fri, 4 May 2001 21:32:12 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknpm18648 for ; Fri, 4 May 2001 21:32:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknpm23873 for ; Fri, 4 May 2001 21:31:57 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknpm26147 for ; Fri, 4 May 2001 21:31:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA09248 for mpls@uu.net; Fri, 4 May 2001 17:31:56 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknpm18501 for ; Fri, 4 May 2001 21:31:14 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknpm17622 for ; Fri, 4 May 2001 21:31:02 GMT Received: from sjc3-1.relay.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sjc3-1.relay.mail.uu.net [199.171.54.122]) id QQknpm24665 for ; Fri, 4 May 2001 21:31:01 GMT Received: from mail.uu.net by sjc3sosrv11.alter.net with SMTP (peer crosschecked as: [64.5.243.230]) id QQknpm07517 for ; Fri, 4 May 2001 21:31:00 GMT Message-Id: From: Paul.Risman@UU.NET Date: Fri, 04 May 2001 17:29:56 To: mpls@UU.NET Subject: Please read the following it could change your life MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. //////////////////////////////////////////////////////////// ONE TIME MAILING, NO NEED TO REMOVE //////////////////////////////////////////////////////////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. Subject: Five Is The Key To My Freedom, It Could Be Yours Too. AS SEEN ON NATIONAL TV: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANK'S TO THE COMPUTER AGE AND THE INTERNET ! ================================================== BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the Internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO Laws prohibiting the participation in the program and if people can -follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so gladI finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in." Pam Hedland, Fort Lee, New Jersey. =================================================== Here is another testimonial: "This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa ..... 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything.'' More testimonials later but first, ===== PRINT THIS NOW FOR YOUR FUTUREREFERENCE ====== $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: =====Order all 5 reports shown on the list below ===== For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. Preferably use a word processor to type legibly these details and print on your printer. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. === When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00. Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work !!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.... After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2.... Move the name & address in REPORT # 4 down TO REPORT # 5. 3.... Move the name & address in REPORT # 3 down TO REPORT # 4. 4.... Move the name & address in REPORT # 2 down TO REPORT # 3. 5.... Move the name & address in REPORT # 1 down TO REPORT # 2 6.... Insert YOUR name & address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ========================================================== **** Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD # 1: BY SENDING BULK E-MAIL LEGALLY ========================================================== Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e-mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2%. Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e-mails. With a 0.2% response, that is only 10 orders for report # 1. Those 10 people responded by sending out 5,000 e-mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's=100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4 .. $50,000 + 5..... $500,000 ........ Grand Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGUREOUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY ! ========================================================= REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone or half or even one 4th of those people mailed 100,000e-mails each or more? There are over 150 million people on the Internet worldwide and counting. Believe me, many people will do just that, and more! METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET ======================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the Internet will easily get a larger response. We strongly suggest you start with Method # 1 and dd METHOD # 2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it. Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they can not advertise until they receivethe report. =========== AVAILABLE REPORTS ==================== ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. Preferably use a word processor and your printer to do this. ================================================= PLACE YOUR ORDER FOR THESE REPORTS NOW : ============================================================ REPORT # 1: 'The Insider's Guide to Advertising for Free on the Net Order Report #1 from: Paul J. Risman P.O. Box 368 Tweed Ontario K0K 3J0 Canada _____________________________________________________________ REPORT # 2: The Insider's Guide to Sending Bulk e-mail on the Net Order Report # 2 from: PDP P.O. BOX 80572 185 10 PIRAEUS GREECE ____________________________________________________ REPORT # 3: Secret to Multilevel marketing on the net Order Report # 3 from: S.S. 32 Cross Street San Francisco, CA 94112 USA ________________________________________________________________ REPORT # 4: How to become a millionaire utilizing MLM& the Net Order Report # 4 from: Ada Ario 50 First Street, Suite I San Francisco, CA 94105 USA ________________________________________________________________ REPORT #5: How to send out 0ne Million emails for free Order Report # 5 From: Art Ano 146 McAllister Street,#103 San Francisco, CA 94102 USA ========================================================== ____________________________________________________________ $$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$ Follow these guidelines to guarantee your success: === If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. === After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT # 2. If you did not, continue advertising or sending e-mails until you do. === Once you have received 100 or more orders for Report # 2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business !!! ====================================================== FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........# 5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW ! ============ MORE TESTIMONIALS ================ "My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jodyaboutreceiving ''junk mail''. I made fun of the whole thing,spoutingmy knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ........... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf M.D., Chicago, Illinois ====================================================== ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. '' I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big." Dan Sondstrom, Alberta, Canada ======================================================= ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks." Susan De Suza, New York, N.Y. ======================================================= ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $20,560.00 and by the end of third month my total cash count was $362,840.00. Life is beautiful, Thanx to internet.". Fred Dellaca, Westport, New Zealand ======================================================= ORDER YOUR REPORTS TODAY AND GET STARTED ON 'YOUR' ROAD TO FINANCIAL FREEDOM ! ======================================================= If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. From owner-mpls@UU.NET Fri May 4 18:45:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21884 for ; Fri, 4 May 2001 18:45:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpq16317; Fri, 4 May 2001 22:43:44 GMT Received: by mail-control.mail.uu.net id QQknpq16244 for mpls-outgoing; Fri, 4 May 2001 22:43:10 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknpq16224 for ; Fri, 4 May 2001 22:42:54 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknpq24161 for ; Fri, 4 May 2001 22:42:41 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknpq17342 for ; Fri, 4 May 2001 22:42:40 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f44Mh7a25776 for ; Fri, 4 May 2001 15:43:07 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id SAA12639 for mpls@uu.net; Fri, 4 May 2001 18:42:39 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknot10309 for ; Fri, 4 May 2001 16:48:46 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknot22125 for ; Fri, 4 May 2001 16:48:41 GMT Received: from msmailhub.ou.edu by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: msmailhub.oulan.ou.edu [129.15.87.16]) id QQknot20297 for ; Fri, 4 May 2001 16:48:40 GMT Received: by msmailhub.oulan.ou.edu with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 11:48:35 -0500 Message-ID: <372E9068C013D211891F00805F9FD1C207569D02@mail3.oulan.ou.edu> From: "Atiquzzaman, Mohammed" To: "'Naidu, Venkata'" , "'mpls@uu.net'" Cc: "'te-wg@ops.ietf.org'" Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 11:48:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA21884 You might want to look at the 802.1D standard for MAC bridges which provides user priority in MAC frames? Regards Mohammed Atiquzzaman Tel: (405) 325 8077 School of Computer Science Fax: (520) 962 8422, University of Oklahoma (405) 325 4044 200 Felgar St., Room EL-154 Email: atiq@ou.edu Norman, OK 73019-6151 atiq@ieee.org www.cs.ou.edu/~atiq > -----Original Message----- > From: Naidu, Venkata [mailto:Venkata.Naidu@Marconi.com] > Sent: Friday, May 04, 2001 9:59 AM > To: 'mpls@uu.net' > Cc: 'te-wg@ops.ietf.org' > Subject: QoS in Shared Media > > > Hi All > > I have a doubt regarding "QoS in Shared Media". I don't > know how much this is applicable to this discussion list :-) > > But anyway, I am hearing about 40/10(OC768) Gig Ethernet > evolution. If not at the core, these technologies may be > at the enterprise/access networks(?). > > Moreover, The QoS issue is especially interesting over > wireless access networks as they are likely to be bottlenecks > (compared to wireline links) and they are often shared > media (e.g., wire­ less LANs). Providing service > differentiation on shared media is difficult due to > the risk of collisions between packets of different priority. > > * So, first, Is MPLS useful/applicable to these technologies? > > * If so, how the present singling protocols (RSVP/CR-LDP) or > diffserv TE extended protocols will take care of this? > As far as I know, classical RSVP is designed for such goals > and ofcourse, present IP routing protocols also runs > on such shared media, P2P and NBMA environments. > > * In a simple environment Ethernet -> ATM/NBMA -> Ethernet > How resource reservation takes place and is there something > more the present signaling/routing protocols need to do > for QoS guaranties. > > I didn't find anything useful in TE-WG drafts! > Is that I am missing something? > > Thanks & Regards > --Venkata Naidu > From owner-mpls@UU.NET Fri May 4 18:48:12 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21922 for ; Fri, 4 May 2001 18:48:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknpr05910; Fri, 4 May 2001 22:45:09 GMT Received: by mail-control.mail.uu.net id QQknpq16379 for mpls-outgoing; Fri, 4 May 2001 22:44:35 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknpq16310 for ; Fri, 4 May 2001 22:44:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknpq09426 for ; Fri, 4 May 2001 22:42:44 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknpq17395 for ; Fri, 4 May 2001 22:42:42 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f44Mggn20326 for ; Fri, 4 May 2001 15:42:42 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id SAA12643 for mpls@uu.net; Fri, 4 May 2001 18:42:41 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknoz29527 for ; Fri, 4 May 2001 18:23:06 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknoz10978 for ; Fri, 4 May 2001 18:18:49 GMT Received: from nfl.METERA.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nfl.metera.com [63.114.212.50]) id QQknoz09518 for ; Fri, 4 May 2001 18:18:49 GMT Received: by nfl.METERA.COM with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 13:19:31 -0500 Message-ID: From: Badri Devalla To: Fred Baker , "Naidu, Venkata" Cc: "'mpls@uu.net'" , "'te-wg@ops.ietf.org'" Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 13:19:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D4C6.BF341AD0" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D4C6.BF341AD0 Content-Type: text/plain; charset="ISO-8859-1" || -----Original Message----- || From: Fred Baker [mailto:fred@cisco.com] || Sent: Friday, May 04, 2001 12:48 PM || To: Naidu, Venkata || Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org' || Subject: Re: QoS in Shared Media || || || At 10:58 AM 5/4/2001 -0400, Naidu, Venkata wrote: || >I have a doubt regarding "QoS in Shared Media". || || many have doubts in this area. || || Fundamentally, if I can talk with a switch, I am in control || of my end of || the line and it is in control of its end, and we can make || promises about || what we will each do in our direction. On shared media, || anything resembling || QoS assertions or guarantees requires making promises on || behalf of other || systems one does not control. The nearest solutions I see to || that have been || in 802.5 and FDDI LANs, and I wouldn't describe those as having been || "wildly successful." || Just a nit-pick. I agree with your thoughts on inability to guarantee QoS without control in multi-access shared media. However, 802.5 and FDDI LANs are multiple access and can be run in modes where you can provide guaranteed deadlines (and not shared media). I am referring to Synchronous Bandwith allocation and Timed token protocol. You cannot do this is shared Ethernet. Token ring and FDDI are like Baby Boomers - they had their time ;) badri ------_=_NextPart_001_01C0D4C6.BF341AD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: QoS in Shared Media

|| -----Original Message-----
|| From: Fred Baker [mailto:fred@cisco.com]
|| Sent: Friday, May 04, 2001 12:48 PM
|| To: Naidu, Venkata
|| Cc: 'mpls@uu.net'; 'te-wg@ops.ietf.org'
|| Subject: Re: QoS in Shared Media
||
||
|| At 10:58 AM 5/4/2001 -0400, Naidu, Venkata = wrote:
|| >I have a doubt regarding "QoS in Shared = Media".
||
|| many have doubts in this area.
||
|| Fundamentally, if I can talk with a switch, I am = in control
|| of my end of
|| the line and it is in control of its end, and we = can make
|| promises about
|| what we will each do in our direction. On shared = media,
|| anything resembling
|| QoS assertions or guarantees requires making = promises on
|| behalf of other
|| systems one does not control. The nearest = solutions I see to
|| that have been
|| in 802.5 and FDDI LANs, and I wouldn't describe = those as having been
|| "wildly successful."
||

Just a nit-pick.
I agree with your thoughts on inability to guarantee = QoS without control in multi-access shared media.
However, 802.5 and FDDI LANs are multiple access and = can be run in modes where you can provide guaranteed deadlines (and not = shared media). I am referring to Synchronous Bandwith allocation and = Timed token protocol. You cannot do this is shared Ethernet.

Token ring and FDDI are like Baby Boomers - they had = their time ;)

badri

------_=_NextPart_001_01C0D4C6.BF341AD0-- From owner-mpls@UU.NET Fri May 4 19:16:23 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22221 for ; Fri, 4 May 2001 19:16:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknps11027; Fri, 4 May 2001 23:14:54 GMT Received: by mail-control.mail.uu.net id QQknps10720 for mpls-outgoing; Fri, 4 May 2001 23:14:25 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknps10709 for ; Fri, 4 May 2001 23:14:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknps24347 for ; Fri, 4 May 2001 23:14:11 GMT Received: from ganymede.or.intel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: jffdns01.or.intel.com [134.134.248.3]) id QQknps16091 for ; Fri, 4 May 2001 23:14:10 GMT Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.36 2001/04/18 16:16:02 root Exp $) with SMTP id XAA15299; Fri, 4 May 2001 23:14:08 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 04 May 2001 23:14:08 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 May 2001 16:14:05 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E89006E18AD1@orsmsx35.jf.intel.com> From: "Gross, Gerhard" To: "'Vishal Sharma'" , "'David Charlap'" , "'mpls@uu.net'" Subject: RE: terminology - change request Date: Fri, 4 May 2001 16:13:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I support Vishal's request for (re)defining terms that more clearly describe "tunnel" related issues. Changing names in the RFCs may be out of reach but we can still do this in the drafts, before they get to the RFC level. Misconceptions for me start at section 3.27 of RFC 3031, especially 3.27.3 where "LSP tunnel" is first defined. In this case the definition refers to an LSP where the packets traveling through it have a label stack greater than 1. If we accept that definition, since it is already RFCed, consider (as you already have) some of the text in draft-ietf-mpls-rsvp-lsp-tunnel-08.txt. Even in the first 4 pages of the draft there seem to be contradictions: (1) Sec 1, para 1: "This document is a specification of extensions to RSVP for establishing label switched paths (LSPs) in Multi-protocol Label Switching (MPLS) networks." This seems to me to be a simple, accurate and necessary statement. (2) Sec 1, para 6: "The purpose of this document is to describe the use of RSVP to establish LSP tunnels." This is confusing in light of (1). Implication A) The only way to make statements (1) and (2) true is to equate "LSP" and "LSP tunnel". (3) Sec 1.2": a) "LSP: A Label Switched Path" b) "LSP Tunnel: An LSP which is used to tunnel below normal IP routing and/or filtering mechanisms." Item (3) contradicts implication A) by implying there is a difference between "LSP" and "LSP Tunnel". I think the use of the term "LSP tunnel" in the first few pages of the draft should be changed to make it inline with how RFC 3031 defines "LSP tunnel". I also agree with Vishal's clear reasoning and idea that > the "collection of LSPs sharing > a common SESSION object" needs a different term. A unique name should be chosen that more closely describes what it is (e.g. LSP Session Group). The title of the draft should also be changed to be more accurate, such as: " RSVP-TE: Extensions to RSVP for Establishing LSPs " This covers LSPs and "LSP tunnels" as they are defined in RFC 3031 to any label stack depth. Gery XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X Gerhard W. Gross, Ph.D. X X Intel X X 2111 NE 25th Ave X X Hillsboro, OR 97124-5961, USA X X Internet Infrastructure Arch. Group X X - Internet and Communication Lab X X phone: (503) 264-6389 X X fax: (503) 264-3483 X X email: gerhard.gross@intel.com X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > -----Original Message----- > From: Vishal Sharma [mailto:vishal@JasmineNetworks.com] > Sent: Thursday, May 03, 2001 4:33 PM > To: 'David Charlap'; 'mpls@uu.net' > Cc: 'gerhard.gross@intel.com' > Subject: RE: terminology > > > David, > > I agree with your characterization below. Even the paragraph quoted by > Gerhard from RFC 3031 makes sense in the context in which > you've explained > it. > > Namely, if we define a "tunnel" as being any means of making a packet > arrive at a non-directly-attached router, then an LSP may be viewed > as one realization of a tunnel. (Even in that case, however, why don't > we just settle on the term "tunnel". I guess one could argue that the > phrase "LSP tunnel" is a bit more descriptive, in that it > indicates how > the tunnel in question is being realized; through an LSP.) > Although, I am not sure that any of the documents actually > states things > the way you've defined them (which would make things much clearer for > us all). > > I still have a problem (and have had for quite some time), however, > with the RSVP-TE draft, since it uses the term "tunnel" in > contradictory > and confusing ways. > > The following is an excerpt taken directly from Section 1.0 > of the RSVP-TE > draft: > > "Since the traffic that flows along a label-switched path > is defined > by the label applied at the ingress node of the LSP, these > paths can > be treated as tunnels, tunneling below normal IP routing and > filtering mechanisms. When an LSP is used in this way we > refer to it > as an LSP tunnel. > > LSP tunnels allow the implementation of a variety of > policies related > to network performance optimization. For example, LSP > tunnels can be > automatically or manually routed away from network failures, > congestion, and bottlenecks. Furthermore, multiple parallel LSP > tunnels can be established between two nodes, and traffic > between the > two nodes can be mapped onto the LSP tunnels according to local > policy. Although traffic engineering (that is, performance > optimization of operational networks) is expected to be an > important > application of this specification, the extended RSVP > protocol can be > used in a much wider context. > > The purpose of this document is to describe the use of RSVP to > establish LSP tunnels. The intent is to fully describe all the > objects, packet formats, and procedures required to realize > interoperable implementations. A few new objects are also defined > that enhance management and diagnostics of LSP tunnels." > > As one reads through this, one might conclude that this part actually > uses the term "LSP tunnel" in the same way that RFC 3031 uses it, and > in the way that you've defined it. > > However, as you've observed yourself, later on in the same draft the > term "LSP tunnel" is applied to something quite different; a > collection > of LSPs that share a common destination, or, more precisely, a common > SESSION object. This latter use is very specific and quite different > from what one is lead to believe in the Introduction, and indeed in > much of the draft. > > If we agree that the commonly accepted definition of "tunnel" is > what you've defined (and which I've paraphrased above), and, if > we agree that the term "LSP tunnel" is, in fact, merely another > term for an LSP, with the additional connotation that the LSP can > be used to realize a "tunnel," (which is a bit of a stretch, since > every LSP is after all an "LSP tunnel"), > > then clearly, the "collection of LSPs sharing > a common SESSION object" needs a different term. > I don't know what yet, but a different term. > > -Vishal > > > > -----Original Message----- > > From: David Charlap [mailto:david.charlap@marconi.com] > > Sent: Thursday, May 03, 2001 12:52 PM > > To: 'mpls@uu.net' > > Subject: Re: terminology > > > > > > "Gross, Gerhard" wrote: > > > > > > The definitions "LSP tunnel" in the docs seem to be somewhat > > > misleading. For example, section 3.27.3 of RFC 3031 states: > > > > > > "It is possible to implement a tunnel as a LSP, and use label > > > switching rather than network layer encapsulation to cause the > > > packet to travel through the tunnel. ... > > > This is called a "LSP Tunnel." > > > > > > This is standard MPLS as far as I tell. > > > Why rename it? > > > > The definition of "tunnel" seems to be different in different > > documents. > > > > In RSVP-TE, a tunnel is a collection of one or more LSPs > that are all > > signaled with the same SESSION object. (Session being > defined as the > > triplet egress-address, tunnel-ID, and extended-tunnel-ID.) > > If extended > > tunnel ID is zero, these LSPs may originate from different ingress > > routers. The distinction is important because all LSPs in a single > > tunnel will share resources where possible, when an SE-style > > reservation > > is used. > > > > Colloquially, this is the definition I usually use. I usually say > > "tunnel" when I mean a collection of LSPs that share a common > > destination. If I mean a single LSP, I just say "LSP". > > > > But this is not RFC 3031's definition. RFC 3031 defines a "tunneled > > packet" as any packet that is forwarded to a not-directly-attached > > router. A tunnel is defined as any means for making this work. > > > > It then goes on to define three kinds of tunnels, the first > two don't > > necessarily involve MPLS. > > > > The first is a hop-by-hop routed tunnel. The data is > > encapsulated in a > > network-layer header that gets it to the next-hop router. > > One possible > > non-MPLS example of this might be an IP-in-IP tunnel. > > > > The second is an explicitly-routed tunnel. The data is > > encapsulated in > > a network-layer header that is explicitly routed to the next-hop > > router. One possible non-MPLS example of this might be an ATM PVC. > > > > The third is the LSP tunnel. The data is labeled and > forwarded using > > MPLS. > > > > If my understanding is incorrect, hopefully one of the RFC > > authors will > > be able to correct me. > > > > -- David > > > From owner-mpls@UU.NET Fri May 4 21:12:02 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23209 for ; Fri, 4 May 2001 21:12:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknqa27028; Sat, 5 May 2001 01:10:45 GMT Received: by mail-control.mail.uu.net id QQknqa01905 for mpls-outgoing; Sat, 5 May 2001 01:10:12 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknqa01854 for ; Sat, 5 May 2001 01:09:51 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknqa24211 for ; Sat, 5 May 2001 01:09:33 GMT Received: from antipater.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: antipater.hosting.pacbell.net [216.100.99.13]) id QQknqa22957 for ; Sat, 5 May 2001 01:09:32 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by antipater.hosting.pacbell.net id VAA00662; Fri, 4 May 2001 21:08:52 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Juha Heinanen" , "HANSEN CHAN" Cc: "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 18:07:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15090.64600.180853.33136@lohi.eng.telia.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Well, RPR gives you bandwidth endurance at the link level, a shared media in this case. On higher level, you may conduct your QoS as appropriate, Diffserv, Intserv, or else. One does not preclude the other, IMO. - jay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha Heinanen Sent: Friday, May 04, 2001 12:01 PM To: HANSEN CHAN Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org' Subject: Re: QoS in Shared Media HANSEN CHAN writes: > How about the work in IEEE 802.17 RPR? I believe it will be a shared-media > technology. Does that mean they will have a hard time to achieve QoS > guarantees? last time that i checked, the rpr proposal (based on cisco dpt) had two classes of service (strict priority and best effort). that is clearly not adequate for diffserv. node based fairness applied to the best effort class. in diffserv, node based fairness makes sense only for the highest dp packets in each traffic class. -- juha From owner-mpls@UU.NET Fri May 4 21:19:28 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23332 for ; Fri, 4 May 2001 21:19:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknqb06092; Sat, 5 May 2001 01:17:50 GMT Received: by mail-control.mail.uu.net id QQknqb03314 for mpls-outgoing; Sat, 5 May 2001 01:17:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknqb03306 for ; Sat, 5 May 2001 01:17:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknqb29511 for ; Sat, 5 May 2001 01:16:32 GMT Received: from lysimachus.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lysimachus.hosting.pacbell.net [216.100.98.17]) id QQknqb05068 for ; Sat, 5 May 2001 01:16:32 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id VAA01667; Fri, 4 May 2001 21:16:14 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Jay Wang" , "Juha Heinanen" , "HANSEN CHAN" Cc: "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media Date: Fri, 4 May 2001 18:14:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >Well, RPR gives you bandwidth endurance at the link level, a shared bandwidth *assurance* that is ...., the spelling checker thing .. - jay >media in this case. On higher level, you may conduct your QoS as >appropriate, Diffserv, Intserv, or else. One does not preclude the other, >IMO. > >- jay -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha Heinanen Sent: Friday, May 04, 2001 12:01 PM To: HANSEN CHAN Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org' Subject: Re: QoS in Shared Media HANSEN CHAN writes: > How about the work in IEEE 802.17 RPR? I believe it will be a shared-media > technology. Does that mean they will have a hard time to achieve QoS > guarantees? last time that i checked, the rpr proposal (based on cisco dpt) had two classes of service (strict priority and best effort). that is clearly not adequate for diffserv. node based fairness applied to the best effort class. in diffserv, node based fairness makes sense only for the highest dp packets in each traffic class. -- juha From owner-mpls@UU.NET Fri May 4 22:31:04 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25160 for ; Fri, 4 May 2001 22:31:03 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknqg18187; Sat, 5 May 2001 02:30:03 GMT Received: by mail-control.mail.uu.net id QQknqf29563 for mpls-outgoing; Sat, 5 May 2001 02:29:29 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknqf29546 for ; Sat, 5 May 2001 02:29:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknqf02624 for ; Sat, 5 May 2001 02:27:53 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknqf22533 for ; Sat, 5 May 2001 02:27:53 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id WAA22868 for mpls@uu.net; Fri, 4 May 2001 22:27:52 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknqf29436 for ; Sat, 5 May 2001 02:27:27 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknqf16815 for ; Sat, 5 May 2001 02:25:33 GMT Received: from boyle.eng.level3.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rdu26-34-243.nc.rr.com [66.26.34.243]) id QQknqf18655 for ; Sat, 5 May 2001 02:25:33 GMT Received: from boyle.eng.level3.com (boyle.eng.level3.com [127.0.0.1]) by boyle.eng.level3.com (8.9.3/8.8.7) with ESMTP id UAA03624; Fri, 4 May 2001 20:58:33 -0600 Date: Fri, 4 May 2001 20:58:33 -0600 (MDT) From: Jim Boyle X-Sender: jboyle@boyle.eng.level3.com To: Martin-Guy Richard cc: "'jwysocki83@hotmail.com'" , mpls@UU.NET Subject: RE: draft-katz-yeung-ospf-traffic-04 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Thu, 26 Apr 2001, Martin-Guy Richard wrote: > John, > > The best way to see it is to use an example: > > Those are the sub-TLVs for the Link TLV. > > 1 - Link type (1 octet) > 2 - Link ID (4 octets) > 3 - Local interface IP address (4 octets) > 4 - Remote interface IP address (4 octets) > 5 - Traffic engineering metric (4 octets) > 6 - Maximum bandwidth (4 octets) > 7 - Maximum reservable bandwidth (4 octets) > 8 - Unreserved bandwidth (32 octets) > 9 - Resource class/color (4 octets) > > Let say on a certain interface on a certain router we have for the Max > Rsv BW and Unreserved bandwidth sub-TLVs the following values: > > Maximum reservable bandwidth : 1250000 > Priority 0 : 1250000 Priority 1 : 1225000 > Priority 2 : 1225000 Priority 3 : 1225000 > Priority 4 : 1225000 Priority 5 : 1209750 > Priority 6 : 1209750 Priority 7 : 1209750 > > You can see that I've set the Max Resv BW to 10Mbps > (10Mbps/8bytes=1250000 bytes per second) > > One thing you have to know before I continue: > > On that particular interface on that same router, I have two tunnel > having two different hold priority > > Tunnel 1 has a hold priority of 5, with Resv BW of 122 kbps > Tunnel 2 has a hold priority of 1, with Resv BW of 200 kbps. > > Let's continue. > > To find the Unreserved Bandwidth at each priority we need to apply the > following formula: > > (Unreserved BW for current hold priority)=(Unreserved BW from previous > hold priority) - (Resv BW for current hold priority) > where in the draft does it say this? this is one common implementation, but all the draft says is you advertise the bandwidth available at the given priorities, it doesn't impose a must (or even should) on doing preemption, or even get into the details on how one strictly must implement preemption. In your above case, the following would also be a valid advertisement. Maximum reservable bandwidth : 1250000 Priority 0 : 1209750 Priority 1 : 1209750 Priority 2 : 1209750 Priority 3 : 1209750 Priority 4 : 1209750 Priority 5 : 1209750 Priority 6 : 1209750 Priority 7 : 1209750 or for that matter.... Maximum reservable bandwidth : 1250000 Priority 0 : 100000 Priority 1 : 100000 Priority 2 : 1209750 Priority 3 : 100000 Priority 4 : 1209750 Priority 5 : 1209750 Priority 6 : 1209750 Priority 7 : 1209750 (say for instance, I wanted to limit the reservations at those "priorities", to match up with queing for instance). This could be a very scalable (it's all releative :) implementation for achieving certain QoS objectives in an network. RSVP (or CR-LDP) should then just check the bandwidth available at that priority, and in fact those drafts (at least the rsvp one) don't require some sort of exhaustive search when doing path lookups, or even make preemption a requirement. cheers, Jim > At priority 0, I still have the maximum reservable bandwidth. It is > equal to Max Resv BW. > At priority 1, I have a different number. When we apply the formula, we > get 1225000 bytes per second left for next priority. > > At priority 2, nothing reserved, so by applying the formula, we still > have 1225000 bytes per second left for next priority. > > At priority 3, same thing. > At priority 4, same thing. > At priority 5, we get 1209750 bytes per second since I reserved 122 kbps > for that hold priority. > At priority 6, nothing reserved, so by applying the formula, we still > have 1209750 bytes per second left for next priority. > > At priority 7, same thing. > > I hope that my example is "draft compliant"! > > -----Original Message----- > From: owner-mpls@UU.NET [ mailto:owner-mpls@UU.NET > ]On Behalf Of John > Wysocki > Sent: April 25, 2001 2:45 PM > To: mpls@UU.NET > Subject: draft-katz-yeung-ospf-traffic-04 > > > In this draft 2.4.2 Link TLV has sub-TLV 8 - Unreserved bandwidth (32 > octets). > > 2.5.8 says Each value will be less than or equal to the maximum > reservable > bandwidth. It specifies not yet reserved BW at each of the eight > priority > levels. > > Does this mean each 4 octets (32/8 = 4) will represent unreserved > bandwith > for a priority? > What does it represent? 2^4 = 16 values, but how do you use it? > > Does anyone know? > > Thanks. > > John > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > From owner-mpls@UU.NET Sat May 5 00:15:57 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26893 for ; Sat, 5 May 2001 00:15:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknqm03481; Sat, 5 May 2001 04:14:52 GMT Received: by mail-control.mail.uu.net id QQknqm18755 for mpls-outgoing; Sat, 5 May 2001 04:14:19 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknqm18747 for ; Sat, 5 May 2001 04:14:12 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknqm17817 for ; Sat, 5 May 2001 04:14:08 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknqm02136 for ; Sat, 5 May 2001 04:14:07 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f454EYa00429 for ; Fri, 4 May 2001 21:14:34 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id AAA13234 for mpls@uu.net; Sat, 5 May 2001 00:14:06 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknpy09845 for ; Sat, 5 May 2001 00:36:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknpy12508 for ; Sat, 5 May 2001 00:36:16 GMT Received: from longmail2.lboard.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.109.116.89]) id QQknpy12876 for ; Sat, 5 May 2001 00:36:16 GMT Received: by longmail2.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 4 May 2001 20:36:28 -0400 Message-ID: From: Ed Ellesson To: "'mpls@uu.net'" Cc: "'George Swallow'" , "'Vijay Srinivasan'" , "Joel M. Halpern" , "'Wijnen, Bert (Bert)'" Subject: MPLS WG: Policy Terminology Draft, Extended WG Last Call Date: Fri, 4 May 2001 20:36:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk MPLS WG: Our AD has asked us to inform your WG that this WG Last Call is going on in the Policy Framework WG. This is to give you a chance for review and comments, because the terminology is also meant to be used by your WG. Extended WG Last Call: This last call is hereby extended to end at CoB on Fri, May 18, 2001. The latest revision of the Terminology Draft is in the I-D repository. for your reference: http://www.ietf.org/internet-drafts/draft-ietf-policy-terminology-03.txt Please also note that the title is changing to be more descriptive: Terminology for Policy-Based Management This revision reflects all known issues and comments. This note extends the current working group last call, to two weeks from today, and is intended to bring forth any last issues. After such issues are resolved according to the working group consensus, we will be submitting this document to the IESG for publication as an informational RFC. We are also strongly suggesting that the comments/discussion be done to/on the policy fw wg mailing list... so that we have one archive to check later if needed. If you are not already subscribed to the policy framework mailing list: General Discussion: policy@raleigh.ibm.com To Subscribe: policy-request@raleigh.ibm.com In Body: subscribe Archive: ftp://ftp.ietf.org/ietf-mail-archive/policy Thank you, and we apologize if you receive more than one notice like this. Ed Ellesson, with Joel Halpern Co-chairs, Policy Framework Working Group From owner-mpls@UU.NET Sat May 5 01:56:41 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03436 for ; Sat, 5 May 2001 01:56:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknqt14656; Sat, 5 May 2001 05:55:33 GMT Received: by mail-control.mail.uu.net id QQknqt18557 for mpls-outgoing; Sat, 5 May 2001 05:55:00 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknqt18537 for ; Sat, 5 May 2001 05:54:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknqt18139 for ; Sat, 5 May 2001 05:53:39 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknqt27944 for ; Sat, 5 May 2001 05:53:24 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id BAA00019 for mpls@uu.net; Sat, 5 May 2001 01:53:23 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknqt18414 for ; Sat, 5 May 2001 05:52:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknqt11820 for ; Sat, 5 May 2001 05:52:31 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQknqt26821 for ; Sat, 5 May 2001 05:52:30 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f455qHF19346; Sat, 5 May 2001 08:52:17 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15091.38161.514887.486740@lohi.eng.telia.fi> Date: Sat, 5 May 2001 08:52:17 +0300 (EEST) To: "Jay Wang" Cc: "HANSEN CHAN" , "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media In-Reply-To: References: <15090.64600.180853.33136@lohi.eng.telia.fi> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jay Wang writes: > Well, RPR gives you bandwidth endurance at the link level, a shared > media in this case. On higher level, you may conduct your QoS as > appropriate, Diffserv, Intserv, or else. One does not preclude the other, > IMO. how about if someone would like to give different bandwidth assurance to more than one independent traffic class? also, within a diffserv traffic class, droping of packets is based on the drop presedence of the packet, not based on behind which nodes the packets arrived. as i said before, node based fairness can only be applied to the highest dp packets within each class. dpt (and also rpr if it adopts dpt) thus supports diffserv only in a very limited sense. as far as i remember, it is the only ieee mac standard, where the specification tells how many queues the switch has. -- juha From owner-mpls@UU.NET Sat May 5 17:04:13 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18049 for ; Sat, 5 May 2001 17:04:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkntc20080; Sat, 5 May 2001 21:02:51 GMT Received: by mail-control.mail.uu.net id QQkntc10490 for mpls-outgoing; Sat, 5 May 2001 21:02:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkntc10389 for ; Sat, 5 May 2001 21:02:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkntc18407 for ; Sat, 5 May 2001 21:01:22 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkntc18136 for ; Sat, 5 May 2001 21:01:22 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id RAA25833 for mpls@uu.net; Sat, 5 May 2001 17:01:22 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkntc06934 for ; Sat, 5 May 2001 21:00:48 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkntc02802 for ; Sat, 5 May 2001 21:00:31 GMT Received: from tonga.force10networks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.force10networks.com [206.54.51.114]) id QQkntc17047 for ; Sat, 5 May 2001 21:00:31 GMT Received: by tonga.ncorenetworks.com with Internet Mail Service (5.5.2653.19) id ; Sat, 5 May 2001 14:00:29 -0700 Message-ID: From: Jason Chen To: "'mpls@uu.net'" Cc: Jason Chen Subject: OSPF TE testing tool / protocol simulator Date: Sat, 5 May 2001 14:00:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi, All, If you know any test tools or protocol simulator for OSPF TE (RFC 2676) in the market, would you pass that information to me ? Thanks, Jason From owner-mpls@UU.NET Sun May 6 04:51:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08226 for ; Sun, 6 May 2001 04:51:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknux29122; Sun, 6 May 2001 08:50:25 GMT Received: by mail-control.mail.uu.net id QQknux19691 for mpls-outgoing; Sun, 6 May 2001 08:49:52 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknux19673 for ; Sun, 6 May 2001 08:49:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknux23601 for ; Sun, 6 May 2001 08:49:30 GMT Received: from noya.bupt.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQknux26950 for ; Sun, 6 May 2001 08:49:27 GMT Received: from vinus ([202.112.109.71]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f467wbR23445 for ; Sun, 6 May 2001 15:58:38 +0800 (CST) Message-Id: <200105060758.f467wbR23445@noya.bupt.edu.cn> Date: Sun, 6 May 2001 15:57:29 +0800 From: Felix Chang To: mpls_maillist Subject: Parameters in LDP entity table X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi,everyone I am confused by some parameters in the LDP entity table. Suppose there are several kinds of mpls-capable interfaces(eg.ATM-based, fr-based) in a LSR, it should use per interface label space. So it has several LDP entities. Is that right? In these entities, are the values of some parameters such as mplsLdpEntityLabelDistributionMethod, mplsLdpEntityLabelRetentionMode, the same? Best regards! Felix Chang mplszhz@263.net From owner-mpls@UU.NET Sun May 6 11:18:14 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11548 for ; Sun, 6 May 2001 11:18:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknvx28441; Sun, 6 May 2001 15:16:50 GMT Received: by mail-control.mail.uu.net id QQknvx01569 for mpls-outgoing; Sun, 6 May 2001 15:16:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknvx01531 for ; Sun, 6 May 2001 15:16:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknvx15851 for ; Sun, 6 May 2001 15:15:42 GMT Received: from ext1.ics.forth.gr by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.ics.forth.gr [139.91.1.2]) id QQknvx21108 for ; Sun, 6 May 2001 15:15:41 GMT Received: from ismene.ics.forth.gr (mailhost.ics.forth.gr [139.91.157.51]) by ext1.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.5-GATE) with ESMTP id SAA23455; Sun, 6 May 2001 18:15:38 +0300 (EET DST) Received: from sappho.ics.forth.gr (sappho-lane.ics.forth.gr [139.91.157.50]) by ismene.ics.forth.gr (8.8.8/ICS-FORTH/V3) with ESMTP id SAA01328; Sun, 6 May 2001 18:11:38 +0300 (EET DST) Posted-Date: Sun, 6 May 2001 18:11:38 +0300 (EET DST) Organization: Received: from localhost (tziou@localhost) by sappho.ics.forth.gr (8.9.3/ICS-FORTH/V8.2.2C-INTNULL) with ESMTP id SAA18296; Sun, 6 May 2001 18:10:40 +0300 (EEST) X-Authentication-Warning: sappho.ics.forth.gr: tziou owned process doing -bs Date: Sun, 6 May 2001 18:10:40 +0300 (EEST) From: Chrysostomos Tziouvaras To: mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: Modelling of CR-LSP requests In-Reply-To: <00bb01c0bce2$2d543ce0$92feffcb@etri.re.kr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Dear all, I am trying to conduct some experiments concerning MPLambdaS. The experimental scenario is that there is an optical backbone to which are attached many MPLS client networks. These client networks produce Label Request messages. Do you have in mind any realistic scenario about -the probability distribution concerning the arrival of such requests -the lifetime of the requested CR-LSPs -the size of bandwidth that each CR-LSP request can ask. Thanks Tziouvaras Chrysostomos ICS-FORTH Researcher From owner-mpls@UU.NET Sun May 6 16:29:32 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13547 for ; Sun, 6 May 2001 16:29:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknwr02249; Sun, 6 May 2001 20:28:36 GMT Received: by mail-control.mail.uu.net id QQknwr00237 for mpls-outgoing; Sun, 6 May 2001 20:28:04 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknwr00222 for ; Sun, 6 May 2001 20:27:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknwr02474 for ; Sun, 6 May 2001 20:27:07 GMT Received: from dnsmx2pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQknwr07230 for ; Sun, 6 May 2001 20:27:07 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA06416 for ; Sun, 6 May 2001 16:22:27 -0400 (EDT) Subject: RSVP hello message To: mpls@UU.NET From: "Hong Liao" Date: Sun, 6 May 2001 16:22:53 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/06/2001 04:22:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the format for hello message is as on section 5.1: :: = [] I want to make sure if the Hello object here is only one or a list of Hello objects. For my understanding, the format in Hello message, is not a list of Hello objects, it should be one Hello object between two RSVP neighbours. Can anyone help me to confirm this? Thanks in an advance. Julia From owner-mpls@UU.NET Sun May 6 18:35:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14413 for ; Sun, 6 May 2001 18:35:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxa17413; Sun, 6 May 2001 22:34:44 GMT Received: by mail-control.mail.uu.net id QQknxa17566 for mpls-outgoing; Sun, 6 May 2001 22:34:11 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknxa17561 for ; Sun, 6 May 2001 22:34:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknxa24752 for ; Sun, 6 May 2001 22:33:14 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQknxa28808 for ; Sun, 6 May 2001 22:33:14 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA09917; Sun, 6 May 2001 18:32:12 -0400 (EDT) Subject: Re: signaling preemption in GMPLS RSVP To: "Reeve, Andrew" Cc: mpls@UU.NET From: "Hong Liao" Date: Sun, 6 May 2001 18:32:38 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/06/2001 06:32:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, Look at this message, I would like to ask some question related to this in RSVP-TE. For my understanding of RSVP-TE , if there is a Path message send out from the Ingress router, and there is no Resv message back from the Egress router, the Ingress router should send out PathTear to clear the connect(path state) instead of sending out PahtErr to clear the connection. I did not find this statement 'Removing State with a PathErr message' in the latest version of RSVP-TE. Sorry I know you are discussing about the GMPLS RSVP. Can anyone point me out? Thanks, Julia "Reeve, Andrew" on 05/04/2001 11:57:37 AM To: "'mpls@uu.net'" cc: (bcc: Hong Liao/Telcordia) Subject: signaling preemption in GMPLS RSVP Section 4 'Removing State with a PathErr message' in draft-ietf-mpls-generalized-rsvp-te-03.txt makes a welcome improvement to the signaling when LSPs are torn down by the network. I assume that it is intended that the benefits be obtained for any 'network clear'. However the draft mentions its use for 'certain error conditions' without explaining what these are. I suggest that the section be modified to state explicitly that the mechanism can be used anywhere a PathErr is used. In other words it should be possible to use the Path_State_Removed flag for any error and also to use it during preemption. Regards, Andy > __________________________ > Andy Reeve, > Senior Consultant, > Internet Technology and Networks. __________________________ > Roke Manor Research Ltd, > A SIEMENS Company. > > Roke Manor, > Romsey. SO51 OZN. > > Tel: +44 1794 833580 > Fax: +44 1794 833616 > > mailto:andrew.reeve@roke.co.uk > > http://www.roke.co.uk > http://www.roke-manor.com > __________________________ The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-mpls@UU.NET Sun May 6 19:07:59 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14691 for ; Sun, 6 May 2001 19:07:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxc01337; Sun, 6 May 2001 23:06:48 GMT Received: by mail-control.mail.uu.net id QQknxc08622 for mpls-outgoing; Sun, 6 May 2001 23:06:15 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknxc08584 for ; Sun, 6 May 2001 23:06:08 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknxc21412 for ; Sun, 6 May 2001 23:05:03 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQknxc28498 for ; Sun, 6 May 2001 23:05:03 GMT Received: from zcars04e.nortelnetworks.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id TAA21355; Sun, 6 May 2001 19:04:58 -0400 Received: from zcard015.ca.nortel.com (actually zcard015) by zcars04e.nortelnetworks.com; Sun, 6 May 2001 19:05:01 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 May 2001 19:05:03 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4051EBE1E@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'Chrysostomos Tziouvaras'" , mpls@UU.NET, ip-optical@lists.bell-labs.com Subject: RE: Modelling of CR-LSP requests Date: Sun, 6 May 2001 19:05:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D680.FA6561C0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D680.FA6561C0 Content-Type: text/plain; charset="iso-8859-1" That's a tough one and it depends on the granularity of the requests. Initially the requests will be large, on the order of an OC-48 or 192 and mostly initiated by routers. Obviously the routers will not trigger requests for such large pipes very often but it will probably be very bursty. Other kinds of devices will request smaller pipes, down to STS-1 level and you will see cross connects with 100,000 or more STS-n to STS-n capability. The model I would expect is 'lots' of requests in a very short time, then dead calm for extended periods of time. In other words, the worst possible pattern. We can probably take many of the lessons we already have learned about data patterns and scale them down and get the kind of behavior to expect for optical trail creation. This makes even more sense if routers start dynamically switching up trails in reaction to traffic patterns. Sorry I don't have any hard numbers for you but assuming the worst is probably a good assumption. Cheers, Peter Ashwood-Smith -----Original Message----- From: Chrysostomos Tziouvaras [SMTP:tziou@ics.forth.gr] Sent: Sunday, May 06, 2001 11:11 AM To: mpls@UU.NET; ip-optical@lists.bell-labs.com Subject: Modelling of CR-LSP requests Dear all, I am trying to conduct some experiments concerning MPLambdaS. The experimental scenario is that there is an optical backbone to which are attached many MPLS client networks. These client networks produce Label Request messages. Do you have in mind any realistic scenario about -the probability distribution concerning the arrival of such requests -the lifetime of the requested CR-LSPs -the size of bandwidth that each CR-LSP request can ask. Thanks Tziouvaras Chrysostomos ICS-FORTH Researcher ------_=_NextPart_001_01C0D680.FA6561C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Modelling of CR-LSP requests

That's a tough one and it depends on = the granularity of the requests. Initially the requests will be large, = on the order of an OC-48 or 192 and mostly initiated by routers. = Obviously the routers will not trigger requests for such large pipes = very often but it will probably be very bursty. Other kinds of devices = will request smaller pipes, down to STS-1 level and you will see cross = connects with 100,000 or more STS-n to STS-n capability.

The model I would expect is 'lots' of = requests in a very short time, then dead calm for extended periods of = time. In other words, the worst possible pattern.

We can probably take many of the = lessons we already have learned about data patterns and scale them down = and get the kind of behavior to expect for optical trail creation. This = makes even more sense if routers start dynamically switching up trails = in reaction to traffic patterns.

Sorry I don't have any hard numbers = for you but assuming the worst is probably a good assumption.

Cheers,

Peter Ashwood-Smith




    -----Original = Message-----
    From:   Chrysostomos = Tziouvaras [SMTP:tziou@ics.forth.gr]
    Sent:   Sunday, May 06, 2001 11:11 AM
    To:     mpls@UU.NET; ip-optical@lists.bell-labs.com
    Subject:       = Modelling of CR-LSP requests

    Dear all,
    I am trying to conduct some = experiments concerning MPLambdaS. The
    experimental scenario is that there = is an optical backbone to which are
    attached many MPLS client networks. = These client networks produce Label
    Request messages.
    Do you have in mind any realistic = scenario about
    -the probability distribution = concerning the arrival  of such requests
    -the lifetime of the requested = CR-LSPs
    -the size of bandwidth that each = CR-LSP request can ask.

    Thanks
    Tziouvaras Chrysostomos
    ICS-FORTH Researcher

------_=_NextPart_001_01C0D680.FA6561C0-- From owner-mpls@UU.NET Sun May 6 20:45:37 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15505 for ; Sun, 6 May 2001 20:45:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxi20689; Mon, 7 May 2001 00:44:11 GMT Received: by mail-control.mail.uu.net id QQknxi05328 for mpls-outgoing; Mon, 7 May 2001 00:43:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknxi05320 for ; Mon, 7 May 2001 00:43:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknxi25667 for ; Mon, 7 May 2001 00:43:10 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQknxi23045 for ; Mon, 7 May 2001 00:43:09 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id UAA22868; Sun, 6 May 2001 20:39:31 -0400 (EDT) Subject: disconnect connection To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Sun, 6 May 2001 20:39:58 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/06/2001 08:39:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi David, I have questions for disconnecting(clear connection). 1. Suppose LSR received Path message from Ingress router, and LSR sent out Resv message back. If the LSR wanted to tear down this session, it will send out ResvTear to Ingress router, and Ingress router will take out the Resv state of LSR, and do not response back anything, this session will be ended. I may wrong. 2. another way round, if there is LSR and it forwarded Path message to Egress router, and Egress router sent back Resv message to LSR, suppose the LSR wants to tear down this session, it will send out the PathTear to the Egress router, and Egress router will move the Path state of LSR, do not response anything, this session is ended. Did I understand correct? 3. If the Ingress router sends out the Path message, but the no Resv message sent back from LSR, does Ingress router need to send out PathTear to clear the path state in case that this Path state has already been sent there. 4. How about the transit router to try to clear/tear down the session? Can you help me to understand more of the RSVP protocol. Thanks in an advance. Julia From owner-mpls@UU.NET Sun May 6 23:38:19 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18744 for ; Sun, 6 May 2001 23:38:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxu27631; Mon, 7 May 2001 03:37:14 GMT Received: by mail-control.mail.uu.net id QQknxu15872 for mpls-outgoing; Mon, 7 May 2001 03:36:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknxu15864 for ; Mon, 7 May 2001 03:36:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknxu21441 for ; Mon, 7 May 2001 03:36:09 GMT Received: from bgslc02.TBG.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [63.99.125.2]) id QQknxu05610 for ; Mon, 7 May 2001 03:36:08 GMT Received: by BGSLC02 with Internet Mail Service (5.5.2650.21) id ; Sun, 6 May 2001 21:21:42 -0600 Message-ID: <0C875DC28791D21192CD00104B95BFE701E49A98@BGSLC02> From: Irwin Lazar To: mpls@UU.NET Subject: "Dynamic" MPLS Date: Sun, 6 May 2001 21:21:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D6A4.D5BFC2CE" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D6A4.D5BFC2CE Content-Type: text/plain; charset="iso-8859-1" An article in this month's "Wired" on Caspian Networks claims that they use a patented approach called "Dynamic" MPLS to detect and classify packet flows such as voice, video and data, or even data from a specific customer. They claim that their D/MPLS architecture provides performance far greater than what is currently available from packet-based routers from Cisco, Juniper & Pluris. I've never heard the term "Dynamic" MPLS before. Could someone provide any pointers? Are these claims valid? AFAIK, once you get inside the boxes, the core router switching fabrics from Cisco & Juniper are all cell-based, not packet based, is that correct? Thanks in advance, Irwin ------_=_NextPart_001_01C0D6A4.D5BFC2CE Content-Type: text/html; charset="iso-8859-1"
An article in this month's "Wired" on Caspian Networks claims that they use a patented approach called "Dynamic" MPLS to detect and classify packet flows such as voice, video and data, or even data from a specific customer.  They claim that their D/MPLS architecture provides performance far greater than what is currently available from packet-based routers from Cisco, Juniper & Pluris.
 
I've never heard the term "Dynamic" MPLS before.  Could someone provide any pointers?  Are these claims valid?
 
AFAIK, once you get inside the boxes, the core router switching fabrics from Cisco & Juniper are all cell-based, not packet based, is that correct?
 
Thanks in advance,
Irwin
------_=_NextPart_001_01C0D6A4.D5BFC2CE-- From owner-mpls@UU.NET Mon May 7 00:11:40 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19054 for ; Mon, 7 May 2001 00:11:39 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxw22409; Mon, 7 May 2001 04:10:44 GMT Received: by mail-control.mail.uu.net id QQknxw07340 for mpls-outgoing; Mon, 7 May 2001 04:09:44 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknxw07314 for ; Mon, 7 May 2001 04:09:28 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknxw24161 for ; Mon, 7 May 2001 04:09:22 GMT From: mgoel@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQknxw26430 for ; Mon, 7 May 2001 04:09:19 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f474ARf19269; Mon, 7 May 2001 09:40:27 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A45.00157883 ; Mon, 7 May 2001 09:24:31 +0530 X-Lotus-FromDomain: HSS To: "Gross, Gerhard" cc: mpls@UU.NET Message-ID: <65256A45.00157493.00@sandesh.hss.hns.com> Date: Mon, 7 May 2001 09:38:34 +0530 Subject: Re: terminology Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk Hi Grey, As per my understanding, the section 3.27 of RFC 3031 just wants to emphasise that both LSP tunneling as well as network layer tunneling can be used for routing mpls packets. For e.g. Let the network topology is like A------B------C------D-------E Now say an unlabeled packet comes at ingress router A, with say destination X. Router A finds that the next LSR to which this datagram should be forwarded is E. Now two cases may arise. 1. There is not an LSP between A and E, but there is a routing table entry in A for the router E. In this case LSR A will first push the label which is understood by E. Then A will forward the datagram so formed after pushing the label for E to the IP forwarding function specifying the destination hop for this datagram to be router E. This is normal network layer tunneling used for forwarding the mpls packets. In my opinion this type of tunneling cannot be used if we want some sort of quality of service also. This can only be used if we want only destination based forwarding of mpls datagrams. 2. There is an LSP between A to E(obviously using LSP tunneling). Then A will first push the label which is understood by E. Then push the label which is understood by B, and it will forward the datagram to LSR B. At LSR D, the datagram that will be forwarded to E will contain only that label that is understood by E. This is the case with LSP tunneling. Pls correct me if I am wrong. Regards Mohit Goel "Gross, Gerhard" on 05/03/2001 11:06:09 PM To: "'mpls@uu.net'" cc: (bcc: Mohit Goel/HSS) Subject: terminology Sorry, sent previous message prematurely. Once again... The definitions "LSP tunnel" in the docs seem to be somewhat misleading. For example, section 3.27.3 of RFC 3031 states: "It is possible to implement a tunnel as a LSP, and use label switching rather than network layer encapsulation to cause the packet to travel through the tunnel. ... This is called a "LSP Tunnel." This is standard MPLS as far as I tell. Why rename it? Also, section 1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt states: "Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel." Again this seems to be just normal use of MPLS. The text implies that an LSP tunnel is a special case of MPLS. Is there any other use of MPLS? Thanks! Gery XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X X X Gerhard W. Gross, Ph.D. X X Intel X X 2111 NE 25th Ave X X Hillsboro, OR 97124-5961, USA X X Internet Infrastructure Arch. Group X X - Internet and Communication Lab X X phone: (503) 264-6389 X X fax: (503) 264-3483 X X email: gerhard.gross@intel.com X X X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX From owner-mpls@UU.NET Mon May 7 00:14:51 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19096 for ; Mon, 7 May 2001 00:14:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxw05337; Mon, 7 May 2001 04:13:41 GMT Received: by mail-control.mail.uu.net id QQknxw07945 for mpls-outgoing; Mon, 7 May 2001 04:13:08 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknxw07915 for ; Mon, 7 May 2001 04:12:56 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknxw02071 for ; Mon, 7 May 2001 04:12:52 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQknxw03587 for ; Mon, 7 May 2001 04:12:49 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f474E7s19528 for ; Mon, 7 May 2001 09:44:07 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A45.0015B54C ; Mon, 7 May 2001 09:27:06 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A45.0015B08F.00@sandesh.hss.hns.com> Date: Mon, 7 May 2001 09:26:50 +0530 Subject: a simple question! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi! why was downstream label assignment chosen in MPLS over upstream label assignment as is the case with generalised MPLS? Is there any specific advantage/constraint posed by the downstream label assignment method? regards sumit From owner-mpls@UU.NET Mon May 7 00:56:10 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19441 for ; Mon, 7 May 2001 00:56:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknxz22376; Mon, 7 May 2001 04:55:02 GMT Received: by mail-control.mail.uu.net id QQknxz11110 for mpls-outgoing; Mon, 7 May 2001 04:54:30 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknxz11102 for ; Mon, 7 May 2001 04:54:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknxz11792 for ; Mon, 7 May 2001 04:53:20 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQknxz19902 for ; Mon, 7 May 2001 04:53:17 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f474sXq22702 for ; Mon, 7 May 2001 10:24:33 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A45.00198716 ; Mon, 7 May 2001 10:08:49 +0530 X-Lotus-FromDomain: HSS To: mpls@UU.NET Message-ID: <65256A45.001985E6.00@sandesh.hss.hns.com> Date: Mon, 7 May 2001 10:08:45 +0530 Subject: Attributes of a Label Binding Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi all! referring to section 3.5 of RFC 3031;- what are these attributes being talked about that may be learned from the downstream LSR for a particular bind. To me if anything is specific to a binding for a particular FEC then it should be a part of the FEC itself i.e. it should be one of the FEC elements that defines that packet class. I am not able to appreciate the need for any other information that needs to exist and be exchanged for a binding. regards sumit From owner-mpls@UU.NET Mon May 7 06:39:27 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05302 for ; Mon, 7 May 2001 06:39:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknyw01374; Mon, 7 May 2001 10:38:30 GMT Received: by mail-control.mail.uu.net id QQknyw01120 for mpls-outgoing; Mon, 7 May 2001 10:37:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknyw01111 for ; Mon, 7 May 2001 10:37:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknyw26332 for ; Mon, 7 May 2001 10:37:37 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQknyw00070 for ; Mon, 7 May 2001 10:37:36 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id QAA06841 for ; Mon, 7 May 2001 16:15:54 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GCYOGA00.GD8 for ; Mon, 7 May 2001 16:13:22 +0530 Date: Mon, 7 May 2001 16:12:52 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: mpls@UU.NET Subject: LSPID in CRLDP, Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk Hi, The LSPID TLV in section 4.5 of draft-ietf-mpls-cr-ldp-04 is given to be ingress LSR ID (or its own IP address). When a LSR receive ER Hops composed of LSPID as the second ER HOP and the LSR is not part of this LSPID, then LSR is supposed to propagate this request to a next hop that is along the path to the ingress of the tunnel formed by the LSPID. My question is how do I find this path if the LSPID is composed of router ID. I mean if this is composed of IPv4 address, then LSR can find a path to this LSPID ingress tunnel, but what happens with the router ID. I went thro' the archives could not find any solutions on this.. Thanks Chetan S ___________ The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw From owner-mpls@UU.NET Mon May 7 08:54:00 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09647 for ; Mon, 7 May 2001 08:54:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzf28286; Mon, 7 May 2001 12:52:32 GMT Received: by mail-control.mail.uu.net id QQknzf20235 for mpls-outgoing; Mon, 7 May 2001 12:51:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknzf20227 for ; Mon, 7 May 2001 12:51:53 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzf14309 for ; Mon, 7 May 2001 12:51:47 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknzf26861 for ; Mon, 7 May 2001 12:51:46 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id IAA07205 for mpls@uu.net; Mon, 7 May 2001 08:51:45 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknzf20179 for ; Mon, 7 May 2001 12:51:01 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzf11038 for ; Mon, 7 May 2001 12:50:44 GMT Received: from rtp-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQknzf25094 for ; Mon, 7 May 2001 12:50:43 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f47CnYm21145; Mon, 7 May 2001 08:49:34 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.84.75.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAB01597; Mon, 7 May 2001 08:50:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20010507085305.018f9ac8@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 08:53:32 -0400 To: Shahram Davari , "'mpls@uu.net'" From: "Thomas D. Nadeau" Subject: Re: LSR MIB question In-Reply-To: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C18@BBY1EXM01> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Both. You should keep track of information for both of the labels involved. --Tom >If an LSR is the origin point of an MPLS tunnel, and it receives an MPLS >packet, it first swaps the top label and pushes a new label on top of >that. Which performance statistics are required to be collected by >LSR-MIB: The swapped label or the pushed label or both? > >Yours, >Shahram Davari > > From owner-mpls@UU.NET Mon May 7 09:22:28 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10675 for ; Mon, 7 May 2001 09:22:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzh14453; Mon, 7 May 2001 13:21:15 GMT Received: by mail-control.mail.uu.net id QQknzh11840 for mpls-outgoing; Mon, 7 May 2001 13:20:42 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknzh11835 for ; Mon, 7 May 2001 13:20:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzh09686 for ; Mon, 7 May 2001 13:20:24 GMT Received: from mail-blue.research.att.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQknzh13185 for ; Mon, 7 May 2001 13:20:24 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 6C5E94DA60; Mon, 7 May 2001 09:13:29 -0400 (EDT) Received: from research.att.com (dhcp145.research.att.com [135.207.28.145]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id JAA16228; Mon, 7 May 2001 09:13:28 -0400 (EDT) Message-ID: <3AF6A02A.895E4D9F@research.att.com> Date: Mon, 07 May 2001 09:16:27 -0400 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: Re: a simple question! References: <65256A45.0015B08F.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I can figure out one reason: (1) It is convenient to achieve LSP merging, i.e., to generate a destination rooted tree. --- guangzhi suchauhan@hss.hns.com wrote: > hi! > why was downstream label assignment chosen in MPLS over upstream label > assignment as is the case with generalised MPLS? Is there any specific > advantage/constraint posed by the downstream label assignment method? > > regards > sumit From owner-mpls@UU.NET Mon May 7 09:54:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12011 for ; Mon, 7 May 2001 09:54:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzj00367; Mon, 7 May 2001 13:53:44 GMT Received: by mail-control.mail.uu.net id QQknzj14774 for mpls-outgoing; Mon, 7 May 2001 13:52:35 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknzj14737 for ; Mon, 7 May 2001 13:52:17 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzj05067 for ; Mon, 7 May 2001 13:51:51 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknzj27612 for ; Mon, 7 May 2001 13:51:51 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f47Dpon12295 for ; Mon, 7 May 2001 06:51:50 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA14315 for mpls@uu.net; Mon, 7 May 2001 09:51:49 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknzh12467 for ; Mon, 7 May 2001 13:27:05 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzh07160 for ; Mon, 7 May 2001 13:26:21 GMT Received: from anti_vir1.rad.co.il by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [192.116.244.108]) id QQknzh22047 for ; Mon, 7 May 2001 13:26:19 GMT Received: from anti_vir1.rad.co.il (localhost [127.0.0.1]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id QAA19081 for ; Mon, 7 May 2001 16:27:15 +0200 (IST) Received: from radmail.rad.co.il (radmail [192.114.24.30]) by anti_vir1.rad.co.il (8.9.3+Sun/8.9.3) with ESMTP id QAA19065; Mon, 7 May 2001 16:27:14 +0200 (IST) Received: from tlv1.axerra.com ([192.168.254.14]) by radmail.rad.co.il (Post.Office MTA v3.5.3 release 223 ID# 0-69802U1300L1200S0V35) with ESMTP id il; Mon, 7 May 2001 16:27:14 +0300 Received: by TLV1 with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 16:25:37 +0200 Message-ID: From: Sasha Vainshtein To: "'Guangzhi Li'" , suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: RE: a simple question! Date: Mon, 7 May 2001 16:25:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I see another reason: it makes support of the hop-by-hop forwarding application (i.e., forwarding which follows the routes buit by the IGP) very easy. ______________________________________________ With best regards, Sasha Vainshtein mailto: sasha@axerra.com phone: +972-3-7659993 (office) fax: +972-3-6487779 (office) >>-----Original Message----- >>From: Guangzhi Li [mailto:gli@research.att.com] >>Sent: Monday, May 07, 2001 3:16 PM >>To: suchauhan@hss.hns.com >>Cc: mpls@UU.NET >>Subject: Re: a simple question! >> >> >>Hi, >> >>I can figure out one reason: >> >>(1) It is convenient to achieve LSP merging, i.e., to >>generate a destination >>rooted tree. >> >>--- guangzhi >> >>suchauhan@hss.hns.com wrote: >> >>> hi! >>> why was downstream label assignment chosen in MPLS >>over upstream label >>> assignment as is the case with generalised MPLS? Is there >>any specific >>> advantage/constraint posed by the downstream label >>assignment method? >>> >>> regards >>> sumit >> From owner-mpls@UU.NET Mon May 7 09:56:16 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12103 for ; Mon, 7 May 2001 09:56:16 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzj19725; Mon, 7 May 2001 13:55:12 GMT Received: by mail-control.mail.uu.net id QQknzj14818 for mpls-outgoing; Mon, 7 May 2001 13:52:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknzj14763 for ; Mon, 7 May 2001 13:52:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzj14672 for ; Mon, 7 May 2001 13:51:23 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQknzj01821 for ; Mon, 7 May 2001 13:51:23 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f47Dppa09159 for ; Mon, 7 May 2001 06:51:51 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA14285 for mpls@uu.net; Mon, 7 May 2001 09:51:21 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknyq04810 for ; Mon, 7 May 2001 09:08:51 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknyq27588 for ; Mon, 7 May 2001 09:08:48 GMT Received: from mailgw.local.ipunplugged.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQknyq27294 for ; Mon, 7 May 2001 09:08:47 GMT Received: from HANSPC (a27.local.ipunplugged.com [192.168.4.197]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA01388; Mon, 7 May 2001 11:09:33 +0200 From: "Hans Sj?strand" To: "Felix Chang" , "mpls_maillist" Subject: RE: Parameters in LDP entity table Date: Mon, 7 May 2001 11:07:28 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200105060758.f467wbR23445@noya.bupt.edu.cn> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit It's true that for many ATM or FR based interfaces uses the encap from rfc3034 or rfc3035. It's also true that those use per intreface label space. In that case you have several entities. distribution and retention method isn't neccesary the same over the label switch even though it's defently the most common case. from RFC 3037 LDP Applicability, section 3 Downstream on Demand distribution with conservative label retention and ordered control is appropriate in situations where labels are a relatively scarce resource that must be conserved, and Downstream Unsolicited distribution with liberal label retention and independent control is appropriate where labels are plentiful and need not be carefully conserved. However, the protocol permits other combinations of distribution method, label retention mode and control mode, including hybrid variants of them. Regards /// Hasse > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Felix Chang > Sent: den 6 maj 2001 09:57 > To: mpls_maillist > Subject: Parameters in LDP entity table > > > hi,everyone > > I am confused by some parameters in the LDP entity table. > Suppose there are several kinds of mpls-capable > interfaces(eg.ATM-based, fr-based) in a LSR, it should use per > interface label space. So it has several LDP entities. Is that > right? In these entities, are the values of some parameters such > as mplsLdpEntityLabelDistributionMethod, > mplsLdpEntityLabelRetentionMode, the same? > > > Best regards! > Felix Chang > mplszhz@263.net From owner-mpls@UU.NET Mon May 7 10:15:37 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12739 for ; Mon, 7 May 2001 10:15:37 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzk29097; Mon, 7 May 2001 14:13:21 GMT Received: by mail-control.mail.uu.net id QQknzk00989 for mpls-outgoing; Mon, 7 May 2001 14:12:48 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknzk00767 for ; Mon, 7 May 2001 14:12:35 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknzk17608 for ; Mon, 7 May 2001 14:11:25 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQknzk08779 for ; Mon, 7 May 2001 14:11:25 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 382EF94006; Mon, 7 May 2001 10:11:17 -0400 (EDT) Message-ID: <3AF6AD05.C380E7D6@sandburst.com> Date: Mon, 07 May 2001 10:11:17 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: suchauhan@hss.hns.com Cc: mpls@UU.NET Subject: Re: a simple question! References: <65256A45.0015B08F.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Sumit, First of all, GMPLS defines extensions to MPLS signaling to allow upstream label 'assignment' but the default mode is still downstream allocation. The extensions are provided to cover specific instances in the general case where it is possible to gain significant optimization of system behavior at little cost. In these instances, use of extensions will likely be the normal case - however, that is not the same as saying that GMPLS somehow turns signaling around in general. The key reason for downstream label allocation is that - in choosing between a downstream (which needs to interpret the labels it receives) and an upstream (which only needs to write the label into the packet), we (the MPLS working group) felt that it makes the most sense to allow the device that has to interpret labels be the one that allocates them. This paradigm extends generally - in most cases even extending to behavior 'inside the box'. GMPLS, on the other hand, deals with a number of instances in which there is no 'label' per-se. For example, a TDM time slot, a lambda or a physical fiber interface may stand in for a 'label'. In these cases, the usage of a 'label' are fairly well understood and the need to allow the receiver to 'control' allocation of 'labels' does not exist. In addition, it is even possible that allowing the upstream device to assign the 'label' lends a significant advantage. For example - if the upstream device needs to undergo a physical re-alignment in order to use the 'assigned' label, and this alignment process consumes some non-zero time, then there is a clear benefit to be realized from allocating the corresponding 'label' at the upstream device. This would be the case, for instance, if a device uses some technology (e.g. - perhaps twisted multi-laminate nano-technology) to physically position a mirror or prism in the optical transmission path. -- Eric Gray You wrote: > hi! > why was downstream label assignment chosen in MPLS over upstream label > assignment as is the case with generalised MPLS? Is there any specific > advantage/constraint posed by the downstream label assignment method? > > regards > sumit From owner-mpls@UU.NET Mon May 7 10:40:36 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13298 for ; Mon, 7 May 2001 10:40:35 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzm11145; Mon, 7 May 2001 14:39:26 GMT Received: by mail-control.mail.uu.net id QQknzm09882 for mpls-outgoing; Mon, 7 May 2001 14:38:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknzm09867 for ; Mon, 7 May 2001 14:38:48 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzm06240 for ; Mon, 7 May 2001 14:38:16 GMT Received: from zcars0m9.nortelnetworks.com by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) id QQknzm04078 for ; Mon, 7 May 2001 14:38:15 GMT Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4) id KAA01019; Mon, 7 May 2001 10:38:11 -0400 Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 7 May 2001 10:37:54 -0400 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 10:37:58 -0400 Message-ID: <03E3E0690542D211A1490000F80836F4051EBE21@zcard00f.ca.nortel.com> From: "Peter Ashwood-Smith" To: "'suchauhan@hss.hns.com'" , mpls@UU.NET Subject: RE: a simple question! Date: Mon, 7 May 2001 10:37:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D703.4DED87A0" X-Orig: Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D703.4DED87A0 Content-Type: text/plain; charset="iso-8859-1" Its strictly a performance thing. For pure optical switches it takes time to position a mirror, bubble, tune a laser etc. If you allow for upstream label assignment it means that by the time the signaling has arrived all the way downstream, most of the data path is already in place. In 'traditional' MPLS the labels are in-band and programming the hardware to use them is effectively instantaneous so a downstream mode seems more rational since it is the downstream that really has to worry about the availability of those labels. Cheers, Peter Ashwood-Smith -----Original Message----- From: suchauhan@hss.hns.com [SMTP:suchauhan@hss.hns.com] Sent: Sunday, May 06, 2001 11:57 PM To: mpls@UU.NET Subject: a simple question! hi! why was downstream label assignment chosen in MPLS over upstream label assignment as is the case with generalised MPLS? Is there any specific advantage/constraint posed by the downstream label assignment method? regards sumit ------_=_NextPart_001_01C0D703.4DED87A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: a simple question!

Its strictly a performance thing. For = pure optical switches it takes time to position a mirror, bubble, tune = a laser etc. If you allow for upstream label assignment it means that = by the time the signaling has arrived all the way downstream, most of = the data path is already in place.

In 'traditional' MPLS the labels are = in-band and programming the hardware to use them is effectively = instantaneous so a downstream mode seems more rational since it is the = downstream that really has to worry about the availability of those = labels.

Cheers,

Peter Ashwood-Smith

    -----Original = Message-----
    From:   = suchauhan@hss.hns.com [SMTP:suchauhan@hss.hns.com]
    Sent:   Sunday, May 06, 2001 11:57 PM
    To:     mpls@UU.NET
    Subject:       = a simple question!



    hi!
         why was = downstream label assignment chosen in MPLS over upstream label
    assignment as is the case with = generalised MPLS? Is there any specific
    advantage/constraint posed by the = downstream label assignment method?

    regards
    sumit

------_=_NextPart_001_01C0D703.4DED87A0-- From owner-mpls@UU.NET Mon May 7 10:42:13 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13325 for ; Mon, 7 May 2001 10:42:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzm09425; Mon, 7 May 2001 14:41:49 GMT Received: by mail-control.mail.uu.net id QQknzm10154 for mpls-outgoing; Mon, 7 May 2001 14:41:17 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknzm10094 for ; Mon, 7 May 2001 14:41:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzm05347 for ; Mon, 7 May 2001 14:40:48 GMT From: Giovanni.Zangrando@alcatel.it Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244]) id QQknzm15545 for ; Mon, 7 May 2001 14:40:47 GMT Received: from tlvhdk.netit.alcatel.it (tlvhgd.netit.alcatel.it [151.98.14.48]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id QAA22000 for ; Mon, 7 May 2001 16:41:13 +0200 (MET DST) Received: from localhost (root@localhost) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA16092 for mpls@UU.NET; Mon, 7 May 2001 16:36:34 +0200 (METDST) X-OpenMail-Hops: 1 Date: Mon, 7 May 2001 15:08:23 +0200 Message-Id: Subject: RSVP-TE MIB MIME-Version: 1.0 TO: mpls@UU.NET Content-Type: multipart/mixed; boundary="openmail-part-02b8f4d8-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-02b8f4d8-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit Hi all, I have a problem with RSVP-TE MIBs. In fact while the functional aspects are addressed in draft-ietf-mpls-rsvp-lsp-tunnel, as far as I know the MIB to manage RSVP-extensions is still to be defined (the only available MIB is RFC2206). Please, does anybody knwow whether there is an ongoing activity to define the RSVP-TE MIB? Thanks in advance. Best regards, Giovanni Zangrando _________________________________________ Giovanni Zangrando OMSN System Engineer - R&D ALCATEL E-mail: giovanni.zangrando@alcatel.it Tel: +39 039 686 9132 Fax: +39 039 686 3590 --openmail-part-02b8f4d8-00000001-- From owner-mpls@UU.NET Mon May 7 11:13:09 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13991 for ; Mon, 7 May 2001 11:13:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzo25850; Mon, 7 May 2001 15:10:32 GMT Received: by mail-control.mail.uu.net id QQknzo19415 for mpls-outgoing; Mon, 7 May 2001 15:09:58 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQknzo19134 for ; Mon, 7 May 2001 15:09:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzo09668 for ; Mon, 7 May 2001 15:08:14 GMT Received: from gorilla.mchh.siemens.de by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gorilla.mchh.siemens.de [194.138.158.18]) id QQknzo26506 for ; Mon, 7 May 2001 15:08:14 GMT Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA02087; Mon, 7 May 2001 17:08:09 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA29105; Mon, 7 May 2001 17:08:09 +0200 (MET DST) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 17:08:09 +0200 Message-ID: From: Heiles Juergen To: mpls@UU.NET, ccamp@ops.ietf.org Subject: Comments on G-PID Date: Mon, 7 May 2001 17:08:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt. Juergen The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID intorduciton text "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload." Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required. Now to the detailed comments: The follwoing G-PIDs have to be removed as they are not defined: 8 Bit synchronous mapping of E3 9 Byte synchronous mapping of E3 12 Byte synchronous mapping of DS2/T2 As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore: 19 Same as 12 but in a VC-12 20 Same as 13 but in a VC-12 21 Same as 14 but in a VC-12 SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals): The whole set of SONET/SDH G-PIDs: Asynchronous mapping of E4 PDH framed Asynchronous mapping of E4 SDH framed Asynchronous mapping of E4 transparent Asynchronous mapping of DS3 M23 Asynchronous mapping of DS3 C-Bit Parity Asynchronous mapping of DS3 transparent Asynchronous mapping of E3 PDH framed Asynchronous mapping of E3 SDH framed Asynchronous mapping of E3 transparent Asynchronous mapping of DS2/T2 Bit synchronous mapping of DS2/T2 Asynchronous mapping of E1 framed Asynchronous mapping of E1 transparent Byte synchronous mapping of E1 framed Byte synchronous mapping of 31 * 64kbit/s Asynchronous mapping of DS1/T1 SF Asynchronous mapping of DS1/T1 ESF Asynchronous mapping of DS1/T1 transparent Bit synchronous mapping of DS1/T1 SF Bit synchronous mapping of DS1/T1 ESF Bit synchronous mapping of DS1/T1 transparent Byte synchronous mapping of DS1/T1 SF Byte synchronous mapping of DS1/T1 ESF VTG/TUG STS Group/AUG POS - No Scrambling, 16 bit CRC POS - No Scrambling, 32 bit CRC POS - Scrambling, 16 bit CRC POS - Scrambling, 32 bit CRC ATM mapping FDDI mapping DQDB mapping GFP mapping LAPS IP (X.85) LAPS Ethernet (X.86) SDL, set-reset scrambler SDL, self-synchronizing scrambler O.181 test signal Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be payload of an PDH LSP, only of a SONET/SDH and this is already defined. As I assume that no one will setup PDH LSPs the ANSI-PDH technology should be removed completley. The mapping into SONET/SDH is covered under SONET/SDH technology. The G-PIDs 33 Ethernet Lambda, Fiber specific 34 SDH Lambda, Fiber " 35 SONET Lambda, Fiber " 36 Digital Wrapper Lambda, Fiber " 37 Lambda Fiber " are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown? "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID. From owner-mpls@UU.NET Mon May 7 11:19:33 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14113 for ; Mon, 7 May 2001 11:19:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzp07392; Mon, 7 May 2001 15:18:00 GMT Received: by mail-control.mail.uu.net id QQknzp24934 for mpls-outgoing; Mon, 7 May 2001 15:17:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknzp24884 for ; Mon, 7 May 2001 15:17:15 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknzp15306 for ; Mon, 7 May 2001 15:16:50 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknzp05566 for ; Mon, 7 May 2001 15:16:50 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA20643 for mpls@uu.net; Mon, 7 May 2001 11:16:50 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknzp24513 for ; Mon, 7 May 2001 15:16:14 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQknzo21513 for ; Mon, 7 May 2001 15:13:40 GMT Received: from rtp-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQknzo00851 for ; Mon, 7 May 2001 15:13:39 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f47FCVm03805; Mon, 7 May 2001 11:12:31 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.84.75.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAC01672; Mon, 7 May 2001 11:13:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20010507111551.019e3c58@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 11:16:28 -0400 To: Giovanni.Zangrando@alcatel.it, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: RSVP-TE MIB In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Try the MPLS-TE-MIB at: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt --Tom >I have a problem with RSVP-TE MIBs. >In fact while the functional aspects are addressed in >draft-ietf-mpls-rsvp-lsp-tunnel, as far as I know the MIB to manage >RSVP-extensions is still to be defined (the only available MIB is >RFC2206). > >Please, does anybody knwow whether there is an ongoing activity >to define the RSVP-TE MIB? > >Thanks in advance. > >Best regards, >Giovanni Zangrando > >_________________________________________ >Giovanni Zangrando >OMSN System Engineer - R&D ALCATEL >E-mail: giovanni.zangrando@alcatel.it >Tel: +39 039 686 9132 Fax: +39 039 686 3590 From owner-mpls@UU.NET Mon May 7 11:44:10 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14706 for ; Mon, 7 May 2001 11:44:10 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzq14174; Mon, 7 May 2001 15:43:06 GMT Received: by mail-control.mail.uu.net id QQknzq06535 for mpls-outgoing; Mon, 7 May 2001 15:42:27 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknzq06513 for ; Mon, 7 May 2001 15:42:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzq18257 for ; Mon, 7 May 2001 15:41:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQknzq17160 for ; Mon, 7 May 2001 15:41:32 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id LAA23126 for mpls@uu.net; Mon, 7 May 2001 11:41:31 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknzq06343 for ; Mon, 7 May 2001 15:41:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzq07215 for ; Mon, 7 May 2001 15:37:55 GMT Received: from rtp-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtp-msg-core-1.cisco.com [161.44.11.97]) id QQknzq11836 for ; Mon, 7 May 2001 15:37:55 GMT Received: from bucket.cisco.com (bucket.cisco.com [161.44.131.26]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f47Fakm05818; Mon, 7 May 2001 11:36:46 -0400 (EDT) Received: from TNADEAU-PC02.cisco.com (tnadeau-frame2.cisco.com [10.84.75.67]) by bucket.cisco.com (Mirapoint) with ESMTP id AAC02049; Mon, 7 May 2001 11:37:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20010507114026.0197ef40@bucket.cisco.com> X-Sender: tnadeau@bucket.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 07 May 2001 11:40:44 -0400 To: Giovanni.Zangrando@alcatel.it, mpls@UU.NET From: "Thomas D. Nadeau" Subject: Re: RSVP-TE MIB In-Reply-To: <4.3.2.7.2.20010507111551.019e3c58@bucket.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk Sorry, cut-and-paste error. Try this: http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-mib-06.txt --Tom > Try the MPLS-TE-MIB at: > >http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsr-mib-07.txt > > --Tom > > >>I have a problem with RSVP-TE MIBs. >>In fact while the functional aspects are addressed in >>draft-ietf-mpls-rsvp-lsp-tunnel, as far as I know the MIB to manage >>RSVP-extensions is still to be defined (the only available MIB is >>RFC2206). >> >>Please, does anybody knwow whether there is an ongoing activity >>to define the RSVP-TE MIB? >> >>Thanks in advance. >> >>Best regards, >>Giovanni Zangrando >> >>_________________________________________ >>Giovanni Zangrando >>OMSN System Engineer - R&D ALCATEL >>E-mail: giovanni.zangrando@alcatel.it >>Tel: +39 039 686 9132 Fax: +39 039 686 3590 From owner-mpls@UU.NET Mon May 7 12:25:07 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15856 for ; Mon, 7 May 2001 12:25:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzt19486; Mon, 7 May 2001 16:23:51 GMT Received: by mail-control.mail.uu.net id QQknzt01280 for mpls-outgoing; Mon, 7 May 2001 16:23:17 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQknzt01265 for ; Mon, 7 May 2001 16:23:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzt25566 for ; Mon, 7 May 2001 16:23:01 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQknzt16001 for ; Mon, 7 May 2001 16:23:01 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08148 for ; Mon, 7 May 2001 12:22:58 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13383 for ; Mon, 7 May 2001 12:22:57 -0400 (EDT) Message-ID: <3AF6CBEE.E4F4CED9@marconi.com> Date: Mon, 07 May 2001 12:23:10 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP hello message References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the > format for hello message is as on section 5.1: > > :: = [] > > I want to make sure if the Hello object here is only one or a list > of Hello objects. > For my understanding, the format in Hello message, is not > a list of Hello objects, it should be one Hello object between two > RSVP neighbours. > Can anyone help me to confirm this? You have the correct understanding. A single HELLO object per message. One message per peer. If for some reason you have multiple peers sharing an interface (eg. a shared-media link), then each peer gets a separate Hello message, each containing one HELLO object. -- David From owner-mpls@UU.NET Mon May 7 13:26:41 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17273 for ; Mon, 7 May 2001 13:26:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQknzx02628; Mon, 7 May 2001 17:25:59 GMT Received: by mail-control.mail.uu.net id QQknzx27531 for mpls-outgoing; Mon, 7 May 2001 17:25:26 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQknzx27526 for ; Mon, 7 May 2001 17:25:25 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQknzx15520 for ; Mon, 7 May 2001 17:23:19 GMT Received: from sj-msg-core-1.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQknzx28064 for ; Mon, 7 May 2001 17:23:19 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f47HNIn28023 for ; Mon, 7 May 2001 10:23:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA15059 for mpls@uu.net; Mon, 7 May 2001 13:23:17 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQknzx27236 for ; Mon, 7 May 2001 17:22:18 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQknzx24972 for ; Mon, 7 May 2001 17:21:32 GMT Received: from acc.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQknzx24810 for ; Mon, 7 May 2001 17:21:31 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f47HJLI14995 for ; Mon, 7 May 2001 10:19:21 -0700 (PDT) Reply-To: From: "Hari Kishan" To: Subject: E-LSP merging ? Date: Mon, 7 May 2001 10:17:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Why is not allowed to merge TWO E-LSPs { E-LSP (1), E-LSP(2) } which were signalled to support the following set of BAs into E-LSP (3). E-LSP (1) supports BAs - AF11, AF12, AF13, EF E-LSP (2) supports BAs - AF21, AF22, AF23, AF11, AF12, AF13, EF merge =============>> E-LSP (3) - BE, AF21, AF22, AF23, AF11, AF12, AF13, EF kishan --------------------------------- Hari Kishan Desineni, Ericsson Inc, Data Backbone & Optical Division, Santabarbara, California - 93117 Office:(805) 562 6419 Home:(805) 968 1894 From owner-mpls@UU.NET Mon May 7 14:14:58 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18659 for ; Mon, 7 May 2001 14:14:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoaa25436; Mon, 7 May 2001 18:14:20 GMT Received: by mail-control.mail.uu.net id QQkoaa23688 for mpls-outgoing; Mon, 7 May 2001 18:13:42 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoaa23579 for ; Mon, 7 May 2001 18:13:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoaa13687 for ; Mon, 7 May 2001 18:13:12 GMT Received: from xover.mindspeed.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [38.160.241.130]) id QQkoaa23872 for ; Mon, 7 May 2001 18:13:12 GMT Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2650.21) id <2X8CPXT0>; Mon, 7 May 2001 14:13:09 -0400 Message-ID: <87009604743AD411B1F600508BA0F95971BAC6@XOVER.dedham.mindspeed.com> From: "Saha, Sayandeb" To: "'ccamp@ops.ietf.org'" , "'mpls@UU.NET'" Subject: UPSTREAM_COMPONENT_INTERFACE_ID question Date: Mon, 7 May 2001 14:13:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk draft-kompella-mpls-bundle-05.txt (section 5.2.1) speaks about the UPSTREAM_COMPONENT_INTERFACE_ID object which is to be included as a part of the for bidirectional LSPs when using Explicit Indication by Unnumbered. This seems to be an exception which allows one to specify a component for the upstream traffic. Specification of a component for upstream traffic is not supported for other indication types in Bundling (Implicit Indication and Explicit Indication by IP address), but instead is inferred. Also in the non-bundling case, when signaling unnumbered interfaces, the ERO only includes the upstream router_id and the outgoing interface Id, again nothing about the upstream link on which traffic should be carried. My question: What is the point in having a UPSTREAM_COMPONENT_INTERFACE_ID for the Explicit Indication by Unnumbered case, when there is nothing similar for other cases? Isn't the DOWNSTREAM_COMPONENT_INTERFACE_ID enough to let us know which link should be selected for reverse direction of the Bidirectional LSP? Am I missing something here? -Sayan From owner-mpls@UU.NET Mon May 7 14:37:56 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18944 for ; Mon, 7 May 2001 14:37:55 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoac28356; Mon, 7 May 2001 18:37:27 GMT Received: by mail-control.mail.uu.net id QQkoac26735 for mpls-outgoing; Mon, 7 May 2001 18:36:54 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoac26723 for ; Mon, 7 May 2001 18:36:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoac09754 for ; Mon, 7 May 2001 18:35:47 GMT Received: from acc.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailsrv.acc.com [129.192.64.128]) id QQkoac09175 for ; Mon, 7 May 2001 18:35:46 GMT Received: from kishan (devdhcp6211.dev.acc.am.ericsson.se [129.192.62.11]) by acc.com (8.11.1/8.11.1) with SMTP id f47IXaI24121 for ; Mon, 7 May 2001 11:33:36 -0700 (PDT) Reply-To: From: "Hari Kishan" To: Subject: Question on LdpEntityIndex ?? Date: Mon, 7 May 2001 11:32:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit The draft-ietf-mpls-ldp-mib-07.txt has the following description about EntityIndex. " mplsLdpEntityIndex OBJECT-TYPE .... .... A secondary index (this object) is needed by some but not all, LDP implementations. For example in an LDP implementation which uses PPP, this index may be needed." ::= { mplsLdpEntityEntry 2 } " Can anybody tell me one practical scenario where this entityindex MUST be used. ( I could not understand the PPP example written in the draft) This Entity Index is made part of the INDEX for many tables like adjacency table, session table , etc., As per my understanding a LDP Session can be uniquely identified by { mplsLdpEntityLdpId,mplsLdpPeerLdpId }, but the ldp-mib uses {mplsLdpEntityLdpId,mplsLdpEntityIndex, mplsLdpPeerLdpId } as the INDEX. If {a,b} forms the INDEX of a table, {a,b,c} ( assume 'c' is a column in the table ) also works ( of course any superset of {a,b} works ). Again, I would like to know when exactly does it become a MUST to use this entityindex to uniquely identify a LDP session in LDP Session table. thanks, Kishan --------------------------------- Hari Kishan Desineni, Ericsson Inc, Data Backbone & Optical Division, Santabarbara, California - 93117 Office:(805) 562 6419 Home:(805) 968 1894 From owner-mpls@UU.NET Mon May 7 14:40:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18991 for ; Mon, 7 May 2001 14:40:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoac13782; Mon, 7 May 2001 18:39:49 GMT Received: by mail-control.mail.uu.net id QQkoac26970 for mpls-outgoing; Mon, 7 May 2001 18:39:17 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoac26947 for ; Mon, 7 May 2001 18:39:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoac18928 for ; Mon, 7 May 2001 18:38:28 GMT Received: from dnsmx2pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQkoac03007 for ; Mon, 7 May 2001 18:38:28 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA07005; Mon, 7 May 2001 14:36:58 -0400 (EDT) Subject: Re: RSVP hello message To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Mon, 7 May 2001 14:37:23 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/07/2001 02:37:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for your pointer. I really appreciated. Did you get chance to take a look at my disconnection(clear network) questions? Thanks Julia David Charlap on 05/07/2001 12:23:10 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: RSVP hello message Hong Liao wrote: > > The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the > format for hello message is as on section 5.1: > > :: = [] > > I want to make sure if the Hello object here is only one or a list > of Hello objects. > For my understanding, the format in Hello message, is not > a list of Hello objects, it should be one Hello object between two > RSVP neighbours. > Can anyone help me to confirm this? You have the correct understanding. A single HELLO object per message. One message per peer. If for some reason you have multiple peers sharing an interface (eg. a shared-media link), then each peer gets a separate Hello message, each containing one HELLO object. -- David From owner-mpls@UU.NET Mon May 7 15:44:15 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20533 for ; Mon, 7 May 2001 15:44:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoag08938; Mon, 7 May 2001 19:43:07 GMT Received: by mail-control.mail.uu.net id QQkoag22278 for mpls-outgoing; Mon, 7 May 2001 19:42:34 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoag22268 for ; Mon, 7 May 2001 19:42:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoag00379 for ; Mon, 7 May 2001 19:40:47 GMT Received: from relay2.nai.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: relay2.nai.com [161.69.3.67]) id QQkoag05388 for ; Mon, 7 May 2001 19:40:46 GMT Received: from scwsout1.nai.com (webshield2.nai.com [161.69.3.73]) by relay2.nai.com (8.9.3/8.9.3) with SMTP id MAA26055 for ; Mon, 7 May 2001 12:40:46 -0700 (PDT) Received: FROM ca-ex-bridge2.nai.com BY scwsout1.nai.com ; Mon May 07 12:40:44 2001 -0700 Received: by dns-31.dhcp-5.nai.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 May 2001 12:51:16 -0700 Message-ID: <55E02B6F8FA8D311985300902740BB2003598278@ca-exchange4.nai.com> From: "Grant, Scott" To: "'mpls@uu.net'" Subject: LDP formats Date: Mon, 7 May 2001 12:34:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I'm working on a decode for sniffer and I've encountered something that isn't exactly described in RFC 3036. I have a trace file from Extreme Networks where there are frames with several PDUs in a single TCP message. I've read through RFC 3036, and I can't find anything saying that there can or can't be multiple PDUs in a frame. Is this something that will become a defacto standard due to several vendors doing this? I'd appreciate any comments. Scott Grant From owner-mpls@UU.NET Mon May 7 16:06:02 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21165 for ; Mon, 7 May 2001 16:06:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoai01346; Mon, 7 May 2001 20:04:51 GMT Received: by mail-control.mail.uu.net id QQkoai05346 for mpls-outgoing; Mon, 7 May 2001 20:04:21 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoai05291 for ; Mon, 7 May 2001 20:04:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoai05541 for ; Mon, 7 May 2001 20:03:11 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkoai08657 for ; Mon, 7 May 2001 20:03:11 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27468 for ; Mon, 7 May 2001 16:03:08 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03150 for ; Mon, 7 May 2001 16:03:08 -0400 (EDT) Message-ID: <3AF6FF89.E0D859E7@marconi.com> Date: Mon, 07 May 2001 16:03:21 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: disconnect connection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I have questions for disconnecting(clear connection). > > 1. Suppose LSR received Path message from Ingress router, and LSR > sent out Resv message back. If the LSR wanted to tear down this > session, it will send out ResvTear to Ingress router, and Ingress > router will take out the Resv state of LSR, and do not response > back anything, this session will be ended. I may wrong. First of all, only an egress router should be generating ResvTear messages, unless there's a failure somewhere. (In which case, various PathErr and ResvErr messages should also be generated.) A transit router should not arbitrarily go around sending out teardown messages. As a matter of fact, in the case of MPLS, since LSP creation is driven by the ingress router, only the ingress router should be doing any kind of tearing (not counting cleanup after failures.) The ingress router, of course, can not generate a ResvTear, because it won't go anywhere. It will send a PathTear when it wants to destroy the LSP. If an egress router sends ResvTear, the reservation will be removed. If the ingress router doesn't subsequently tear the Path, however, the Path state will remain in the network. This will waste bandwidth due to the refreshes for the unused state. It may also result in wasted resources, since some switches may allocate resources during Path processing. If a transit router tries to do this, it's even worse. You end up with leftover Path state everywhere, and leftover reservations downstream of that transit router. In general, ResvTear is not used in MPLS, except possibly in conjunction with PathErr messages. There is no reason for a non- ingress router to tear an LSP except in the face of failures. > 2. another way round, if there is LSR and it forwarded Path message > to Egress router, and Egress router sent back Resv message to LSR, > suppose the LSR wants to tear down this session, it will send out > the PathTear to the Egress router, and Egress router will move the > Path state of LSR, do not response anything, this session is ended. > Did I understand correct? This is how an ingress router will tear an LSP. If some router other than ingress does this, however, you will wind up with leftover Path state in all routers upstream of the LSR. And until the Resv state times out, there will be leftover reservations on those nodes as well. > 3. If the Ingress router sends out the Path message, but the no Resv > message sent back from LSR, does Ingress router need to send out > PathTear to clear the path state in case that this Path state has > already been sent there. Yes. Path state (and all of the Path refreshing) will remain in place forever if it is not torn down. > 4. How about the transit router to try to clear/tear down the > session? This should only happen if there is a failure (or perhaps preemption.) In which case, it should send a PathErr upstream. The ingress router, upon receiving this, may then choose to tear the LSP by sending a PathTear message. If the failure is a broken link (where the attached router knows that a PathTear message can't get through to the downstream nodes), the Path state will timeout (due to lack of refreshes on that interface), resulting in the eventual transmission of PathTear. The router should probably choose to immediately send the PathTear as an optimization (since a link failure will result in the nodes upstream of the failure tearing the state), but this isn't a hard requirement. -- David From owner-mpls@UU.NET Mon May 7 16:06:51 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21193 for ; Mon, 7 May 2001 16:06:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoai13241; Mon, 7 May 2001 20:06:18 GMT Received: by mail-control.mail.uu.net id QQkoai12775 for mpls-outgoing; Mon, 7 May 2001 20:05:41 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoai07715 for ; Mon, 7 May 2001 20:04:49 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoai07963 for ; Mon, 7 May 2001 20:04:42 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoai13475 for ; Mon, 7 May 2001 20:04:42 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA15401 for mpls@uu.net; Mon, 7 May 2001 16:04:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoai04892 for ; Mon, 7 May 2001 20:04:03 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoai07349 for ; Mon, 7 May 2001 20:03:45 GMT Received: from sj-msg-core-2.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.43.88]) id QQkoai00147 for ; Mon, 7 May 2001 20:03:45 GMT Received: from rhthomas-sun2.cisco.com (rhthomas-sun2.cisco.com [161.44.134.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f47K4Da29414; Mon, 7 May 2001 13:04:13 -0700 (PDT) Received: from localhost (rhthomas@localhost) by rhthomas-sun2.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) with ESMTP id QAA05723; Mon, 7 May 2001 16:03:40 -0400 (EDT) Message-Id: <200105072003.QAA05723@rhthomas-sun2.cisco.com> X-Authentication-Warning: rhthomas-sun2.cisco.com: rhthomas owned process doing -bs To: "Grant, Scott" cc: "'mpls@uu.net'" Subject: Re: LDP formats In-reply-to: Your message of "Mon, 07 May 2001 12:34:09 PDT." <55E02B6F8FA8D311985300902740BB2003598278@ca-exchange4.nai.com> Date: Mon, 07 May 2001 16:03:40 -0400 From: Bob Thomas Sender: owner-mpls@UU.NET Precedence: bulk > I'm working on a decode for sniffer and I've encountered something that > isn't exactly described in RFC 3036. I have a trace file from Extreme > Networks where there are frames with several PDUs in a single TCP message. > I've read through RFC 3036, and I can't find anything saying that there can > or can't be multiple PDUs in a frame. Is this something that will become a > defacto standard due to several vendors doing this? I'd appreciate any > comments. The trace is legal. Note also that it is legal for a single LDP PDU to span multiple TCP segments. RFC3036 specifies the use of TCP to transport messages for LDP sessions. IMO it is neither necessary nor desirable for it to specify the mapping of data (LDP messages) to TCP segments. Bob From owner-mpls@UU.NET Mon May 7 16:12:26 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21376 for ; Mon, 7 May 2001 16:12:25 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoai21340; Mon, 7 May 2001 20:11:25 GMT Received: by mail-control.mail.uu.net id QQkoai14121 for mpls-outgoing; Mon, 7 May 2001 20:10:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoai14073 for ; Mon, 7 May 2001 20:10:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoai27546 for ; Mon, 7 May 2001 20:10:20 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkoai07920 for ; Mon, 7 May 2001 20:10:20 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28279 for ; Mon, 7 May 2001 16:10:18 -0400 (EDT) Received: from marconi.com (lego-king.dc.fore.com [169.144.136.180]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05392 for ; Mon, 7 May 2001 16:10:17 -0400 (EDT) Message-ID: <3AF70132.382B2A83@marconi.com> Date: Mon, 07 May 2001 16:10:26 -0400 From: Jack Brennen X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: LDP formats References: <55E02B6F8FA8D311985300902740BB2003598278@ca-exchange4.nai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit "Grant, Scott" wrote: > > I'm working on a decode for sniffer and I've encountered something that > isn't exactly described in RFC 3036. I have a trace file from Extreme > Networks where there are frames with several PDUs in a single TCP message. > I've read through RFC 3036, and I can't find anything saying that there can > or can't be multiple PDUs in a frame. Is this something that will become a > defacto standard due to several vendors doing this? I'd appreciate any > comments. I think that the answer here is that there is no such thing as a "single TCP message" -- TCP is a stream-based protocol; there are no internal boundaries defined at the transport layer. The only boundaries in an LDP session stream are the boundaries between PDUs. At the application level, an LDP implementation must be prepared to parse PDUs whether they arrive in huge blocks of 10 PDUs at once, or whether they arrive 1 byte at a time -- either can happen over TCP. Jack From owner-mpls@UU.NET Mon May 7 16:19:36 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21573 for ; Mon, 7 May 2001 16:19:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoaj17270; Mon, 7 May 2001 20:18:31 GMT Received: by mail-control.mail.uu.net id QQkoaj15416 for mpls-outgoing; Mon, 7 May 2001 20:17:59 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoaj15370 for ; Mon, 7 May 2001 20:17:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoaj29900 for ; Mon, 7 May 2001 20:17:45 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkoaj28721 for ; Mon, 7 May 2001 20:17:45 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28958 for ; Mon, 7 May 2001 16:17:43 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA07850 for ; Mon, 7 May 2001 16:17:42 -0400 (EDT) Message-ID: <3AF702F3.2A76BB17@marconi.com> Date: Mon, 07 May 2001 16:17:55 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: LDP formats References: <200105072003.QAA05723@rhthomas-sun2.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Bob Thomas wrote: > > IMO it is neither necessary nor desirable for it to specify the > mapping of data (LDP messages) to TCP segments. Nor is it necessarily possible. -- David From owner-mpls@UU.NET Mon May 7 16:40:47 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21973 for ; Mon, 7 May 2001 16:40:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoak23751; Mon, 7 May 2001 20:39:46 GMT Received: by mail-control.mail.uu.net id QQkoak17295 for mpls-outgoing; Mon, 7 May 2001 20:39:13 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoak17283 for ; Mon, 7 May 2001 20:38:57 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoak09339 for ; Mon, 7 May 2001 20:38:09 GMT Received: from dnsmx1pya.telcordia.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkoak01752 for ; Mon, 7 May 2001 20:38:09 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA02089; Mon, 7 May 2001 13:02:56 -0400 (EDT) Subject: Re: RSVP hello message To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Mon, 7 May 2001 13:03:22 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/07/2001 01:03:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for your pointer. I really appreciated. Did you get chance to take a look at my disconnection(clear network) questions? Thanks Julia David Charlap on 05/07/2001 12:23:10 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: RSVP hello message Hong Liao wrote: > > The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the > format for hello message is as on section 5.1: > > :: = [] > > I want to make sure if the Hello object here is only one or a list > of Hello objects. > For my understanding, the format in Hello message, is not > a list of Hello objects, it should be one Hello object between two > RSVP neighbours. > Can anyone help me to confirm this? You have the correct understanding. A single HELLO object per message. One message per peer. If for some reason you have multiple peers sharing an interface (eg. a shared-media link), then each peer gets a separate Hello message, each containing one HELLO object. -- David From owner-mpls@UU.NET Mon May 7 18:42:50 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23670 for ; Mon, 7 May 2001 18:42:50 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoas07739; Mon, 7 May 2001 22:42:28 GMT Received: by mail-control.mail.uu.net id QQkoas07861 for mpls-outgoing; Mon, 7 May 2001 22:41:57 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoas07850 for ; Mon, 7 May 2001 22:41:41 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoas02100 for ; Mon, 7 May 2001 22:40:54 GMT Received: from tenornetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkoas26277 for ; Mon, 7 May 2001 22:40:54 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f47MerK02532 for ; Mon, 7 May 2001 18:40:53 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; MON, 7 May 2001 18:35:55 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V8AX62>; Mon, 7 May 2001 18:35:55 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56C65C81@newman.tenornet.com> From: "Li, Eve" To: mpls@UU.NET Subject: Comments on kompella-mpls-l2vpn-02 draft Date: Mon, 7 May 2001 18:35:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk BGP's next hop field for L2VPN signalling is not clearly specified. Since [BGP-MP] (rfc 2858) requires that the next hop address be in the same address family as the NLRI. What the next hop address should be for L2VPN-specific NLRIs? Thx, -eve From owner-mpls@UU.NET Mon May 7 19:14:57 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24237 for ; Mon, 7 May 2001 19:14:57 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoau11970; Mon, 7 May 2001 23:13:50 GMT Received: by mail-control.mail.uu.net id QQkoau29403 for mpls-outgoing; Mon, 7 May 2001 23:13:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoau29389 for ; Mon, 7 May 2001 23:13:04 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoau08037 for ; Mon, 7 May 2001 23:11:42 GMT Received: from philotas.hosting.pacbell.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: philotas.hosting.pacbell.net [216.100.99.24]) id QQkoau13394 for ; Mon, 7 May 2001 23:11:42 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by philotas.hosting.pacbell.net id TAA26062; Mon, 7 May 2001 19:11:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Juha Heinanen" , "Jay Wang" Cc: "HANSEN CHAN" , "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media Date: Mon, 7 May 2001 16:09:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15091.38161.514887.486740@lohi.eng.telia.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Dunno what is the problem. To support diffserv, the underneath transport (MAC layer and lower), does not have to have a sophisticated traffic management matching diffserv PHBs. The fact that cisco's DPT (or others RPR version for that matter), a MAC layer technology, that supports only two transmit queueing priorities, hence is not a disqualifier for supporting diffserv on the higher level, where you suggested otherwise. In a share-media environment, from diffserv's perspective, what we need from below is a link layer that may ensure a quantifiable and stable guaranteed throughput for the target nodes, regardless of the other sharing nodes. This is what is missing in the original IEEE-802-style LAN. The DPT, on the other hand, assures total_ring-BandWidth/node_num for each node. Given that, the business of diffserv traffic management, e.g., BA classification, policing, color-based RED dropping, PHB scheduling, and so on and so forth, can be conducted as they should have been at the connected nodes. - jay -----Original Message----- From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] Sent: Friday, May 04, 2001 10:52 PM To: Jay Wang Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net'; te-wg@ops.ietf.org Subject: RE: QoS in Shared Media Jay Wang writes: > Well, RPR gives you bandwidth endurance at the link level, a shared > media in this case. On higher level, you may conduct your QoS as > appropriate, Diffserv, Intserv, or else. One does not preclude the other, > IMO. how about if someone would like to give different bandwidth assurance to more than one independent traffic class? also, within a diffserv traffic class, droping of packets is based on the drop presedence of the packet, not based on behind which nodes the packets arrived. as i said before, node based fairness can only be applied to the highest dp packets within each class. dpt (and also rpr if it adopts dpt) thus supports diffserv only in a very limited sense. as far as i remember, it is the only ieee mac standard, where the specification tells how many queues the switch has. -- juha -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha Heinanen Sent: Friday, May 04, 2001 12:01 PM To: HANSEN CHAN Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org' Subject: Re: QoS in Shared Media HANSEN CHAN writes: > How about the work in IEEE 802.17 RPR? I believe it will be a shared-media > technology. Does that mean they will have a hard time to achieve QoS > guarantees? last time that i checked, the rpr proposal (based on cisco dpt) had two classes of service (strict priority and best effort). that is clearly not adequate for diffserv. node based fairness applied to the best effort class. in diffserv, node based fairness makes sense only for the highest dp packets in each traffic class. -- juha From owner-mpls@UU.NET Mon May 7 19:48:29 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24632 for ; Mon, 7 May 2001 19:48:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoax29286; Mon, 7 May 2001 23:48:05 GMT Received: by mail-control.mail.uu.net id QQkoax02285 for mpls-outgoing; Mon, 7 May 2001 23:47:26 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoax02266 for ; Mon, 7 May 2001 23:46:59 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoax19465 for ; Mon, 7 May 2001 23:45:36 GMT Received: from ns2.cypress.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.cypress.com [157.95.67.5]) id QQkoax25850 for ; Mon, 7 May 2001 23:45:35 GMT Received: from corpmail.cypress.com (corpmail.cypress.com [157.95.1.2]) by ns2.cypress.com (8.10.2/8.10.2) with ESMTP id f47NjM401206; Mon, 7 May 2001 16:45:22 -0700 (PDT) Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5]) by corpmail.cypress.com (8.10.2/8.10.2) with ESMTP id f47NgIW03795; Mon, 7 May 2001 16:42:18 -0700 (PDT) Received: from cypress.com ([172.16.130.117]) by cobweb.mis.cypress.com (8.10.2/8.10.2) with ESMTP id f47NirS09788; Mon, 7 May 2001 16:45:03 -0700 (PDT) Message-ID: <3AF733B8.8E93C4F5@cypress.com> Date: Mon, 07 May 2001 16:46:00 -0700 From: Pankaj K Jha Organization: Cypress Semiconductor Corp. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Wang CC: Juha Heinanen , HANSEN CHAN , Fred Baker , "Naidu, Venkata" , "'mpls@uu.net'" , te-wg@ops.ietf.org Subject: Re: QoS in Shared Media References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jay: It's the other way around: let's say you have four nodes A, B, C, D. If [B, C] require more bandwidth for a certain traffic flow (after making reservations through RSVP, etc.) they should be able to get it. In case of Ethernet connecting A, B, C, and D (in sequence, not on the same LAN - we're looking at ring-type scenario so we can compare Ethernet vs. DPT performance), the Ethernet MAC doesn't look at Diff-serv bits and passes packets to the system. The system allows/rejects flows through a node (for transit as well as transmit traffic) according to rules and permissions. Ethernet doesn't come in the way of doing these. DPT, on the other hand, will go ahead and divide available bandwidth equally to all four nodes - ignoring whatever you may do with Diff-serv. DPT works best when all nodes have equal bandwidth requirements, and it doesn't work when you have dissimilar bandwidth needs. Dissimilar bandwidth needs are quite common in metro networks where hub-and-spoke configurations are norm. If you have bandwidth paying customers such as financial institutions and corporate clients on a metro ring along with average over-provisioned clients, DPT will not do the job at all, in my view. It must be noted that a shared LAN-like behavior will give just that - a LAN-like performance. Diff-serv, etc. are not for all nodes on the same side of a LAN - these are when you go from network to network. So you cannot use DPT and make the ring like a pure shared LAN and then try to apply diff-serv to give different treatment to different customers on the nodes on the *same* LAN. In a ring network, nodes are not hanging off a wire like Ethernet nodes do on a LAN. Instead, nodes are connected in sequence - packets enter a node and go to next node (depending on traffic engineering at the node) and so on. I do feel a better MAC will do the job here better than Ethernet, but this MAC has to be carefully designed. A MAC cannot first bypass all L3/L2 assignments and then tell the system to do the rest. By the time the MAC is done with transit and node transmit packets, the packet treatments have already been done and the packet is already out on the Tx port (especially the transit packet). Maybe I'm missing something here? -Pankaj Jay Wang wrote: > Dunno what is the problem. To support diffserv, the underneath > transport (MAC layer and lower), does not have to have a > sophisticated traffic management matching diffserv PHBs. The fact > that cisco's DPT (or others RPR version for that matter), a MAC > layer technology, that supports only two transmit queueing priorities, > hence is not a disqualifier for supporting diffserv on the higher level, > where you suggested otherwise. In a share-media environment, from > diffserv's perspective, what we need from below is a link layer > that may ensure a quantifiable and stable guaranteed throughput for the > target nodes, regardless of the other sharing nodes. This is what is > missing in the original IEEE-802-style LAN. The DPT, on the other hand, > assures total_ring-BandWidth/node_num for each node. Given that, the > business of diffserv traffic management, e.g., BA classification, > policing, color-based RED dropping, PHB scheduling, and so on and so forth, > can be conducted as they should have been at the connected nodes. > > - jay > > -----Original Message----- > From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] > Sent: Friday, May 04, 2001 10:52 PM > To: Jay Wang > Cc: HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net'; > te-wg@ops.ietf.org > Subject: RE: QoS in Shared Media > > Jay Wang writes: > > > Well, RPR gives you bandwidth endurance at the link level, a shared > > media in this case. On higher level, you may conduct your QoS as > > appropriate, Diffserv, Intserv, or else. One does not preclude the other, > > IMO. > > how about if someone would like to give different bandwidth assurance to > more than one independent traffic class? also, within a diffserv > traffic class, droping of packets is based on the drop presedence of the > packet, not based on behind which nodes the packets arrived. > > as i said before, node based fairness can only be applied to the highest > dp packets within each class. dpt (and also rpr if it adopts dpt) thus > supports diffserv only in a very limited sense. as far as i remember, > it is the only ieee mac standard, where the specification tells how many > queues the switch has. > > -- juha > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Juha > Heinanen > Sent: Friday, May 04, 2001 12:01 PM > To: HANSEN CHAN > Cc: Fred Baker; Naidu, Venkata; 'mpls@uu.net'; 'te-wg@ops.ietf.org' > Subject: Re: QoS in Shared Media > > HANSEN CHAN writes: > > > How about the work in IEEE 802.17 RPR? I believe it will be a > shared-media > > technology. Does that mean they will have a hard time to achieve QoS > > guarantees? > > last time that i checked, the rpr proposal (based on cisco dpt) had two > classes of service (strict priority and best effort). that is clearly > not adequate for diffserv. node based fairness applied to the best > effort class. in diffserv, node based fairness makes sense only for the > highest dp packets in each traffic class. > > -- juha From owner-mpls@UU.NET Mon May 7 19:53:38 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24701 for ; Mon, 7 May 2001 19:53:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoax19903; Mon, 7 May 2001 23:52:39 GMT Received: by mail-control.mail.uu.net id QQkoax02927 for mpls-outgoing; Mon, 7 May 2001 23:52:04 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoax02883 for ; Mon, 7 May 2001 23:51:44 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoax06770 for ; Mon, 7 May 2001 23:51:12 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkoax04038 for ; Mon, 7 May 2001 23:51:12 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA11106 for ; Mon, 7 May 2001 19:51:09 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07915 for ; Mon, 7 May 2001 19:51:09 -0400 (EDT) Message-ID: <3AF734FB.A0908D69@marconi.com> Date: Mon, 07 May 2001 19:51:23 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "'mpls@uu.net'" Subject: Re: QoS in Shared Media References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jay Wang wrote: > > Dunno what is the problem. To support diffserv, the underneath > transport (MAC layer and lower), does not have to have a > sophisticated traffic management matching diffserv PHBs. ... > In a share-media environment, from diffserv's perspective, what we > need from below is a link layer that may ensure a quantifiable and > stable guaranteed throughput for the target nodes, regardless of the > other sharing nodes. If every node is connected via a layer-2 switch that is policing and shaping traffic, then the nodes are not sharing media. If the media is actually shared - connected via repeaters and not bridges - then QoS can only work when everybody plays nice together. -- David From owner-mpls@UU.NET Mon May 7 20:36:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25253 for ; Mon, 7 May 2001 20:36:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoba29363; Tue, 8 May 2001 00:36:05 GMT Received: by mail-control.mail.uu.net id QQkoba25078 for mpls-outgoing; Tue, 8 May 2001 00:35:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoba25073 for ; Tue, 8 May 2001 00:35:30 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoba10809 for ; Tue, 8 May 2001 00:34:45 GMT Received: from red.juniper.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: red.juniper.net [207.17.136.137]) id QQkoba27194 for ; Tue, 8 May 2001 00:34:45 GMT Received: from fuinar.juniper.net (fuinar.juniper.net [172.17.12.75]) by red.juniper.net (8.9.3/8.9.3) with ESMTP id RAA15209; Mon, 7 May 2001 17:34:44 -0700 (PDT) Received: (from qv@localhost) by fuinar.juniper.net (8.8.8/8.7.3) id RAA17975; Mon, 7 May 2001 17:34:44 -0700 (PDT) From: Quaizar Vohra MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 7 May 2001 17:34:44 -0700 (PDT) To: "Li, Eve" Cc: mpls@UU.NET Subject: Comments on kompella-mpls-l2vpn-02 draft In-Reply-To: <6B190B34070BD411ACA000B0D0214E56C65C81@newman.tenornet.com> References: <6B190B34070BD411ACA000B0D0214E56C65C81@newman.tenornet.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <15095.10563.65347.901536@fuinar.juniper.net> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit > BGP's next hop field for L2VPN signalling is not clearly specified. > > Since [BGP-MP] (rfc 2858) requires that the next hop address be in the same > address family as the NLRI. What the next hop address should be for > L2VPN-specific NLRIs? Thx, I couldn't find any such requirement in the rfc. Since you want MPLS LSPs terminating in these next-hop addresses, and currently most implementation use IPv4 addresses as destinations in the LSPs, it seems like IPv4 addresses are a good candidate for the nexthop field. We will update the L2VPN specification to reflect this as a recommendation. Thanks, Quaizar > > -eve From owner-mpls@UU.NET Mon May 7 20:39:50 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25272 for ; Mon, 7 May 2001 20:39:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoba09307; Tue, 8 May 2001 00:39:28 GMT Received: by mail-control.mail.uu.net id QQkoba25392 for mpls-outgoing; Tue, 8 May 2001 00:38:56 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoba25368 for ; Tue, 8 May 2001 00:38:43 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoba19064 for ; Tue, 8 May 2001 00:38:20 GMT Received: from lysimachus.hosting.pacbell.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lysimachus.hosting.pacbell.net [216.100.98.17]) id QQkoba06908 for ; Tue, 8 May 2001 00:38:19 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by lysimachus.hosting.pacbell.net id UAA18652; Mon, 7 May 2001 20:37:50 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Pankaj K Jha" Cc: "Juha Heinanen" , "HANSEN CHAN" , "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media Date: Mon, 7 May 2001 17:36:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF733B8.8E93C4F5@cypress.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pankaj, -----Original Message----- From: Pankaj K Jha [mailto:pkj@cypress.com] Sent: Monday, May 07, 2001 4:46 PM To: Jay Wang Cc: Juha Heinanen; HANSEN CHAN; Fred Baker; Naidu, Venkata; 'mpls@uu.net'; te-wg@ops.ietf.org Subject: Re: QoS in Shared Media >DPT, on the other hand, will go ahead and divide available bandwidth equally to >all four nodes - ignoring whatever you may do with Diff-serv. DPT works best >when all nodes have equal bandwidth requirements, and it doesn't work when you >have dissimilar bandwidth needs. Dissimilar bandwidth needs are quite common in >metro networks where hub-and-spoke configurations are norm. If you have >bandwidth paying customers such as financial institutions and corporate clients >on a metro ring along with average over-provisioned clients, DPT will not do the >job at all, in my view. I believe DPT allows you to artificially specify a cap on the bandwidth, by configuring the MAX_USAGE parameter, on a per-node basis. But even if all the nodes evenly divide the ring bandwidth, this does not mean that on each node, I can not provide differentiated treatment (in terms of forwarding and bandwidth allocation) among diffserv PHBs at the nodes. Also if the nodes have very different BW needs, then they don't have to be placed on the same ring, a traffic engineering issue for the carrier. - jay From owner-mpls@UU.NET Mon May 7 21:07:29 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25675 for ; Mon, 7 May 2001 21:07:29 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkobc09865; Tue, 8 May 2001 01:06:18 GMT Received: by mail-control.mail.uu.net id QQkobc15921 for mpls-outgoing; Tue, 8 May 2001 01:05:40 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkobc15575 for ; Tue, 8 May 2001 01:05:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkobc08052 for ; Tue, 8 May 2001 01:02:48 GMT Received: from antipater.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: antipater.hosting.pacbell.net [216.100.99.13]) id QQkobc11415 for ; Tue, 8 May 2001 01:02:48 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by antipater.hosting.pacbell.net id VAA05361; Mon, 7 May 2001 21:01:55 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "David Charlap" , "'mpls@uu.net'" Subject: RE: QoS in Shared Media Date: Mon, 7 May 2001 18:00:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3AF734FB.A0908D69@marconi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit >> >> Dunno what is the problem. To support diffserv, the underneath >> transport (MAC layer and lower), does not have to have a >> sophisticated traffic management matching diffserv PHBs. ... >> In a share-media environment, from diffserv's perspective, what we >> need from below is a link layer that may ensure a quantifiable and >> stable guaranteed throughput for the target nodes, regardless of the >> other sharing nodes. >If every node is connected via a layer-2 switch that is policing and >shaping traffic, then the nodes are not sharing media. > >If the media is actually shared - connected via repeaters and not >bridges - then QoS can only work when everybody plays nice together. > >-- David Yes, indeed. thanks, - jay From owner-mpls@UU.NET Mon May 7 21:08:39 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25725 for ; Mon, 7 May 2001 21:08:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkobc16443; Tue, 8 May 2001 01:07:42 GMT Received: by mail-control.mail.uu.net id QQkobc16260 for mpls-outgoing; Tue, 8 May 2001 01:07:08 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkobc16040 for ; Tue, 8 May 2001 01:06:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkobc24208 for ; Tue, 8 May 2001 01:05:56 GMT Received: from noya.bupt.edu.cn by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkobc15444 for ; Tue, 8 May 2001 01:05:54 GMT Received: from vinus ([202.112.109.71]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f4815RR08565; Tue, 8 May 2001 09:05:33 +0800 (CST) Message-Id: <200105080105.f4815RR08565@noya.bupt.edu.cn> Date: Tue, 8 May 2001 9:3:37 +0800 From: Felix Chang To: Hans Sj?strand CC: "mpls@UU.NET" Subject: Re: RE: Parameters in LDP entity table X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA25725 hi,Hansse Thank you, but I still have some questions. As you said, we could have several entities when the LSR have ATM-based and FR-based interfaces at the same time. And these entities could have different distribution and retention method. My question is: If in one LSR, two entities for two interfaces have different distribution and retention method, could these two interfaces interwork? If a LSP is setting up between them, we should use which distribution method in these two entities? Best regards! Felix On 2001-05-07 11:07:00 you wrote£º >It's true that for many ATM or FR based interfaces uses the >encap from rfc3034 or rfc3035. It's also true that those use >per intreface label space. In that case you have several >entities. distribution and retention method isn't neccesary >the same over the label switch even though it's defently the >most common case. > >from RFC 3037 LDP Applicability, section 3 > Downstream on Demand distribution with conservative label retention > and ordered control is appropriate in situations where labels are a > relatively scarce resource that must be conserved, and Downstream > Unsolicited distribution with liberal label retention and independent > control is appropriate where labels are plentiful and need not be > carefully conserved. However, the protocol permits other > combinations of distribution method, label retention mode and control > mode, including hybrid variants of them. > >Regards >/// Hasse > >> -----Original Message----- >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Felix Chang >> Sent: den 6 maj 2001 09:57 >> To: mpls_maillist >> Subject: Parameters in LDP entity table >> >> >> hi,everyone >> >> I am confused by some parameters in the LDP entity table. >> Suppose there are several kinds of mpls-capable >> interfaces(eg.ATM-based, fr-based) in a LSR, it should use per >> interface label space. So it has several LDP entities. Is that >> right? In these entities, are the values of some parameters such >> as mplsLdpEntityLabelDistributionMethod, >> mplsLdpEntityLabelRetentionMode, the same? >> >> >> Best regards! >> Felix Chang >> mplszhz@263.net Best regards£¡ Felix Chang mplszhz@263.net From owner-mpls@UU.NET Mon May 7 22:02:41 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27311 for ; Mon, 7 May 2001 22:02:40 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkobg14533; Tue, 8 May 2001 02:02:30 GMT Received: by mail-control.mail.uu.net id QQkobg28616 for mpls-outgoing; Tue, 8 May 2001 02:01:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkobg27822 for ; Tue, 8 May 2001 02:01:47 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkobg26857 for ; Tue, 8 May 2001 02:01:20 GMT Received: from dnsmx1rrc.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkobg13158 for ; Tue, 8 May 2001 02:01:20 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id WAA02868; Mon, 7 May 2001 22:00:39 -0400 (EDT) Subject: Re: RSVP hello message To: "Hong Liao" Cc: mpls@UU.NET From: "Hong Liao" Date: Mon, 7 May 2001 22:01:04 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/07/2001 10:01:05 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for your detail explanation for the RSVP tear down connection issue. I still have one more for the Hello message needed to confirm. Anytime, the Ingress, Egress or LSR which supports Hello extension, will send out Hello(request) message, for any reason the router which received this Hello request message must first reply Hello ack back, then it can move to another stage. Suppose there is Ingress router which sends out Path message, it is waiting Resv back from the Egress, but before it receives the Resv, it received a Hello request message from neighbour, it must send out Hello ack back first for any reason. Thanks in an advance. Julia "Hong Liao" on 05/07/2001 02:37:23 PM To: David Charlap cc: mpls@UU.NET (bcc: Hong Liao/Telcordia) Subject: Re: RSVP hello message David, Thanks for your pointer. I really appreciated. Did you get chance to take a look at my disconnection(clear network) questions? Thanks Julia David Charlap on 05/07/2001 12:23:10 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: RSVP hello message Hong Liao wrote: > > The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the > format for hello message is as on section 5.1: > > :: = [] > > I want to make sure if the Hello object here is only one or a list > of Hello objects. > For my understanding, the format in Hello message, is not > a list of Hello objects, it should be one Hello object between two > RSVP neighbours. > Can anyone help me to confirm this? You have the correct understanding. A single HELLO object per message. One message per peer. If for some reason you have multiple peers sharing an interface (eg. a shared-media link), then each peer gets a separate Hello message, each containing one HELLO object. -- David From owner-mpls@UU.NET Mon May 7 22:24:41 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27627 for ; Mon, 7 May 2001 22:24:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkobh12440; Tue, 8 May 2001 02:24:11 GMT Received: by mail-control.mail.uu.net id QQkobh11924 for mpls-outgoing; Tue, 8 May 2001 02:23:39 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkobh11908 for ; Tue, 8 May 2001 02:23:33 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkobh07506 for ; Tue, 8 May 2001 02:23:11 GMT Received: from dnsmx2pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx2pya.telcordia.com [128.96.20.32]) id QQkobh10819 for ; Tue, 8 May 2001 02:23:11 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id WAA03358; Mon, 7 May 2001 22:20:51 -0400 (EDT) Subject: Re: RSVP hello message To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Mon, 7 May 2001 22:21:16 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/07/2001 10:21:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Sorry, I send the last email to myself by mistakes. Thanks for your detail explanation for the RSVP tear down connection issue. I still have one more for the Hello message needed to confirm. Anytime, the Ingress, Egress or LSR which supports Hello extension, will send out Hello(request) message, for any reason the router which received this Hello request message must first reply Hello ack back, then it can move to another stage. Suppose there is Ingress router which sends out Path message, it is waiting Resv back from the Egress, but before it receives the Resv, it received a Hello request message from neighbour, it must send out Hello ack back first for any reason. Thanks in an advance. Julia David Charlap on 05/07/2001 12:23:10 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: RSVP hello message Hong Liao wrote: > > The hello message in RSVP draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, the > format for hello message is as on section 5.1: > > :: = [] > > I want to make sure if the Hello object here is only one or a list > of Hello objects. > For my understanding, the format in Hello message, is not > a list of Hello objects, it should be one Hello object between two > RSVP neighbours. > Can anyone help me to confirm this? You have the correct understanding. A single HELLO object per message. One message per peer. If for some reason you have multiple peers sharing an interface (eg. a shared-media link), then each peer gets a separate Hello message, each containing one HELLO object. -- David From owner-mpls@UU.NET Tue May 8 02:07:23 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15343 for ; Tue, 8 May 2001 02:07:23 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkobw01843; Tue, 8 May 2001 06:06:25 GMT Received: by mail-control.mail.uu.net id QQkobw14198 for mpls-outgoing; Tue, 8 May 2001 06:05:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkobw14152 for ; Tue, 8 May 2001 06:05:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkobw29241 for ; Tue, 8 May 2001 06:04:31 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkobw12298 for ; Tue, 8 May 2001 06:04:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id CAA19706 for mpls@uu.net; Tue, 8 May 2001 02:04:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkobw08657 for ; Tue, 8 May 2001 06:03:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkobw25551 for ; Tue, 8 May 2001 06:03:16 GMT Received: from lohi.eng.telia.fi by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkobw28392 for ; Tue, 8 May 2001 06:03:15 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f48633k02257; Tue, 8 May 2001 09:03:03 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15095.35863.76753.616693@lohi.eng.telia.fi> Date: Tue, 8 May 2001 09:03:03 +0300 (EEST) To: "Jay Wang" Cc: "HANSEN CHAN" , "Fred Baker" , "Naidu, Venkata" , "'mpls@uu.net'" , Subject: RE: QoS in Shared Media In-Reply-To: References: <15091.38161.514887.486740@lohi.eng.telia.fi> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit jay, dpt is layer 2 technology and i was talking about diffserv support at layer 2, which dpt doesn't properly have. ethernet, on the other hand, does support diffserv also at layer 2, which allows you to build a layer 2 switched network of any topology and still have proper support for diffserv. according to your definition even atm supports diffserv since one can always use cbr vcs between routers and then let the routers do the proper queueing. for several reasons this is not a good idea. -- juha From owner-mpls@UU.NET Tue May 8 04:53:48 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17383 for ; Tue, 8 May 2001 04:53:48 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoch21340; Tue, 8 May 2001 08:53:04 GMT Received: by mail-control.mail.uu.net id QQkoch05846 for mpls-outgoing; Tue, 8 May 2001 08:52:32 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoch05838 for ; Tue, 8 May 2001 08:52:26 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoch25659 for ; Tue, 8 May 2001 08:52:09 GMT Received: from smtp.163.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.108.44.212]) id QQkoch24546 for ; Tue, 8 May 2001 08:52:08 GMT Received: from hllu (unknown [61.152.8.120]) by smtp.163.com (Postfix) with SMTP id 3B7771C3C4892 for ; Tue, 8 May 2001 17:01:47 +0800 (CST) Date: Tue, 8 May 2001 16:49:27 +0800 From: "Hailong Lu.sean" Reply-To: sealong@163.com To: "mpls@uu.net" Subject: rfc3031 section3.2 X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20010508090147.3B7771C3C4892@smtp.163.com> Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi,there I am new guy to MPLS.While reading rfc3031's section 3.2,there are some words I can't understand: "To say that one node is upstream and one is downstream with respect to a given binding means only that a particular label represents a particular FEC in packets travelling from the upstream node to the downstream node. This is NOT meant to imply that packets in that FEC would actually be routed from the upstream node to the downstream node" thanks. sean From owner-mpls@UU.NET Tue May 8 05:12:09 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17674 for ; Tue, 8 May 2001 05:12:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoci21422; Tue, 8 May 2001 09:11:51 GMT Received: by mail-control.mail.uu.net id QQkoci26141 for mpls-outgoing; Tue, 8 May 2001 09:11:18 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoci26058 for ; Tue, 8 May 2001 09:10:57 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoci26121 for ; Tue, 8 May 2001 09:09:46 GMT Received: from wiprom2mx1.wipro.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkoci18936 for ; Tue, 8 May 2001 09:09:36 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id OAA25390 for ; Tue, 8 May 2001 14:47:50 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GD0F1N00.BQN; Tue, 8 May 2001 14:45:23 +0530 Date: Tue, 8 May 2001 14:44:52 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: "Hailong Lu.sean" cc: "mpls@uu.net" Subject: Re: rfc3031 section3.2 In-Reply-To: <20010508090147.3B7771C3C4892@smtp.163.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk > Hi,there > I am new guy to MPLS.While reading rfc3031's section 3.2,there > are some words I can't understand: Hi, This paragraph is to say that, the terms 'upstream' and 'downstream' are applicable to a set of two nodes only in the context of one particular FEC and corresponding lable for that FEC between these to nodes, and for nothing else. Would this make clear ?? Thanks Chetan S > > "To say that one node is upstream and one is downstream with respect > to a given binding means only that a particular label represents a > particular FEC in packets travelling from the upstream node to the > downstream node. This is NOT meant to imply that packets in that FEC > would actually be routed from the upstream node to the downstream > node" > > thanks. > > > > sean > > From owner-mpls@UU.NET Tue May 8 06:22:01 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA18322 for ; Tue, 8 May 2001 06:22:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkocn16551; Tue, 8 May 2001 10:21:25 GMT Received: by mail-control.mail.uu.net id QQkocn20780 for mpls-outgoing; Tue, 8 May 2001 10:20:53 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkocn20775 for ; Tue, 8 May 2001 10:20:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkocn28623 for ; Tue, 8 May 2001 10:20:11 GMT From: suchauhan@hss.hns.com Received: from hindon.hss.co.in by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [202.54.26.202]) id QQkocn08266 for ; Tue, 8 May 2001 10:19:44 GMT Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f48AJre09258; Tue, 8 May 2001 15:49:53 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A46.00374F5D ; Tue, 8 May 2001 15:34:07 +0530 X-Lotus-FromDomain: HSS To: chetan.kumar@wipro.com cc: "Hailong Lu.sean" , "mpls@uu.net" Message-ID: <65256A46.0037434F.00@sandesh.hss.hns.com> Date: Tue, 8 May 2001 15:33:35 +0530 Subject: Re: rfc3031 section3.2 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-mpls@UU.NET Precedence: bulk hi all! In my opinion what the statement means is that when the downstream LSR(Rd) suggests a mapping for a given FEC to a upstream LSR (Ru) it is not binding or mandatory for the Ru to use that binding for forwarding packets belonging to that FEC through Rd. Think of a DU mode operation for a set of downstream routers, all sending the binding for the same FEC to a upstream router Ru. The decision is for LSR Ru to decide which one it wants to use for forwarding the packets. Of course the decision algorithm is out of scope here. ciao sumit "chetan kumar s" on 05/08/2001 02:44:52 PM Please respond to chetan.kumar@wipro.com To: "Hailong Lu.sean" cc: "mpls@uu.net" (bcc: Sumit Chauhan/HSS) Subject: Re: rfc3031 section3.2 > Hi,there > I am new guy to MPLS.While reading rfc3031's section 3.2,there > are some words I can't understand: Hi, This paragraph is to say that, the terms 'upstream' and 'downstream' are applicable to a set of two nodes only in the context of one particular FEC and corresponding lable for that FEC between these to nodes, and for nothing else. Would this make clear ?? Thanks Chetan S > > "To say that one node is upstream and one is downstream with respect > to a given binding means only that a particular label represents a > particular FEC in packets travelling from the upstream node to the > downstream node. This is NOT meant to imply that packets in that FEC > would actually be routed from the upstream node to the downstream > node" > > thanks. > > > > sean > > From owner-mpls@UU.NET Tue May 8 09:14:31 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20692 for ; Tue, 8 May 2001 09:14:31 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkocy14584; Tue, 8 May 2001 13:13:35 GMT Received: by mail-control.mail.uu.net id QQkocy00893 for mpls-outgoing; Tue, 8 May 2001 13:13:02 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkocy00839 for ; Tue, 8 May 2001 13:12:41 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkocy17856 for ; Tue, 8 May 2001 13:12:39 GMT Received: from tenornetworks.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: rtu.tenornetworks.com [63.77.213.2]) id QQkocy16876 for ; Tue, 8 May 2001 13:12:39 GMT Received: from tenornet.com (newman [192.168.0.185]) by tenornetworks.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f48DCcK08038; Tue, 8 May 2001 09:12:38 -0400 (EDT) Received: from 192.168.0.185 by tenornet.com; TUE, 8 May 2001 09:07:31 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id <22V8AY9T>; Tue, 8 May 2001 09:07:31 -0400 Message-ID: <6B190B34070BD411ACA000B0D0214E56C65C8C@newman.tenornet.com> From: "Li, Eve" To: Quaizar Vohra , "Li, Eve" Cc: mpls@UU.NET Subject: RE: Comments on kompella-mpls-l2vpn-02 draft Date: Tue, 8 May 2001 09:07:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk In rfc 2858 [BGP-MP], Page 3: Address Family Identifier: This field carries the identity of the Network Layer protocol associated with the Network Address that follows. Presently defined values for this field are specified in RFC 1700 (see the Address Family Numbers section). on Page 4: Network Address of Next Hop: A variable length field that contains the Network Address of the next router on the path to the destination system My understanding is that these two paragraphs requires Next Hop need to be of the same format as NLRI for a given address family. But given that a new address family (l2vpn) is defined, specifying the next hop for l2vpn is always an IPV4 address is fine with me. -eve -----Original Message----- From: Quaizar Vohra [mailto:qv@juniper.net] Sent: Monday, May 07, 2001 8:35 PM To: Li, Eve Cc: mpls@UU.NET Subject: Comments on kompella-mpls-l2vpn-02 draft > BGP's next hop field for L2VPN signalling is not clearly specified. > > Since [BGP-MP] (rfc 2858) requires that the next hop address be in the same > address family as the NLRI. What the next hop address should be for > L2VPN-specific NLRIs? Thx, I couldn't find any such requirement in the rfc. Since you want MPLS LSPs terminating in these next-hop addresses, and currently most implementation use IPv4 addresses as destinations in the LSPs, it seems like IPv4 addresses are a good candidate for the nexthop field. We will update the L2VPN specification to reflect this as a recommendation. Thanks, Quaizar > > -eve From owner-mpls@UU.NET Tue May 8 10:05:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22975 for ; Tue, 8 May 2001 10:05:20 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodc00708; Tue, 8 May 2001 14:04:30 GMT Received: by mail-control.mail.uu.net id QQkodc15878 for mpls-outgoing; Tue, 8 May 2001 14:02:56 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkodc10795 for ; Tue, 8 May 2001 14:01:48 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkodc09299 for ; Tue, 8 May 2001 14:01:19 GMT Received: from yarilo.pluris.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: host200.pluris.com [208.227.9.200]) id QQkodc28228 for ; Tue, 8 May 2001 14:01:19 GMT Received: from volsung.pluris.com (volsung.pluris.com [172.16.50.19]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id HAA19659; Tue, 8 May 2001 07:00:47 -0700 (PDT) Received: from localhost (akyol@localhost) by volsung.pluris.com (8.8.8+Sun/8.8.8) with ESMTP id HAA10287; Tue, 8 May 2001 07:00:46 -0700 (PDT) Date: Tue, 8 May 2001 07:00:46 -0700 (PDT) From: Bora Akyol To: Juha Heinanen cc: Fred Baker , "'mpls@uu.net'" , te-wg@ops.ietf.org Subject: RE: QoS in Shared Media In-Reply-To: <15095.35863.76753.616693@lohi.eng.telia.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Tue, 8 May 2001, Juha Heinanen wrote: > > according to your definition even atm supports diffserv since one can > always use cbr vcs between routers and then let the routers do the > proper queueing. for several reasons this is not a good idea. > > -- juha > Juha Would you care to explain your comment above. I would prefer to do the queueing in the routers rather than let L2 QoS mechanisms manage the queueing. Bora From owner-mpls@UU.NET Tue May 8 10:20:44 2001 Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23982 for ; Tue, 8 May 2001 10:20:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodd03812; Tue, 8 May 2001 14:19:27 GMT Received: by mail-control.mail.uu.net id QQkodd26414 for mpls-outgoing; Tue, 8 May 2001 14:18:54 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkodd26407 for ; Tue, 8 May 2001 14:18:52 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkodd10337 for ; Tue, 8 May 2001 14:15:14 GMT Received: from ns2.cypress.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ns2.cypress.com [157.95.67.5]) id QQkodd18751 for ; Tue, 8 May 2001 14:15:13 GMT Received: from corpmail.cypress.com (corpmail.cypress.com [157.95.1.2]) by ns2.cypress.com (8.10.2/8.10.2) with ESMTP id f48EF6418058; Tue, 8 May 2001 07:15:07 -0700 (PDT) Received: from cobweb.mis.cypress.com (cobweb.mis.cypress.com [172.16.2.5]) by corpmail.cypress.com (8.10.2/8.10.2) with ESMTP id f48EC0W24847; Tue, 8 May 2001 07:12:00 -0700 (PDT) Received: from cypress.com ([157.95.237.150]) by cobweb.mis.cypress.com (8.10.2/8.10.2) with ESMTP id f48EGH027251; Tue, 8 May 2001 07:16:32 -0700 (PDT) Message-ID: <3AF7FF94.F9FBE54A@cypress.com> Date: Tue, 08 May 2001 07:15:48 -0700 From: Pankaj K Jha Organization: Cypress Semiconductor Corp. X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jay Wang CC: Juha Heinanen , HANSEN CHAN , Fred Baker , "Naidu, Venkata" , "'mpls@uu.net'" , te-wg@ops.ietf.org Subject: Re: QoS in Shared Media References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jay: DPT (or similar technologies) give a "virtual" shared media, and its MAC does play a significant role in packet forwarding. I've looked at DPT simulation results, and also looked carefully into its bandwidth allocation. Another problem with DPT bandwidth management is that a node sends usage notification upstream through a control message. This prevents statistical multiplexing or bursting of packets, as actual packet usage changes from packet to packet (by the time upstream node has taken note of available bandwidth at the downstream node, the downstream node situation may have changed). Even though there is a MAX_USAGE field defined, this is not used for the kind of operation you want. You cannot do PHB if MAC is not helping, that is, if the MAC has already gone ahead and put transit packets into output transit buffer. The DPT MAC completely bypasses other schemes by forcing traffic into one of two classes - high or low. Multiple classes can be used when the MAC either allows it, or doesn't come in the way of doing it. Maybe you can do PHB if you can somehow bypass MAC's 2-priority classification and control the whole thing yourself. On BW issue, typically in metro networks there is usually one or more node that provides access to Internet, is a file server, or performs similar functions. Bandwidth requirements at these nodes are quite different from those of other nodes. You wouldn't want to create multiple rings each time you have nodes that are data hot points (you can do it easily in LAN environments where you can segment the network easily using L2/L3 devices. Rings are harder to come by and need more equipment and installed cabling). Please let me know if you find a way of doing it with DPT, I'd like to find out. -Pankaj Jay Wang wrote: > Pankaj, > > -----Original Message----- > From: Pankaj K Jha [mailto:pkj@cypress.com] > Sent: Monday, May 07, 2001 4:46 PM > To: Jay Wang > Cc: Juha Heinanen; HANSEN CHAN; Fred Baker; Naidu, Venkata; > 'mpls@uu.net'; te-wg@ops.ietf.org > Subject: Re: QoS in Shared Media > > >DPT, on the other hand, will go ahead and divide available bandwidth > equally to > >all four nodes - ignoring whatever you may do with Diff-serv. DPT works > best > >when all nodes have equal bandwidth requirements, and it doesn't work when > you > >have dissimilar bandwidth needs. Dissimilar bandwidth needs are quite > common in > >metro networks where hub-and-spoke configurations are norm. If you have > >bandwidth paying customers such as financial institutions and corporate > clients > >on a metro ring along with average over-provisioned clients, DPT will not > do the > >job at all, in my view. > > I believe DPT allows you to artificially specify a cap on the bandwidth, by > configuring the MAX_USAGE parameter, on a per-node basis. But even if all > the > nodes evenly divide the ring bandwidth, this does not mean that on each > node, > I can not provide differentiated treatment (in terms of forwarding and > bandwidth > allocation) among diffserv PHBs at the nodes. Also if the nodes have very > different > BW needs, then they don't have to be placed on the same ring, a traffic > engineering > issue for the carrier. > > - jay From owner-mpls@UU.NET Tue May 8 10:35:06 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24825 for ; Tue, 8 May 2001 10:35:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodc29438; Tue, 8 May 2001 14:02:01 GMT Received: by mail-control.mail.uu.net id QQkodc09965 for mpls-outgoing; Tue, 8 May 2001 14:01:21 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkodc09509 for ; Tue, 8 May 2001 14:01:00 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkodc15935 for ; Tue, 8 May 2001 14:00:30 GMT Received: from sj-msg-core-2.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-2.cisco.com [171.69.24.11]) id QQkodc26984 for ; Tue, 8 May 2001 14:00:29 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f48E0QH21618 for ; Tue, 8 May 2001 07:00:27 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA19009 for mpls@uu.net; Tue, 8 May 2001 10:00:27 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkocw09526 for ; Tue, 8 May 2001 12:38:37 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkocw28527 for ; Tue, 8 May 2001 12:37:11 GMT Received: from EXCHANGE_SERVER by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.125.243]) id QQkocw19473 for ; Tue, 8 May 2001 12:36:58 GMT Received: from usha (FIREWALL [203.197.125.228]) by EXCHANGE_SERVER with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KQ1VSBFY; Tue, 8 May 2001 18:10:21 +0530 Message-ID: <022c01c0d7bb$8b6b11c0$4d6e10ac@ushacomm.co.in> From: "Siddhartha Kataki" To: "Hoang, Ban" , "'Chrysostomos Tziouvaras'" , , References: Subject: Re: [IP-Optical] Modelling of CR-LSP requests Date: Tue, 8 May 2001 18:06:41 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0229_01C0D7E9.A21AEFC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0229_01C0D7E9.A21AEFC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] Modelling of CR-LSP requestsHellp Ban, I would suggest if you can go to the DARPA = site(http://www.darpa.mil/MTO/MEMS/). Maybe you can get some = information. Regards, Siddhartha ----- Original Message -----=20 From: Hoang, Ban=20 To: 'Chrysostomos Tziouvaras' ; mpls@UU.NET ; = ip-optical@lists.bell-labs.com=20 Sent: Monday, May 07, 2001 10:24 PM Subject: RE: [IP-Optical] Modelling of CR-LSP requests Hi all:=20 I would like to know if any one have the informations about MEMS ( = Micro ElectroMechanical Systems) technology. Please guide me if you have = any web site discussion/having good informations about it. Thanks a lot = ! Ban Hoang=20 -----Original Message-----=20 From: Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr]=20 Sent: Sunday, May 06, 2001 8:11 AM=20 To: mpls@UU.NET; ip-optical@lists.bell-labs.com=20 Subject: [IP-Optical] Modelling of CR-LSP requests=20 Dear all,=20 I am trying to conduct some experiments concerning MPLambdaS. The=20 experimental scenario is that there is an optical backbone to which = are=20 attached many MPLS client networks. These client networks produce = Label=20 Request messages.=20 Do you have in mind any realistic scenario about=20 -the probability distribution concerning the arrival of such requests = -the lifetime of the requested CR-LSPs=20 -the size of bandwidth that each CR-LSP request can ask.=20 Thanks=20 Tziouvaras Chrysostomos=20 ICS-FORTH Researcher=20 _______________________________________________=20 IP-Optical mailing list=20 IP-Optical@lists.bell-labs.com=20 http://lists.bell-labs.com/mailman/listinfo/ip-optical=20 ------=_NextPart_000_0229_01C0D7E9.A21AEFC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IP-Optical] Modelling of CR-LSP requests
Hellp Ban,
 
I would suggest if you can go to the = DARPA site(http://www.darpa.mil/MTO/MEMS/). Maybe=20 you can get some information.
 
Regards,
 
Siddhartha
----- Original Message -----
From:=20 Hoang,=20 Ban
To: 'Chrysostomos Tziouvaras' ; mpls@UU.NET ; ip-optical@lists.bell-labs.com=
Sent: Monday, May 07, 2001 = 10:24 PM
Subject: RE: [IP-Optical] = Modelling of=20 CR-LSP requests

Hi all:

I would like to know if any one have the = informations about=20 MEMS ( Micro ElectroMechanical Systems) technology. Please guide me if = you=20 have any web site discussion/having good informations about it. Thanks = a lot=20 !

Ban Hoang

-----Original Message-----
From:=20 Chrysostomos Tziouvaras [mailto:tziou@ics.forth.gr] =
Sent: Sunday, May 06, 2001 8:11 AM
To: mpls@UU.NET; ip-optical@lists.bell-labs= .com=20
Subject: [IP-Optical] Modelling of CR-LSP = requests=20


Dear all,
I am trying to = conduct some=20 experiments concerning MPLambdaS. The
experimental=20 scenario is that there is an optical backbone to which are =
attached many MPLS client networks. These client networks = produce=20 Label
Request messages.
Do you=20 have in mind any realistic scenario about
-the=20 probability distribution concerning the arrival  of such = requests=20
-the lifetime of the requested CR-LSPs =
-the size of bandwidth that each CR-LSP request can = ask.

Thanks
Tziouvaras = Chrysostomos=20
ICS-FORTH Researcher



_______________________________________________=20
IP-Optical mailing list
IP-Optical@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/ip-optical=20

------=_NextPart_000_0229_01C0D7E9.A21AEFC0-- From owner-mpls@UU.NET Tue May 8 12:45:46 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01293 for ; Tue, 8 May 2001 12:45:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodm24793; Tue, 8 May 2001 16:44:38 GMT Received: by mail-control.mail.uu.net id QQkodm18104 for mpls-outgoing; Tue, 8 May 2001 16:44:07 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkodm18070 for ; Tue, 8 May 2001 16:43:53 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkodm23953 for ; Tue, 8 May 2001 16:43:19 GMT Received: from philotas.hosting.pacbell.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: philotas.hosting.pacbell.net [216.100.99.24]) id QQkodm02679 for ; Tue, 8 May 2001 16:43:18 GMT Received: from jaypc (adsl-64-168-85-242.dsl.snfc21.pacbell.net [64.168.85.242]) by philotas.hosting.pacbell.net id MAA07136; Tue, 8 May 2001 12:43:05 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] From: "Jay Wang" To: "Juha Heinanen" Cc: "'mpls@uu.net'" , Subject: RE: QoS in Shared Media Date: Tue, 8 May 2001 09:41:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <15095.35863.76753.616693@lohi.eng.telia.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hi Juha, >jay, > >dpt is layer 2 technology and i was talking about diffserv support at >layer 2, I see. Sorry for the misunderstanding. >which dpt doesn't properly have. ethernet, on the other hand, >does support diffserv also at layer 2, which allows you to build a layer >2 switched network of any topology and still have proper support for >diffserv. >according to your definition even atm supports diffserv since one can >always use cbr vcs between routers and then let the routers do the >proper queueing. for several reasons this is not a good idea. > I that case, would you mind elaborating your concerns? thanks, - jay From owner-mpls@UU.NET Tue May 8 15:40:21 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05768 for ; Tue, 8 May 2001 15:40:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkody28635; Tue, 8 May 2001 19:39:25 GMT Received: by mail-control.mail.uu.net id QQkody04565 for mpls-outgoing; Tue, 8 May 2001 19:38:54 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkody04555 for ; Tue, 8 May 2001 19:38:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkody11270 for ; Tue, 8 May 2001 19:37:59 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkody11083 for ; Tue, 8 May 2001 19:37:58 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20253; Tue, 8 May 2001 15:37:55 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26116; Tue, 8 May 2001 15:37:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 15:37:39 -0400 Message-ID: <4FBEA8857476D311A03300204840E1CF446C5A@whq-msgusr-02.pit.comms.marconi.com> From: "Choudhury, Sanjaya" To: "'Thomas D. Nadeau'" , "'mpls@UU.NET'" Subject: draft-nadeau-mpls-ds-te-mib-00.txt -some suggestions Date: Tue, 8 May 2001 15:37:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi! Posted these suggestions couple of months back, re-posting for soliciting feedback. Thanks, sanjay -----Original Message----- From: Choudhury, Sanjaya Sent: Wednesday, February 28, 2001 10:55 AM To: 'Thomas D. Nadeau'; mpls@UU.NET Cc: Choudhury, Sanjaya Subject: RE: draft-nadeau-mpls-ds-te-mib-00.txt -some suggestions Hi! I have few suggestions related to the mplsDsTeIfClassTypeTable. I will appreciate, if you can take them in to consideration. Thanks, sanjay Suggestions related to the mplsDsTeIfClassTypeTable: --------------------------------------------------- Advantages of the suggested change: ----------------------------------- (1) Builds the support for the concepts introduced in the DiffServ-TE (mpls-diff-te-reqts-00) draft, based on the earlier MPLS-DiffServ draft(mpls-diff-ext-07). How: (a) mpls-diff-ext-07 support ---------------------------- MPLS-DiffServ draft expects the signaling messages to indicate the PSC (section 5.2.2) for L-LSPs. It also allows the provision by which user can specify the bandwidth associated with each of these PSCs. It allows the LSR to perform admission control to ensure that constraints on the availability of bandwidth for relevant PSC.[Appendix -B.2] (I am aware of the fact that to have MIB support for this draft needs more work (E-LSP etc), but that discussion is beyond the context). --> The suggested changes allows for this support. (b) mpls-diff-te-reqts-00 + ospf-diff-te-00 ------------------------------------------- As the reqts-00 draft points out, at its finest granularity each class-type TE is degenerated into a single Diff-Serv class. This draft allows, per-class parameters into the per-Class-Type parameter for scalability of IGP link state adv. --> The suggested changes allows for this support. (c) mpls-diff-te-ext-01 ---------------------- Allows the class-type to be signaled in the during connection setup. [Personally, I think this information is redundant, specifically for L-LSPs, but I may be wrong.] --> The suggested changes allows for this support. (2) Does not restrict the user from deciding the number of class-types he wants to support in his domain. Changes suggested: ------------------- [This changes listed here just to get the idea across and may not be syntactically correct or complete.] (1) --Add the ability for the user to specify the PSC associated with --a L-LSP. Logically, this field belongs to the extension of the --mplsXCTable and mplsTunnelTable (=>mplsDsTeLspTable or equivalent) mplsDsTeLspPSC OBJECT-TYPE SYNTAX Integer --16bit value [mpls-diff-ext-07, 5.2.2] mplsDsTeTunPSC OBJECT-TYPE SYNTAX Integer --16bit value [mpls-diff-ext-07, 5.2.2] (2) --Add the ability to specify the bandwidth requirement for each class --(mpls-diff-ext-07) --Add the ability to group per class parameters to per-class-type --parameters -- --PSC (class) to class-type mapping (per interface mapping --or should they be per LSR ?) -- mplsDsPscToClassTypeEntry OBJECT-TYPE MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { mplsInterfaceConfIndex, psc } ::= { mplsDsPscToClassTypeTable 1 } MplsDsPscToClassTypeEntry ::= SEQUENCE { psc Unsigned16, --16bit value [mpls-diff-ext-07] classType Integer(0..64) --[mpls-diff-te-reqts-00] } -- --per class-type bandwidth requirement (per interface mapping) -- mplsDsClassTypeEntry OBJECT-TYPE MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { mplsInterfaceConfIndex, classType } ::= { mplsDsClassTypeTable 2 } MplsDsPscToClassTypeEntry ::= SEQUENCE { classType INTEGER(0..64), MaxResBw Unsigned32, UnResBw Unsigned32 } (3) --May be we want to introduce two fields to support maximum number --of class-types that can be supported and the number of class-types -- currently configured. -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Friday, February 23, 2001 1:41 PM To: te-wg@UU.NET; mpls@UU.NET Cc: tnadeau@cisco.com; flefauch@europe.cisco.com; angela.chiu@celion.com; btownsend@tenornetworks.com; dareks@nortelnetworks.com; martin.tatham@bt.com Subject: draft-nadeau-mpls-ds-te-mib-00.txt Hi, FYI a new MIB for managing MPLS DiffServ-Aware TE has been posted. This document goes along with the other four DiffServ-Aware TE documents which have been adopted in the MPLS, TE, ISIS and OSPF WGs. It should be available shortly via the IETF's web site. In the meantime, it is available at the following web/ftp link. As usual, comments are welcome. ftp://anonymous@ftp-eng.cisco.com/ftp/tnadeau/draft-nadeau-mpls-ds-te-mib-00 .txt --Tom From owner-mpls@UU.NET Tue May 8 16:07:31 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06463 for ; Tue, 8 May 2001 16:07:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoea13362; Tue, 8 May 2001 20:06:30 GMT Received: by mail-control.mail.uu.net id QQkoea18485 for mpls-outgoing; Tue, 8 May 2001 20:05:57 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoea18114 for ; Tue, 8 May 2001 20:05:40 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoea08329 for ; Tue, 8 May 2001 20:04:05 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoea13070 for ; Tue, 8 May 2001 20:04:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA10145 for mpls@uu.net; Tue, 8 May 2001 16:04:04 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoea16430 for ; Tue, 8 May 2001 20:03:33 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoea11976 for ; Tue, 8 May 2001 20:02:49 GMT Received: from netmail2.alcatel.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkoea05890 for ; Tue, 8 May 2001 20:02:49 GMT Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id PAA18259; Tue, 8 May 2001 15:02:48 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f48K2lT29966; Tue, 8 May 2001 15:02:48 -0500 (CDT) Message-ID: <3AF850B2.B57DB97A@usa.alcatel.com> Date: Tue, 08 May 2001 15:01:54 -0500 From: sambasiva mantha Organization: Alcatel X-Mailer: Mozilla 4.73 [en]C-ANS 1.02 (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Lou Berger CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: new rev of GMPLS signaling I-Ds References: <4.3.2.7.2.20010417170633.02440e90@mo-ex1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit As mentioned in the attached email, has the draft for SONET/SDH published yet? Thanks Sambu Lou Berger wrote: > All, > It looks like the I-D folks are out (and not publishing) for a few > days. For those interested updated versions of the generalized signaling > docs, they are available at: > > http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-03.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-02.txt > http://www.labn.net/docs/draft-ietf-mpls-generalized-cr-ldp-02.txt > > Per the last IETF, these drafts don't include SONET/SDH specifics. A new > draft covering the specifics will be published in a few days. > > Lou (and co-authors) > > >Subject: Autoreply from Internet Draft Submission Manager > >From: ietfauto@ietf.org (Internet Draft Submission Manager) > > > >Hello, > > > >This message is being sent to acknowledge receipt of your submission > >or message to internet-drafts@ietf.org > > > >The I-D administrator will be out of the office until Monday, > >April 23rd. All submissions will be processed. > > > >Thank you. We appreciate your understanding and patience. From owner-mpls@UU.NET Tue May 8 16:23:36 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06842 for ; Tue, 8 May 2001 16:23:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoeb08115; Tue, 8 May 2001 20:23:20 GMT Received: by mail-control.mail.uu.net id QQkoeb28667 for mpls-outgoing; Tue, 8 May 2001 20:22:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoeb28662 for ; Tue, 8 May 2001 20:22:40 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoeb06222 for ; Tue, 8 May 2001 20:22:13 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkoeb11884 for ; Tue, 8 May 2001 20:22:11 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f48KJxS17594; Tue, 8 May 2001 16:19:59 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 16:24:08 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D0220404019821CE@mail1.tellium.com> From: Bala Rajagopalan To: "'Fong, Man Wing'" , mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Tue, 8 May 2001 16:24:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hello, I'm a bit confused by the question. If you had a channelized OC-12 link, wouldn't you just advertise it with suitable Min Reservable Bw values to indicate that it can carry lower granularity traffic? In other words, why would you introduce the notion of a "logical" link in this case? REgards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > Sent: Monday, April 30, 2001 3:31 PM > To: mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: Question about logical link in Link bundling > > > Hi All, > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > multiple links > between two LSRs can be bundled as a single link to improve > the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to > bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized > OC-12 interface? > > Thanks. > > Regards, > Man Wing > > > From owner-mpls@UU.NET Tue May 8 18:06:37 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08669 for ; Tue, 8 May 2001 18:06:36 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoei27641; Tue, 8 May 2001 22:06:15 GMT Received: by mail-control.mail.uu.net id QQkoei05672 for mpls-outgoing; Tue, 8 May 2001 22:05:40 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoei05403 for ; Tue, 8 May 2001 22:05:25 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoei08028 for ; Tue, 8 May 2001 22:05:11 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQkoei05032 for ; Tue, 8 May 2001 22:05:11 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 17:04:09 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE4D@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: "'Bala Rajagopalan'" , mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Tue, 8 May 2001 17:04:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Bala, Correct me if I am wrong. For my understanding, a channelized OC-12 interface can support 12 channels (12 logical DS3 interfaces). Some even capable of defining logical interface within those DS3 channel to support T1. Then, each logical DS3 interfaces can create a (logical) link to the remote routers' DS3 interfaces. The original used of the channelized OC-12 interface is to reduce the cabling and additional equipment cost and labor cost at the central location. Since it is a channelized interface, I believe, it would not allow the user to use it as an OC-12c interface. By applying link bundling on that, now you can size your pipe whatever you want upto the maximum BW (in this case, it will be STS-12c). In addition, using O-UNI, you will get a true bandwidth on demand. Just a thought. Man Wing -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] Sent: Tuesday, May 08, 2001 3:24 PM To: 'Fong, Man Wing'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Hello, I'm a bit confused by the question. If you had a channelized OC-12 link, wouldn't you just advertise it with suitable Min Reservable Bw values to indicate that it can carry lower granularity traffic? In other words, why would you introduce the notion of a "logical" link in this case? REgards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > Sent: Monday, April 30, 2001 3:31 PM > To: mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: Question about logical link in Link bundling > > > Hi All, > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > multiple links > between two LSRs can be bundled as a single link to improve > the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to > bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized > OC-12 interface? > > Thanks. > > Regards, > Man Wing > > > From owner-mpls@UU.NET Tue May 8 18:13:42 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08814 for ; Tue, 8 May 2001 18:13:41 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoei10780; Tue, 8 May 2001 22:13:10 GMT Received: by mail-control.mail.uu.net id QQkoei13739 for mpls-outgoing; Tue, 8 May 2001 22:12:34 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoei13582 for ; Tue, 8 May 2001 22:12:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoei27742 for ; Tue, 8 May 2001 22:11:33 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQkoei16003 for ; Tue, 8 May 2001 22:11:32 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 17:10:30 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE4E@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: "'Bala Rajagopalan'" , mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Tue, 8 May 2001 17:10:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Of course, the routers connected to the optical network will use the channelized interfaces. Man Wing -----Original Message----- From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] Sent: Tuesday, May 08, 2001 5:04 PM To: 'Bala Rajagopalan'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Bala, Correct me if I am wrong. For my understanding, a channelized OC-12 interface can support 12 channels (12 logical DS3 interfaces). Some even capable of defining logical interface within those DS3 channel to support T1. Then, each logical DS3 interfaces can create a (logical) link to the remote routers' DS3 interfaces. The original used of the channelized OC-12 interface is to reduce the cabling and additional equipment cost and labor cost at the central location. Since it is a channelized interface, I believe, it would not allow the user to use it as an OC-12c interface. By applying link bundling on that, now you can size your pipe whatever you want upto the maximum BW (in this case, it will be STS-12c). In addition, using O-UNI, you will get a true bandwidth on demand. Just a thought. Man Wing -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] Sent: Tuesday, May 08, 2001 3:24 PM To: 'Fong, Man Wing'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Hello, I'm a bit confused by the question. If you had a channelized OC-12 link, wouldn't you just advertise it with suitable Min Reservable Bw values to indicate that it can carry lower granularity traffic? In other words, why would you introduce the notion of a "logical" link in this case? REgards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > Sent: Monday, April 30, 2001 3:31 PM > To: mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: Question about logical link in Link bundling > > > Hi All, > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > multiple links > between two LSRs can be bundled as a single link to improve > the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to > bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized > OC-12 interface? > > Thanks. > > Regards, > Man Wing > > > From owner-mpls@UU.NET Tue May 8 18:20:50 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08851 for ; Tue, 8 May 2001 18:20:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoej18896; Tue, 8 May 2001 22:20:25 GMT Received: by mail-control.mail.uu.net id QQkoej19143 for mpls-outgoing; Tue, 8 May 2001 22:19:47 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoej19120 for ; Tue, 8 May 2001 22:19:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoej14032 for ; Tue, 8 May 2001 22:19:05 GMT Received: from mailhost.avici.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [208.246.215.9]) id QQkoej17388 for ; Tue, 8 May 2001 22:19:05 GMT Received: from aatlas-pc (aatlas-pc.avici.com [10.2.20.92]) by mailhost.avici.com (8.11.0/8.11.0) with SMTP id f48MJ3e06242; Tue, 8 May 2001 18:19:03 -0400 (EDT) Message-Id: <4.1.20010508175232.00a7d410@mailhost.avici.com> X-Sender: aatlas@mailhost.avici.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 08 May 2001 18:15:35 -0500 To: Sanjay Wadhwa From: Alia Atlas Subject: Re: Cc: mpls@UU.NET In-Reply-To: <20010426000203.94524.qmail@web11402.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-mpls@UU.NET Precedence: bulk Sanjay, I am considering the same problem. With the below topology, assume the primary LSP is R1-R2-R3-R4-R5-R6. R7 --------- R8 -------- R9 ------- R10 | | | | R1-------- R2 --------- R3 ------- R4 ------- R5 -------- R6 The backup from R2 is signalled as R2-R7-R8-R9-R4. The backup from R3 is signalled as R3-R8-R9-R10-R5. In the PATH messages, clearly the DETOUR object and the ERO distinguish the two detours. However, in the RESV, from the draft, the only way to distinguish the two is based on the contents of the RRO. I would suggest that it would make sense to set the "IPv4 tunnel sender address" in the SENDER_TEMPLATE to an address of the PLR (R2 in the example above). This is how draft-swallow-rsvp-bypass-label-01.txt suggests distinguishing a backup from the primary. It has the advantage that the "IPv4 tunnel sender address" is copied from the SENDER_TEMPLATE in the PATH message into the FILTER_SPEC in the RESV message. Does this make sense to you? Have you heard any other suggestions for how to distinguish the different detours? Thanks, Alia At 05:02 PM 4/25/01 -0700, Sanjay Wadhwa wrote: >Hi >The re-route technique mentioned in this draft talks about using the >same sender_template for each detour LSP and the primary LSP. It is >also restricted to use FF style. How would overlapping detours be >handled here ? > > > R1 ---- R2 ---- R3 ------ R4 ----- R5 ----- R6 > | o | o > | o | o > +------ R7 -o-o-o R8 oooooooo > >Lets say R2 and R3 are local repairers. >R2-R7-R8-R4 (dashed path) provides detour for node R3. >R3-R7-R8-R5 (bubbled path) provides a detour for R4. >Both detours have R7-R8 as a common link. In this case you would want >R8 to send different labels corresponding to the two detours to R7, >since R8 needs to switch packets coming on the two detours out >different interfaces (R8-R4 and R8-R5). If the sender_template is >identical for the two detours how would R8 send two different labels to >R7 (labels go with the filter-spec in RESVs. And I don't see the detour >object being passed back in the RESV to possibly identify the detour) ? > >-Sanjay > > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Auctions - buy the things you want at great prices >http://auctions.yahoo.com/ From owner-mpls@UU.NET Tue May 8 18:23:53 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08920 for ; Tue, 8 May 2001 18:23:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoej22090; Tue, 8 May 2001 22:23:26 GMT Received: by mail-control.mail.uu.net id QQkoej19637 for mpls-outgoing; Tue, 8 May 2001 22:22:31 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoej19571 for ; Tue, 8 May 2001 22:22:11 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoej02975 for ; Tue, 8 May 2001 22:20:28 GMT Received: from longwood.cs.ucf.edu by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: longwood.cs.ucf.edu [132.170.108.1]) id QQkoej18473 for ; Tue, 8 May 2001 22:20:28 GMT Received: from iris.cs.ucf.edu (iris [132.170.108.55]) by longwood.cs.ucf.edu (8.11.1/8.11.1) with ESMTP id f48MKek11641 for ; Tue, 8 May 2001 18:20:40 -0400 (EDT) From: Arturo Nunez Received: (from artnpp@localhost) by iris.cs.ucf.edu (8.9.3/8.9.0) id SAA11034 for mpls@UU.NET; Tue, 8 May 2001 18:18:59 -0400 (EDT) Message-Id: <200105082218.SAA11034@iris.cs.ucf.edu> Subject: OFF-TOPIC:BGP7 To: mpls@UU.NET Date: Tue, 8 May 2001 18:18:59 -0400 (EDT) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: Has anybody heard about BGP7 ?? Any good site where I can search for information ?? Best Regards Arturo Nunez From owner-mpls@UU.NET Tue May 8 20:27:00 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10329 for ; Tue, 8 May 2001 20:26:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoer02062; Wed, 9 May 2001 00:25:52 GMT Received: by mail-control.mail.uu.net id QQkoer08549 for mpls-outgoing; Wed, 9 May 2001 00:25:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoer08528 for ; Wed, 9 May 2001 00:25:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoer12549 for ; Wed, 9 May 2001 00:24:44 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoer20999 for ; Wed, 9 May 2001 00:24:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id UAA26157 for mpls@uu.net; Tue, 8 May 2001 20:24:43 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoer08468 for ; Wed, 9 May 2001 00:24:10 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoer10277 for ; Wed, 9 May 2001 00:22:55 GMT Received: from alpha.tellium.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alpha.tellium.com [151.198.92.2]) id QQkoer18472 for ; Wed, 9 May 2001 00:22:54 GMT Received: from mail1.tellium.com (mail1 [151.198.92.140]) by alpha.tellium.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f490KnS23278; Tue, 8 May 2001 20:20:49 -0400 (EDT) Received: by mail1.tellium.com with Internet Mail Service (5.5.2650.21) id ; Tue, 8 May 2001 20:24:58 -0400 Message-ID: <0CD7D73C734BD411AEE100B0D022040401916351@mail1.tellium.com> From: Debanjan Saha To: "'Fong, Man Wing'" , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Tue, 8 May 2001 20:24:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Fong, You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. However, if all of them are terminating on the same LSR, I'm not sure why you'll use a channelized OC-12 and not an OC-12c. Debanjan -----Original Message----- From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] Sent: Tuesday, May 08, 2001 5:04 PM To: 'Bala Rajagopalan'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Bala, Correct me if I am wrong. For my understanding, a channelized OC-12 interface can support 12 channels (12 logical DS3 interfaces). Some even capable of defining logical interface within those DS3 channel to support T1. Then, each logical DS3 interfaces can create a (logical) link to the remote routers' DS3 interfaces. The original used of the channelized OC-12 interface is to reduce the cabling and additional equipment cost and labor cost at the central location. Since it is a channelized interface, I believe, it would not allow the user to use it as an OC-12c interface. By applying link bundling on that, now you can size your pipe whatever you want upto the maximum BW (in this case, it will be STS-12c). In addition, using O-UNI, you will get a true bandwidth on demand. Just a thought. Man Wing -----Original Message----- From: Bala Rajagopalan [mailto:BRaja@tellium.com] Sent: Tuesday, May 08, 2001 3:24 PM To: 'Fong, Man Wing'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Hello, I'm a bit confused by the question. If you had a channelized OC-12 link, wouldn't you just advertise it with suitable Min Reservable Bw values to indicate that it can carry lower granularity traffic? In other words, why would you introduce the notion of a "logical" link in this case? REgards, Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901 Tel: (732) 923-4237 Fax: (732) 923-9804 Email: braja@tellium.com > -----Original Message----- > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > Sent: Monday, April 30, 2001 3:31 PM > To: mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: Question about logical link in Link bundling > > > Hi All, > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > multiple links > between two LSRs can be bundled as a single link to improve > the routing > scalability. Apparently, it can be used to bundle multiple links from > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > etc...) to be a single link. However, can it be used to > bundle logical links > like T1s in channelized T3, or DS3s, STS-3c in channelized > OC-12 interface? > > Thanks. > > Regards, > Man Wing > > > From owner-mpls@UU.NET Wed May 9 01:54:53 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22089 for ; Wed, 9 May 2001 01:54:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodo27655; Tue, 8 May 2001 17:12:25 GMT Received: by mail-control.mail.uu.net id QQkodo09632 for mpls-outgoing; Tue, 8 May 2001 17:11:52 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkodo09627 for ; Tue, 8 May 2001 17:11:45 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkodo27423 for ; Tue, 8 May 2001 17:11:29 GMT Received: from mailgate.pit.comms.marconi.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkodo21035 for ; Tue, 8 May 2001 17:11:28 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06874 for ; Tue, 8 May 2001 13:11:26 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21641 for ; Tue, 8 May 2001 13:11:26 -0400 (EDT) Message-ID: <3AF828CE.A3D9738C@marconi.com> Date: Tue, 08 May 2001 13:11:42 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP hello message References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > I still have one more for the Hello message needed to confirm. > Anytime, the Ingress, Egress or LSR which supports Hello extension, > will send out Hello(request) message, for any reason the router > which received this Hello request message must first reply Hello > ack back, then it can move to another stage. > > Suppose there is Ingress router which sends out Path message, it is > waiting Resv back from the Egress, but before it receives the Resv, > it received a Hello request message from neighbour, it must send > out Hello ack back first for any reason. RSVP must not be run synchronously. If a Path message is sent out, it MUST NOT block waiting for a Resv to come back. It may receive a thousand other Path messages before then, and it can't block them all. Since Hello messages are not dependant on any RSVP state, it should be possible to handle them as they arrive, without regard for what other messages may or may not have been received. Keep in mind that if you delay responding to a Hello message, your neighbor may decide that you have reset, tearing down all your sessions. If the draft's recommended interval/multiple for Hello is in use, you will only have 17.5ms to get your response out. -- David From owner-mpls@UU.NET Wed May 9 01:54:53 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22092 for ; Wed, 9 May 2001 01:54:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkodc14816; Tue, 8 May 2001 14:03:16 GMT Received: by mail-control.mail.uu.net id QQkodc10665 for mpls-outgoing; Tue, 8 May 2001 14:01:41 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkodc09993 for ; Tue, 8 May 2001 14:01:23 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkodc12868 for ; Tue, 8 May 2001 14:00:19 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkodc26698 for ; Tue, 8 May 2001 14:00:18 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f48E0In24634 for ; Tue, 8 May 2001 07:00:18 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA19005 for mpls@uu.net; Tue, 8 May 2001 10:00:17 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoce24494 for ; Tue, 8 May 2001 08:03:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoce05163 for ; Tue, 8 May 2001 08:02:35 GMT Received: from mailgw.local.ipunplugged.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkoce23898 for ; Tue, 8 May 2001 08:02:31 GMT Received: from HANSPC (a27.local.ipunplugged.com [192.168.4.197]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA21110; Tue, 8 May 2001 10:02:42 +0200 From: "Hans Sj?strand" To: "Felix Chang" Cc: Subject: RE: RE: Parameters in LDP entity table Date: Tue, 8 May 2001 10:00:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200105080105.f4815RR08565@noya.bupt.edu.cn> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr1.ash.ops.us.uu.net id QQkodc14816 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22092 Yes they can. But since the different modes of LDP serves differnet deployment scenarious of LDP the need for it becomes almost none in my mind. However, since the LDP and arch specs allows for it, the mib has to support it, hence the placement of the objects on entity level instead on LSR level. So this explanation is academic. E.g. In a network where some part "A" consist of modern ATM LSRs with L3 forwarding capacity. The distribution in this part could be independant to get faster convergance and if a labelled packet comes in for which it has no LSP XC it will pop and forward. The other part "B" consist of cheaper ATM LSRs without L3 forwarding capacity, these basically have to use Ordered since the they can't handle "partially setup LSRs". The LSR on the boundary between these network parts will have one interface with independant and one with ordered distribution control. The XC between an label on the "A" interface and a label on the "B" interface will happen when the labels for the FEC is assigned or received from the peers. There is no such thing as internal distribution method. The method percieved will probably differ depending on from which direction the label request are coming from and the internal capabilities of the LSR (wheither it can or want to L3 forward), but this is a implentation issue. Read section 2.6 in 3036 a few times and play with some LSP setups and you will get a grip of it. Regards /// Hasse > -----Original Message----- > From: Felix Chang [mailto:mplszhz@263.net] > Sent: den 8 maj 2001 00:00 > To: Hans Sj?strand > Cc: mpls@UU.NET > Subject: Re: RE: Parameters in LDP entity table > > > hi,Hansse > Thank you, but I still have some questions. > As you said, we could have several entities when the LSR have > ATM-based and FR-based interfaces at the same time. And these > entities could have different distribution and retention method. > My question is: If in one LSR, two entities for two interfaces > have different distribution and retention method, could these two > interfaces interwork? If a LSP is setting up between them, we should > use which distribution method in these two entities? > > Best regards! > > Felix > > On 2001-05-07 11:07:00 you wrote£º > >It's true that for many ATM or FR based interfaces uses the > >encap from rfc3034 or rfc3035. It's also true that those use > >per intreface label space. In that case you have several > >entities. distribution and retention method isn't neccesary > >the same over the label switch even though it's defently the > >most common case. > > > >from RFC 3037 LDP Applicability, section 3 > > Downstream on Demand distribution with conservative label retention > > and ordered control is appropriate in situations where labels are a > > relatively scarce resource that must be conserved, and Downstream > > Unsolicited distribution with liberal label retention and independent > > control is appropriate where labels are plentiful and need not be > > carefully conserved. However, the protocol permits other > > combinations of distribution method, label retention mode and control > > mode, including hybrid variants of them. > > > >Regards > >/// Hasse > > > >> -----Original Message----- > >> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > Felix Chang > >> Sent: den 6 maj 2001 09:57 > >> To: mpls_maillist > >> Subject: Parameters in LDP entity table > >> > >> > >> hi,everyone > >> > >> I am confused by some parameters in the LDP entity table. > >> Suppose there are several kinds of mpls-capable > >> interfaces(eg.ATM-based, fr-based) in a LSR, it should use per > >> interface label space. So it has several LDP entities. Is that > >> right? In these entities, are the values of some parameters such > >> as mplsLdpEntityLabelDistributionMethod, > >> mplsLdpEntityLabelRetentionMode, the same? > >> > >> > >> Best regards! > >> Felix Chang > >> mplszhz@263.net > > Best regards£¡ > > Felix Chang > mplszhz@263.net From owner-mpls@UU.NET Wed May 9 05:26:52 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02611 for ; Wed, 9 May 2001 05:26:52 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogb07385; Wed, 9 May 2001 09:25:59 GMT Received: by mail-control.mail.uu.net id QQkogb11135 for mpls-outgoing; Wed, 9 May 2001 09:25:26 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkogb11129 for ; Wed, 9 May 2001 09:25:20 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkogb09321 for ; Wed, 9 May 2001 09:24:42 GMT Received: from wiprom2mx1.wipro.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: wiprom2mx1.wipro.com [203.197.164.41]) id QQkogb04769 for ; Wed, 9 May 2001 09:24:40 GMT Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id PAA24790 for ; Wed, 9 May 2001 15:02:53 GMT Received: from soflt.alc.wipinfo.soft.net ([192.168.220.205]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GD2AEP00.674; Wed, 9 May 2001 15:00:25 +0530 Date: Wed, 9 May 2001 14:59:52 +0530 (IST) From: "chetan kumar s" X-Sender: chetansk@soflt.alc.wipinfo.soft.net Reply-To: chetan.kumar@wipro.com To: suchauhan@hss.hns.com cc: mpls@UU.NET Subject: Re: Attributes of a Label Binding In-Reply-To: <65256A45.001985E6.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mpls@UU.NET Precedence: bulk On Mon, 7 May 2001 suchauhan@hss.hns.com wrote: > > > hi all! > referring to section 3.5 of RFC 3031;- Hi Sumit, The label attribitues that are reffered here are attributes associated with the label (inturn to the LSP), this is not associated to the FEC. It could be Hop Count OR Path Vector.. Thanks Chetan S > > what are these attributes being talked about that may be learned from > the downstream LSR for a particular bind. To me if anything is > specific to a binding for a particular FEC then it should be a part of > the FEC itself i.e. it should be one of the FEC elements that defines > that packet class. I am not able to appreciate the need for any other > information that needs to exist and be exchanged for a binding. > > regards > sumit > > From owner-mpls@UU.NET Wed May 9 05:57:30 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02883 for ; Wed, 9 May 2001 05:57:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogd04650; Wed, 9 May 2001 09:56:56 GMT Received: by mail-control.mail.uu.net id QQkogd13845 for mpls-outgoing; Wed, 9 May 2001 09:56:25 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkogd13805 for ; Wed, 9 May 2001 09:56:16 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogd10269 for ; Wed, 9 May 2001 09:54:34 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkogd29170 for ; Wed, 9 May 2001 09:54:33 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA16836 for mpls@uu.net; Wed, 9 May 2001 05:54:33 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkogd13685 for ; Wed, 9 May 2001 09:54:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogd09757 for ; Wed, 9 May 2001 09:53:54 GMT Received: from alemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkogd28464 for ; Wed, 9 May 2001 09:53:54 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f499rsG11974 for ; Wed, 9 May 2001 05:53:54 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f499rrh11943 for ; Wed, 9 May 2001 05:53:53 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA01637; Wed, 9 May 2001 11:53:52 +0200 (MET DST) Cc: "'Bala Rajagopalan'" , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA01553; Wed, 9 May 2001 11:53:48 +0200 (MET DST) Message-ID: <3AF913AB.EAA21B5B@lucent.com> Date: Wed, 09 May 2001 11:53:47 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fong, Man Wing" Original-CC: "'Bala Rajagopalan'" , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling References: <66E0B27B8A29D511B19600D0B744446527AE4D@192-168-1-220.customer.algx.net> Content-Type: multipart/mixed; boundary="------------700A3D4014597873ABD418F9" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------700A3D4014597873ABD418F9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Man Wing, An OC12 interface port (when connect to another OC12 interface port) provides what is called a "topological link" in ITU-T Rec. G.852.2 to its client (HOVC/STS) layer network. This topological link supports one or more HOVC/STS link connections, as expressed in terms defined in G.853.8 "pre-provisioned adaptation management": - pamMaxProvisionableCapacity: The pamMaxProvisionableCapacity attribute provides the value that represents the maximum capacity that could be provisioned for a link from the server trail of this link. However, this maximum may not be provisioned for this link if several links are supported by the same server trail: in this case, they are sharing the maximum capacity. - pamPotentialLinkCapacity: The pamPotentialLinkCapacity attribute provides a value that represents the potential capacity that could be provisioned on a link from the capacity that has not already been provisioned from the server trail of this link. - pamProvisionedLinkCapacity: The pamProvisionedLinkCapacity attribute provides the capacity provisioned on a link. - pamAvailableLinkCapacity: The pamAvailableLinkCapacity attribute represents the provisioned capacity that is not assigned. For an OC12, the following may be supported: - example 1 - STS1, STS3c and STS12c supported: pamMaxProvisionableCapacity: STS1: 12; STS3c: 4; STS12c: 1 pamPotentialLinkCapacity: STS1: 12; STS3c: 4; STS12c: 1 pamProvisionedLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 pamAvailableLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 - example 2 - only STS3c supported: pamMaxProvisionableCapacity: STS1: 0; STS3c: 4; STS12c: 0 pamPotentialLinkCapacity: STS1: 0; STS3c: 4; STS12c: 0 pamProvisionedLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 pamAvailableLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 - example 3 - STS1 and STS12c supported: pamMaxProvisionableCapacity: STS1: 12; STS3c: 0; STS12c: 1 pamPotentialLinkCapacity: STS1: 12; STS3c: 0; STS12c: 1 pamProvisionedLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 pamAvailableLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0 The above examples are assuming an initial situation in which none of the link connections is already providing service. For the case 1 STS1 and 1 STS3c link connection are providing service example 1 would have its parameters presented as: - example 1 - STS1, STS3c and STS12c supported and 1 STS1 and 1 STS3c link connection used: pamMaxProvisionableCapacity: STS1: 12; STS3c: 4; STS12c: 1 pamPotentialLinkCapacity: STS1: 6; STS3c: 2; STS12c: 0 pamProvisionedLinkCapacity: STS1: 1; STS3c: 1; STS12c: 0 pamAvailableLinkCapacity: STS1: 2; STS3c: 0; STS12c: 0 See for more examples my ASTN layer network architecture document. Note that DS3's, T1's, etc are not visible at this point in the layer network structure. The HOVC/STS layer network deals with VC3/STS1, VC4/STS3c, VC-4-4c/STS12c, VC-4-16c/STS48c, VC-4-64c/STS192c and VC-4-256c/STS768c signals and groups of these signals (AUG-X/STSG-X, groups supporting virtual concatenation, other groups). In addition, these signals may be terminated in trail termination points (TTP) within an Access Group (AG), providing access to its client signals. Such client signals can be a e.g. DS3, E4, ATM, ethernet, IP, MPLS and LOVC/VT signals. For the case the HOVC/STS layer network connects two STS1 or two VC4 ports, the STS1 or VC4 path that is now present provides e.g. a LOVC/VT topological link to the LOVC/VT layer network. Alternatively, if the payload would have been ATM, it would have provided a ATM VP topological link to the ATM VP layer network. For the case the payload would have been DS3, it would have provided a DS3 link connection to e.g. a customer. In the LOVC/VT layer network T1's are not directly visible either. It are the VC11/VT1.5, VC12, VC3 signal and groups of these signals. Only when such signal is terminated in a TTP within an AG in this layer network, access to its client signals (e.g. a T1) is provided. So for the LOVC/VT layer entwork, STS1 and VC4 are the interface ports providing LOVC/VT (topological) links. some examples: For a VC4, the following may be supported: - example 1 - VC11/VT1.5, VC12 and VC3 supported: pamMaxProvisionableCapacity: VC11/VT1.5: 84; VC12: 63; VC3: 3 pamPotentialLinkCapacity: VC11/VT1.5: 84; VC12: 63; VC3: 3 pamProvisionedLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 pamAvailableLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 - example 2 - VC12 and VC3 supported: pamMaxProvisionableCapacity: VC11/VT1.5: 0; VC12: 63; VC3: 3 pamPotentialLinkCapacity: VC11/VT1.5: 0; VC12: 63; VC3: 3 pamProvisionedLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 pamAvailableLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 - example 1 - VC11/VT1.5, VC12 and VC3 supported and 1 VC12 and 1 VC3 link connection: pamMaxProvisionableCapacity: VC11/VT1.5: 84; VC12: 63; VC3: 3 pamPotentialLinkCapacity: VC11/VT1.5: 52; VC12: 39; VC3: 1 pamProvisionedLinkCapacity: VC11/VT1.5: 0; VC12: 1; VC3: 0 pamAvailableLinkCapacity: VC11/VT1.5: 0; VC12: 2; VC3: 0 Now consider that there is one OC12 and one OC48 connection between the two network elements. This would create an additional HOVC/STS topological link supported by the OC48 connection. Assume that this OC48 supports from STS1 to STS48c, then the HOVC/STS link (i.e. the "bundle" in GMPLS terminology) would be characterised as follows: - example 1b - STS1, STS3c and STS12c supported on OC12 and STS1 to STS48c supported on OC48: pamMaxProvisionableCapacity: STS1: 60; STS3c: 20; STS12c: 5; STS48c: 1 pamPotentialLinkCapacity: STS1: 60; STS3c: 20; STS12c: 5; STS48c: 1 pamProvisionedLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0; STS48c: 1 pamAvailableLinkCapacity: STS1: 0; STS3c: 0; STS12c: 0; STS48c: 1 If instead of one VC4 also one STS1 path is present, an additional LOVC/VT topological link would be provided by the STS1 path to the LOVC/VT layer network. If this STS1 supports VT1.5 only, the LOVC/VT link (i.e. the "bundle" in GMPLS terminology) would be characterised as follows: - example 2b - VC12 and VC3 supported on VC4 and VT1.5 on STS1: pamMaxProvisionableCapacity: VC11/VT1.5: 28; VC12: 63; VC3: 3 pamPotentialLinkCapacity: VC11/VT1.5: 28; VC12: 63; VC3: 3 pamProvisionedLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 pamAvailableLinkCapacity: VC11/VT1.5: 0; VC12: 0; VC3: 0 Hope this helps understanding the multi layer aspects as well as "bundling". Regards, Maarten "Fong, Man Wing" wrote: > > Bala, > > Correct me if I am wrong. For my understanding, a channelized OC-12 > interface can support 12 channels (12 logical DS3 interfaces). Some even > capable of defining logical interface within those DS3 channel to support > T1. Then, each logical DS3 interfaces can create a (logical) link to the > remote routers' DS3 interfaces. The original used of the channelized OC-12 > interface is to reduce the cabling and additional equipment cost and labor > cost at the central location. Since it is a channelized interface, I > believe, it would not allow the user to use it as an OC-12c interface. By > applying link bundling on that, now you can size your pipe whatever you want > upto the maximum BW (in this case, it will be STS-12c). In addition, using > O-UNI, you will get a true bandwidth on demand. > > Just a thought. > > Man Wing > > -----Original Message----- > From: Bala Rajagopalan [mailto:BRaja@tellium.com] > Sent: Tuesday, May 08, 2001 3:24 PM > To: 'Fong, Man Wing'; mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: Question about logical link in Link bundling > > Hello, > > I'm a bit confused by the question. If you > had a channelized OC-12 link, wouldn't you > just advertise it with suitable Min Reservable > Bw values to indicate that it can carry lower > granularity traffic? In other words, why would > you introduce the notion of a "logical" link > in this case? > > REgards, > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > > Sent: Monday, April 30, 2001 3:31 PM > > To: mpls@UU.NET; 'Kireeti Kompella' > > Cc: ccamp@ops.ietf.org > > Subject: Question about logical link in Link bundling > > > > > > Hi All, > > > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > > multiple links > > between two LSRs can be bundled as a single link to improve > > the routing > > scalability. Apparently, it can be used to bundle multiple links from > > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > > etc...) to be a single link. However, can it be used to > > bundle logical links > > like T1s in channelized T3, or DS3s, STS-3c in channelized > > OC-12 interface? > > > > Thanks. > > > > Regards, > > Man Wing > > > > > > --------------700A3D4014597873ABD418F9 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------700A3D4014597873ABD418F9-- From owner-mpls@UU.NET Wed May 9 06:09:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03010 for ; Wed, 9 May 2001 06:09:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoge18089; Wed, 9 May 2001 10:09:24 GMT Received: by mail-control.mail.uu.net id QQkoge03384 for mpls-outgoing; Wed, 9 May 2001 10:08:46 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoge03379 for ; Wed, 9 May 2001 10:08:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoge14618 for ; Wed, 9 May 2001 10:07:51 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoge16885 for ; Wed, 9 May 2001 10:07:51 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id GAA17915 for mpls@uu.net; Wed, 9 May 2001 06:07:50 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoge03339 for ; Wed, 9 May 2001 10:07:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoge16936 for ; Wed, 9 May 2001 10:06:30 GMT Received: from alemail1.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: alemail1.lucent.com [192.11.221.161]) id QQkoge14590 for ; Wed, 9 May 2001 10:06:29 GMT Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f49A6Tt17463 for ; Wed, 9 May 2001 06:06:29 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f49A6Sd17445 for ; Wed, 9 May 2001 06:06:29 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA17817; Wed, 9 May 2001 12:06:28 +0200 (MET DST) Cc: "'Fong, Man Wing'" , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA17708; Wed, 9 May 2001 12:06:24 +0200 (MET DST) Message-ID: <3AF9169F.83943047@lucent.com> Date: Wed, 09 May 2001 12:06:23 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Debanjan Saha Original-CC: "'Fong, Man Wing'" , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling References: <0CD7D73C734BD411AEE100B0D022040401916351@mail1.tellium.com> Content-Type: multipart/mixed; boundary="------------7178821E76A65B83EA95C59F" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------7178821E76A65B83EA95C59F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Debanjan, Just a thought... those 12 DS3s terminating on the same router (and providing access to 12 MPLS links) may terminate at the other ends on 12 different routers. With one physical (OC12) interface you have now made (with the help of the transport network) connections with 12 other routers. Very cost effective... Ofcourse you don't need a DS3 to be present in the STS1 is the router at the other end of the transport network has a EC1 of (channelised) OC-N interface. In this case you may deploy direct mapping of MPLS into STS1 payload (via PPP/HDLC or the new GFP encapsulation). One further cost reduction step (for the case there are e.g. only 5 other routers connected) is to use STS1 virtual concatenation with GFP encapsulation of MPLS. You can now size each of the 5 STS pipes between 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12. Regards, Maarten Debanjan Saha wrote: > > Fong, > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. > However, if all of them are terminating on > the same LSR, I'm not sure why you'll use a channelized > OC-12 and not an OC-12c. > > Debanjan > > -----Original Message----- > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > Sent: Tuesday, May 08, 2001 5:04 PM > To: 'Bala Rajagopalan'; mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: Question about logical link in Link bundling > > Bala, > > Correct me if I am wrong. For my understanding, a channelized OC-12 > interface can support 12 channels (12 logical DS3 interfaces). Some even > capable of defining logical interface within those DS3 channel to support > T1. Then, each logical DS3 interfaces can create a (logical) link to the > remote routers' DS3 interfaces. The original used of the channelized OC-12 > interface is to reduce the cabling and additional equipment cost and labor > cost at the central location. Since it is a channelized interface, I > believe, it would not allow the user to use it as an OC-12c interface. By > applying link bundling on that, now you can size your pipe whatever you want > upto the maximum BW (in this case, it will be STS-12c). In addition, using > O-UNI, you will get a true bandwidth on demand. > > Just a thought. > > Man Wing > > -----Original Message----- > From: Bala Rajagopalan [mailto:BRaja@tellium.com] > Sent: Tuesday, May 08, 2001 3:24 PM > To: 'Fong, Man Wing'; mpls@UU.NET; 'Kireeti Kompella' > Cc: ccamp@ops.ietf.org > Subject: RE: Question about logical link in Link bundling > > Hello, > > I'm a bit confused by the question. If you > had a channelized OC-12 link, wouldn't you > just advertise it with suitable Min Reservable > Bw values to indicate that it can carry lower > granularity traffic? In other words, why would > you introduce the notion of a "logical" link > in this case? > > REgards, > > Bala Rajagopalan > Tellium, Inc. > 2 Crescent Place > P.O. Box 901 > Oceanport, NJ 07757-0901 > Tel: (732) 923-4237 > Fax: (732) 923-9804 > Email: braja@tellium.com > > > -----Original Message----- > > From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] > > Sent: Monday, April 30, 2001 3:31 PM > > To: mpls@UU.NET; 'Kireeti Kompella' > > Cc: ccamp@ops.ietf.org > > Subject: Question about logical link in Link bundling > > > > > > Hi All, > > > > From "draft-kompella-mpls-bundle-05.txt", it indicates that > > multiple links > > between two LSRs can be bundled as a single link to improve > > the routing > > scalability. Apparently, it can be used to bundle multiple links from > > multiple physical interfaces (e.g. multiple T1s, DS3s, OC-12s, OC-48s, > > etc...) to be a single link. However, can it be used to > > bundle logical links > > like T1s in channelized T3, or DS3s, STS-3c in channelized > > OC-12 interface? > > > > Thanks. > > > > Regards, > > Man Wing > > > > > > --------------7178821E76A65B83EA95C59F Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------7178821E76A65B83EA95C59F-- From owner-mpls@UU.NET Wed May 9 10:10:48 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07502 for ; Wed, 9 May 2001 10:10:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogu27912; Wed, 9 May 2001 14:10:15 GMT Received: by mail-control.mail.uu.net id QQkogu02644 for mpls-outgoing; Wed, 9 May 2001 14:09:44 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkogu02562 for ; Wed, 9 May 2001 14:09:34 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkogu20958 for ; Wed, 9 May 2001 14:09:20 GMT Received: from exchange01.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.82.134]) id QQkogu26267 for ; Wed, 9 May 2001 14:09:20 GMT Received: from BLIULAPTOP ([64.47.72.35]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 9 May 2001 10:06:23 -0400 Message-ID: <007a01c0d891$3a688600$23482f40@movaz.com> From: "Adrian Farrel" To: , References: <66E0B27B8A29D511B19600D0B744446527AE4D@192-168-1-220.customer.algx.net> <3AF913AB.EAA21B5B@lucent.com> Subject: GMPLS TE MIB Date: Wed, 9 May 2001 10:06:21 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 09 May 2001 14:06:23.0609 (UTC) FILETIME=[3AE18690:01C0D891] Sender: owner-mpls@UU.NET Precedence: bulk We have submitted a draft to extend the TE-MIB to support GMPLS. This is available at http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp ls-te-mib-00.txt We would welcome your thoughts and comments Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com From owner-mpls@UU.NET Wed May 9 10:25:31 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08263 for ; Wed, 9 May 2001 10:25:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogv20709; Wed, 9 May 2001 14:23:13 GMT Received: by mail-control.mail.uu.net id QQkogv12820 for mpls-outgoing; Wed, 9 May 2001 14:22:37 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkogv12790 for ; Wed, 9 May 2001 14:22:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogv10556 for ; Wed, 9 May 2001 14:21:57 GMT Received: from sj-msg-core-1.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkogv18358 for ; Wed, 9 May 2001 14:21:57 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f49ELun03549 for ; Wed, 9 May 2001 07:21:56 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id KAA21501 for mpls@uu.net; Wed, 9 May 2001 10:21:55 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkofy18313 for ; Wed, 9 May 2001 08:37:08 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkofy19963 for ; Wed, 9 May 2001 08:36:43 GMT From: PietroVittorio.Grandi@alcatel.it Received: from tlvsdy.vim.tlt.alcatel.it by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: tlvsdy.vim.tlt.alcatel.it [194.243.74.244]) id QQkofy00509 for ; Wed, 9 May 2001 08:36:42 GMT Received: from tlvhdk.netit.alcatel.it (tlvhgd.netit.alcatel.it [151.98.14.48]) by tlvsdy.vim.tlt.alcatel.it (8.9.3+Sun/8.9.3) with ESMTP id KAA23639; Wed, 9 May 2001 10:37:08 +0200 (MET DST) Received: from localhost (root@localhost) by tlvhdk.netit.alcatel.it (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA28090; Wed, 9 May 2001 10:32:29 +0200 (METDST) X-OpenMail-Hops: 1 Date: Wed, 9 May 2001 10:24:01 +0200 Message-Id: Subject: MPLS NCP for PPP interfaces MIME-Version: 1.0 TO: ietf-ppp@merit.edu, mpls@UU.NET CC: Italo.Busi@netit.alcatel.it, PietroVittorio.Grandi@netit.alcatel.it Content-Type: multipart/mixed; boundary="openmail-part-02bf1ebd-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-02bf1ebd-00000001 Content-Type: text/plain; charset=US-ASCII; name="BDY.TXT" Content-Disposition: inline; filename="BDY.TXT" Content-Transfer-Encoding: 7bit Hi all, could you please give us some references to RFCs or Drafts about MPLS NCP for PPP interfaces ? Thank you Pietro Grandi Italo Busi ---------------------------------------------- Reality is merely an illusion, albeit a very persistent one. (A. Einstein) --openmail-part-02bf1ebd-00000001 Content-Type: application/octet-stream; name="Grandi Pietro (E-mail).vcf" Content-Disposition: attachment; filename="Grandi Pietro (E-mail).vcf" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOlBpZXRybztHcmFuZGkNCkZOOkdyYW5kaSBQ aWV0cm8gKEUtbWFpbCkNCk9SRzpBbGNhdGVsO0FETSBSJkQNClRFTDtXT1JLO1ZPSUNFOisz OSAwMzkgNjg2IDQ5MzANClRFTDtXT1JLO0ZBWDorMzkgMDM5IDY4NiAzNTkwDQpBRFI7V09S Szo7QURNIFN5c3RlbSBMYWI7VmlhIFRyZW50byAzMDtWaW1lcmNhdGU7TWlsYW47MjAwNTk7 SXRhbHkNCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTpBRE0gU3lzdGVt IExhYj0wRD0wQVZpYSBUcmVudG8gMzA9MEQ9MEFWaW1lcmNhdGUsIE1pbGFuIDIwMDU5PTBE PTBBSXRhbHkNCkVNQUlMO1BSRUY7SU5URVJORVQ6cGlldHJvdml0dG9yaW8uZ3JhbmRpQG5l dGl0LmFsY2F0ZWwuaXQNClJFVjoyMDAwMDkwNlQxNjQyNDZaDQpFTkQ6VkNBUkQNCg== --openmail-part-02bf1ebd-00000001-- From owner-mpls@UU.NET Wed May 9 10:38:47 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09101 for ; Wed, 9 May 2001 10:38:47 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogw13469; Wed, 9 May 2001 14:36:17 GMT Received: by mail-control.mail.uu.net id QQkogw14556 for mpls-outgoing; Wed, 9 May 2001 14:35:43 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkogw14541 for ; Wed, 9 May 2001 14:35:31 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogw06840 for ; Wed, 9 May 2001 14:33:51 GMT Received: from sandmail.sandburst.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkogw09387 for ; Wed, 9 May 2001 14:33:50 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id 4742694006; Wed, 9 May 2001 10:33:50 -0400 (EDT) Message-ID: <3AF9554E.405AA454@sandburst.com> Date: Wed, 09 May 2001 10:33:50 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: PietroVittorio.Grandi@alcatel.it Cc: ietf-ppp@merit.edu, mpls@UU.NET, Italo.Busi@netit.alcatel.it, PietroVittorio.Grandi@netit.alcatel.it Subject: Re: MPLS NCP for PPP interfaces References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Pietro Grandi, See section 4.2 of RFC 3032, available at: http://www.ietf.org/rfc/rfc3032.txt You wrote: > Hi all, > > could you please give us some references to RFCs or Drafts > about MPLS NCP for PPP interfaces ? > > Thank you > > Pietro Grandi > Italo Busi > > ---------------------------------------------- > Reality is merely an illusion, albeit a very persistent one. > (A. Einstein) > -- Eric Gray ---------------------------------------------- Persitence is a relative term; relatives are only persitent when you don't want them to be... From owner-mpls@UU.NET Wed May 9 10:43:09 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09339 for ; Wed, 9 May 2001 10:43:09 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogw15289; Wed, 9 May 2001 14:40:19 GMT Received: by mail-control.mail.uu.net id QQkogw14995 for mpls-outgoing; Wed, 9 May 2001 14:39:45 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkogw14969 for ; Wed, 9 May 2001 14:39:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkogw18243 for ; Wed, 9 May 2001 14:39:11 GMT Received: from mailgate.pit.comms.marconi.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkogw04112 for ; Wed, 9 May 2001 14:39:11 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21769; Wed, 9 May 2001 10:39:06 -0400 (EDT) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21500; Wed, 9 May 2001 10:39:07 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 10:38:49 -0400 Message-ID: <39469E08BD83D411A3D900204840EC5510B64B@vie-msgusr-01.dc.fore.com> From: "Topatan, Kutlay" To: "'PietroVittorio.Grandi@alcatel.it'" , ietf-ppp@merit.edu, mpls@UU.NET Cc: Italo.Busi@netit.alcatel.it, PietroVittorio.Grandi@netit.alcatel.it Subject: RE: MPLS NCP for PPP interfaces Date: Wed, 9 May 2001 10:39:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk RFC 3032 Section 4.2 k. > > could you please give us some references to RFCs or Drafts > about MPLS NCP for PPP interfaces ? > > Thank you > > Pietro Grandi > Italo Busi From owner-mpls@UU.NET Wed May 9 10:43:58 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09400 for ; Wed, 9 May 2001 10:43:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogw23589; Wed, 9 May 2001 14:41:55 GMT Received: by mail-control.mail.uu.net id QQkogw15271 for mpls-outgoing; Wed, 9 May 2001 14:41:27 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkogw15069 for ; Wed, 9 May 2001 14:40:30 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkogw20158 for ; Wed, 9 May 2001 14:40:01 GMT Received: from noya.bupt.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkogw04903 for ; Wed, 9 May 2001 14:39:48 GMT Received: from vinus ([202.112.109.71]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f49Djtv01114; Wed, 9 May 2001 21:46:08 +0800 (CST) Message-Id: <200105091346.f49Djtv01114@noya.bupt.edu.cn> Date: Wed, 9 May 2001 21:44:12 +0800 From: Felix Chang To: Hans Sj?strand , mpls_maillist Subject: RE: RE: Parameters in LDP entity table X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit hi,Hasse Thank you a lot! I have understood what you meant. And I have another question: Since LSP is unidirectional, May we specify different distribution methods on the two directions of a LDP session? Best regards! Felix Chang mplszhz@263.net From owner-mpls@UU.NET Wed May 9 10:47:51 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09620 for ; Wed, 9 May 2001 10:47:46 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogx29759; Wed, 9 May 2001 14:45:16 GMT Received: by mail-control.mail.uu.net id QQkogw15585 for mpls-outgoing; Wed, 9 May 2001 14:44:42 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkogw15559 for ; Wed, 9 May 2001 14:44:23 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkogw28811 for ; Wed, 9 May 2001 14:43:49 GMT Received: from noya.bupt.edu.cn by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: noya.bupt.edu.cn [202.112.96.2]) id QQkogw09198 for ; Wed, 9 May 2001 14:43:47 GMT Received: from vinus ([202.112.109.71]) by noya.bupt.edu.cn (8.11.3/8.10.1) with SMTP id f49CjUv00289 for ; Wed, 9 May 2001 20:45:30 +0800 (CST) Message-Id: <200105091245.f49CjUv00289@noya.bupt.edu.cn> Date: Wed, 9 May 2001 20:43:47 +0800 From: Felix Chang To: mpls_maillist Subject: Fw: Re: rfc3031 section3.2 X-mailer: FoxMail 3.11 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA09620 mpls_maillisthi,Hailong Lu.sean£¡ In my opinion, this section means that, when some packets that belong to the FEC travelling through upstream node to downstream node, they use the label to represent these packets. But in the network, packets belong to the FEC may not travel through these two nodes. They may follow another path. On 2001-05-08 16:49:00 you wrote£º >Hi,there > I am new guy to MPLS.While reading rfc3031's section 3.2,there >are some words I can't understand: > > "To say that one node is upstream and one is downstream with respect > to a given binding means only that a particular label represents a > particular FEC in packets travelling from the upstream node to the > downstream node. This is NOT meant to imply that packets in that FEC > would actually be routed from the upstream node to the downstream > node" > > thanks. > > > >sean Best regards£¡ Felix Chang mplszhz@263.net From owner-mpls@UU.NET Wed May 9 11:18:44 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11401 for ; Wed, 9 May 2001 11:18:43 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogz20747; Wed, 9 May 2001 15:16:36 GMT Received: by mail-control.mail.uu.net id QQkogz08272 for mpls-outgoing; Wed, 9 May 2001 15:15:59 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkogz08250 for ; Wed, 9 May 2001 15:15:53 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogz25139 for ; Wed, 9 May 2001 15:15:21 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQkogz15891 for ; Wed, 9 May 2001 15:15:21 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 10:14:18 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE50@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: "'Debanjan Saha'" , "Fong, Man Wing" , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Wed, 9 May 2001 10:14:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Debanjan, As I mentioned in the email, the key is to provide bandwidth on demand. Certainly, if the user needs the STS-12c link up all the time, the OC-12c interface will make more sense. However, if the user doesn't need it all the time, the OC-12c interface will tie the whole STS-12c BW. So that applying link bundling on the channelized OC-12 interface can bundle a few channels to create the right size link the user need between the routers, and the unused STSs within the transport network can be used in somewhere else. What do you think? Man Wing -----Original Message----- From: Debanjan Saha [mailto:DSaha@tellium.com] Sent: Tuesday, May 08, 2001 7:25 PM To: 'Fong, Man Wing'; Bala Rajagopalan; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Fong, You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. However, if all of them are terminating on the same LSR, I'm not sure why you'll use a channelized OC-12 and not an OC-12c. Debanjan -----Original Message----- From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com] Sent: Tuesday, May 08, 2001 5:04 PM To: 'Bala Rajagopalan'; mpls@UU.NET; 'Kireeti Kompella' Cc: ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Bala, Correct me if I am wrong. For my understanding, a channelized OC-12 interface can support 12 channels (12 logical DS3 interfaces). Some even capable of defining logical interface within those DS3 channel to support T1. Then, each logical DS3 interfaces can create a (logical) link to the remote routers' DS3 interfaces. The original used of the channelized OC-12 interface is to reduce the cabling and additional equipment cost and labor cost at the central location. Since it is a channelized interface, I believe, it would not allow the user to use it as an OC-12c interface. By applying link bundling on that, now you can size your pipe whatever you want upto the maximum BW (in this case, it will be STS-12c). In addition, using O-UNI, you will get a true bandwidth on demand. Just a thought. Man Wing From owner-mpls@UU.NET Wed May 9 11:21:20 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11504 for ; Wed, 9 May 2001 11:21:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogz21181; Wed, 9 May 2001 15:19:55 GMT Received: by mail-control.mail.uu.net id QQkogz08869 for mpls-outgoing; Wed, 9 May 2001 15:19:24 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkogz08829 for ; Wed, 9 May 2001 15:19:05 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkogz07142 for ; Wed, 9 May 2001 15:17:08 GMT Received: from wrnxchg.Whiterocknetworks.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.whiterocknetworks.com [65.192.92.133]) id QQkogz17828 for ; Wed, 9 May 2001 15:17:08 GMT Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 10:16:06 -0500 Message-ID: <66E0B27B8A29D511B19600D0B744446527AE51@192-168-1-220.customer.algx.net> From: "Fong, Man Wing" To: "'Maarten Vissers'" , Debanjan Saha Cc: "Fong, Man Wing" , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: RE: Question about logical link in Link bundling Date: Wed, 9 May 2001 10:16:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Maarten, Very good point and description. The last case that you describe using VC would be a good alternative to support the bandwidth on demand. Now that the inverse muxing capability is being transferred from the router to the transport NEs. In this case, (Debanjan, you're right), the user would use an OC-12c interface on a router instead of the channelized OC-12 interface to save cost for this application (BOD). Thanks, Man Wing -----Original Message----- From: Maarten Vissers [mailto:mvissers@lucent.com] Sent: Wednesday, May 09, 2001 5:06 AM To: Debanjan Saha Cc: 'Fong, Man Wing'; Bala Rajagopalan; mpls@UU.NET; 'Kireeti Kompella'; ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling << File: Card for Maarten Vissers >> Debanjan, Just a thought... those 12 DS3s terminating on the same router (and providing access to 12 MPLS links) may terminate at the other ends on 12 different routers. With one physical (OC12) interface you have now made (with the help of the transport network) connections with 12 other routers. Very cost effective... Ofcourse you don't need a DS3 to be present in the STS1 is the router at the other end of the transport network has a EC1 of (channelised) OC-N interface. In this case you may deploy direct mapping of MPLS into STS1 payload (via PPP/HDLC or the new GFP encapsulation). One further cost reduction step (for the case there are e.g. only 5 other routers connected) is to use STS1 virtual concatenation with GFP encapsulation of MPLS. You can now size each of the 5 STS pipes between 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12. Regards, Maarten Debanjan Saha wrote: > > Fong, > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. > However, if all of them are terminating on > the same LSR, I'm not sure why you'll use a channelized > OC-12 and not an OC-12c. > > Debanjan From owner-mpls@UU.NET Wed May 9 11:26:27 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11847 for ; Wed, 9 May 2001 11:26:27 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkogz26979; Wed, 9 May 2001 15:24:35 GMT Received: by mail-control.mail.uu.net id QQkogz09348 for mpls-outgoing; Wed, 9 May 2001 15:23:59 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkogz09331 for ; Wed, 9 May 2001 15:23:52 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkogz13343 for ; Wed, 9 May 2001 15:20:15 GMT Received: from web8003.mail.in.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web8003.in.yahoo.com [203.199.70.21]) id QQkogz28731 for ; Wed, 9 May 2001 15:20:14 GMT Message-ID: <20010509152311.23863.qmail@web8003.mail.in.yahoo.com> Received: from [169.144.84.57] by web8003.mail.in.yahoo.com; Wed, 09 May 2001 16:23:11 BST Date: Wed, 9 May 2001 16:23:11 +0100 (BST) From: =?iso-8859-1?q?Shankar?= Subject: Re: Fw: Re: rfc3031 section3.2 To: Felix Chang , mpls_maillist In-Reply-To: <200105091245.f49CjUv00289@noya.bupt.edu.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: owner-mpls@UU.NET Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by cmr0.ash.ops.us.uu.net id QQkogz26979 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11847 Hi, My understanding was that the nodes could be acting as transit nodes and not necessarily source and destination nodes. Right?? Thanks shankar --- Felix Chang wrote: > mpls_maillisthi,Hailong Lu.sean£¡ > > In my opinion, this section means that, when some > packets that belong to the FEC > travelling through upstream node to downstream node, > they use the label to represent > these packets. But in the network, packets belong to > the FEC may not travel through > these two nodes. They may follow another path. > > On 2001-05-08 16:49:00 you wrote£º > >Hi,there > > I am new guy to MPLS.While reading rfc3031's > section 3.2,there > >are some words I can't understand: > > > > "To say that one node is upstream and one is > downstream with respect > > to a given binding means only that a particular > label represents a > > particular FEC in packets travelling from the > upstream node to the > > downstream node. This is NOT meant to imply > that packets in that FEC > > would actually be routed from the upstream node > to the downstream > > node" > > > > thanks. > > > > > > > >sean > > Best regards£¡ > > Felix Chang > mplszhz@263.net > > ____________________________________________________________ Do You Yahoo!? For regular News updates go to http://in.news.yahoo.com From owner-mpls@UU.NET Wed May 9 13:15:00 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17809 for ; Wed, 9 May 2001 13:15:00 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohg04088; Wed, 9 May 2001 17:14:09 GMT Received: by mail-control.mail.uu.net id QQkohg29493 for mpls-outgoing; Wed, 9 May 2001 17:13:30 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkohg29360 for ; Wed, 9 May 2001 17:13:12 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohg04636 for ; Wed, 9 May 2001 17:12:46 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkohg06990 for ; Wed, 9 May 2001 17:12:45 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA17363; Wed, 9 May 2001 13:06:59 -0400 (EDT) Subject: Re: RSVP hello message To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Wed, 9 May 2001 13:07:23 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/09/2001 01:07:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Thanks for your reply. Please see my comments. >>RSVP must not be run synchronously. >>If a Path message is sent out, it MUST NOT block waiting for a Resv to >>come back. It may receive a thousand other Path messages before then, >>and it can't block them all. [Julia] I was confused. Ingress is the one which sends out Path message, and LSR will just forward the Path message sent from Ingress to Egress. In your email, you mentioned that "It may receive a thousand other Path messages before then", what does that mean? >>Since Hello messages are not dependant on any RSVP state, it should be >>possible to handle them as they arrive, without regard for what other >>messages may or may not have been received. >>Keep in mind that if you delay responding to a Hello message, your >>neighbor may decide that you have reset, tearing down all your >>sessions. If the draft's recommended interval/multiple for Hello is in >>use, you will only have 17.5ms to get your response out. [Julia] I agree with you. Hello request message should be responsed as soon as possible since the neighbour may tear down the session after the Hello interval. [Julia] So I think if the Ingress sends out the Path message, and before the Resv message back from the Egress router, if there is a Hello request message sent from the neighbour, it should send out Hello ACK message back and then wait the Resv back from Egress. I hope I understand correctly. Julia From owner-mpls@UU.NET Wed May 9 13:24:38 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18206 for ; Wed, 9 May 2001 13:24:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohh17011; Wed, 9 May 2001 17:24:28 GMT Received: by mail-control.mail.uu.net id QQkohh01192 for mpls-outgoing; Wed, 9 May 2001 17:23:50 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohh01184 for ; Wed, 9 May 2001 17:23:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohh02971 for ; Wed, 9 May 2001 17:20:46 GMT From: djoyal@quantumbridge.com Received: from quantumexch.qb.local by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: gatekeeper.quantumbridge.com [63.165.82.130]) id QQkohh15952 for ; Wed, 9 May 2001 17:20:46 GMT Received: by quantumexch.qb.local with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 13:12:15 -0400 Message-ID: <36FB26FEDE20D511BA9C00508BE050B47DC540@quantumexch.qb.local> To: afarrel@movaz.com, mpls@UU.NET, ccamp@ops.ietf.org Subject: RE: GMPLS TE MIB Date: Wed, 9 May 2001 13:12:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Hi Adrian, The SYNTAX of the MplsGeneralizedLabel TC specifies a fixed length of 64 bits. This conflicts with the GMPLS functional specification which defines a generalized label as being of variable length. The SYNTAX is inconsistent with the length of the Waveband label, for example. -Dan -----Original Message----- From: Adrian Farrel [mailto:afarrel@movaz.com] Sent: Wednesday, May 09, 2001 10:06 AM To: mpls@UU.NET; ccamp@ops.ietf.org Subject: GMPLS TE MIB We have submitted a draft to extend the TE-MIB to support GMPLS. This is available at http://search.ietf.org/internet-drafts/draft-nadeau-mpls-gmp ls-te-mib-00.txt We would welcome your thoughts and comments Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com From owner-mpls@UU.NET Wed May 9 13:26:15 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18245 for ; Wed, 9 May 2001 13:26:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohh18437; Wed, 9 May 2001 17:25:34 GMT Received: by mail-control.mail.uu.net id QQkohh01202 for mpls-outgoing; Wed, 9 May 2001 17:24:09 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohh01194 for ; Wed, 9 May 2001 17:23:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohh02807 for ; Wed, 9 May 2001 17:20:43 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkohh12491 for ; Wed, 9 May 2001 17:20:43 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA18927 for mpls@uu.net; Wed, 9 May 2001 13:20:42 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohh00906 for ; Wed, 9 May 2001 17:20:05 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohh00107 for ; Wed, 9 May 2001 17:19:49 GMT Received: from lohi.eng.telia.fi by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: lohi.eng.telia.fi [195.10.149.18]) id QQkohh11357 for ; Wed, 9 May 2001 17:19:48 GMT Received: (from jh@localhost) by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f49HJcQ05132; Wed, 9 May 2001 20:19:38 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15097.31785.760891.353537@lohi.eng.telia.fi> Date: Wed, 9 May 2001 20:19:37 +0300 (EEST) To: "Jay Wang" Cc: "'mpls@uu.net'" , Subject: RE: QoS in Shared Media In-Reply-To: References: <15095.35863.76753.616693@lohi.eng.telia.fi> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Jay Wang writes: > >according to your definition even atm supports diffserv since one can > >always use cbr vcs between routers and then let the routers do the > >proper queueing. for several reasons this is not a good idea. > > I that case, would you mind elaborating your concerns? the idea behind diffserv is that each traffic is allocated a certain amount of aggregate resources (buffer space and bandwidth) at each diffserv (l2 or l3) node. traffic between a pair of edge routers belonging to a given class thus shares the resources at each node with all other traffic in that class. a cbr vc or other kind of "leased line" between the routers would reserve the resources for that pair instead of the whole aggregate. -- juha From owner-mpls@UU.NET Wed May 9 13:32:08 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18497 for ; Wed, 9 May 2001 13:32:02 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohi27934; Wed, 9 May 2001 17:30:50 GMT Received: by mail-control.mail.uu.net id QQkohi03132 for mpls-outgoing; Wed, 9 May 2001 17:30:18 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohi03104 for ; Wed, 9 May 2001 17:30:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohh28514 for ; Wed, 9 May 2001 17:29:43 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkohh26514 for ; Wed, 9 May 2001 17:29:43 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11089 for ; Wed, 9 May 2001 13:29:40 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08654 for ; Wed, 9 May 2001 13:29:41 -0400 (EDT) Message-ID: <3AF97E98.4C1F888A@marconi.com> Date: Wed, 09 May 2001 13:30:01 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: disconnect connection References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > Hope I understand correctly. > > 1. If Ingress sends out Path, and Egress sends back Resv, the LSP > is established. If Ingress wants to tear down the connection, > Ingress sends out PathTear to tear down connection. Yes. > 2. If Egress sends out Path message, but no Resv back from Egress > router, the Egress should send out PathTear to clear the path state. This makes absolutely no sense whatsoever. The egress node can't send out a Path message. Where do you think it is going to send this message to? > 3. If Egress or LSR find there is failure, they will send out > ResvErr, and Ingress send out PathTear to tear down the connection > (basically clear the path and resv state). Yes. Failures are reported with error messages. Teardowns should be initiated by the ingress. The only exception being when it is known that the ingress's tear message can't get through, and that it will be torn anyway. (eg. the node just downstream of a link failure.) > Anyway Ingress is the one which will tear down the connection if > there is one. If the connection has not set up yet, for example, > there is no Resv back after Path message was sent out, Ingress > still need to send out PathTear to clear the Path state. Yes. -- David From owner-mpls@UU.NET Wed May 9 13:36:35 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18631 for ; Wed, 9 May 2001 13:36:30 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohi04221; Wed, 9 May 2001 17:36:03 GMT Received: by mail-control.mail.uu.net id QQkohi04374 for mpls-outgoing; Wed, 9 May 2001 17:35:27 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkohi04290 for ; Wed, 9 May 2001 17:35:09 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkohi28527 for ; Wed, 9 May 2001 17:34:19 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkohi03567 for ; Wed, 9 May 2001 17:34:19 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id NAA11029; Wed, 9 May 2001 13:31:36 -0400 (EDT) Subject: Re: disconnect connection To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Wed, 9 May 2001 13:32:00 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/09/2001 01:32:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Hope I understand correctly. 1. If Ingress sends out Path, and Egress sends back Resv, the LSP is established. If Ingress wants to tear down the connection, Ingress sends out PathTear to tear down connection. 2. If Egress sends out Path message, but no Resv back from Egress router, the Egress should send out PathTear to clear the path state. 3. If Egress or LSR find there is failure, they will send out ResvErr, and Ingress send out PathTear to tear down the connection(basically clear the path and resv state). Anyway Ingress is the one which will tear down the connection if there is one. If the connection has not set up yet, for example, there is no Resv back after Path message was sent out, Ingress still need to send out PathTear to clear the Path state. Thanks, Julia David Charlap on 05/07/2001 04:03:21 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: disconnect connection Hong Liao wrote: > > I have questions for disconnecting(clear connection). > > 1. Suppose LSR received Path message from Ingress router, and LSR > sent out Resv message back. If the LSR wanted to tear down this > session, it will send out ResvTear to Ingress router, and Ingress > router will take out the Resv state of LSR, and do not response > back anything, this session will be ended. I may wrong. First of all, only an egress router should be generating ResvTear messages, unless there's a failure somewhere. (In which case, various PathErr and ResvErr messages should also be generated.) A transit router should not arbitrarily go around sending out teardown messages. As a matter of fact, in the case of MPLS, since LSP creation is driven by the ingress router, only the ingress router should be doing any kind of tearing (not counting cleanup after failures.) The ingress router, of course, can not generate a ResvTear, because it won't go anywhere. It will send a PathTear when it wants to destroy the LSP. If an egress router sends ResvTear, the reservation will be removed. If the ingress router doesn't subsequently tear the Path, however, the Path state will remain in the network. This will waste bandwidth due to the refreshes for the unused state. It may also result in wasted resources, since some switches may allocate resources during Path processing. If a transit router tries to do this, it's even worse. You end up with leftover Path state everywhere, and leftover reservations downstream of that transit router. In general, ResvTear is not used in MPLS, except possibly in conjunction with PathErr messages. There is no reason for a non- ingress router to tear an LSP except in the face of failures. > 2. another way round, if there is LSR and it forwarded Path message > to Egress router, and Egress router sent back Resv message to LSR, > suppose the LSR wants to tear down this session, it will send out > the PathTear to the Egress router, and Egress router will move the > Path state of LSR, do not response anything, this session is ended. > Did I understand correct? This is how an ingress router will tear an LSP. If some router other than ingress does this, however, you will wind up with leftover Path state in all routers upstream of the LSR. And until the Resv state times out, there will be leftover reservations on those nodes as well. > 3. If the Ingress router sends out the Path message, but the no Resv > message sent back from LSR, does Ingress router need to send out > PathTear to clear the path state in case that this Path state has > already been sent there. Yes. Path state (and all of the Path refreshing) will remain in place forever if it is not torn down. > 4. How about the transit router to try to clear/tear down the > session? This should only happen if there is a failure (or perhaps preemption.) In which case, it should send a PathErr upstream. The ingress router, upon receiving this, may then choose to tear the LSP by sending a PathTear message. If the failure is a broken link (where the attached router knows that a PathTear message can't get through to the downstream nodes), the Path state will timeout (due to lack of refreshes on that interface), resulting in the eventual transmission of PathTear. The router should probably choose to immediately send the PathTear as an optimization (since a link failure will result in the nodes upstream of the failure tearing the state), but this isn't a hard requirement. -- David From owner-mpls@UU.NET Wed May 9 13:41:18 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18793 for ; Wed, 9 May 2001 13:41:13 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohi08607; Wed, 9 May 2001 17:40:56 GMT Received: by mail-control.mail.uu.net id QQkohi06020 for mpls-outgoing; Wed, 9 May 2001 17:40:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohi06001 for ; Wed, 9 May 2001 17:40:19 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohi28843 for ; Wed, 9 May 2001 17:39:59 GMT Received: from mailgate.pit.comms.marconi.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailgate.pit.comms.marconi.com [169.144.68.6]) id QQkohi09288 for ; Wed, 9 May 2001 17:39:59 GMT Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12290 for ; Wed, 9 May 2001 13:39:56 -0400 (EDT) Received: from marconi.com (dcharlap-pc.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11842 for ; Wed, 9 May 2001 13:39:57 -0400 (EDT) Message-ID: <3AF98101.D011B870@marconi.com> Date: Wed, 09 May 2001 13:40:17 -0400 From: David Charlap X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: mpls@UU.NET Subject: Re: RSVP hello message References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hong Liao wrote: > > [Julia] I was confused. Ingress is the one which sends out Path > message, and LSR will just forward the Path message sent from > Ingress to Egress. You do not understand how RSVP operates. Transit routers do NOT just forward Path messages. They must intercept the messages (which is why the router-alert option is used), establish path state, and then generate a new Path message (which will not be identical to the one it received) to send downstream. > In your email, you mentioned that "It may receive a thousand other > Path messages before then", what does that mean? Isn't this obvious to you? A transit router doesn't work with just one LSP. A network may try to establish thousands of LSPs through a transit router. If you receive a Path, and then block the entire router waiting for the matching Resv (as your comment about Hello messages seems to imly), you will destroy the entire network's performance. It is quite possible that you can receive thousands of Path messages - corresponding to thousands of LSPs - before you receive your first Resv message. > [Julia] So I think if the Ingress sends out the Path message, and > before the Resv message back from the Egress router, if there is a > Hello request message sent from the neighbour, it should send out > Hello ACK message back and then wait the Resv back from Egress. I > hope I understand correctly. Your router shouldn't be _waiting_ for anything. It should handle every message as it arrives. If the proper handling means establishing partial state, pending receipt of another message, then so be it. It is always wrong for a router to halt awaiting some specific kind of packet. If the reason for this is not obvious to you, please arrange a meeting with an engineer at your own site. This is all very basic information that everybody developing router software should know. -- David From owner-mpls@UU.NET Wed May 9 13:43:13 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18925 for ; Wed, 9 May 2001 13:43:08 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohi11637; Wed, 9 May 2001 17:42:55 GMT Received: by mail-control.mail.uu.net id QQkohi06572 for mpls-outgoing; Wed, 9 May 2001 17:42:24 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkohi06517 for ; Wed, 9 May 2001 17:42:16 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohi07762 for ; Wed, 9 May 2001 17:40:43 GMT Received: from web8003.mail.in.yahoo.com by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: web8003.in.yahoo.com [203.199.70.21]) id QQkohi08260 for ; Wed, 9 May 2001 17:40:42 GMT Message-ID: <20010509174339.4976.qmail@web8003.mail.in.yahoo.com> Received: from [169.144.84.57] by web8003.mail.in.yahoo.com; Wed, 09 May 2001 18:43:39 BST Date: Wed, 9 May 2001 18:43:39 +0100 (BST) From: =?iso-8859-1?q?Shankar?= Subject: Re: disconnect connection To: Hong Liao , David Charlap Cc: mpls@UU.NET In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit --- Hong Liao wrote: > > David, > > Hope I understand correctly. > > 1. If Ingress sends out Path, and Egress sends back > Resv, the LSP is > established. If Ingress wants to tear down the > connection, Ingress sends > out PathTear to tear down connection. > Correct. > 2. If Egress sends out Path message, but no Resv > back from Egress router, > the Egress should send out PathTear to clear the > path state. > Is it "Ingress sends out Path message" ..... "Egress should send out PathTear" ..? > 3. If Egress or LSR find there is failure, they > will send out ResvErr, and > Ingress send out PathTear to tear down the > connection(basically clear the > path and resv state). > > Anyway Ingress is the one which will tear down the > connection if there is > one. If the connection has not set up yet, for > example, there is no Resv > back after Path message was sent out, Ingress still > need to send out > PathTear to clear the Path state. Here, you have it right. shankar > > Thanks, > > Julia > > > > > > David Charlap on > 05/07/2001 04:03:21 PM > > To: mpls@UU.NET > cc: (bcc: Hong Liao/Telcordia) > Subject: Re: disconnect connection > > > > Hong Liao wrote: > > > > I have questions for disconnecting(clear > connection). > > > > 1. Suppose LSR received Path message from Ingress > router, and LSR > > sent out Resv message back. If the LSR wanted to > tear down this > > session, it will send out ResvTear to Ingress > router, and Ingress > > router will take out the Resv state of LSR, and do > not response > > back anything, this session will be ended. I may > wrong. > > First of all, only an egress router should be > generating ResvTear > messages, unless there's a failure somewhere. (In > which case, various > PathErr and ResvErr messages should also be > generated.) A transit > router should not arbitrarily go around sending out > teardown messages. > > As a matter of fact, in the case of MPLS, since LSP > creation is driven > by the ingress router, only the ingress router > should be doing any kind > of tearing (not counting cleanup after failures.) > The ingress router, > of course, can not generate a ResvTear, because it > won't go anywhere. > It will send a PathTear when it wants to destroy the > LSP. > > If an egress router sends ResvTear, the reservation > will be removed. If > the ingress router doesn't subsequently tear the > Path, however, the Path > state will remain in the network. This will waste > bandwidth due to the > refreshes for the unused state. It may also result > in wasted resources, > since some switches may allocate resources during > Path processing. > > If a transit router tries to do this, it's even > worse. You end up with > leftover Path state everywhere, and leftover > reservations downstream of > that transit router. > > In general, ResvTear is not used in MPLS, except > possibly in conjunction > with PathErr messages. There is no reason for a > non- ingress router to > tear an LSP except in the face of failures. > > > 2. another way round, if there is LSR and it > forwarded Path message > > to Egress router, and Egress router sent back Resv > message to LSR, > > suppose the LSR wants to tear down this session, > it will send out > > the PathTear to the Egress router, and Egress > router will move the > > Path state of LSR, do not response anything, this > session is ended. > > Did I understand correct? > > This is how an ingress router will tear an LSP. > > If some router other than ingress does this, > however, you will wind up > with leftover Path state in all routers upstream of > the LSR. And until > the Resv state times out, there will be leftover > reservations on those > nodes as well. > > > 3. If the Ingress router sends out the Path > message, but the no Resv > > message sent back from LSR, does Ingress router > need to send out > > PathTear to clear the path state in case that > this Path state has > > already been sent there. > > Yes. Path state (and all of the Path refreshing) > will remain in place > forever if it is not torn down. > > > 4. How about the transit router to try to > clear/tear down the > > session? > > This should only happen if there is a failure (or > perhaps preemption.) > > In which case, it should send a PathErr upstream. > The ingress router, > upon receiving this, may then choose to tear the LSP > by sending a > PathTear message. > > If the failure is a broken link (where the attached > router knows that a > PathTear message can't get through to the downstream > nodes), the Path > state will timeout (due to lack of refreshes on that > interface), > resulting in the eventual transmission of PathTear. > > The router should probably choose to immediately > send the PathTear as an > optimization (since a link failure will result in > the nodes upstream of > the failure tearing the state), but this isn't a > hard requirement. > > -- David > > > > ____________________________________________________________ Do You Yahoo!? For regular News updates go to http://in.news.yahoo.com From owner-mpls@UU.NET Wed May 9 13:45:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19082 for ; Wed, 9 May 2001 13:45:53 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohj16156; Wed, 9 May 2001 17:45:26 GMT Received: by mail-control.mail.uu.net id QQkohi07367 for mpls-outgoing; Wed, 9 May 2001 17:44:51 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkohi07326 for ; Wed, 9 May 2001 17:44:43 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohi14518 for ; Wed, 9 May 2001 17:43:45 GMT From: wesam.alanqar@mail.sprint.com Received: from damgwp01.corp.sprint.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: parker2.sprint.com [199.14.91.106]) id QQkohi12956 for ; Wed, 9 May 2001 17:43:44 GMT Received: from kcmgwp02.corp.sprint.com (kcmgwp02 [10.185.6.93]) by damgwp01.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f49HsmF01289; Wed, 9 May 2001 12:54:48 -0500 (CDT) Received: from kcopmp02.corp.sprint.com (kcopmp02m.corp.sprint.com [10.74.2.73]) by kcmgwp02.corp.sprint.com (Switch-2.0.2/Switch-2.0.2) with ESMTP id f49Hhhj12180; Wed, 9 May 2001 12:43:43 -0500 (CDT) Received: from localhost (root@localhost) by kcopmp02.corp.sprint.com (8.8.6 (PHNE_17190)/8.8.6) with ESMTP id MAA22407; Wed, 9 May 2001 12:43:43 -0500 (CDT) X-OpenMail-Hops: 1 Date: Wed, 9 May 2001 12:43:42 -0500 Message-Id: Subject: Status of draf-stdenis-ms-over-mpls-00 MIME-Version: 1.0 TO: mpls@UU.NET CC: pwe3@ietf.org Content-Type: multipart/mixed; boundary="openmail-part-225174ca-00000001" Sender: owner-mpls@UU.NET Precedence: bulk --openmail-part-225174ca-00000001 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline ;Creation-Date="Wed, 9 May 2001 12:43:42 -0500" Content-Transfer-Encoding: 8bit Can any body update me with the status of draft-stdenis-ms-over-mpls-00? Any cooperation with Martini drafts? Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Research Group (TR) Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --openmail-part-225174ca-00000001 Content-Type: application/octet-stream Content-Disposition: attachment; filename="Wesam Alanqar (E-mail).vcf" ;Creation-Date="Wed, 9 May 2001 12:43:42 -0500" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --openmail-part-225174ca-00000001-- From owner-mpls@UU.NET Wed May 9 14:56:06 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21453 for ; Wed, 9 May 2001 14:56:06 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohn21314; Wed, 9 May 2001 18:55:03 GMT Received: by mail-control.mail.uu.net id QQkohn03303 for mpls-outgoing; Wed, 9 May 2001 18:54:33 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkohn03298 for ; Wed, 9 May 2001 18:54:27 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkohn19847 for ; Wed, 9 May 2001 18:52:57 GMT Received: from exchange01.movaz.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.82.134]) id QQkohn19119 for ; Wed, 9 May 2001 18:52:57 GMT Received: from BLIULAPTOP ([64.47.72.35]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Wed, 9 May 2001 14:50:00 -0400 Message-ID: <007c01c0d8b8$d9c8c710$23482f40@movaz.com> From: "Adrian Farrel" To: , , Cc: "Edward Harrison" , , "Thomas D. Nadeau" , , References: <36FB26FEDE20D511BA9C00508BE050B47DC540@quantumexch.qb.local> Subject: Re: GMPLS TE MIB Date: Wed, 9 May 2001 14:49:56 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 09 May 2001 18:50:00.0736 (UTC) FILETIME=[D9E10A00:01C0D8B8] Sender: owner-mpls@UU.NET Precedence: bulk Thanks Dan, Yes, we're aware of this issue and are discussing it. The current 64 bit field is something of a place holder. Our concerns are - to allow flexible configuration of different label types - to keep the MIB from sprawling - to arrive at a label type that can be used to index a GMPLS LSR MIB Best regards, Adrian -- Adrian Farrel Movaz Networks Inc. afarrel@movaz.com ----- Original Message ----- From: To: ; ; Sent: Wednesday, May 09, 2001 1:12 PM Subject: RE: GMPLS TE MIB > Hi Adrian, > > The SYNTAX of the MplsGeneralizedLabel TC specifies a fixed length of > 64 bits. This conflicts with the GMPLS functional specification which > defines a generalized label as being of variable length. The SYNTAX > is inconsistent with the length of the Waveband label, for example. > > -Dan From owner-mpls@UU.NET Wed May 9 15:09:14 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21908 for ; Wed, 9 May 2001 15:09:14 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoho24508; Wed, 9 May 2001 19:08:32 GMT Received: by mail-control.mail.uu.net id QQkoho15424 for mpls-outgoing; Wed, 9 May 2001 19:07:59 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoho15227 for ; Wed, 9 May 2001 19:07:42 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoho10352 for ; Wed, 9 May 2001 19:07:36 GMT Received: from dnsmx1rrc.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1rrc.telcordia.com [128.96.20.41]) id QQkoho23292 for ; Wed, 9 May 2001 19:07:36 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.3) with ESMTP id PAA05528; Wed, 9 May 2001 15:03:23 -0400 (EDT) Subject: Re: disconnect connection To: David Charlap Cc: mpls@UU.NET From: "Hong Liao" Date: Wed, 9 May 2001 15:03:47 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/09/2001 03:03:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk David, Sorry to confuse you. For the second question, I mean the Ingress will send out the PathTear message out. Julia David Charlap on 05/09/2001 01:30:01 PM To: mpls@UU.NET cc: (bcc: Hong Liao/Telcordia) Subject: Re: disconnect connection Hong Liao wrote: > > Hope I understand correctly. > > 1. If Ingress sends out Path, and Egress sends back Resv, the LSP > is established. If Ingress wants to tear down the connection, > Ingress sends out PathTear to tear down connection. Yes. > 2. If Egress sends out Path message, but no Resv back from Egress > router, the Egress should send out PathTear to clear the path state. This makes absolutely no sense whatsoever. The egress node can't send out a Path message. Where do you think it is going to send this message to? > 3. If Egress or LSR find there is failure, they will send out > ResvErr, and Ingress send out PathTear to tear down the connection > (basically clear the path and resv state). Yes. Failures are reported with error messages. Teardowns should be initiated by the ingress. The only exception being when it is known that the ingress's tear message can't get through, and that it will be torn anyway. (eg. the node just downstream of a link failure.) > Anyway Ingress is the one which will tear down the connection if > there is one. If the connection has not set up yet, for example, > there is no Resv back after Path message was sent out, Ingress > still need to send out PathTear to clear the Path state. Yes. -- David From owner-mpls@UU.NET Wed May 9 15:30:55 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22519 for ; Wed, 9 May 2001 15:30:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohq21137; Wed, 9 May 2001 19:30:36 GMT Received: by mail-control.mail.uu.net id QQkohq26261 for mpls-outgoing; Wed, 9 May 2001 19:30:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkohp26222 for ; Wed, 9 May 2001 19:29:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohp04148 for ; Wed, 9 May 2001 19:28:28 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkohp26115 for ; Wed, 9 May 2001 19:28:28 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id PAA03991 for mpls@uu.net; Wed, 9 May 2001 15:28:28 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkohp24134 for ; Wed, 9 May 2001 19:15:07 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoho00066 for ; Wed, 9 May 2001 19:13:37 GMT Received: from father.pmc-sierra.bc.ca by cmr1.ash.ops.us.uu.net with SMTP (peer crosschecked as: father.pmc-sierra.bc.ca [216.241.224.13]) id QQkoho14321 for ; Wed, 9 May 2001 19:13:37 GMT Received: (qmail 4682 invoked by uid 104); 9 May 2001 19:13:36 -0000 Received: from Shahram_Davari@pmc-sierra.com by father with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.433974 secs); 09/05/2001 12:13:36 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by father.pmc-sierra.bc.ca with SMTP; 9 May 2001 19:13:35 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f49JDZ111255 for ; Wed, 9 May 2001 12:13:35 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 12:16:16 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C38@BBY1EXM01> From: Shahram Davari To: "'mpls@uu.net'" Subject: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 12:16:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D8BC.84359810" Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0D8BC.84359810 Content-Type: text/plain; charset="iso-8859-1" Hi, In an BGP/MPLS VPN scenario if a CE router sends an MPLS packet rather than an IP packet to a PE router, the PE router should still push 2 labels. My question is, should the PE router swap the customer's label too or leave it unchanged? Yours, -Shahram ------_=_NextPart_000_01C0D8BC.84359810 Content-Type: application/octet-stream; name="Shahram Davari.vcf" Content-Disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD ------_=_NextPart_000_01C0D8BC.84359810-- From owner-mpls@UU.NET Wed May 9 15:56:09 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23124 for ; Wed, 9 May 2001 15:56:04 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohr21700; Wed, 9 May 2001 19:55:44 GMT Received: by mail-control.mail.uu.net id QQkohr29024 for mpls-outgoing; Wed, 9 May 2001 19:54:52 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkohr29015 for ; Wed, 9 May 2001 19:54:44 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohr04804 for ; Wed, 9 May 2001 19:54:15 GMT Received: from nfl.METERA.COM by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: nfl.metera.com [63.114.212.50]) id QQkohr19871 for ; Wed, 9 May 2001 19:54:15 GMT Received: from slapshot.metera.com ([12.19.1.154]) by nfl.METERA.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J452X6GB; Wed, 9 May 2001 14:55:14 -0500 Received: from nyknicks.metera.com (nyknicks [12.19.1.5]) by slapshot.metera.com (8.9.3+Sun/8.9.1) with ESMTP id OAA06856 for ; Wed, 9 May 2001 14:54:14 -0500 (CDT) Received: from metera.com (localhost [127.0.0.1]) by nyknicks.metera.com (8.9.3+Sun/8.9.1) with ESMTP id OAA24708 for ; Wed, 9 May 2001 14:54:12 -0500 (CDT) Message-ID: <3AF9A064.8EB44E48@metera.com> Date: Wed, 09 May 2001 14:54:12 -0500 From: Gopal Jayaraman Organization: Metera Networks X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: "'mpls@uu.net'" Subject: Re: BGP/MPLS VPN PE LSR References: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C38@BBY1EXM01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit shahram, the PE that is connected to the final CE, uses the second label to identify which CE/CE port it has to be deliverd. The whole mpls header is trimmed before delivering to CE. Once the CE port is identified, packet is deliverd as raw IPv4 to the CE by the PE. The second label is not looked up by any of the intermediate P nodes. PE is typically a egress node. -Gopal. Shahram Davari wrote: > > Hi, > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS packet rather than an IP packet to a PE router, the PE router should still push 2 labels. My question is, should the PE router swap the customer's label too or leave it unchanged? > > Yours, > -Shahram From owner-mpls@UU.NET Wed May 9 16:08:12 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23396 for ; Wed, 9 May 2001 16:08:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohs11763; Wed, 9 May 2001 20:07:06 GMT Received: by mail-control.mail.uu.net id QQkohs10545 for mpls-outgoing; Wed, 9 May 2001 20:06:23 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohs10412 for ; Wed, 9 May 2001 20:06:07 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohs23700 for ; Wed, 9 May 2001 20:04:26 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkohs08717 for ; Wed, 9 May 2001 20:04:25 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA08415 for mpls@uu.net; Wed, 9 May 2001 16:04:25 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohs00118 for ; Wed, 9 May 2001 20:00:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohr07874 for ; Wed, 9 May 2001 19:59:02 GMT Received: from mother.pmc-sierra.bc.ca by cmr2.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkohr02423 for ; Wed, 9 May 2001 19:59:02 GMT Received: (qmail 5125 invoked by uid 104); 9 May 2001 19:59:01 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.413023 secs); 09/05/2001 12:59:00 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 9 May 2001 19:59:00 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f49Jx0117942; Wed, 9 May 2001 12:59:00 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 13:01:41 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C3A@BBY1EXM01> From: Shahram Davari To: "'Gopal Jayaraman'" Cc: "'mpls@uu.net'" Subject: RE: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 13:01:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk Hi Gopal, But I was talking of having 3 labels. The bottom most label belonging to the customer, the second label being the VPN label and the top label being the MPLS routing label. Does the PE swap the bottom most label? -Shahram > -----Original Message----- > From: Gopal Jayaraman [mailto:Gopal.Jayaraman@metera.com] > Sent: Wednesday, May 09, 2001 3:53 PM > To: Shahram Davari > Subject: Re: BGP/MPLS VPN PE LSR > > > shahram, > > the PE that is connected to the final CE, uses the second label > to identify which CE/CE port it has to be deliverd. The whole mpls > header is trimmed before delivering to CE. > > Once the CE port is identified, packet is deliverd as raw IPv4 to > the CE by the PE. The second label is not looked up by any of the > intermediate P nodes. PE is typically a egress node. > > > -Gopal. > > Shahram Davari wrote: > > > > Hi, > > > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > packet rather than an IP packet to a PE router, the PE router > should still push 2 labels. My question is, should the PE > router swap the customer's label too or leave it unchanged? > > > > Yours, > > -Shahram > From owner-mpls@UU.NET Wed May 9 16:25:49 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23794 for ; Wed, 9 May 2001 16:25:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohm29103; Wed, 9 May 2001 18:33:16 GMT Received: by mail-control.mail.uu.net id QQkohm01220 for mpls-outgoing; Wed, 9 May 2001 18:32:44 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkohm01207 for ; Wed, 9 May 2001 18:32:31 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkohm01493 for ; Wed, 9 May 2001 18:31:59 GMT Received: from sandmail.sandburst.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sandburst-gw.bstn-gw02.ma.us.intelilink.net [216.57.129.34]) id QQkohm26285 for ; Wed, 9 May 2001 18:31:59 GMT Received: from sandburst.com (pediment.sandburst.com [172.16.5.210]) by sandmail.sandburst.com (Postfix) with ESMTP id ABA9F94006; Wed, 9 May 2001 14:31:54 -0400 (EDT) Message-ID: <3AF98D1A.7D30FAC3@sandburst.com> Date: Wed, 09 May 2001 14:31:54 -0400 From: Eric Gray X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Shankar Cc: Hong Liao , David Charlap , mpls@UU.NET Subject: Re: disconnect connection References: <20010509174339.4976.qmail@web8003.mail.in.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Julia/Shankar, Between the two of you and David Charlap, it was writ: > --- Hong Liao wrote: > > > David, > > > > Hope I understand correctly. > > > > 1. If Ingress sends out Path, and Egress sends back > > Resv, the LSP is > > established. If Ingress wants to tear down the > > connection, Ingress sends > > out PathTear to tear down connection. > > > Correct. Not quite. When the Ingress sends Path and receives Resv, the LSP is established. The Ingress may tear down the LSP by sending PathTear because this forcibly removes Path state associated with the LSP. Alternatively, the ingress may simply not send further Path messages for this LSP - but, while this will work, it is a substantially suboptimal approach. > > > 2. If Egress sends out Path message, but no Resv > > back from Egress router, > > the Egress should send out PathTear to clear the > > path state. > > > Is it "Ingress sends out Path message" ..... > "Egress should send out PathTear" ..? At some point, the ingress may become disinterested in using an LSP should it ever be setup. At that point the ingress will stop trying to set it up and should forcibly remove Path state downstream. This frees up resources for the next LSR that wants to wait for an LSP to be established. > > > > 3. If Egress or LSR find there is failure, they > > will send out ResvErr, and > > Ingress send out PathTear to tear down the > > connection(basically clear the > > path and resv state). > > > > Anyway Ingress is the one which will tear down the > > connection if there is > > one. If the connection has not set up yet, for > > example, there is no Resv > > back after Path message was sent out, Ingress still > > need to send out > > PathTear to clear the Path state. > > Here, you have it right. Except that the term 'need' is not consisten with the the use of the word SHOULD. The ingress can cease to exist and the LSP will still be torn down and Path state will still be removed. > > shankar > > > > Thanks, > > > > Julia > > > > > > > > > > > > David Charlap on > > 05/07/2001 04:03:21 PM > > > > To: mpls@UU.NET > > cc: (bcc: Hong Liao/Telcordia) > > Subject: Re: disconnect connection > > > > > > > > Hong Liao wrote: > > > > > > I have questions for disconnecting(clear > > connection). > > > > > > 1. Suppose LSR received Path message from Ingress > > router, and LSR > > > sent out Resv message back. If the LSR wanted to > > tear down this > > > session, it will send out ResvTear to Ingress > > router, and Ingress > > > router will take out the Resv state of LSR, and do > > not response > > > back anything, this session will be ended. I may > > wrong. > > > > First of all, only an egress router should be > > generating ResvTear > > messages, unless there's a failure somewhere. (In > > which case, various > > PathErr and ResvErr messages should also be > > generated.) A transit > > router should not arbitrarily go around sending out > > teardown messages. > > > > As a matter of fact, in the case of MPLS, since LSP > > creation is driven > > by the ingress router, only the ingress router > > should be doing any kind > > of tearing (not counting cleanup after failures.) > > The ingress router, > > of course, can not generate a ResvTear, because it > > won't go anywhere. > > It will send a PathTear when it wants to destroy the > > LSP. > > > > If an egress router sends ResvTear, the reservation > > will be removed. If > > the ingress router doesn't subsequently tear the > > Path, however, the Path > > state will remain in the network. This will waste > > bandwidth due to the > > refreshes for the unused state. It may also result > > in wasted resources, > > since some switches may allocate resources during > > Path processing. > > > > If a transit router tries to do this, it's even > > worse. You end up with > > leftover Path state everywhere, and leftover > > reservations downstream of > > that transit router. > > > > In general, ResvTear is not used in MPLS, except > > possibly in conjunction > > with PathErr messages. There is no reason for a > > non- ingress router to > > tear an LSP except in the face of failures. > > > > > 2. another way round, if there is LSR and it > > forwarded Path message > > > to Egress router, and Egress router sent back Resv > > message to LSR, > > > suppose the LSR wants to tear down this session, > > it will send out > > > the PathTear to the Egress router, and Egress > > router will move the > > > Path state of LSR, do not response anything, this > > session is ended. > > > Did I understand correct? > > > > This is how an ingress router will tear an LSP. > > > > If some router other than ingress does this, > > however, you will wind up > > with leftover Path state in all routers upstream of > > the LSR. And until > > the Resv state times out, there will be leftover > > reservations on those > > nodes as well. > > > > > 3. If the Ingress router sends out the Path > > message, but the no Resv > > > message sent back from LSR, does Ingress router > > need to send out > > > PathTear to clear the path state in case that > > this Path state has > > > already been sent there. > > > > Yes. Path state (and all of the Path refreshing) > > will remain in place > > forever if it is not torn down. > > > > > 4. How about the transit router to try to > > clear/tear down the > > > session? > > > > This should only happen if there is a failure (or > > perhaps preemption.) > > > > In which case, it should send a PathErr upstream. > > The ingress router, > > upon receiving this, may then choose to tear the LSP > > by sending a > > PathTear message. > > > > If the failure is a broken link (where the attached > > router knows that a > > PathTear message can't get through to the downstream > > nodes), the Path > > state will timeout (due to lack of refreshes on that > > interface), > > resulting in the eventual transmission of PathTear. > > > > The router should probably choose to immediately > > send the PathTear as an > > optimization (since a link failure will result in > > the nodes upstream of > > the failure tearing the state), but this isn't a > > hard requirement. > > > > -- David > > > > > > > > > > ____________________________________________________________ > Do You Yahoo!? > For regular News updates go to http://in.news.yahoo.com From owner-mpls@UU.NET Wed May 9 16:27:59 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23856 for ; Wed, 9 May 2001 16:27:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoht05188; Wed, 9 May 2001 20:27:20 GMT Received: by mail-control.mail.uu.net id QQkoht21462 for mpls-outgoing; Wed, 9 May 2001 20:26:50 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoht21432 for ; Wed, 9 May 2001 20:26:25 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoht25265 for ; Wed, 9 May 2001 20:25:19 GMT Received: from abel.senecanetworks.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: abel.senecanetworks.com [63.97.216.18]) id QQkoht02841 for ; Wed, 9 May 2001 20:25:18 GMT Received: (from root@localhost) by abel.senecanetworks.com (8.9.3/8.99.99) id LAA14626; Wed, 9 May 2001 11:28:41 -0500 Received: from vsharmapc ([10.0.1.238]) by abel.senecanetworks.com (8.9.3/8.9.3) with SMTP id LAA14570; Wed, 9 May 2001 11:28:41 -0500 From: "Vipul Sharma" To: "'Gopal Jayaraman'" Cc: "'mpls@uu.net'" Subject: RE: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 16:25:58 -0400 Message-ID: <01b501c0d8c6$42780520$ee01000a@vsharmapc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3AF9A064.8EB44E48@metera.com> X-scanner: echelon Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Guys, What is a PE and CE router?? .... Thanx. Vip -----Original Message----- From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Gopal Jayaraman Sent: Wednesday, May 09, 2001 3:54 PM Cc: 'mpls@uu.net' Subject: Re: BGP/MPLS VPN PE LSR shahram, the PE that is connected to the final CE, uses the second label to identify which CE/CE port it has to be deliverd. The whole mpls header is trimmed before delivering to CE. Once the CE port is identified, packet is deliverd as raw IPv4 to the CE by the PE. The second label is not looked up by any of the intermediate P nodes. PE is typically a egress node. -Gopal. Shahram Davari wrote: > > Hi, > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS packet rather than an IP packet to a PE router, the PE router should still push 2 labels. My question is, should the PE router swap the customer's label too or leave it unchanged? > > Yours, > -Shahram From owner-mpls@UU.NET Wed May 9 16:36:04 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24055 for ; Wed, 9 May 2001 16:35:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohu09620; Wed, 9 May 2001 20:35:22 GMT Received: by mail-control.mail.uu.net id QQkohu22363 for mpls-outgoing; Wed, 9 May 2001 20:34:43 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkohu22316 for ; Wed, 9 May 2001 20:34:22 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkohu16862 for ; Wed, 9 May 2001 20:33:35 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkohu12971 for ; Wed, 9 May 2001 20:33:35 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA11751 for mpls@uu.net; Wed, 9 May 2001 16:33:34 -0400 (EDT) Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoht21705 for ; Wed, 9 May 2001 20:29:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoht07704 for ; Wed, 9 May 2001 20:29:15 GMT Received: from mother.pmc-sierra.bc.ca by cmr0.ash.ops.us.uu.net with SMTP (peer crosschecked as: mother.pmc-sierra.bc.ca [216.241.224.12]) id QQkoht01786 for ; Wed, 9 May 2001 20:29:15 GMT Received: (qmail 12422 invoked by uid 104); 9 May 2001 20:29:14 -0000 Received: from Shahram_Davari@pmc-sierra.com by mother with qmail-scanner-0.93 (uvscan: v4.0.70/v4074. . Clean. Processed in 0.40614 secs); 09/05/2001 13:29:14 Received: from unknown (HELO procyon.pmc-sierra.bc.ca) (134.87.115.1) by mother.pmc-sierra.bc.ca with SMTP; 9 May 2001 20:29:13 -0000 Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by procyon.pmc-sierra.bc.ca (dave/8.11.2) with ESMTP id f49KTD123033; Wed, 9 May 2001 13:29:13 -0700 (PDT) Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 13:31:54 -0700 Message-ID: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C3B@BBY1EXM01> From: Shahram Davari To: "'Vipul Sharma'" , "'Gopal Jayaraman'" Cc: "'mpls@uu.net'" Subject: RE: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 13:31:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mpls@UU.NET Precedence: bulk PE: Provider Edge Router CE: Customer Edge Router > -----Original Message----- > From: Vipul Sharma [mailto:vsharma@senecanetworks.com] > Sent: Wednesday, May 09, 2001 4:26 PM > To: 'Gopal Jayaraman' > Cc: 'mpls@uu.net' > Subject: RE: BGP/MPLS VPN PE LSR > > > Guys, > What is a PE and CE router?? .... Thanx. > > Vip > > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Gopal > Jayaraman > Sent: Wednesday, May 09, 2001 3:54 PM > Cc: 'mpls@uu.net' > Subject: Re: BGP/MPLS VPN PE LSR > > > shahram, > > the PE that is connected to the final CE, uses the second label > to identify which CE/CE port it has to be deliverd. The whole mpls > header is trimmed before delivering to CE. > > Once the CE port is identified, packet is deliverd as raw IPv4 to > the CE by the PE. The second label is not looked up by any of the > intermediate P nodes. PE is typically a egress node. > > > -Gopal. > > > > Shahram Davari wrote: > > > > Hi, > > > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > packet rather > than an IP packet to a PE router, the PE router should still > push 2 labels. > My question is, should the PE router swap the customer's > label too or leave > it unchanged? > > > > Yours, > > -Shahram > From owner-mpls@UU.NET Wed May 9 17:13:24 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25099 for ; Wed, 9 May 2001 17:13:24 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkohw04491; Wed, 9 May 2001 21:12:59 GMT Received: by mail-control.mail.uu.net id QQkohw14741 for mpls-outgoing; Wed, 9 May 2001 21:12:16 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkohw14715 for ; Wed, 9 May 2001 21:12:08 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkohw17027 for ; Wed, 9 May 2001 21:11:25 GMT Received: from spomail01.br.attla.corp by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: webmail.netstream.com.br [200.192.1.34]) id QQkohw27338 for ; Wed, 9 May 2001 21:11:24 GMT Received: from nsrjo4.br.attla.corp (nsrjo4.attla.corp [10.21.10.6]) by spomail01.br.attla.corp with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.10) id KTPDMFKD; Wed, 9 May 2001 18:09:53 -0300 Received: by nsrjo4 with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 18:10:36 -0300 Message-ID: From: "Loureiro, Rodrigo" To: "'Shahram Davari'" , "'Gopal Jayaraman'" Cc: "'mpls@uu.net'" Subject: RES: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 18:10:36 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA25099 Shahram, > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > packet rather than an IP packet to a PE router, the PE router > should still push 2 labels. It doesn´t make much sense. Once you decided to extend the MPLS toward the CE, you can use the hierarchy of routing knowledge capability, in order to avoid the propagation of VPNv4 prefixes through the provider cloud (like an ISP as a client). > My question is, should the PE > router swap the customer's label too or leave it unchanged? > Try to explain better the VPN topology you are thinking and why do you want to extend the MPLS to the CE. Rodrigo Loureiro Systems Engineer - AT&T LA Tel: 55-11-3365-1670/9655-9676 ---------------------------------------------------------------------------- ----------------The Art of Strategy: "Those who are victorious plan effectively and change decisively. They are like a great river that maintains its course but adjusts its flow... They have form but are formless. They are skilled in both planning and adapting and need not fear the result of a thousand battles; for they win in advance, defeating those that have already lost." - Sun Tzu, Chinese Warrior and Philosopher, 100 B.C. ---------------------------------------------------------------------------- ---------------- From owner-mpls@UU.NET Wed May 9 18:21:59 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27408 for ; Wed, 9 May 2001 18:21:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoib28888; Wed, 9 May 2001 22:21:42 GMT Received: by mail-control.mail.uu.net id QQkoib11725 for mpls-outgoing; Wed, 9 May 2001 22:21:07 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoib11707 for ; Wed, 9 May 2001 22:20:52 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoib28083 for ; Wed, 9 May 2001 22:18:37 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoib01654 for ; Wed, 9 May 2001 22:18:37 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA19135 for mpls@uu.net; Wed, 9 May 2001 18:18:37 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoia11024 for ; Wed, 9 May 2001 22:14:22 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoia17856 for ; Wed, 9 May 2001 22:13:40 GMT Received: from motgate.mot.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: motgate.mot.com [129.188.136.100]) id QQkoia19699 for ; Wed, 9 May 2001 22:13:40 GMT Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA00830 for ; Wed, 9 May 2001 15:13:40 -0700 (MST)] Received: [from il02exi02.comm.mot.com (il02exi02.comm.mot.com [145.1.204.41]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA02193 for ; Wed, 9 May 2001 15:13:40 -0700 (MST)] Received: by il02exi02.comm.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 May 2001 17:13:39 -0500 Message-ID: <01FAF65DEA16D4119B95009027E78F3104E89CD0@il02exm26.comm.mot.com> From: Narayanan Vidya-CVN065 To: "'Shahram Davari'" , "'mpls@uu.net'" Subject: RE: BGP/MPLS VPN PE LSR Date: Wed, 9 May 2001 17:13:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I would imagine that to be dependent on the VPN implementation. If the CE and PE routers actually exchange label information, then, I would imagine the label to be swapped. Otherwise, if labels are exchanged independently among PE routers (iBGP peers)and among CE routers (possibly through the PE routers), then, there would be 3 labels in the scenario you described. To my knowledge, MPLS capable CE devices have not been addressed much at all, although that is mentioned as a possibility in the VPN drafts. -Vidya > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, May 09, 2001 2:16 PM > To: 'mpls@uu.net' > Subject: BGP/MPLS VPN PE LSR > > > Hi, > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > packet rather than an IP packet to a PE router, the PE router > should still push 2 labels. My question is, should the PE > router swap the customer's label too or leave it unchanged? > > Yours, > -Shahram > > From owner-mpls@UU.NET Wed May 9 18:30:49 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27773 for ; Wed, 9 May 2001 18:30:49 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoic12569; Wed, 9 May 2001 22:30:18 GMT Received: by mail-control.mail.uu.net id QQkoib12407 for mpls-outgoing; Wed, 9 May 2001 22:29:43 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoib12400 for ; Wed, 9 May 2001 22:29:37 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoib22718 for ; Wed, 9 May 2001 22:29:27 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoib11438 for ; Wed, 9 May 2001 22:29:27 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id SAA20164 for mpls@uu.net; Wed, 9 May 2001 18:29:26 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoib12366 for ; Wed, 9 May 2001 22:28:47 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoib05259 for ; Wed, 9 May 2001 22:27:27 GMT Received: from netmail2.alcatel.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: netmail2.alcatel.com [128.251.168.51]) id QQkoib05788 for ; Wed, 9 May 2001 22:27:27 GMT Received: from postal.adn.alcatel.com (workstation.alcatel.com [198.205.33.79] (may be forged)) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA08189 for ; Wed, 9 May 2001 17:27:26 -0500 (CDT) Received: from usa.alcatel.com ([198.205.41.31]) by postal.adn.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAA6726 for ; Wed, 9 May 2001 18:41:06 -0400 Message-ID: <3AF9C4A5.820B56FE@usa.alcatel.com> Date: Wed, 09 May 2001 18:28:53 -0400 From: Yuan Gu Organization: Alcatel USA X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mpls Subject: record label in RRO Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit Hello: I have some questions about Record Label subobject of Record Route Object in rsvp-lsp-tunnel-08.txt(section 4.4) : 1. What's the purpose of record label? 2. Should it be implemented one way (only along Path direction) or both way (Path and Resv)? 3. Which label should be put in the RRO, in_label or out_label? 4. In case of both way, which label should be put in the RRO of RESV msg, in_label or out_label? Regards! Yuan Gu From owner-mpls@UU.NET Thu May 10 03:07:58 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20287 for ; Thu, 10 May 2001 03:07:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkojk22257; Thu, 10 May 2001 07:07:31 GMT Received: by mail-control.mail.uu.net id QQkojk11111 for mpls-outgoing; Thu, 10 May 2001 07:06:57 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkojk11103 for ; Thu, 10 May 2001 07:06:46 GMT Received: from cmr0.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkojk18191 for ; Thu, 10 May 2001 07:05:56 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkojk18758 for ; Thu, 10 May 2001 07:05:53 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 10 May 2001 12:41:23 +0530 Received: from future.futsoft.com (arumugamr.future.futsoft.com [10.20.6.33]) by kailash.future.futsoft.com (8.11.0/8.11.0) with ESMTP id f4A75is19755; Thu, 10 May 2001 12:35:44 +0530 Message-Id: <3AFA3F9C.E3043735@future.futsoft.com> Date: Thu, 10 May 2001 12:43:32 +0530 From: Arumugam R Organization: FSL X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Adrian Farrel , "mpls@uu.net" Subject: Doubts in gmpls-te-mib Content-Type: multipart/mixed; boundary="------------C6C130CAE17A60E5012529A8" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------C6C130CAE17A60E5012529A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Adrian, While going through the latest gmpls mib, the following observations are found. 1. A new textual convention has been defined as MplsGeneralizedLabelTypes, but when it is referred down the line, it is referred as MplsGeneralizedLabelType only (in gmplsTunnelHopExplicitLabelType and gmplsTunnelHopReversePathExplicitLabelType ). Which one to keep (Types or Type). I think it is a typo error. 2. In GmplsTunnelEntry the first object is gmplsTunnelAdminStatus. While describing the object it is stated as mplsTunnelAdminStatus and it refers to mplsTunnelEntry. If the above entry is to be modified pointing to gmplsTunnelEntry then I think all other objects have to be shifted one step down since gmplsTunnelOperStatus has a value { gmplsTunnelEntry 1 }. Will it be modified or the AdminStatus will be removed from the TunnelEntry. 3. Also gmplsTunnelGPID and gmplsTunnelRNC are pointing to the same value { gmplsTunnelEntry 6 }. I think this has to be changed i.e. shifted down. In the present TE mib ( te-mib-06), the MplsTunnelHopEntry does not have the support of signaling Unnumbered Links in EROs. It is also not mentioned in the GmplsTunnelHopEntry. Will it be mentioned in future, in any one of the mibs or is it left to the implementation. Thanks and regards Arumugam R --------------C6C130CAE17A60E5012529A8 Content-Type: text/x-vcard; charset=us-ascii; name="arumugamr.vcf" Content-Description: Card for Arumugam R Content-Disposition: attachment; filename="arumugamr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Ramasamy;Arumugam tel;home:6223683 tel;work:4330550 Extn- 363 x-mozilla-html:FALSE url:www.futsoft.com org:Future Software;Products version:2.1 email;internet:arumugamr@future.futsoft.com title:Senior Software Engineer adr;quoted-printable:;;480 Mount Road,=0D=0ANandanam,=0D=0A;Chennai;Tamil Nadu;600 035;India fn:Aru end:vcard --------------C6C130CAE17A60E5012529A8-- From owner-mpls@UU.NET Thu May 10 03:27:51 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20565 for ; Thu, 10 May 2001 03:27:51 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkojl12983; Thu, 10 May 2001 07:27:36 GMT Received: by mail-control.mail.uu.net id QQkojl13098 for mpls-outgoing; Thu, 10 May 2001 07:27:03 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkojl13085 for ; Thu, 10 May 2001 07:26:58 GMT Received: from cmr0.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkojl22311 for ; Thu, 10 May 2001 07:26:40 GMT Received: from fsnt.future.futsoft.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [203.197.140.35]) id QQkojl09908 for ; Thu, 10 May 2001 07:26:39 GMT Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 10 May 2001 13:02:06 +0530 Received: from future.futsoft.com (arumugamr.future.futsoft.com [10.20.6.33]) by kailash.future.futsoft.com (8.11.0/8.11.0) with ESMTP id f4A7QRs20875; Thu, 10 May 2001 12:56:27 +0530 Message-Id: <3AFA4477.B759640E@future.futsoft.com> Date: Thu, 10 May 2001 13:04:15 +0530 From: Arumugam R Organization: FSL X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Yuan Gu Cc: mpls Subject: Re: record label in RRO References: <3AF9C4A5.820B56FE@usa.alcatel.com> Content-Type: multipart/mixed; boundary="------------82B84D4D1FBE2A553EADB096" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------82B84D4D1FBE2A553EADB096 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Yuan. The comments are inlined. Yuan Gu wrote: > Hello: > > I have some questions about Record Label subobject of Record Route > Object in rsvp-lsp-tunnel-08.txt(section 4.4) : > > 1. What's the purpose of record label? The purpose of record label is for fast rerouting using bypass tunnels. ( refer swallow-rsvp-bypass-label draft). > > 2. Should it be implemented one way (only along Path direction) or both > way (Path and Resv)? As mentioned in the draft it can be impemented in only one direction i.e in Resv direction.. > > 3. Which label should be put in the RRO, in_label or out_label? The label being put is the incoming label because this is the label being allocated by the particular node. The outgoing label might have been pushed by the upstream node. > > 4. In case of both way, which label should be put in the RRO of RESV > msg, in_label or out_label? > I think it is clear, it is not both way. only in Resv path and that too incoming label only.. > > Regards! > Yuan Gu Regards Arumugam R --------------82B84D4D1FBE2A553EADB096 Content-Type: text/x-vcard; charset=us-ascii; name="arumugamr.vcf" Content-Description: Card for Arumugam R Content-Disposition: attachment; filename="arumugamr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Ramasamy;Arumugam tel;home:6223683 tel;work:4330550 Extn- 363 x-mozilla-html:FALSE url:www.futsoft.com org:Future Software;Products version:2.1 email;internet:arumugamr@future.futsoft.com title:Senior Software Engineer adr;quoted-printable:;;480 Mount Road,=0D=0ANandanam,=0D=0A;Chennai;Tamil Nadu;600 035;India fn:Aru end:vcard --------------82B84D4D1FBE2A553EADB096-- From owner-mpls@UU.NET Thu May 10 05:22:15 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21390 for ; Thu, 10 May 2001 05:22:15 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkojt29440; Thu, 10 May 2001 09:17:43 GMT Received: by mail-control.mail.uu.net id QQkojt29804 for mpls-outgoing; Thu, 10 May 2001 09:17:11 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkojt29799 for ; Thu, 10 May 2001 09:17:02 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkojt16174 for ; Thu, 10 May 2001 09:16:41 GMT Received: from ntexgswp02.DMZ by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: smtp.kpnqwest.com [193.242.92.8]) id QQkojt29067 for ; Thu, 10 May 2001 09:16:40 GMT Received: from ntexghub01.kpnqwest.com (unverified) by ntexgswp02.DMZ (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 10 May 2001 10:49:46 +0200 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Thu, 10 May 2001 10:41:16 +0200 Message-ID: From: "Metz, Eduard" To: "'Shahram Davari'" Cc: "'mpls@uu.net'" Subject: RE: BGP/MPLS VPN PE LSR Date: Thu, 10 May 2001 10:43:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mpls@UU.NET Precedence: bulk I assume you are referring to the 'carriers-carrier' model. This section in the draft is pretty vague. However, are you sure 2 labels will be added? Could the PE not also use the customer label as the inner label (and thus swap it)? > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 09 May 2001 21:16 > To: 'mpls@uu.net' > Subject: BGP/MPLS VPN PE LSR > > > Hi, > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > packet rather than an IP packet to a PE router, the PE router > should still push 2 labels. My question is, should the PE > router swap the customer's label too or leave it unchanged? > > Yours, > -Shahram > > From owner-mpls@UU.NET Thu May 10 05:45:07 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21740 for ; Thu, 10 May 2001 05:45:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoju07834; Thu, 10 May 2001 09:44:18 GMT Received: by mail-control.mail.uu.net id QQkoju01522 for mpls-outgoing; Thu, 10 May 2001 09:43:44 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoju01512 for ; Thu, 10 May 2001 09:43:39 GMT Received: from cmr1.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoju06894 for ; Thu, 10 May 2001 09:43:08 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoju24467 for ; Thu, 10 May 2001 09:43:08 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id FAA16367 for mpls@uu.net; Thu, 10 May 2001 05:43:08 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoju01457 for ; Thu, 10 May 2001 09:42:38 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoju27408 for ; Thu, 10 May 2001 09:42:34 GMT Received: from cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: london2.cisco.com [144.254.32.10]) id QQkoju23955 for ; Thu, 10 May 2001 09:42:34 GMT Received: from JGUICHAR-W2K.cisco.com (jguichar-isdn-home.cisco.com [10.49.131.222]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id LAA06851; Thu, 10 May 2001 11:42:03 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010510103601.01b0eb48@london2.cisco.com> X-Sender: jguichar@london2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 10 May 2001 10:41:06 +0100 To: "Metz, Eduard" From: jim guichard Subject: RE: BGP/MPLS VPN PE LSR Cc: "'Shahram Davari'" , "'mpls@uu.net'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mpls@UU.NET Precedence: bulk The case where a PE will receive a labelled packet is referred to as the Carriers Carrier architecture and it has several flavours. In the case where the VPN site is running MPLS, then you will see a two level label stack across the carrier backbone. A three level label stack will be seen when the VPN site is running MPLS VPN and this is referred to as a hierarchical VPN. Jim At 10:43 10/05/2001 +0200, Metz, Eduard wrote: >I assume you are referring to the 'carriers-carrier' model. This section in >the draft is pretty vague. However, are you sure 2 labels will be added? >Could the PE not also use the customer label as the inner label (and thus >swap it)? > > > > -----Original Message----- > > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > > Sent: 09 May 2001 21:16 > > To: 'mpls@uu.net' > > Subject: BGP/MPLS VPN PE LSR > > > > > > Hi, > > > > In an BGP/MPLS VPN scenario if a CE router sends an MPLS > > packet rather than an IP packet to a PE router, the PE router > > should still push 2 labels. My question is, should the PE > > router swap the customer's label too or leave it unchanged? > > > > Yours, > > -Shahram > > > > Jim Guichard CCIE #2069 Technical Leader EMEA +44 208 756 8806 Mobile: +44 7802 809763 From owner-mpls@UU.NET Thu May 10 07:46:35 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23241 for ; Thu, 10 May 2001 07:46:33 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkokd03204; Thu, 10 May 2001 11:46:09 GMT Received: by mail-control.mail.uu.net id QQkokd19229 for mpls-outgoing; Thu, 10 May 2001 11:45:20 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkokd19224 for ; Thu, 10 May 2001 11:45:15 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkokc16325 for ; Thu, 10 May 2001 11:44:33 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkokc01476 for ; Thu, 10 May 2001 11:44:23 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id HAA21101 for mpls@uu.net; Thu, 10 May 2001 07:44:23 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkokc18787 for ; Thu, 10 May 2001 11:43:55 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkokc27643 for ; Thu, 10 May 2001 11:43:00 GMT Received: from ihemail2.firewall.lucent.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: ihemail2.lucent.com [192.11.222.163]) id QQkokc24951 for ; Thu, 10 May 2001 11:43:00 GMT Received: from ihemail2.firewall.lucent.com (localhost [127.0.0.1]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ABh0L07926 for ; Thu, 10 May 2001 07:43:00 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemail2.firewall.lucent.com (Switch-2.1.1/Switch-2.1.0) with ESMTP id f4ABgxM07893 for ; Thu, 10 May 2001 07:42:59 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA02004; Thu, 10 May 2001 13:42:58 +0200 (MET DST) Cc: Debanjan Saha , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA01913; Thu, 10 May 2001 13:42:55 +0200 (MET DST) Message-ID: <3AFA7EBE.6570755E@lucent.com> Date: Thu, 10 May 2001 13:42:54 +0200 From: Maarten Vissers Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Fong, Man Wing" Original-CC: Debanjan Saha , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Subject: Re: Question about logical link in Link bundling References: <66E0B27B8A29D511B19600D0B744446527AE51@192-168-1-220.customer.algx.net> Content-Type: multipart/mixed; boundary="------------FC9EDFA8EF9D477928E13512" Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --------------FC9EDFA8EF9D477928E13512 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Man Wing, The virtual concatenation capability included in the transport NEs is targeted to support pay-as-you-grow ethernet connections through the transport network, which ingress/egress the transport network via physical ethernet interfaces (10M, 100M, 1G, 10G). This capability is not intended (at least not in today's view) to support an OC12c (STM-4 with VC-4-4c) as ingress/egress physical interface to the transport network. The fact that the transport NEs are extended with this virtual concatenation capability is an intermediate step (early availibility) in the pay-as-you-grow ethernet connections offer. The final step should bring the virtual concatenation endpoints to the routers again, such that in the emerging automatic switched transport network, routers can dial up additional (or release superfluous) bandwidth, in a hitless manner (using LCAS from the endpoints). This will keep the OC12 (in general OC-N) interfaces on the routers (using VSR optics similar to those used in ehternet today), and removes the need to perform an additional conversion in the ingress/egress ports of the transport network (saving costs also here). In addition, the routers are now again free in selecting the protocol between them (IP/ethernet, IP/PPP/HDLC, IP/PPP/GFP, MPLS/GFP, IP/ATM, ...) while the transport network will transparently pass through the virtual concatenated signal including(its payload with the particular protocol). Regards, Maarten "Fong, Man Wing" wrote: > > Maarten, > > Very good point and description. The last case that you describe using VC > would be a good alternative to support the bandwidth on demand. Now that the > inverse muxing capability is being transferred from the router to the > transport NEs. In this case, (Debanjan, you're right), the user would use an > OC-12c interface on a router instead of the channelized OC-12 interface to > save cost for this application (BOD). > > Thanks, > Man Wing > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, May 09, 2001 5:06 AM > To: Debanjan Saha > Cc: 'Fong, Man Wing'; Bala Rajagopalan; mpls@UU.NET; 'Kireeti Kompella'; > ccamp@ops.ietf.org > Subject: Re: Question about logical link in Link bundling > > << File: Card for Maarten Vissers >> Debanjan, > > Just a thought... those 12 DS3s terminating on the same router (and > providing access to 12 MPLS links) may terminate at the other ends on 12 > different routers. With one physical (OC12) interface you have now made > (with the help of the transport network) connections with 12 other > routers. Very cost effective... > > Ofcourse you don't need a DS3 to be present in the STS1 is the router at > the other end of the transport network has a EC1 of (channelised) OC-N > interface. In this case you may deploy direct mapping of MPLS into STS1 > payload (via PPP/HDLC or the new GFP encapsulation). > > One further cost reduction step (for the case there are e.g. only 5 > other routers connected) is to use STS1 virtual concatenation with GFP > encapsulation of MPLS. You can now size each of the 5 STS pipes between > 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12. > > Regards, > > Maarten > > Debanjan Saha wrote: > > > > Fong, > > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. > > However, if all of them are terminating on > > the same LSR, I'm not sure why you'll use a channelized > > OC-12 and not an OC-12c. > > > > Debanjan --------------FC9EDFA8EF9D477928E13512 Content-Type: text/x-vcard; charset=us-ascii; name="mvissers.vcf" Content-Description: Card for Maarten Vissers Content-Disposition: attachment; filename="mvissers.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --------------FC9EDFA8EF9D477928E13512-- From owner-mpls@UU.NET Thu May 10 09:25:40 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25804 for ; Thu, 10 May 2001 09:25:32 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkokj14371; Thu, 10 May 2001 13:25:09 GMT Received: by mail-control.mail.uu.net id QQkokj08508 for mpls-outgoing; Thu, 10 May 2001 13:24:36 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkokj08499 for ; Thu, 10 May 2001 13:24:31 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkokj17660 for ; Thu, 10 May 2001 13:24:15 GMT Received: from sj-msg-core-1.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: sj-msg-core-1.cisco.com [171.71.163.11]) id QQkokj13345 for ; Thu, 10 May 2001 13:24:13 GMT Received: from erosen-sun.cisco.com (erosen-sun.cisco.com [161.44.134.50]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4ADOG915611 for ; Thu, 10 May 2001 06:24:16 -0700 (PDT) Received: (erosen@localhost) by erosen-sun.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id JAA25836 for mpls@uu.net; Thu, 10 May 2001 09:24:11 -0400 (EDT) Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkoha11103 for ; Wed, 9 May 2001 15:40:06 GMT Received: from cmr1.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoha01909 for ; Wed, 9 May 2001 15:38:34 GMT Received: from mailgw.local.ipunplugged.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [213.88.134.217]) id QQkoha09515 for ; Wed, 9 May 2001 15:38:33 GMT Received: from HANSPC (a27.local.ipunplugged.com [192.168.4.197]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA21012; Wed, 9 May 2001 17:39:18 +0200 From: =?Windows-1252?Q?Hans_Sj=F6strand?= To: "Felix Chang" , "mpls_maillist" Subject: RE: RE: Parameters in LDP entity table Date: Wed, 9 May 2001 17:37:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200105091346.f49Djtv01114@noya.bupt.edu.cn> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit No, from section 3036 2.6 However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. section 3.5.7.1.3 elaborates in detail why. The negotiation is valid for both directions, there is no reason why to have different modes for different directions. If the two entities propose different modes, it's resolved as described in 3036. /// Hasse > From Felix Chang wrote: > > hi,Hasse > > Thank you a lot! I have understood what you meant. > And I have another question: Since LSP is unidirectional, > May we specify different distribution methods on the two directions > of a LDP session? > > Best regards! > Felix Chang > mplszhz@263.net > > From owner-mpls@UU.NET Thu May 10 09:32:17 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26081 for ; Thu, 10 May 2001 09:32:11 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkokk11654; Thu, 10 May 2001 13:30:58 GMT Received: by mail-control.mail.uu.net id QQkokk09248 for mpls-outgoing; Thu, 10 May 2001 13:30:22 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkokk09203 for ; Thu, 10 May 2001 13:30:01 GMT Received: from cmr2.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkokj25576 for ; Thu, 10 May 2001 13:28:39 GMT Received: from exchange01.movaz.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: [64.47.82.134]) id QQkokj18381 for ; Thu, 10 May 2001 13:28:39 GMT Received: from BLIULAPTOP ([64.47.72.35]) by exchange01.movaz.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 10 May 2001 09:25:41 -0400 Message-ID: <019b01c0d954$b567c190$23482f40@movaz.com> From: "Adrian Farrel" To: "Arumugam R" Cc: References: <3AFA3F9C.E3043735@future.futsoft.com> Subject: Re: Doubts in gmpls-te-mib Date: Thu, 10 May 2001 09:25:40 -0400 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-OriginalArrivalTime: 10 May 2001 13:25:41.0249 (UTC) FILETIME=[B588B710:01C0D954] Sender: owner-mpls@UU.NET Precedence: bulk Arumugam Hi and thanks. > 1. A new textual convention has been defined as > MplsGeneralizedLabelTypes, but when it is referred down the line, it is > referred as MplsGeneralizedLabelType only (in > gmplsTunnelHopExplicitLabelType and > gmplsTunnelHopReversePathExplicitLabelType ). > Which one to keep (Types or Type). I think it is a typo error. Got it. Keep Types. > 2. In GmplsTunnelEntry the first object is gmplsTunnelAdminStatus. While > describing the object it is stated as mplsTunnelAdminStatus and it > refers to > mplsTunnelEntry. If the above entry is to be modified pointing to > gmplsTunnelEntry then I think all other objects have to be shifted one > step down since > gmplsTunnelOperStatus has a value { gmplsTunnelEntry 1 }. Will it be > modified or the AdminStatus will be removed from the TunnelEntry. My view is that gmplsAdminStatus is not required and should be removed. > 3. Also gmplsTunnelGPID and gmplsTunnelRNC are pointing to the same > value { gmplsTunnelEntry 6 }. I think this has to be changed i.e. > shifted down. Thanks > In the present TE mib ( te-mib-06), the MplsTunnelHopEntry does not have > the support of signaling Unnumbered Links in EROs. It is also not > mentioned in the > GmplsTunnelHopEntry. Will it be mentioned in future, in any one of the > mibs or is it left to the implementation. We are debating whether this should go in here. It is simple to add. The issue is that it is not strictly a GMPLS feature. Regards, Adrian From owner-mpls@UU.NET Thu May 10 10:53:08 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29402 for ; Thu, 10 May 2001 10:52:54 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkokn11727; Thu, 10 May 2001 14:18:07 GMT Received: by mail-control.mail.uu.net id QQkokn02490 for mpls-outgoing; Thu, 10 May 2001 14:17:33 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkokn01873 for ; Thu, 10 May 2001 14:17:13 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkokn11899 for ; Thu, 10 May 2001 14:15:19 GMT Received: from dnsmx1pya.telcordia.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkokn09599 for ; Thu, 10 May 2001 14:15:18 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id KAA07757 for ; Thu, 10 May 2001 10:12:47 -0400 (EDT) Subject: RSVP-TE-- ResvErr message To: mpls@UU.NET From: "Hong Liao" Date: Thu, 10 May 2001 10:13:10 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/10/2001 10:13:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi, In ResvErr message, ::= | | And the | | is come from the Resv message, since the Resv message has been changed in the mpls RSVP-TE, those field in ResvErr message will use the same objects in Resv message of RSVP-TE. I hope I understand correctly. Then the same thing for the PathErr, PathTear, and ResvTear. Julia From owner-mpls@UU.NET Thu May 10 13:03:26 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03488 for ; Thu, 10 May 2001 13:03:26 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoky17171; Thu, 10 May 2001 17:02:53 GMT Received: by mail-control.mail.uu.net id QQkoky05273 for mpls-outgoing; Thu, 10 May 2001 17:02:16 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoky05121 for ; Thu, 10 May 2001 17:02:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkoky24964 for ; Thu, 10 May 2001 17:01:26 GMT Received: from mill.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoky15478 for ; Thu, 10 May 2001 17:01:26 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA13087 for mpls@uu.net; Thu, 10 May 2001 13:01:26 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkokx02923 for ; Thu, 10 May 2001 16:57:03 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkokx11465 for ; Thu, 10 May 2001 16:56:48 GMT Received: from pilgrim.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: pilgrim.cisco.com [171.69.204.12]) id QQkokx09970 for ; Thu, 10 May 2001 16:56:48 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by pilgrim.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA02283; Thu, 10 May 2001 12:56:47 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id MAA04009; Thu, 10 May 2001 12:56:41 -0400 (EDT) Message-Id: <200105101656.MAA04009@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Eric Gray cc: Guangzhi Li , George Swallow , Eric W Gray , mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session In-reply-to: Your message of "Mon, 30 Apr 2001 15:21:43 EDT." <3AEDBB45.99228FBD@sandburst.com> Date: Thu, 10 May 2001 12:56:41 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Eric, Guangzhi - We've had a terminology problem with tunnels all along. The way I think about it is a tunnel is the desire to have a path from a source to destination. When that desire is frustrated we say the 'tunnel is down' or no path extists for this tunnel. A tunnel is *normally* mapped one to one to an LSP. The notable exceptions to this are in the case of a reroute operation or a fast-reroute. The scope of the SE style reservation is to the Session. In order to limit a session to a single tunnel, we extended the session object to include the extended tunnel ID. We also renamed the Port field to tunnel_ID. This creates a means of allowing multiple LSPs to share a session, (and bandwidth using the SE style). The sender_template contains the sender and the LSP_ID. This creates a means of allowing reroute operations. On initial setup any Path message creating an LSP for a tunnel should have The destination field of the session object set to the destination of the tunnel and the source in the sender to the ingress. As the draft says, the extended tunnel_ID is normally zero. This derives from one vendor's hope that they could avoid LDP altogether and that merging destination based trees would be the dominant use of RSVP lsps. Our implementation always fills it in. The way I've modeled fast reroute is as follows. The node making the repair (Point of local repair or PLR for short) creates an lsp from itself to the destination for this purpose. This lsp may merge with the original lsp somewhere prior to the destination but need not. (Note that if the PLR is the penultimate node it cannot.) It uniquely identifies that LSP by using its own address in the sender object. But this only works if the extended_tunnel ID is in use. (A point that I need to add to my reroute draft). So in practive if the extended tunnel ID is non-zero, use that as the identifier of the ingress. If it is zero use the sender. Also note that for GMPLS some folks are considering doing away with the requirement that PATH messages are addressed to the destination. In GMPLS, having non-RSVP routers in the path won't work so the reason for addressing to the destination is gone. Also it is possible to have loss of neighbor connectivity in the control plane while the data plane is just fine. So being able to directly address these without having to do IPinIP would be useful. Don't know if this will actually happen, but relying on the Source/Dest address in the IP header of the Path message may not be a good choice in the long run. ...George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 10 13:11:07 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03716 for ; Thu, 10 May 2001 13:11:07 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoky19784; Thu, 10 May 2001 17:10:00 GMT Received: by mail-control.mail.uu.net id QQkoky15830 for mpls-outgoing; Thu, 10 May 2001 17:09:25 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkoky15815 for ; Thu, 10 May 2001 17:09:11 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoky14357 for ; Thu, 10 May 2001 17:08:06 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoky02956 for ; Thu, 10 May 2001 17:08:05 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id NAA13884 for mpls@uu.net; Thu, 10 May 2001 13:08:04 -0400 (EDT) Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkoky05741 for ; Thu, 10 May 2001 17:03:09 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkoky09004 for ; Thu, 10 May 2001 17:00:50 GMT Received: from bemigl01.swift.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.swift.com [195.99.94.1]) id QQkoky09308 for ; Thu, 10 May 2001 17:00:49 GMT Date: Wed, 09 May 2001 12:16:14 -0700 From: Shahram Davari Subject: BGP/MPLS VPN PE LSR To: "'mpls@uu.net'" Message-id: <9DC5E2ABE65BD54CA9088DA3194461D6037A6C38@BBY1EXM01> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_GpkSt6kDW7ar2i/orP8uhQ)" X-Proxy: besec50.swift.com protected by Firewall Sender: owner-mpls@UU.NET Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_GpkSt6kDW7ar2i/orP8uhQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, In an BGP/MPLS VPN scenario if a CE router sends an MPLS packet rather than an IP packet to a PE router, the PE router should still push 2 labels. My question is, should the PE router swap the customer's label too or leave it unchanged? Yours, -Shahram --Boundary_(ID_GpkSt6kDW7ar2i/orP8uhQ) Content-type: application/octet-stream; name="Shahram Davari.vcf" Content-disposition: attachment; filename="Shahram Davari.vcf" BEGIN:VCARD VERSION:2.1 N:Davari;Shahram FN:Shahram Davari ORG:PMC-Sierra, Inc.;R&D Research Ottawa-109203 TITLE:Product Research Engineer TEL;WORK;VOICE:+1 613 271 4018 ADR;WORK:;Ottawa;Kanata Research Park, Suite 834, Office Tower B, 555 Legget Drive;Kanata;Ontario;K2K 2X3;Canada LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ottawa=0D=0AKanata Research Park, Suite 834, Office Tower B, 555 Legget Driv= e=0D=0AKanata, Ontario K2K 2X3=0D=0ACanada EMAIL;PREF;INTERNET:Shahram_Davari@pmc-sierra.com REV:20010112T213717Z END:VCARD --Boundary_(ID_GpkSt6kDW7ar2i/orP8uhQ)-- From owner-mpls@UU.NET Thu May 10 13:18:19 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04011 for ; Thu, 10 May 2001 13:18:19 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkokz04973; Thu, 10 May 2001 17:17:43 GMT Received: by mail-control.mail.uu.net id QQkokz26155 for mpls-outgoing; Thu, 10 May 2001 17:17:10 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkokz25957 for ; Thu, 10 May 2001 17:17:00 GMT Received: from cmr1.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkokz08921 for ; Thu, 10 May 2001 17:16:43 GMT From: wesam.alanqar@mail.sprint.com Received: from bemigl01.swift.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.swift.com [195.99.94.1]) id QQkokz12230 for ; Thu, 10 May 2001 17:16:41 GMT Date: Wed, 09 May 2001 12:43:42 -0500 Subject: Status of draf-stdenis-ms-over-mpls-00 To: mpls@UU.NET Cc: pwe3@ietf.org Message-id: MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_8ayLE9j2Pmm5ibmPxHiOwQ)" X-Proxy: besec50.swift.com protected by Firewall X-OpenMail-Hops: 1 Sender: owner-mpls@UU.NET Precedence: bulk --Boundary_(ID_8ayLE9j2Pmm5ibmPxHiOwQ) Content-type: text/plain; charset=ISO-8859-1 Content-disposition: inline; Creation-Date="Wed, 9 May 2001 12:43:42 -0500" Content-Transfer-Encoding: 7BIT Can any body update me with the status of draft-stdenis-ms-over-mpls-00? Any cooperation with Martini drafts? Thanks. ------------------------------------------------------------------------ ----------- Wesam Alanqar Member of Technical Staff Technology Research Group (TR) Technology Planning & Integration Dept. (TP&I) Sprint 9300 Metcalf Avenue, KS 66212 Phone: 913-534-5623 Work, Fax: 913-534-3485 ------------------------------------------------------------------------ ----------- --Boundary_(ID_8ayLE9j2Pmm5ibmPxHiOwQ) Content-type: application/octet-stream; NAME="Wesam Alanqar (E-mail).vcf" Content-disposition: attachment; Creation-Date="Wed, 9 May 2001 12:43:42 -0500"; filename="Wesam Alanqar (E-mail).vcf" Content-Transfer-Encoding: base64 QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkFsYW5xYXI7V2VzYW0NCkZOOldlc2FtIEFs YW5xYXIgKEUtbWFpbCkNCk9SRzpUZWNobm9sb2d5IFBsYW5uaW5nICYgSW50ZWdyYXRpb24t U3ByaW50O1RlY2hub2xvZ3kgUGxhbm5pbmcgJiBJbnRlZ3JhdGlvbg0KVElUTEU6TWVtYmVy IG9mIFRlY2huaWNhbCBTdGFmZg0KVEVMO1dPUks7Vk9JQ0U6KDkxMykgNTM0LTU2MjMNClRF TDtXT1JLO0ZBWDooOTEzKSA1MzQtMzQ4NQ0KQURSO1dPUks6Ozg1MTs5MzAwIE1ldGNhbGYg QXZlbnVlO092ZXJsYW5kIFBhcms7S1M7NjYyMTItMTQ2MztVbml0ZWQgU3RhdGVzIG9mIEFt ZXJpY2ENCkxBQkVMO1dPUks7RU5DT0RJTkc9UVVPVEVELVBSSU5UQUJMRTo4NTE9MEQ9MEE5 MzAwIE1ldGNhbGYgQXZlbnVlPTBEPTBBT3ZlcmxhbmQgUGFyaywgS1MgNjYyMTItMTQ2Mz0w RD0wQVVuaXRlZCBTPQ0KdGF0ZXMgb2YgQW1lcmljYQ0KRU1BSUw7UFJFRjtJTlRFUk5FVDp3 ZXNhbS5hbGFucWFyQG1haWwuc3ByaW50LmNvbQ0KUkVWOjIwMDEwMTI5VDE4MjEyN1oNCkVO RDpWQ0FSRA0K --Boundary_(ID_8ayLE9j2Pmm5ibmPxHiOwQ)-- From owner-mpls@UU.NET Thu May 10 13:47:02 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04783 for ; Thu, 10 May 2001 13:47:01 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkolb13767; Thu, 10 May 2001 17:46:14 GMT Received: by mail-control.mail.uu.net id QQkolb29073 for mpls-outgoing; Thu, 10 May 2001 17:45:38 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkolb29059 for ; Thu, 10 May 2001 17:45:18 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkola25494 for ; Thu, 10 May 2001 17:43:58 GMT Received: from bemigl01.swift.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.swift.com [195.99.94.1]) id QQkola05321 for ; Thu, 10 May 2001 17:43:57 GMT Date: Thu, 10 May 2001 12:43:32 +0530 From: Arumugam R Subject: Doubts in gmpls-te-mib To: Adrian Farrel , "mpls@uu.net" Message-id: <3AFA3F9C.E3043735@future.futsoft.com> Organization: FSL MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; I) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_km50bpKgrbgWzgPzkHNWEw)" X-Accept-Language: en X-Proxy: besec50.swift.com protected by Firewall Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_km50bpKgrbgWzgPzkHNWEw) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi Adrian, While going through the latest gmpls mib, the following observations are found. 1. A new textual convention has been defined as MplsGeneralizedLabelTypes, but when it is referred down the line, it is referred as MplsGeneralizedLabelType only (in gmplsTunnelHopExplicitLabelType and gmplsTunnelHopReversePathExplicitLabelType ). Which one to keep (Types or Type). I think it is a typo error. 2. In GmplsTunnelEntry the first object is gmplsTunnelAdminStatus. While describing the object it is stated as mplsTunnelAdminStatus and it refers to mplsTunnelEntry. If the above entry is to be modified pointing to gmplsTunnelEntry then I think all other objects have to be shifted one step down since gmplsTunnelOperStatus has a value { gmplsTunnelEntry 1 }. Will it be modified or the AdminStatus will be removed from the TunnelEntry. 3. Also gmplsTunnelGPID and gmplsTunnelRNC are pointing to the same value { gmplsTunnelEntry 6 }. I think this has to be changed i.e. shifted down. In the present TE mib ( te-mib-06), the MplsTunnelHopEntry does not have the support of signaling Unnumbered Links in EROs. It is also not mentioned in the GmplsTunnelHopEntry. Will it be mentioned in future, in any one of the mibs or is it left to the implementation. Thanks and regards Arumugam R --Boundary_(ID_km50bpKgrbgWzgPzkHNWEw) Content-type: text/x-vcard; name=arumugamr.vcf; charset=us-ascii Content-description: Card for Arumugam R Content-disposition: attachment; filename=arumugamr.vcf Content-Transfer-Encoding: 7BIT begin:vcard n:Ramasamy;Arumugam tel;home:6223683 tel;work:4330550 Extn- 363 x-mozilla-html:FALSE url:www.futsoft.com org:Future Software;Products version:2.1 email;internet:arumugamr@future.futsoft.com title:Senior Software Engineer adr;quoted-printable:;;480 Mount Road,=0D=0ANandanam,=0D=0A;Chennai;Tamil Nadu;600 035;India fn:Aru end:vcard --Boundary_(ID_km50bpKgrbgWzgPzkHNWEw)-- From owner-mpls@UU.NET Thu May 10 14:07:00 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05313 for ; Thu, 10 May 2001 14:06:59 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkolc21555; Thu, 10 May 2001 18:06:05 GMT Received: by mail-control.mail.uu.net id QQkolc11429 for mpls-outgoing; Thu, 10 May 2001 18:05:28 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkolc11367 for ; Thu, 10 May 2001 18:05:19 GMT Received: from cmr2.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkolc10082 for ; Thu, 10 May 2001 18:03:56 GMT Received: from mill.cisco.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkolc19359 for ; Thu, 10 May 2001 18:03:56 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id OAA19729 for mpls@uu.net; Thu, 10 May 2001 14:03:55 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkolc06180 for ; Thu, 10 May 2001 18:03:26 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkolc20498 for ; Thu, 10 May 2001 18:02:50 GMT Received: from bemigl01.swift.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mailhost.swift.com [195.99.94.1]) id QQkolc18142 for ; Thu, 10 May 2001 18:02:49 GMT Date: Thu, 10 May 2001 13:42:54 +0200 From: Maarten Vissers Subject: Re: Question about logical link in Link bundling To: "Fong, Man Wing" Cc: Debanjan Saha , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org Message-id: <3AFA7EBE.6570755E@lucent.com> Organization: Lucent Technologies MIME-version: 1.0 X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (WinNT; I) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_13M27/buoqOE3MhJY1j/cg)" X-Accept-Language: en Original-CC: Debanjan Saha , Bala Rajagopalan , mpls@UU.NET, "'Kireeti Kompella'" , ccamp@ops.ietf.org X-Proxy: besec50.swift.com protected by Firewall References: <66E0B27B8A29D511B19600D0B744446527AE51@192-168-1-220.customer.algx.net> Sender: owner-mpls@UU.NET Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_13M27/buoqOE3MhJY1j/cg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Man Wing, The virtual concatenation capability included in the transport NEs is targeted to support pay-as-you-grow ethernet connections through the transport network, which ingress/egress the transport network via physical ethernet interfaces (10M, 100M, 1G, 10G). This capability is not intended (at least not in today's view) to support an OC12c (STM-4 with VC-4-4c) as ingress/egress physical interface to the transport network. The fact that the transport NEs are extended with this virtual concatenation capability is an intermediate step (early availibility) in the pay-as-you-grow ethernet connections offer. The final step should bring the virtual concatenation endpoints to the routers again, such that in the emerging automatic switched transport network, routers can dial up additional (or release superfluous) bandwidth, in a hitless manner (using LCAS from the endpoints). This will keep the OC12 (in general OC-N) interfaces on the routers (using VSR optics similar to those used in ehternet today), and removes the need to perform an additional conversion in the ingress/egress ports of the transport network (saving costs also here). In addition, the routers are now again free in selecting the protocol between them (IP/ethernet, IP/PPP/HDLC, IP/PPP/GFP, MPLS/GFP, IP/ATM, ...) while the transport network will transparently pass through the virtual concatenated signal including(its payload with the particular protocol). Regards, Maarten "Fong, Man Wing" wrote: > > Maarten, > > Very good point and description. The last case that you describe using VC > would be a good alternative to support the bandwidth on demand. Now that the > inverse muxing capability is being transferred from the router to the > transport NEs. In this case, (Debanjan, you're right), the user would use an > OC-12c interface on a router instead of the channelized OC-12 interface to > save cost for this application (BOD). > > Thanks, > Man Wing > > -----Original Message----- > From: Maarten Vissers [mailto:mvissers@lucent.com] > Sent: Wednesday, May 09, 2001 5:06 AM > To: Debanjan Saha > Cc: 'Fong, Man Wing'; Bala Rajagopalan; mpls@UU.NET; 'Kireeti Kompella'; > ccamp@ops.ietf.org > Subject: Re: Question about logical link in Link bundling > > << File: Card for Maarten Vissers >> Debanjan, > > Just a thought... those 12 DS3s terminating on the same router (and > providing access to 12 MPLS links) may terminate at the other ends on 12 > different routers. With one physical (OC12) interface you have now made > (with the help of the transport network) connections with 12 other > routers. Very cost effective... > > Ofcourse you don't need a DS3 to be present in the STS1 is the router at > the other end of the transport network has a EC1 of (channelised) OC-N > interface. In this case you may deploy direct mapping of MPLS into STS1 > payload (via PPP/HDLC or the new GFP encapsulation). > > One further cost reduction step (for the case there are e.g. only 5 > other routers connected) is to use STS1 virtual concatenation with GFP > encapsulation of MPLS. You can now size each of the 5 STS pipes between > 1 and a Xi STS1s (STS-1-Xv) as long as the sum of X1+X2+X3+X4+X5 <= 12. > > Regards, > > Maarten > > Debanjan Saha wrote: > > > > Fong, > > You're right. A channelize OC-12 can have 12 DS-3s (STS-1)within it. > > However, if all of them are terminating on > > the same LSR, I'm not sure why you'll use a channelized > > OC-12 and not an OC-12c. > > > > Debanjan --Boundary_(ID_13M27/buoqOE3MhJY1j/cg) Content-type: text/x-vcard; name=mvissers.vcf; charset=us-ascii Content-description: Card for Maarten Vissers Content-disposition: attachment; filename=mvissers.vcf Content-Transfer-Encoding: 7BIT begin:vcard n:Vissers;Maarten tel;cell:+31 62 061 3945 tel;fax:+31 35 687 5976 tel;home:+31 35 526 5463 tel;work:+31 35 687 4270 x-mozilla-html:FALSE org:Lucent Technologies Nederland;NA&CPSE version:2.1 email;internet:mvissers@lucent.com adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands fn:Maarten Vissers end:vcard --Boundary_(ID_13M27/buoqOE3MhJY1j/cg)-- From owner-mpls@UU.NET Thu May 10 15:02:43 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06280 for ; Thu, 10 May 2001 15:02:38 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkolg02553; Thu, 10 May 2001 19:02:00 GMT Received: by mail-control.mail.uu.net id QQkolg28276 for mpls-outgoing; Thu, 10 May 2001 19:01:22 GMT Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkolg28150 for ; Thu, 10 May 2001 19:01:04 GMT Received: from cmr2.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkolg29625 for ; Thu, 10 May 2001 19:00:17 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQkolg21471 for ; Thu, 10 May 2001 19:00:12 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 74C704D451; Thu, 10 May 2001 15:00:08 -0400 (EDT) Received: from research.att.com (dhcp145.research.att.com [135.207.28.145]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id PAA25772; Thu, 10 May 2001 15:00:08 -0400 (EDT) Message-ID: <3AFAE5EC.C229F149@research.att.com> Date: Thu, 10 May 2001 15:03:08 -0400 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow Cc: Eric Gray , Eric W Gray , mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session References: <200105101656.MAA04009@telescope.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George: Thanks. So the conclusion could be: (1) In order to support destination rooted tree lsps, the SESSION field of extended ID must be zero. (2) In order to support fast reroute, the SESSION field of extended ID must be used (non zero). Then you can not have both. But both are legal based on RSVP-TE. It is vendor's choice for implementation. But should be ready to accept both. Right ? Now sender_template. Is it legal to put sender_template address different from extended ID when extended ID is non-zero? In your example of fast reroute, Is it legal to put PLR address in the sender_template ? if not, then which one ? Thanks, -- Guangzhi George Swallow wrote: > Eric, Guangzhi - > > We've had a terminology problem with tunnels all along. The way I > think about it is a tunnel is the desire to have a path from a source > to destination. When that desire is frustrated we say the 'tunnel is > down' or no path extists for this tunnel. A tunnel is *normally* > mapped one to one to an LSP. The notable exceptions to this are in > the case of a reroute operation or a fast-reroute. > > The scope of the SE style reservation is to the Session. In order to > limit a session to a single tunnel, we extended the session object to > include the extended tunnel ID. We also renamed the Port field to > tunnel_ID. This creates a means of allowing multiple LSPs to > share a session, (and bandwidth using the SE style). > > The sender_template contains the sender and the LSP_ID. This creates > a means of allowing reroute operations. > > On initial setup any Path message creating an LSP for a tunnel should > have The destination field of the session object set to the > destination of the tunnel and the source in the sender to the > ingress. As the draft says, the extended tunnel_ID is normally zero. > This derives from one vendor's hope that they could avoid LDP > altogether and that merging destination based trees would be the > dominant use of RSVP lsps. Our implementation always fills it in. > > The way I've modeled fast reroute is as follows. > > The node making the repair (Point of local repair or PLR for short) > creates an lsp from itself to the destination for this purpose. > This lsp may merge with the original lsp somewhere prior to the > destination but need not. (Note that if the PLR is the penultimate > node it cannot.) It uniquely identifies that LSP by using its own > address in the sender object. But this only works if the > extended_tunnel ID is in use. (A point that I need to add to my > reroute draft). > > So in practive if the extended tunnel ID is non-zero, use that as the > identifier of the ingress. If it is zero use the sender. > > Also note that for GMPLS some folks are considering doing away with > the requirement that PATH messages are addressed to the destination. > In GMPLS, having non-RSVP routers in the path won't work so the reason > for addressing to the destination is gone. Also it is possible to > have loss of neighbor connectivity in the control plane while the data > plane is just fine. So being able to directly address these without > having to do IPinIP would be useful. Don't know if this will actually > happen, but relying on the Source/Dest address in the IP header of the > Path message may not be a good choice in the long run. > > ...George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 10 16:25:12 2001 Received: from cmr0.ash.ops.us.uu.net ([198.5.241.38]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07645 for ; Thu, 10 May 2001 16:25:12 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkoll04650; Thu, 10 May 2001 20:24:49 GMT Received: by mail-control.mail.uu.net id QQkoll21183 for mpls-outgoing; Thu, 10 May 2001 20:24:22 GMT Received: from imr1.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr1.ash.ops.us.uu.net [153.39.43.46]) id QQkoll20678 for ; Thu, 10 May 2001 20:21:33 GMT Received: from cmr1.ash.ops.us.uu.net by imr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr1.ash.ops.us.uu.net [198.5.241.39]) id QQkoll09137 for ; Thu, 10 May 2001 20:19:08 GMT Received: from mill.cisco.com by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mill.cisco.com [161.44.131.47]) id QQkoll13639 for ; Thu, 10 May 2001 20:19:06 GMT Received: (erosen@localhost) by mill.cisco.com (8.8.5-Cisco.1/8.6.5) id QAA29487 for mpls@uu.net; Thu, 10 May 2001 16:19:06 -0400 (EDT) Received: from imr3.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr3.ash.ops.us.uu.net [153.39.43.47]) id QQkolk17218 for ; Thu, 10 May 2001 20:14:45 GMT Received: from cmr0.ash.ops.us.uu.net by imr3.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkolj16489 for ; Thu, 10 May 2001 19:49:34 GMT Received: from funnel.cisco.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: funnel.cisco.com [161.44.131.24]) id QQkolj26264 for ; Thu, 10 May 2001 19:49:33 GMT Received: from telescope.cisco.com (telescope.cisco.com [161.44.128.68]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA11944; Thu, 10 May 2001 15:49:33 -0400 (EDT) Received: from localhost (swallow@localhost) by telescope.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with ESMTP id PAA05674; Thu, 10 May 2001 15:32:07 -0400 (EDT) Message-Id: <200105101932.PAA05674@telescope.cisco.com> X-Authentication-Warning: telescope.cisco.com: swallow owned process doing -bs To: Guangzhi Li cc: George Swallow , Eric Gray , Eric W Gray , mpls@UU.NET, swallow@cisco.com Subject: Re: Determining the Ingress IP address in an RSVP session In-reply-to: Your message of "Thu, 10 May 2001 15:03:08 EDT." <3AFAE5EC.C229F149@research.att.com> Date: Thu, 10 May 2001 15:32:07 -0400 From: George Swallow Sender: owner-mpls@UU.NET Precedence: bulk Guangzhi - > Thanks. So the conclusion could be: > > (1) In order to support destination rooted tree lsps, the SESSION field > of extended ID must be zero. Yes. > (2) In order to support fast reroute, the SESSION field of extended ID > must be used (non zero). Only if you care about sharing the bandwidth. If you're just doing a best effort service then the restriction isn't necessary. > Then you can not have both. But both are legal based on RSVP-TE. It is > vendor's choice for implementation. But should be ready to accept both. > Right ? Again only if you're worried about bandwidth. > Now sender_template. Is it legal to put sender_template address different > from extended ID when extended ID is non-zero? In your example of fast > reroute, Yes. > Is it legal to put PLR address in the sender_template ? if not, then which > one ? Yes. ,,,George ================================================================== George Swallow Cisco Systems (978) 244-8143 250 Apollo Drive Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 10 17:13:58 2001 Received: from cmr2.ash.ops.us.uu.net ([198.5.241.40]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08423 for ; Thu, 10 May 2001 17:13:58 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkolo14667; Thu, 10 May 2001 21:13:40 GMT Received: by mail-control.mail.uu.net id QQkolo13596 for mpls-outgoing; Thu, 10 May 2001 21:13:08 GMT Received: from imr2.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr2.ash.ops.us.uu.net [153.39.43.15]) id QQkolo13343 for ; Thu, 10 May 2001 21:12:55 GMT Received: from cmr2.ash.ops.us.uu.net by imr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr2.ash.ops.us.uu.net [198.5.241.40]) id QQkolo05045 for ; Thu, 10 May 2001 21:04:17 GMT Received: from mail-blue.research.att.com by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-blue.research.att.com [135.207.30.102]) id QQkolo04562 for ; Thu, 10 May 2001 21:04:17 GMT Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 9B5624DF6E; Thu, 10 May 2001 17:04:13 -0400 (EDT) Received: from research.att.com (dhcp145.research.att.com [135.207.28.145]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id RAA07770; Thu, 10 May 2001 17:04:13 -0400 (EDT) Message-ID: <3AFB0301.4C0AC0B8@research.att.com> Date: Thu, 10 May 2001 17:07:13 -0400 From: Guangzhi Li X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: George Swallow Cc: Eric Gray , Eric W Gray , mpls@UU.NET Subject: Re: Determining the Ingress IP address in an RSVP session References: <200105101932.PAA05674@telescope.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mpls@UU.NET Precedence: bulk Content-Transfer-Encoding: 7bit George: I think your answer solves a lot of questions posted in this mailing list. Thanks, -- Guangzhi George Swallow wrote: > Guangzhi - > > > Thanks. So the conclusion could be: > > > > (1) In order to support destination rooted tree lsps, the SESSION field > > of extended ID must be zero. > > Yes. > > > (2) In order to support fast reroute, the SESSION field of extended ID > > must be used (non zero). > > Only if you care about sharing the bandwidth. If you're just doing a > best effort service then the restriction isn't necessary. > > > Then you can not have both. But both are legal based on RSVP-TE. It is > > vendor's choice for implementation. But should be ready to accept both. > > Right ? > > Again only if you're worried about bandwidth. > > > Now sender_template. Is it legal to put sender_template address different > > from extended ID when extended ID is non-zero? In your example of fast > > reroute, > > Yes. > > > Is it legal to put PLR address in the sender_template ? if not, then which > > one ? > > Yes. > > ,,,George > > ================================================================== > George Swallow Cisco Systems (978) 244-8143 > 250 Apollo Drive > Chelmsford, Ma 01824 From owner-mpls@UU.NET Thu May 10 18:19:28 2001 Received: from cmr1.ash.ops.us.uu.net ([198.5.241.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09157 for ; Thu, 10 May 2001 18:19:28 -0400 (EDT) Received: from mail-control.mail.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: mail-control.mail.uu.net [153.39.51.35]) id QQkolt09951; Thu, 10 May 2001 22:18:50 GMT Received: by mail-control.mail.uu.net id QQkolt10406 for mpls-outgoing; Thu, 10 May 2001 22:18:18 GMT Received: from imr0.ash.ops.us.uu.net by mail-control.mail.uu.net with ESMTP (peer crosschecked as: imr0.ash.ops.us.uu.net [153.39.43.11]) id QQkolt10398 for ; Thu, 10 May 2001 22:18:01 GMT Received: from cmr0.ash.ops.us.uu.net by imr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: cmr0.ash.ops.us.uu.net [198.5.241.38]) id QQkolq19141 for ; Thu, 10 May 2001 21:30:18 GMT Received: from dnsmx1pya.telcordia.com by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: dnsmx1pya.telcordia.com [128.96.20.31]) id QQkolq15186 for ; Thu, 10 May 2001 21:30:18 GMT Received: from notes640.cc.telcordia.com (notes640.cc.telcordia.com [128.96.22.6]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA07489; Thu, 10 May 2001 17:24:50 -0400 (EDT) Subject: RSVP To: George Swallow Cc: mpls@UU.NET From: "Hong Liao" Date: Thu, 10 May 2001 17:25:13 -0400 Message-ID: X-MIMETrack: Serialize by Router on notes640/Telcordia(Release 5.0.6a |January 17, 2001) at 05/10/2001 05:25:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mpls@UU.NET Precedence: bulk Hi George, In ResvErr message, ::= | | o WF Style: ::= o FF style: ::= o SE style: ::= Should ::= [ ] or [ ]