From owner-ips@ece.cmu.edu Sat Dec 1 01:39:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02294 for ; Sat, 1 Dec 2001 01:39:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB15qZH18431 for ips-outgoing; Sat, 1 Dec 2001 00:52:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f167.pav2.hotmail.com [64.4.37.167]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB15qVl18424 for ; Sat, 1 Dec 2001 00:52:31 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 30 Nov 2001 21:52:25 -0800 Received: from 64.38.134.101 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 01 Dec 2001 05:52:25 GMT X-Originating-IP: [64.38.134.101] From: "Bernard Aboba" To: Shridhar_Mukund@adaptec.com, ips@ece.cmu.edu Cc: wdixon@microsoft.com Subject: Re: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I Date: Fri, 30 Nov 2001 21:52:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Dec 2001 05:52:25.0500 (UTC) FILETIME=[5A497DC0:01C17A2C] Sender: owner-ips@ece.cmu.edu Precedence: bulk In our analysis of algorithms, we have been constrained by the transforms existing or under development by IPsec WG. In general, the IPsec WG takes it lead from NIST/ANSI, which looks not only at performance and implementability in hardware and software, but also security and intellectual property issues. To reference a given algorithm in the IPS security draft, we need to be able to reference an IPsec WG transform document, and that in turn tends to be dependent on standardization of the algorithms and modes in question. Thus, the algorithms that are specified in the draft all correspond to previous or current algorithms under consideration by NIST, for which IPsec transform documents exist or are currently under development. You will notice that these algorithms are not necessarily the optimal ones (at least judged by software performance metrics). For example, AES-OCB has considerably lower cycles per-byte cost in software than AES-CTR mode + CBC-MAC with XCBC extensions, though I'm told that they're roughly equivalent in hardware. Another example of non-optimal algorithm selection occurs in the authentication algorithms, where we have HMAC-SHA1 as a MUST and CBC-MAC with XCBC extensions as a SHOULD. As I am sure you are aware, authentication algorithms such as PMAC are MUCH more efficient to implement in hardware, and algorithms such as UMAC are MUCH more efficient to implement in software than the algorithms that we chose. The problem was that our understanding was that neither PMAC nor UMAC was far enough along in the NIST process. Ultimately, the algorithms that end up in the final security document will largely be gated by what IPsec transform documents can be standardized in the necessary timeframe. We chose 3DES-CBC and HMAC-SHA1 as MUST implement because they were already widely implemented and IPsec transform documents exist which we can reference, although the performance of both algorithms is less than ideal for 1+ Gbps operation. The argument was that everyone could at least implement these algorithms, warts and all. Given that 3DES-CBC-I has already been standardized by ANSI, it may be feasible to get an IPsec transform document written and adopted as a work item by IPsec WG. If this can happen, then it would be possible to argue the merits of this algorithm versus the other ones under consideration. Given the prevalence of 3DES-CBC however, I suspect that the argument would be over whether 3DES-CBC-I would become a MAY or a SHOULD implement, rather than a MUST. >From: "Mukund, Shridhar" >To: ips@ece.cmu.edu >CC: "Mukund, Shridhar" >Subject: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I >Date: Fri, 30 Nov 2001 18:15:15 -0800 > > >Hello, > > Re: Choice of ESP alg. in >http://www.ietf.org/internet-drafts/draft-ietf-ips-security-06.txt > > Question: > As noted, we need an algorithm implementable in hardware at speeds >of >up > to 10Gbps, as well as being efficient for implementation in >software >at speeds > of 100Mbps or slower. AES-CTR is an excellent solution. But then it >will take time to > get approved and further time to get "time tested" before being >adopted. Even after > adotion of AES-CTR, 3DES-CBC will need to co-exist for many years >to >come. > > 3DES-CBC does not gracefully scale to 10Gbps for two reasons: > 1. Frequent rekeying at 10Gbps: This issue is discussed in depth in >the draft. > Although very inconvenient, state-of-art IKE stacks (esp. when >running on off-load > processor) can deal with it. > 2. Lack of pipeline-ability: The feedback loop dictated by CBC >prohibits pipelined > high-speed VLSI implementation of the 3DES-CBC engine. > > The ANSI standard X9.52-1998 which specifies 3DES-CBC(TCBC) also >specifies > an equally standard variant called TCBC-I(say 3DES-CBC-Interleaved) >with same > security properties. The effort required to enhance existing >software >and VLSI > implementations of 3DES-CBC to 3DES-CBC-I is "minor". 3DES-CBC can >be >realized > simply thru' a degenerate usage of the 3DES-CBC-I module. On the >positive side, it > brings "substantial" savings in multi-gig VLSI implementation. > Was the candidate ESP algorithm 3DES-CBC-I (superset of 3DES-CBC) >considered > for the SHOULD implement option? Eventually something like AES-CTR >will pervade, > but for the interm this is indeed a low-cost option to get to >speeds >up to 10Gbps. > > Comments on the VLSI implementation: > A 3DES(not 3DES-CBC) engine by itself is highly pipeline-able and >can >pump 10Gbps > even on an FPGA. However for 3DES-CBC, one has to wait for 3DES to >be >completed > on a given 64-bit symbol before commencing 3DES on the next symbol. >As a result, > a "single" 3DES-CBC engine max throughput is somewhere above 1Gbps, >depending > on the process technology. > > As usual, there is a brute-force solution to the problem which >requires use of > multiple 3DES-CBC units. These engines take up significant silicon >real estate. The > implementation complexity is not just due to the multiplicity of >3DES-CBC units but > more so due to all the "incidental" kitchen-sinks and bath-tubs >that >get thrown into > the cauldron to support the multiplicity: scheduler, buffers per >engine(think jumbo frames), > keeping track of contexts (10Gbps traffic could all belong to the >one >connection or > multiple connections), latency, power, ... > > 3DES-CBC-I partitions the symbol stream into three sub-streams so >that a single > engine with three pipeline stages can pump 3X throughput and hence >bring about a > 3X reduction in the kitchen-sink count and complexity. > > Further more: At the time 3DES-CBC-I was conceived multi-gig >throughput at the > network end-point was probably not anticipated(my guess). As a >result, they stopped > at tri-partitioning or 3-levels of interleaving(my guess). After >all >it is only the IP Storage > application that is pioneering multi-gig IPSec throughput at the >end >point. If we used > 8-levels of interleaving we can pump all 10Gbps of throughput >through >a single engine > using current process technologies. No kitchen-sinks, no bath-tubs! > >Thoughts, Comments, Concerns ? > >-Shridhar Mukund > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Sat Dec 1 03:55:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04142 for ; Sat, 1 Dec 2001 03:55:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB18BFJ25624 for ips-outgoing; Sat, 1 Dec 2001 03:11:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB18BDl25620 for ; Sat, 1 Dec 2001 03:11:13 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id JAA33446 for ; Sat, 1 Dec 2001 09:11:06 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB18BMP55764 for ; Sat, 1 Dec 2001 09:11:23 +0100 Subject: Re: Fwd: questions on iSCSI draft To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 1 Dec 2001 09:39:33 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/12/2001 10:11:15 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk some comments in text - Julo Subbu Subramaniam To: "Julian Satran" Subject: Fwd: questions on iSCSI draft 11/29/2001 08:09 PM Hi Julian, I had sent the questions in the attached mail to the mailing list, but nobody has clarified. I thought I would check with the author of the draft. I would appreciate if you can answer them. thanks, -Subbu Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ----- Message from Subbu Subramaniam on Fri, 16 Nov 2001 15:44:13 -0800 (PST) ----- To: ips@ece.cmu.edu cc: subbu_ario@yahoo.com Subject: questions on iSCSI draft Hi, I am reading through the iSCSI draft, and a I have a few questions. I would appreciate if someone clarifies: 1. The default value of FirstBurstSize (amount of data that can be included immediate with a commdn) is 128 units, and that of DataPDULength (amount of data in a DATA-only PDU) is 16 units. If a target can accept 128 bytes of data immediately with a command, do we expect that the same target will only accept less number of units in a later PDU? Why? Should the FirstBurstSize not be less than DataPDULength and not vice versa? (asme argument holds for initiator, since both can specify this option). +++ You must be reading an old version of the spec. But even there the units where not bytes by 512 byte block. First burst includes immediate and unsolicited data PDUs that follow. +++ 2. If a target has sent more than one R2T PDUs, and DataSequenceInOrder is "no", then can the initiator interleave data between the two sequences? It seems that the target should be able to distinguish between the PDUs belonging to the two sequences using the "Buffer Offset" field, and the spec does not prohibit the initiator from sending two sequences simultaneously. +++ The spec requires R2Ts to be fulfilled in order as the target may need the data in that order (and to minimize bookkeeping at the target). +++ Thanks, -Subbu __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com From owner-ips@ece.cmu.edu Sat Dec 1 11:55:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17213 for ; Sat, 1 Dec 2001 11:55:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB1FfJl29358 for ips-outgoing; Sat, 1 Dec 2001 10:41:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB1FfIl29354 for ; Sat, 1 Dec 2001 10:41:18 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA97422 for ; Sat, 1 Dec 2001 09:38:06 -0600 Received: from d04nms19.raleigh.ibm.com (d04nms19.raleigh.ibm.com [9.67.228.10]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB1FfBX134796 for ; Sat, 1 Dec 2001 10:41:16 -0500 Importance: Normal Subject: How Target knows if Initiator is draft 07 or 08? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Allen St Clair" Date: Sat, 1 Dec 2001 10:40:43 -0500 X-MIMETrack: Serialize by Router on D04NMS19/04/M/IBM(Release 5.0.8 |June 18, 2001) at 12/01/2001 10:41:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry if this has been discussed here before... Both draft 08 and 07 use 0x2 for the version number. The iSCSI target needs to know if the iSCSI initiator wants draft 07 or 08 compliance. Would a vender specific key be good for this purpose. For example, X-Version="draft-07" or "draft-08". Any suggestions? Allen From owner-ips@ece.cmu.edu Sat Dec 1 12:38:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18104 for ; Sat, 1 Dec 2001 12:38:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB1GeCx02509 for ips-outgoing; Sat, 1 Dec 2001 11:40:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB1GeAl02503 for ; Sat, 1 Dec 2001 11:40:10 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA20062 for ; Sat, 1 Dec 2001 17:40:03 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB1GeKP35806 for ; Sat, 1 Dec 2001 17:40:20 +0100 Subject: Re: iSCSI:Clear Task Set To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 1 Dec 2001 18:17:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/12/2001 18:40:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I am afraid that is not entirely possible as it may affect other iSCSI barier sets (that is SCSI semantics). Clear task-set is a SCSI command that has clear delivery underpinnings and (as some others) does not offer an easy "layering" way out). We might either drop it (implementation is not mandatory) or implement it with all effects on other initiators. Please do not forget that implementers choosing a common queue technique know what to expect - and they expect a full clear. We may want to take this off-line for a while. Julo "Mallikarjun C." To: ips Subject: Re: iSCSI:Clear Task Set Sent by: owner-ips@ece. cmu.edu 12/01/2001 02:28 AM Please respond to cbm Julian, I tend to agree with John on this one. Passing the 'clear task set' onto target SCSI layer once the current session is dealt with is the right choice. That avoids iSCSI having to say anything on the relative order across sessions, and also addresses the issue John raised - that of differing LUN mappings for the same LU. At a minimum, the second sentence in the current wording "All tasks associated with the specified LUN and initiator. For all other initiators all tasks at LUN with no regard to order." should be dropped since it implies that 'clear task set' affects all other initiators. In fact, this determination can not be made until the TST bit is checked in the SCSI control mode page - which is completely in the SCSI realm. That of course requires the task management function to be propagated up. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > John, > > That looks more like in T10 territory. > T10 defines differently Abort Task Set and Clear Task Set. > We could either: > > decide not to implement clear task set (T10 allows that but "per target" > not "per transport") > enable clear task set - in which case we have to say something about the > relative order of the task management request with regard to the task > comming from other initiators - and that is what I attempted to say in 9.4 > > Julo > > John Hufferd/San Jose/IBM@IBMUS > Sent by: owner-ips@ece.cmu.edu > 23-11-01 23:30 > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI:Clear Task Set > > > > Julian, and list, > The question now becomes, if we have all that carefully thought out > processing that is defined in 9.4 in how to handle the other > Tasks/Commands > that are "In Flight", and not yet given to SCSI, how does that apply to > the > other Sessions with other initiators? > > That is, at the iSCSI Target layer we do not have the LU Number to LU > mapping on any Session with any Initiator, so how do we cause the careful > processing, which is defined in 9.4, to occur on the other sessions that > may have and association to the subject LU? Especially since all we know > is > a LU Number on the Clearing Session. > > Perhaps we do not care about the 9.4 processing on the other Session and > Other Initiators and just let SCSI layer do its thing, and at the iSCSI > layer we pay no attention to the other Sessions. Do you think this is > correct? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/23/2001 07:56:36 AM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI:Clear Task Set > > John, > > The LUN is just a mistake there - in all three instances it should be LU. > The definitions are in accordance with SAM . There are two task management > modes - tasks sets-per-initiator at each LU or common for all initiators. > The mode is a SCSI issue controlled by a field in the Control-Mode page. > Clear task set MAY clear all the tasks in the task set - even if common to > all initiators if that is the way the task set is managed. That is also > the difference between clear-task-set and abort task set. > > Julo > > John Hufferd@IBMUS > 23-11-01 11:29 > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > cc: ips@ece.cmu.edu > From: John Hufferd/San Jose/IBM@IBMUS > Subject: iSCSI:Clear Task Set > > Julian, and List (using v 0.9) > In point 9.4, just before 9.5 the Table entry associated with Clear Task > Set applies to: > > "All tasks associated with the specified LUN and initiator. For all other > initiators all tasks at LUN with no regard to order." > > Perhaps we mean LU here, but I know that the iSCSI layer does not have > information about LU, only about the LU Number (LUN) in the command. We > can not tell, at the iSCSI layer, if the LU represented by a LUN on > Session 1, has any relationship to any LUN on any other session. > > This is because each initiator may have their own numbering for LUs. > Therefore, do we just pass the Clear Task Set to the SCSI layer and hope > for the best, or does the iSCSI layer also suppose to apply the Clear Task > Set to all the sessions that it has coming into the iSCSI (SCSI) Target > Port? If the latter, again how will that work when the iSCSI layer has no > idea what LU an Initiator's LUN will map to? > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Dec 1 12:41:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18177 for ; Sat, 1 Dec 2001 12:41:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB1GeBW02507 for ips-outgoing; Sat, 1 Dec 2001 11:40:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB1Ge8l02497 for ; Sat, 1 Dec 2001 11:40:08 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA19548 for ; Sat, 1 Dec 2001 17:40:01 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB1GeJx177576 for ; Sat, 1 Dec 2001 17:40:20 +0100 Subject: Re: iSCSI DataSN Can equal 2**32 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 1 Dec 2001 18:09:25 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/12/2001 18:40:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, I'll fix the wording - and the conflicting statement about data ack. Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: 12/01/2001 From: John Hufferd/San Jose/IBM@IBMUS 11:04 AM Subject: Re: iSCSI DataSN Can equal 2**32(Document link: Julian Satran - Mail) Julian, I think that is what I said. The document does not say that the largest number is 2**32-1, it says the number of PDUs sent must be 2**32-1, and then be less then that. I thought I understood what is meant, but it is not what is written. Please see my suggestions for rewrite, highlighted in red, below. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 11/30/2001 08:51 PM To: John Hufferd/San Jose/IBM@IBMUS@IBMDE cc: From: Julian Satran/Haifa/IBM@Haifa/IBM@IBMIL Subject: Re: iSCSI DataSN Can equal 2**32 (Document link: John Hufferd) John, The limitation to 2**31-1 stems from the ExpDataSN - the number of data/R2T PDUs the target has sent. The largest number that can be announced is 2**31-1 and that means 2**32 PDUs (numbering starts from 0). Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu 11/30/2001 From: John Hufferd/San Jose/IBM@IBMUS 08:46 AM Subject: iSCSI DataSN Can equal 2**32 Julian, At 3.7.5 there is a statement that data sequence MUST contain less then 2**32-1 numbered PDUs. I did not understand that since the count starts at 0, which should mean that 2**32 PDUs could be possible. So I do not understand the -1 in the count of PDUs, and I then do not understand "less then" (which I guess would mean 2**32-2). I think the number should be able to go from 0 to 2**32-1, inclusive, which is 2*32 different PDUs and not "less then 2**32-1". Perhaps the statement should read that the sequence number of the Data PDU can not be greater then 2**32-1. Or the total number of Data PDUs in a Sequence can not be greater then 2**32. But perhaps I missed something. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Dec 1 17:36:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23316 for ; Sat, 1 Dec 2001 17:36:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB1LljJ20429 for ips-outgoing; Sat, 1 Dec 2001 16:47:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB1Llhl20423 for ; Sat, 1 Dec 2001 16:47:43 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Dec 2001 16:47:34 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937231@CORPMX14> From: Black_David@emc.com To: stclair@us.ibm.com, ips@ece.cmu.edu Subject: iSCSI: RE: How Target knows if Initiator is draft 07 or 08? Date: Sat, 1 Dec 2001 16:36:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Given that the protocol is still under development, the Initiator should be doing -08 (actually -09 now), and if the Initiator can't cope, it's broken and needs to be updated. I'm not real pleased that the version number has advanced over the course of draft revisions, and the final RFC will NOT contain features intended only to support implementations that use an old draft version of the protocol and hence don't comply with the RFC. Every Internet-Draft contains a long version of "subject to change", and implementations based on old versions need to be updated as opposed to burdening implementers who are making the required changes with the hassle of dealing with other implementations that haven't. Be forewarned that further requests of this form may result in instructions from on high to rev the version number downward in a future draft version. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Allen St Clair [mailto:stclair@us.ibm.com] > Sent: Saturday, December 01, 2001 10:41 AM > To: ips@ece.cmu.edu > Subject: How Target knows if Initiator is draft 07 or 08? > > > Sorry if this has been discussed here before... > > Both draft 08 and 07 use 0x2 for the version number. The iSCSI target > needs to know if the iSCSI initiator wants draft 07 or 08 compliance. > Would a vender specific key be good for this purpose. For example, > > X-Version="draft-07" or "draft-08". > > Any suggestions? > > Allen > From owner-ips@ece.cmu.edu Sat Dec 1 17:42:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23520 for ; Sat, 1 Dec 2001 17:42:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB1M0gu21209 for ips-outgoing; Sat, 1 Dec 2001 17:00:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB1M0el21204 for ; Sat, 1 Dec 2001 17:00:40 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Dec 2001 16:56:35 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937232@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI:Clear Task Set Date: Sat, 1 Dec 2001 16:49:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk A few points of advice on this issue: - Clear Task Set needs to be in the iSCSI protocol. It can be OPTIONAL to implement, but failing to specify it will cause issues with T10 down the road. - I think John started this thread with a confused notion. SCSI does not require any ordering of delivery across multiple nexii (nexuses). All the stuff in 9.4 applies only to the iSCSI session on which the Clear Task Set arrives, and exists because we are trying to: - Have our cake: Process Clear Task Set immediately without waiting for any prior (according to CmdSN) in-flight commands to arrive. - And eat it too: Respect SAM-2's ordering requirements for Task Management commands. As noted above, these requirements only apply to a single iSCSI session (SCSI IT nexus). - Please recall a number of prior comments from SCSI experts on this list about the effects of SCSI task management commands (e.g., Clear Task Set) not being entirely predictable. If there are commands in flight/pending on one nexus and a Clear Task Set is issued to the same LU on another nexus, there are a number of possible outcomes in terms of which commands on the first nexus are aborted. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, December 01, 2001 11:18 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI:Clear Task Set > > > Mallikarjun, > > I am afraid that is not entirely possible as it may affect other iSCSI > barier sets (that is SCSI semantics). > Clear task-set is a SCSI command that has clear delivery > underpinnings and > (as some others) does not offer an easy "layering" way out). We might > either drop it (implementation is not mandatory) or implement > it with all > effects on other initiators. > Please do not forget that implementers choosing a common > queue technique > know what to expect - and they expect a full clear. > We may want to take this off-line for a while. > > Julo > > > > > > "Mallikarjun > > C." To: ips > > > > om> Subject: Re: > iSCSI:Clear Task Set > > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 12/01/2001 > > 02:28 AM > > Please respond > > to cbm > > > > > > > > > Julian, > > I tend to agree with John on this one. > > Passing the 'clear task set' onto target SCSI layer once > the current session is dealt with is the right choice. That > avoids iSCSI having to say anything on the relative order > across sessions, and also addresses the issue John raised - > that of differing LUN mappings for the same LU. > > At a minimum, the second sentence in the current wording > > "All tasks associated with the specified LUN and initiator. > For all other initiators all tasks at LUN with no regard > to order." > > should be dropped since it implies that 'clear task set' affects > all other initiators. In fact, this determination can not be made > until the TST bit is checked in the SCSI control mode page - which > is completely in the SCSI realm. That of course requires the task > management function to be propagated up. > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > John, > > > > That looks more like in T10 territory. > > T10 defines differently Abort Task Set and Clear Task Set. > > We could either: > > > > decide not to implement clear task set (T10 allows that but > "per target" > > not "per transport") > > enable clear task set - in which case we have to say > something about the > > relative order of the task management request with regard > to the task > > comming from other initiators - and that is what I > attempted to say in > 9.4 > > > > Julo > > > > John Hufferd/San Jose/IBM@IBMUS > > Sent by: owner-ips@ece.cmu.edu > > 23-11-01 23:30 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI:Clear Task Set > > > > > > > > Julian, and list, > > The question now becomes, if we have all that carefully thought out > > processing that is defined in 9.4 in how to handle the other > > Tasks/Commands > > that are "In Flight", and not yet given to SCSI, how does > that apply to > > the > > other Sessions with other initiators? > > > > That is, at the iSCSI Target layer we do not have the LU > Number to LU > > mapping on any Session with any Initiator, so how do we > cause the careful > > processing, which is defined in 9.4, to occur on the other > sessions that > > may have and association to the subject LU? Especially > since all we know > > is > > a LU Number on the Clearing Session. > > > > Perhaps we do not care about the 9.4 processing on the > other Session and > > Other Initiators and just let SCSI layer do its thing, and > at the iSCSI > > layer we pay no attention to the other Sessions. Do you > think this is > > correct? > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > Internet address: hufferd@us.ibm.com > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/23/2001 07:56:36 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI:Clear Task Set > > > > John, > > > > The LUN is just a mistake there - in all three instances it > should be LU. > > The definitions are in accordance with SAM . There are two task > management > > modes - tasks sets-per-initiator at each LU or common for > all initiators. > > The mode is a SCSI issue controlled by a field in the > Control-Mode page. > > Clear task set MAY clear all the tasks in the task set - > even if common > to > > all initiators if that is the way the task set is managed. > That is also > > the difference between clear-task-set and abort task set. > > > > Julo > > > > John Hufferd@IBMUS > > 23-11-01 11:29 > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > cc: ips@ece.cmu.edu > > From: John Hufferd/San Jose/IBM@IBMUS > > Subject: iSCSI:Clear Task Set > > > > Julian, and List (using v 0.9) > > In point 9.4, just before 9.5 the Table entry associated > with Clear Task > > Set applies to: > > > > "All tasks associated with the specified LUN and initiator. > For all other > > initiators all tasks at LUN with no regard to order." > > > > Perhaps we mean LU here, but I know that the iSCSI layer > does not have > > information about LU, only about the LU Number (LUN) in the > command. We > > can not tell, at the iSCSI layer, if the LU represented > by a LUN on > > Session 1, has any relationship to any LUN on any other session. > > > > This is because each initiator may have their own numbering for LUs. > > Therefore, do we just pass the Clear Task Set to the SCSI > layer and hope > > for the best, or does the iSCSI layer also suppose to apply > the Clear > Task > > Set to all the sessions that it has coming into the iSCSI > (SCSI) Target > > Port? If the latter, again how will that work when the > iSCSI layer has > no > > idea what LU an Initiator's LUN will map to? > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > Internet address: hufferd@us.ibm.com > > > > From owner-ips@ece.cmu.edu Sat Dec 1 21:17:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26463 for ; Sat, 1 Dec 2001 21:17:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB21DL002444 for ips-outgoing; Sat, 1 Dec 2001 20:13:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB21DKl02440 for ; Sat, 1 Dec 2001 20:13:20 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Sat, 1 Dec 2001 20:09:18 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937238@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI:Clear Task Set Date: Sat, 1 Dec 2001 20:02:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk On rereading the original thread, I screwed up ... > - I think John started this thread with a confused notion. That's wrong and I apologize. John's initial post was about using LU rather than LUN, which is correct. The thread subsequently drifted in the direction of trying to have iSCSI do some sort of coordination of Clear Task Set across Initiators. As I hope is clear from below, those sort of effects are in SCSI's domain and not completely predictable. Thanks/Sorry, --David > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Saturday, December 01, 2001 4:50 PM > To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > Subject: RE: iSCSI:Clear Task Set > > > A few points of advice on this issue: > - Clear Task Set needs to be in the iSCSI protocol. It can > be OPTIONAL to implement, but failing to specify it will > cause issues with T10 down the road. > - I think John started this thread with a confused notion. > SCSI does not require any ordering of delivery across > multiple nexii (nexuses). All the stuff in 9.4 applies > only to the iSCSI session on which the Clear Task Set > arrives, and exists because we are trying to: > - Have our cake: Process Clear Task Set immediately > without waiting for any prior (according to CmdSN) > in-flight commands to arrive. > - And eat it too: Respect SAM-2's ordering requirements > for Task Management commands. As noted above, > these requirements only apply to a single iSCSI > session (SCSI IT nexus). > - Please recall a number of prior comments from SCSI experts > on this list about the effects of SCSI task management > commands (e.g., Clear Task Set) not being entirely > predictable. If there are commands in flight/pending > on one nexus and a Clear Task Set is issued to the same LU > on another nexus, there are a number of possible outcomes > in terms of which commands on the first nexus are aborted. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Saturday, December 01, 2001 11:18 AM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI:Clear Task Set > > > > > > Mallikarjun, > > > > I am afraid that is not entirely possible as it may affect > other iSCSI > > barier sets (that is SCSI semantics). > > Clear task-set is a SCSI command that has clear delivery > > underpinnings and > > (as some others) does not offer an easy "layering" way > out). We might > > either drop it (implementation is not mandatory) or implement > > it with all > > effects on other initiators. > > Please do not forget that implementers choosing a common > > queue technique > > know what to expect - and they expect a full clear. > > We may want to take this off-line for a while. > > > > Julo > > > > > > > > > > > > > "Mallikarjun > > > > > C." To: ips > > > > > > > > > > om> Subject: Re: > > iSCSI:Clear Task Set > > > > Sent by: > > > > > owner-ips@ece. > > > > > cmu.edu > > > > > > > > > > > > > > > 12/01/2001 > > > > > 02:28 AM > > > > > Please respond > > > > > to cbm > > > > > > > > > > > > > > > > > > > > > Julian, > > > > I tend to agree with John on this one. > > > > Passing the 'clear task set' onto target SCSI layer once > > the current session is dealt with is the right choice. That > > avoids iSCSI having to say anything on the relative order > > across sessions, and also addresses the issue John raised - > > that of differing LUN mappings for the same LU. > > > > At a minimum, the second sentence in the current wording > > > > "All tasks associated with the specified LUN and initiator. > > For all other initiators all tasks at LUN with no regard > > to order." > > > > should be dropped since it implies that 'clear task set' affects > > all other initiators. In fact, this determination can not be made > > until the TST bit is checked in the SCSI control mode page - which > > is completely in the SCSI realm. That of course requires the task > > management function to be propagated up. > > > > Regards. > > -- > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Julian Satran wrote: > > > > > > John, > > > > > > That looks more like in T10 territory. > > > T10 defines differently Abort Task Set and Clear Task Set. > > > We could either: > > > > > > decide not to implement clear task set (T10 allows that but > > "per target" > > > not "per transport") > > > enable clear task set - in which case we have to say > > something about the > > > relative order of the task management request with regard > > to the task > > > comming from other initiators - and that is what I > > attempted to say in > > 9.4 > > > > > > Julo > > > > > > John Hufferd/San Jose/IBM@IBMUS > > > Sent by: owner-ips@ece.cmu.edu > > > 23-11-01 23:30 > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI:Clear Task Set > > > > > > > > > > > > Julian, and list, > > > The question now becomes, if we have all that carefully > thought out > > > processing that is defined in 9.4 in how to handle the other > > > Tasks/Commands > > > that are "In Flight", and not yet given to SCSI, how does > > that apply to > > > the > > > other Sessions with other initiators? > > > > > > That is, at the iSCSI Target layer we do not have the LU > > Number to LU > > > mapping on any Session with any Initiator, so how do we > > cause the careful > > > processing, which is defined in 9.4, to occur on the other > > sessions that > > > may have and association to the subject LU? Especially > > since all we know > > > is > > > a LU Number on the Clearing Session. > > > > > > Perhaps we do not care about the 9.4 processing on the > > other Session and > > > Other Initiators and just let SCSI layer do its thing, and > > at the iSCSI > > > layer we pay no attention to the other Sessions. Do you > > think this is > > > correct? > > > > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > > Internet address: hufferd@us.ibm.com > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/23/2001 > 07:56:36 AM > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: Re: iSCSI:Clear Task Set > > > > > > John, > > > > > > The LUN is just a mistake there - in all three instances it > > should be LU. > > > The definitions are in accordance with SAM . There are two task > > management > > > modes - tasks sets-per-initiator at each LU or common for > > all initiators. > > > The mode is a SCSI issue controlled by a field in the > > Control-Mode page. > > > Clear task set MAY clear all the tasks in the task set - > > even if common > > to > > > all initiators if that is the way the task set is managed. > > That is also > > > the difference between clear-task-set and abort task set. > > > > > > Julo > > > > > > John Hufferd@IBMUS > > > 23-11-01 11:29 > > > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > > cc: ips@ece.cmu.edu > > > From: John Hufferd/San Jose/IBM@IBMUS > > > Subject: iSCSI:Clear Task Set > > > > > > Julian, and List (using v 0.9) > > > In point 9.4, just before 9.5 the Table entry associated > > with Clear Task > > > Set applies to: > > > > > > "All tasks associated with the specified LUN and initiator. > > For all other > > > initiators all tasks at LUN with no regard to order." > > > > > > Perhaps we mean LU here, but I know that the iSCSI layer > > does not have > > > information about LU, only about the LU Number (LUN) in the > > command. We > > > can not tell, at the iSCSI layer, if the LU represented > > by a LUN on > > > Session 1, has any relationship to any LUN on any other session. > > > > > > This is because each initiator may have their own > numbering for LUs. > > > Therefore, do we just pass the Clear Task Set to the SCSI > > layer and hope > > > for the best, or does the iSCSI layer also suppose to apply > > the Clear > > Task > > > Set to all the sessions that it has coming into the iSCSI > > (SCSI) Target > > > Port? If the latter, again how will that work when the > > iSCSI layer has > > no > > > idea what LU an Initiator's LUN will map to? > > > . > > > . > > > . > > > John L. Hufferd > > > Senior Technical Staff Member (STSM) > > > IBM/SSG San Jose Ca > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > > Internet address: hufferd@us.ibm.com > > > > > > > > > From owner-ips@ece.cmu.edu Sun Dec 2 18:57:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00510 for ; Sun, 2 Dec 2001 18:57:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB2MrdZ22334 for ips-outgoing; Sun, 2 Dec 2001 17:53:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from antipater.hosting.pacbell.net (antipater.hosting.pacbell.net [216.100.99.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB2Mral22327 for ; Sun, 2 Dec 2001 17:53:36 -0500 (EST) Received: from somesh (sdsl-66-80-0-42.dsl.sca.megapath.net [66.80.0.42]) by antipater.hosting.pacbell.net id RAA01254; Sun, 2 Dec 2001 17:53:22 -0500 (EST) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Sandeep Joshi" , Subject: RE: iSCSI: unsolicited data Date: Sun, 2 Dec 2001 14:52:30 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <3C0817F2.88647D65@research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep, As discussed earlier, the implementation complexity, especially in network processor like devices is very different between the two cases - data in the same order as the commands, and not in the same order is very different. It is best if as you suggest, data follows the PDU. In any case, the condition of having the data follow in the same order as the commands should not be relaxed at all. Only in the presence of an actual digest error should this condition be not considered a severe protocol error. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sandeep Joshi > Sent: Friday, November 30, 2001 3:36 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: unsolicited data > > > > Julian, > > Perhaps this thread was missed..could you please elaborate on this > deadlock issue..when exactly does it occur? > Note that I am not asking for out-of-order data! > > There was one more question - regarding the allowance given > to the initiator to *not* send unsolicited PDUs right after > the command PDUs, which raises persistent questions. > > See http://www.pdl.cmu.edu/mailinglists/ips/mail/msg07930.html > for the latest question on this issue. > > IIRC, the reasoning here was that this helps the target in "positioning" > operations - since it gets a few commands first, and then the data. > By positioning, do you imply disk/tape seeks or something else ? > Note that the draft must atleast mention the above rationale if we > wish initiators to behave as such, and also targets to optimize for it. > > Regards, > -Sandeep > > "Mallikarjun C." wrote: > > I however could not really see a deadlock per se - my comment was to > > understand > > what it is. More comments would certainly help. > > > > ----- Original Message ----- > > From: "Julian Satran" > > > Mallikarjun, > > > > > > The deadlock free requirement here goes a bit deeper than > your comment may > > > suggest. > > > Unsolicited data needs are very hard to predict and ordering them may > > > remove the need to do so to a large extent. > From owner-ips@ece.cmu.edu Sun Dec 2 18:58:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00521 for ; Sun, 2 Dec 2001 18:58:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB2NXVE24673 for ips-outgoing; Sun, 2 Dec 2001 18:33:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB2NXTl24665 for ; Sun, 2 Dec 2001 18:33:29 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 6121C1F8C7 for ; Sun, 2 Dec 2001 15:33:20 -0800 (PST) Received: from swathi (pal1nai160149.nsr.hp.com [15.244.160.149]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA19114 for ; Sun, 2 Dec 2001 15:34:50 -0800 (PST) Message-ID: <005501c17b89$b9728270$95a0f40f@rose.hp.com> From: "Mallikarjun C." To: "ips" Subject: iSCSI: abort task & abort task set Date: Sun, 2 Dec 2001 15:33:18 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, iSCSI currently requires two responses to be returned for an aborted task - one for the original task with a "good" status, and the second for the task management function (TMF) itself. So, the following legal behaviors are required of a target - a) plug the CmdSN gap if the command was not received, b) send a SCSI response and TMF response if the task still is active, c) send a TMF response if the task isn't active (if already complete). I would like to suggest that we reconsider our approach for case (b) for a variety of reasons, to change it to: b) send a TMF response signalling that the abort is complete, if the task still is active. Here are my reasons - 1. Target iSCSI layer would need to make a SCSI response up on an abort of an active task. It then follows that the iSCSI layer may have to make up several SCSI responses on an 'abort task set'. 2. The current approach also creates a side effect that isn't readily apparent for 'abort task set'. Initiators would need to stall processing 'abort task set' TMF response till task responses (to account for all the tasks in the task set) on multiple TCP connections (possibly on different NICs) are received - which I am afraid would tantamount to an initiator scoreboard. 3. The current approach complicates initiator implementations that want to process a successful SCSI completion even after they initiated timeout processing since on an 'abort task set', initiators can never be sure if the response was pre-abort, or post-abort (made up "good" status). I believe it is worth preserving this implementation choice. 4. I am further concerned that iSCSI is possibly in violation of the spirit of SAM-2, rev20. - clause 5.6.2 that states - "When an initiator causes its own task(s) to be aborted, no notification that the task(s) have been aborted shall be returned to the initiator other than the completion response for the command or task management function action that caused the task(s) to be aborted and notification(s) associated with related effects of the action (e.g., a target reset unit attention condition)." - clause 5.3.1 that states - "GOOD. This status indicates that the device server has successfully completed the task." I propose that the target deliver only the TMF response on an abort of an active task on an 'abort task' TMF, and not transmit an 'abort task set' TMF response until all the current StatSN's on all connections (as on the completion of "abort task set') in the session are ack'ed. This ack may be solicited by way of a NOP-IN with valid TTT. This gives the determinism to initiators that (a) abort task set TMF response signifies that the entire task set had been dealt with, and (b) every task response is a true SCSI end-to-end reponse (not generated by iSCSI), besides doing away with SCSI-response code in the target iSCSI layer. Comments? Did I miss any corner cases? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 From owner-ips@ece.cmu.edu Sun Dec 2 19:37:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00874 for ; Sun, 2 Dec 2001 19:37:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB2Nkxf25439 for ips-outgoing; Sun, 2 Dec 2001 18:46:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB2Nkvl25433 for ; Sun, 2 Dec 2001 18:46:58 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id C9FBA514; Sun, 2 Dec 2001 18:46:56 -0500 (EST) Received: from swathi (pal1nai160149.nsr.hp.com [15.244.160.149]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA20245; Sun, 2 Dec 2001 15:48:25 -0800 (PST) Message-ID: <006801c17b8b$9fa4e8e0$95a0f40f@rose.hp.com> From: "Mallikarjun C." To: Cc: "ips" References: <277DD60FB639D511AC0400B0D068B71E02937238@CORPMX14> Subject: Re: iSCSI:Clear Task Set Date: Sun, 2 Dec 2001 15:46:54 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > those sort of effects are in SCSI's domain and not completely > predictable. Exactly. That's the reason I suggested that iSCSI should not comment on ordering or lack thereof for other sessions, and also suggested that we note that the said task management function be propagated upto SCSI always. Julian may have other reasons - I will check with him as he suggested. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Sent: Saturday, December 01, 2001 5:02 PM Subject: RE: iSCSI:Clear Task Set > On rereading the original thread, I screwed up ... > > > - I think John started this thread with a confused notion. > > That's wrong and I apologize. John's initial post was > about using LU rather than LUN, which is correct. The > thread subsequently drifted in the direction of trying > to have iSCSI do some sort of coordination of Clear Task > Set across Initiators. As I hope is clear from below, > those sort of effects are in SCSI's domain and not completely > predictable. > > Thanks/Sorry, > --David > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Saturday, December 01, 2001 4:50 PM > > To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu > > Subject: RE: iSCSI:Clear Task Set > > > > > > A few points of advice on this issue: > > - Clear Task Set needs to be in the iSCSI protocol. It can > > be OPTIONAL to implement, but failing to specify it will > > cause issues with T10 down the road. > > - I think John started this thread with a confused notion. > > SCSI does not require any ordering of delivery across > > multiple nexii (nexuses). All the stuff in 9.4 applies > > only to the iSCSI session on which the Clear Task Set > > arrives, and exists because we are trying to: > > - Have our cake: Process Clear Task Set immediately > > without waiting for any prior (according to CmdSN) > > in-flight commands to arrive. > > - And eat it too: Respect SAM-2's ordering requirements > > for Task Management commands. As noted above, > > these requirements only apply to a single iSCSI > > session (SCSI IT nexus). > > - Please recall a number of prior comments from SCSI experts > > on this list about the effects of SCSI task management > > commands (e.g., Clear Task Set) not being entirely > > predictable. If there are commands in flight/pending > > on one nexus and a Clear Task Set is issued to the same LU > > on another nexus, there are a number of possible outcomes > > in terms of which commands on the first nexus are aborted. > > > > Thanks, > > --David > > > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Saturday, December 01, 2001 11:18 AM > > > To: ips@ece.cmu.edu > > > Subject: Re: iSCSI:Clear Task Set > > > > > > > > > Mallikarjun, > > > > > > I am afraid that is not entirely possible as it may affect > > other iSCSI > > > barier sets (that is SCSI semantics). > > > Clear task-set is a SCSI command that has clear delivery > > > underpinnings and > > > (as some others) does not offer an easy "layering" way > > out). We might > > > either drop it (implementation is not mandatory) or implement > > > it with all > > > effects on other initiators. > > > Please do not forget that implementers choosing a common > > > queue technique > > > know what to expect - and they expect a full clear. > > > We may want to take this off-line for a while. > > > > > > Julo > > > > > > > > > > > > > > > > > > > > "Mallikarjun > > > > > > > > C." To: ips > > > > > > > > > > > > > > > > om> Subject: Re: > > > iSCSI:Clear Task Set > > > > > > Sent by: > > > > > > > > owner-ips@ece. > > > > > > > > cmu.edu > > > > > > > > > > > > > > > > > > > > > > > > 12/01/2001 > > > > > > > > 02:28 AM > > > > > > > > Please respond > > > > > > > > to cbm > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Julian, > > > > > > I tend to agree with John on this one. > > > > > > Passing the 'clear task set' onto target SCSI layer once > > > the current session is dealt with is the right choice. That > > > avoids iSCSI having to say anything on the relative order > > > across sessions, and also addresses the issue John raised - > > > that of differing LUN mappings for the same LU. > > > > > > At a minimum, the second sentence in the current wording > > > > > > "All tasks associated with the specified LUN and initiator. > > > For all other initiators all tasks at LUN with no regard > > > to order." > > > > > > should be dropped since it implies that 'clear task set' affects > > > all other initiators. In fact, this determination can not be made > > > until the TST bit is checked in the SCSI control mode page - which > > > is completely in the SCSI realm. That of course requires the task > > > management function to be propagated up. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Julian Satran wrote: > > > > > > > > John, > > > > > > > > That looks more like in T10 territory. > > > > T10 defines differently Abort Task Set and Clear Task Set. > > > > We could either: > > > > > > > > decide not to implement clear task set (T10 allows that but > > > "per target" > > > > not "per transport") > > > > enable clear task set - in which case we have to say > > > something about the > > > > relative order of the task management request with regard > > > to the task > > > > comming from other initiators - and that is what I > > > attempted to say in > > > 9.4 > > > > > > > > Julo > > > > > > > > John Hufferd/San Jose/IBM@IBMUS > > > > Sent by: owner-ips@ece.cmu.edu > > > > 23-11-01 23:30 > > > > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI:Clear Task Set > > > > > > > > > > > > > > > > Julian, and list, > > > > The question now becomes, if we have all that carefully > > thought out > > > > processing that is defined in 9.4 in how to handle the other > > > > Tasks/Commands > > > > that are "In Flight", and not yet given to SCSI, how does > > > that apply to > > > > the > > > > other Sessions with other initiators? > > > > > > > > That is, at the iSCSI Target layer we do not have the LU > > > Number to LU > > > > mapping on any Session with any Initiator, so how do we > > > cause the careful > > > > processing, which is defined in 9.4, to occur on the other > > > sessions that > > > > may have and association to the subject LU? Especially > > > since all we know > > > > is > > > > a LU Number on the Clearing Session. > > > > > > > > Perhaps we do not care about the 9.4 processing on the > > > other Session and > > > > Other Initiators and just let SCSI layer do its thing, and > > > at the iSCSI > > > > layer we pay no attention to the other Sessions. Do you > > > think this is > > > > correct? > > > > > > > > . > > > > . > > > > . > > > > John L. Hufferd > > > > Senior Technical Staff Member (STSM) > > > > IBM/SSG San Jose Ca > > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > > > Internet address: hufferd@us.ibm.com > > > > > > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 11/23/2001 > > 07:56:36 AM > > > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > To: ips@ece.cmu.edu > > > > cc: > > > > Subject: Re: iSCSI:Clear Task Set > > > > > > > > John, > > > > > > > > The LUN is just a mistake there - in all three instances it > > > should be LU. > > > > The definitions are in accordance with SAM . There are two task > > > management > > > > modes - tasks sets-per-initiator at each LU or common for > > > all initiators. > > > > The mode is a SCSI issue controlled by a field in the > > > Control-Mode page. > > > > Clear task set MAY clear all the tasks in the task set - > > > even if common > > > to > > > > all initiators if that is the way the task set is managed. > > > That is also > > > > the difference between clear-task-set and abort task set. > > > > > > > > Julo > > > > > > > > John Hufferd@IBMUS > > > > 23-11-01 11:29 > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL@IBMDE > > > > cc: ips@ece.cmu.edu > > > > From: John Hufferd/San Jose/IBM@IBMUS > > > > Subject: iSCSI:Clear Task Set > > > > > > > > Julian, and List (using v 0.9) > > > > In point 9.4, just before 9.5 the Table entry associated > > > with Clear Task > > > > Set applies to: > > > > > > > > "All tasks associated with the specified LUN and initiator. > > > For all other > > > > initiators all tasks at LUN with no regard to order." > > > > > > > > Perhaps we mean LU here, but I know that the iSCSI layer > > > does not have > > > > information about LU, only about the LU Number (LUN) in the > > > command. We > > > > can not tell, at the iSCSI layer, if the LU represented > > > by a LUN on > > > > Session 1, has any relationship to any LUN on any other session. > > > > > > > > This is because each initiator may have their own > > numbering for LUs. > > > > Therefore, do we just pass the Clear Task Set to the SCSI > > > layer and hope > > > > for the best, or does the iSCSI layer also suppose to apply > > > the Clear > > > Task > > > > Set to all the sessions that it has coming into the iSCSI > > > (SCSI) Target > > > > Port? If the latter, again how will that work when the > > > iSCSI layer has > > > no > > > > idea what LU an Initiator's LUN will map to? > > > > . > > > > . > > > > . > > > > John L. Hufferd > > > > Senior Technical Staff Member (STSM) > > > > IBM/SSG San Jose Ca > > > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > > > > Home Office (408) 997-6136, Cell: (408) 499-9702 > > > > Internet address: hufferd@us.ibm.com > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 3 06:13:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25986 for ; Mon, 3 Dec 2001 06:13:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3A47e00759 for ips-outgoing; Mon, 3 Dec 2001 05:04:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.bld.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3A46l00755 for ; Mon, 3 Dec 2001 05:04:06 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA23066 for ; Mon, 3 Dec 2001 05:01:19 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB3A44f45486 for ; Mon, 3 Dec 2001 03:04:04 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI Typo in R2T w.r.t. DataSequenceInOrder To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 3 Dec 2001 02:03:08 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/03/2001 03:04:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I think there is a typo in 3.8 just above 3.8.1 where is says: "...If DataSequenceInOrder is yes then consecutive R2Ts SHOULD refer to continuous non-overlapping ranges. However, even when DataSequenceInOrder is no, a target MAY send out-of-order R2Ts (e.g., for recovery) ..." I think it should read: "... However, even when DataSequenceInOrder is yes, a target MAY .... " . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Dec 3 08:32:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28324 for ; Mon, 3 Dec 2001 08:32:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3CVR719363 for ips-outgoing; Mon, 3 Dec 2001 07:31:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3CVPl19358 for ; Mon, 3 Dec 2001 07:31:25 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id NAA79716 for ; Mon, 3 Dec 2001 13:31:13 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB3CVOu59332 for ; Mon, 3 Dec 2001 13:31:30 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: abort task & abort task set X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Julian Satran" Message-ID: Date: Mon, 3 Dec 2001 14:31:16 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/12/2001 14:31:23, Serialize complete at 03/12/2001 14:31:23 Content-Type: multipart/alternative; boundary="=_alternative 00449F5042256B17_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00449F5042256B17_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, Comments in text - Julo PS - I would like also to point out that we may want to consider a very simple alternative to the barrier scheme outlined in 9.4 - that will require less cooperation between initiator and will be simpler to read and implement. I will outline such a scheme soon. "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 12/03/2001 01:33 AM To: "ips" cc: Subject: iSCSI: abort task & abort task set Julian, iSCSI currently requires two responses to be returned for an aborted task - one for the original task with a "good" status, and the second for the task management function (TMF) itself. So, the following legal behaviors are required of a target - a) plug the CmdSN gap if the command was not received, b) send a SCSI response and TMF response if the task still is active, c) send a TMF response if the task isn't active (if already complete). I would like to suggest that we reconsider our approach for case (b) for a variety of reasons, to change it to: b) send a TMF response signalling that the abort is complete, if the task still is active. Here are my reasons - 1. Target iSCSI layer would need to make a SCSI response up on an abort of an active task. It then follows that the iSCSI layer may have to make up several SCSI responses on an 'abort task set'. 2. The current approach also creates a side effect that isn't readily apparent for 'abort task set'. Initiators would need to stall processing 'abort task set' TMF response till task responses (to account for all the tasks in the task set) on multiple TCP connections (possibly on different NICs) are received - which I am afraid would tantamount to an initiator scoreboard. +++ That is not entirely correct. The whole purpose of requiring the target to send a "good status" is to allow the initiator to send the response immediately and have the initiator mark its internal data structures as aborted - but avoid reusing ITT untill it gets the good answer. This way initiator can make progress and it can be sure that it won't be surprised by an "old" answer after it has reused the ITT +++ 3. The current approach complicates initiator implementations that want to process a successful SCSI completion even after they initiated timeout processing since on an 'abort task set', initiators can never be sure if the response was pre-abort, or post-abort (made up "good" status). I believe it is worth preserving this implementation choice. +++ see above +++ 4. I am further concerned that iSCSI is possibly in violation of the spirit of SAM-2, rev20. - clause 5.6.2 that states - "When an initiator causes its own task(s) to be aborted, no notification that the task(s) have been aborted shall be returned to the initiator other than the completion response for the command or task management function action that caused the task(s) to be aborted and notification(s) associated with related effects of the action (e.g., a target reset unit attention condition)." +++ I did say explicitly that the good status is a "good-will" message between iSCSI target and initiator. It does not have to reach SCSI. SAM also allows statuses that have been sent before an abort was executed but received after the TM response to be delivered or not at initiators will +++ - clause 5.3.1 that states - "GOOD. This status indicates that the device server has successfully completed the task." I propose that the target deliver only the TMF response on an abort of an active task on an 'abort task' TMF, and not transmit an 'abort task set' TMF response until all the current StatSN's on all connections (as on the completion of "abort task set') in the session are ack'ed. This ack may be solicited by way of a NOP-IN with valid TTT. +++ that may result in an initiator reusing prematurely an ITT and being hit by a late arriving status for a "former" task - i.e. non-deterministic behavior +++ This gives the determinism to initiators that (a) abort task set TMF response signifies that the entire task set had been dealt with, and (b) every task response is a true SCSI end-to-end reponse (not generated by iSCSI), besides doing away with SCSI-response code in the target iSCSI layer. Comments? Did I miss any corner cases? +++ see above +++ Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 --=_alternative 00449F5042256B17_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

Comments in text - Julo

PS - I would like also to point out that we may want to consider a very simple alternative to the barrier scheme outlined in 9.4
- that will require less cooperation between initiator and will be simpler to read and implement.
I will outline such a scheme soon.


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

12/03/2001 01:33 AM

       
        To:        "ips" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: abort task & abort task set

       


Julian,

iSCSI currently requires two responses to be returned for an aborted task -
one for the original task with a "good" status, and the second for the task
management function (TMF) itself.  So, the following legal behaviors are
required of a target -
   a) plug the CmdSN gap if the command was not received,
   b) send a SCSI response and TMF response if the task still is active,
   c) send a TMF response if the task isn't active (if already complete).

I would like to suggest that we reconsider our approach for case (b) for
a variety of reasons, to change it to:
   b) send a TMF response signalling that the abort is complete, if the
task
       still is active.

Here are my reasons -

   1. Target iSCSI layer would need to make a SCSI response up on
       an abort of an active task.  It then follows that the iSCSI layer
       may have to make up several SCSI responses on an 'abort task set'.

  2.  The current approach also creates a side effect that isn't readily
       apparent for 'abort task set'.  Initiators would need to stall
processing
       'abort task set' TMF response till task responses (to account for
all
       the tasks in the task set) on multiple TCP connections (possibly on
       different NICs) are received - which I am afraid would tantamount to
       an initiator scoreboard.
+++ That is not entirely correct. The whole purpose of requiring the target to send a "good status" is to allow the initiator to send the response immediately and have the initiator mark its internal data structures as aborted - but avoid reusing ITT untill it gets the good answer.
This way initiator can make progress and it can be sure that it won't be surprised by an "old" answer after it has reused the ITT
+++
   3. The current approach complicates initiator implementations that want
       to process a successful SCSI completion even after they initiated
       timeout processing since on an 'abort task set', initiators can
never
       be sure if the response was pre-abort, or post-abort (made up "good"
       status).  I believe it is worth preserving this implementation
choice.
+++ see above +++
  4.  I am further concerned that iSCSI is possibly in violation of the
spirit of
       SAM-2, rev20.
        - clause 5.6.2 that states -
"When an initiator causes its own task(s) to be aborted, no notification
that the task(s) have been aborted shall be
returned to the initiator other than the completion response for the command
or task management function action
that caused the task(s) to be aborted and notification(s) associated with
related effects of the action (e.g., a target
reset unit attention condition)."
+++ I did say explicitly that the good status is a "good-will" message between iSCSI target and initiator. It does not have to reach SCSI. SAM also allows statuses that have been sent before an abort was executed but received after the TM response to be delivered or not at initiators will +++
        - clause 5.3.1 that states -
"GOOD. This status indicates that the device server has successfully
completed the task."

I propose that the target deliver only the TMF response on an abort of
an active task on an 'abort task' TMF, and not transmit an 'abort task set'
TMF response until all the current StatSN's on all connections (as on the
completion of "abort task set') in the session are ack'ed.  This ack may be
solicited by way of a NOP-IN with valid TTT.
+++ that may result in an initiator reusing prematurely an ITT and being hit by a late arriving status
for a "former" task - i.e. non-deterministic behavior +++
 
This gives the determinism to initiators that  (a) abort task set TMF
response
signifies that the entire task set had been dealt with, and (b) every task
response
is a true SCSI end-to-end reponse (not generated by iSCSI), besides doing
away with SCSI-response code in the target iSCSI layer.

Comments?  Did I miss any corner cases?
+++ see above +++

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


--=_alternative 00449F5042256B17_=-- From owner-ips@ece.cmu.edu Mon Dec 3 10:56:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08631 for ; Mon, 3 Dec 2001 10:56:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3EvYY28724 for ips-outgoing; Mon, 3 Dec 2001 09:57:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3DXml23011 for ; Mon, 3 Dec 2001 08:33:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28358; Mon, 3 Dec 2001 08:33:31 -0500 (EST) Message-Id: <200112031333.IAA28358@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ips-fcip-slp-01.txt Date: Mon, 03 Dec 2001 08:33:30 -0500 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Storage Working Group of the IETF. Title : Finding FCIP Entities Using SLP Author(s) : D. Peterson Filename : draft-ietf-ips-fcip-slp-01.txt Pages : 11 Date : 30-Nov-01 The FCIP protocol provides a method for the tunneling of Fibre Channel frames over an IP network. This document defines the use of the Service Location Protocol by FCIP entities to discover one another, and provides the appropriate SLPv2 templates describing their services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-slp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ips-fcip-slp-01.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-ips-fcip-slp-01.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: <20011130132754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-slp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-slp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130132754.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Dec 3 11:33:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12716 for ; Mon, 3 Dec 2001 11:33:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3Fivp02456 for ips-outgoing; Mon, 3 Dec 2001 10:44:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fB3FZSl01725 for ; Mon, 3 Dec 2001 10:35:28 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fB3FZD521865; Mon, 3 Dec 2001 10:35:13 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fB3FZD318775; Mon, 3 Dec 2001 10:35:13 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15371.39856.952682.554004@pkoning.dev.equallogic.com> Date: Mon, 3 Dec 2001 10:35:12 -0500 (EST) From: Paul Koning To: bernard_aboba@hotmail.com Cc: ips@ece.cmu.edu Subject: Re: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I References: X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Bernard" == Bernard Aboba writes: Bernard> In our analysis of algorithms, we have been constrained by Bernard> the transforms existing or under development by IPsec WG. In Bernard> general, the IPsec WG takes it lead from NIST/ANSI, which Bernard> looks not only at performance and implementability in Bernard> hardware and software, but also security and intellectual Bernard> property issues. And indeed there are IP concerns relating to several of the proposed "new modes". One of them is subject to a license fee that appears to be documented (not zero, not really close to zero, but arguably tolerable). Another is subject to a "reasonable and non-discriminatory" statement from the owner, but I have seen the default licensing terms from that company in the past and would not agree that the phrase "reasonable" applies. Bernard> ...Given that 3DES-CBC-I has already been standardized by ANSI, Bernard> it may be feasible to get an IPsec transform document Bernard> written and adopted as a work item by IPsec WG. If this can Bernard> happen, then it would be possible to argue the merits of Bernard> this algorithm versus the other ones under Bernard> consideration. Given the prevalence of 3DES-CBC however, I Bernard> suspect that the argument would be over whether 3DES-CBC-I Bernard> would become a MAY or a SHOULD implement, rather than a Bernard> MUST. CBC-I is no less a hardware change than any other new mode. So it's not clear why it would be useful to work on that rather than on other new modes. Perhaps if there aren't IP issues with it? Given that IPSec acts at the datagram level, you can do interleaving on a packet basis. In a high speed implementation, it is reasonable to expect that there are several packets awaiting processing at a time. If so, they can each be run through separate processing elements. So the CBC bottleneck applies within a packet but not across packets. That's not to say that new modes aren't interesting -- but it says that you can continue to improve performance in the meantime. paul From owner-ips@ece.cmu.edu Mon Dec 3 13:34:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19968 for ; Mon, 3 Dec 2001 13:34:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3I7Jk13822 for ips-outgoing; Mon, 3 Dec 2001 13:07:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3I7Gl13816 for ; Mon, 3 Dec 2001 13:07:16 -0500 (EST) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id NAA28650 for ips@ece.cmu.edu; Mon, 3 Dec 2001 13:07:11 -0500 (EST) Received: from compuserve.com (dal-tgn-tko-vty65.as.wcom.net [216.192.227.65]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id NAA28548; Mon, 3 Dec 2001 13:07:01 -0500 (EST) Message-ID: <3C0BAF1C.8A2AC608@compuserve.com> Date: Mon, 03 Dec 2001 10:58:05 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector CC: Murali Rajagopal Subject: Re: FCIP V07 suggestion References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Chong, You are correct. Section 8.1 cannot discuss frame transmission in terms of the FCIP Data Engine portals. The Data Engine and its portals do not exist until after the TCP connection is fully established after the Short Frame is transacted. In the next FCIP revision, I will scrub the "portal" wording out of section 8.1. Thanks. Ralph... > Hi, > > In the FCIP draft V07 () page 28, it > says: > > "After the TCP connect request has been accepted, the FCIP Entity > SHALL wait for the FCIP Short Frame sent by the originator of the > TCP connect request as the first bytes received through the > Encapsulated Frame Receiver Portal on the accepted connection." > > I think this text is confusing. The "FCIP Short Frame" cannot be > received through > the "Encapsulated Frame Receiver Portal" because this Portal > does not exist when the "FCIP Short Frame" is to be received: > (1) According to the draft (page 13), Portals (including "Encapsulated > Frame Receiver Portal") belong to the FCIP_DE. This implies (to me) > that > Portals cannot exist without their corresponding FCIP_DE. > (2) Again according to the draft (page 26 and page 29), FCIP_DE is > created > only after "FCIP Short Frame" are exchanged between the originator > and > recipient of the TCP connection. > > It might make sense for the aforementioned text in the draft be changed > to: > > "After the TCP connect request has been accepted, the FCIP Entity > SHALL wait for the FCIP Short Frame sent by the originator of the > TCP connect request as the first bytes received on the accepted > connection." > > Chong Peng From owner-ips@ece.cmu.edu Mon Dec 3 13:36:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20142 for ; Mon, 3 Dec 2001 13:36:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3HfMV11905 for ips-outgoing; Mon, 3 Dec 2001 12:41:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3HfJl11898 for ; Mon, 3 Dec 2001 12:41:20 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 3969E1F6B0 for ; Mon, 3 Dec 2001 09:41:06 -0800 (PST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id JAA28960 for ; Mon, 3 Dec 2001 09:42:36 -0800 (PST) Message-Id: <200112031742.JAA28960@core.rose.hp.com> Date: Mon, 03 Dec 2001 09:53:58 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: abort task & abort task set References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Resolution of this certainly requires an offline discussion - which we two plan to have. But one comment to make my proposal clear to the list. > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ That is not possible since as I said above, the 'abort task set' TMF response is sent only after all StatSN "snapshots" are ack'ed on all connections. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 Julian Satran wrote: > > Mallikarjun, > > Comments in text - Julo > > PS - I would like also to point out that we may want to consider a > very simple alternative to the barrier scheme outlined in 9.4 > - that will require less cooperation between initiator and will be > simpler to read and implement. > I will outline such a scheme soon. > > "Mallikarjun C." > To: "ips" > Sent by: owner-ips@ece.cmu.edu > cc: > 12/03/2001 01:33 AM Subject: iSCSI: > abort task & abort task set > > > > Julian, > > iSCSI currently requires two responses to be returned for an aborted > task - > one for the original task with a "good" status, and the second for the > task > management function (TMF) itself. So, the following legal behaviors > are > required of a target - > a) plug the CmdSN gap if the command was not received, > b) send a SCSI response and TMF response if the task still is > active, > c) send a TMF response if the task isn't active (if already > complete). > > I would like to suggest that we reconsider our approach for case (b) > for > a variety of reasons, to change it to: > b) send a TMF response signalling that the abort is complete, if > the > task > still is active. > > Here are my reasons - > > 1. Target iSCSI layer would need to make a SCSI response up on > an abort of an active task. It then follows that the iSCSI > layer > may have to make up several SCSI responses on an 'abort task > set'. > > 2. The current approach also creates a side effect that isn't > readily > apparent for 'abort task set'. Initiators would need to stall > processing > 'abort task set' TMF response till task responses (to account > for > all > the tasks in the task set) on multiple TCP connections > (possibly on > different NICs) are received - which I am afraid would > tantamount to > an initiator scoreboard. > +++ That is not entirely correct. The whole purpose of requiring the > target to send a "good status" is to allow the initiator to send the > response immediately and have the initiator mark its internal data > structures as aborted - but avoid reusing ITT untill it gets the good > answer. > This way initiator can make progress and it can be sure that it won't > be surprised by an "old" answer after it has reused the ITT > +++ > 3. The current approach complicates initiator implementations that > want > to process a successful SCSI completion even after they > initiated > timeout processing since on an 'abort task set', initiators can > never > be sure if the response was pre-abort, or post-abort (made up > "good" > status). I believe it is worth preserving this implementation > choice. > +++ see above +++ > 4. I am further concerned that iSCSI is possibly in violation of > the > spirit of > SAM-2, rev20. > - clause 5.6.2 that states - > "When an initiator causes its own task(s) to be aborted, no > notification > that the task(s) have been aborted shall be > returned to the initiator other than the completion response for the > command > or task management function action > that caused the task(s) to be aborted and notification(s) associated > with > related effects of the action (e.g., a target > reset unit attention condition)." > +++ I did say explicitly that the good status is a "good-will" message > between iSCSI target and initiator. It does not have to reach SCSI. > SAM also allows statuses that have been sent before an abort was > executed but received after the TM response to be delivered or not at > initiators will +++ > - clause 5.3.1 that states - > "GOOD. This status indicates that the device server has successfully > completed the task." > > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ > > This gives the determinism to initiators that (a) abort task set TMF > response > signifies that the entire task set had been dealt with, and (b) every > task > response > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > doing > away with SCSI-response code in the target iSCSI layer. > > Comments? Did I miss any corner cases? > > +++ see above +++ > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 From owner-ips@ece.cmu.edu Mon Dec 3 15:02:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26069 for ; Mon, 3 Dec 2001 15:02:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3JEOf19084 for ips-outgoing; Mon, 3 Dec 2001 14:14:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB3JEGl19060 for ; Mon, 3 Dec 2001 14:14:16 -0500 (EST) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fB3JE9g08130 for ; Mon, 3 Dec 2001 14:14:10 -0500 (EST) Content-Class: urn:content-classes:message Subject: IPS-ALL: Interim meeting Announcement -- Feb 6-8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Disposition-Notification-To: "Elizabeth Rodriguez" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 3 Dec 2001 14:14:09 -0500 Message-ID: <9410A0F67DFE7F4D998D4538236498361A5298@nc8220exchange.ral.lucent.com> Thread-Topic: IPS-ALL: Interim meeting Announcement -- Feb 6-8 Thread-Index: AcF5OZYtbow0UrNTRWmBpd1fgcCimgC4AwrA From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fB3JELl19073 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, The IETF IPS working group will be holding an interim meeting on Feb 6-8. It will be co-located with T11. The meeting will be held over a three day period. The formal agenda has not yet been set. An agenda for that meeting will be sent out in January. But, the high level agenda for the meeting is: Wed 8-6: -- iSCSI related topics Thurs 4-9 (or immediately after the T11 Plenary, whichever is later): -- common topics, including security; -- iSCSI carryover, if needed -- FC related topics may start during this session Friday 8-6 (may end earlier, depending on time requirements, and if FC topics started on Thursday): -- iFCP and FCIP related topics No meetings will be on Thursday before 4pm, as T11 requests that no meetings be scheduled to conflict with the T11.3/T11 plenaries. QLogic has also invited IPS WG attendees to a Wed Evening Social, from 6-9 pm. QLogic has graciously agreed to host this interim meeting, so there will be no charge to attend. The cost of meeting space are covered by people staying at the hotel, under the group name "QLogic" -- (T10/T11 model) So, it is requested that you reserve under the group name, even when a corporate rate might be more favorable. LOCATION Hilton Waterfront Beach Resort 21100 Pacific Coast Highway Huntington Beach, CA 92648 Phone: (714) 960-7873 or (800) 822-7893 ROOM RATE $175.00 plus tax (Cutoff Date: 1/12/02) RESERVATION NAME "QLogic" PLEASE STAY AT THIS PROPERTY and mention that you are with the GROUP NAME "QLogic" when making reservations The Meeting Notice and Meeting Map for Feb T11 will be available by Dec 7, at www.t11.org. Meetings are open, so anyone is welcome to attend T11 meetings in addition to the IPS interim meeting. In order to advise QLogic and the hotel property better as to how many rooms we will need each night, please RSVP indicating if what days you are planning on attending, and what evenings you will be staying at the hotel: Attendance Wed ___ Thurs ___ Fri ___ Room Nights Sun ___ Mon ___ Tues ___ Wed ___ Thurs ___ Fri ___ Please respond by Dec 12. Thank you, Elizabeth Rodriguez & David Black From owner-ips@ece.cmu.edu Mon Dec 3 17:14:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06358 for ; Mon, 3 Dec 2001 17:14:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB3LFFJ29802 for ips-outgoing; Mon, 3 Dec 2001 16:15:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fB3LFDl29798 for ; Mon, 3 Dec 2001 16:15:13 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Mon Dec 3 16:15:22 EST 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fB3LEXo81561 for ; Mon, 3 Dec 2001 16:14:33 -0500 (EST) Received: from research.bell-labs.com (IDENT:sandeepj@sandeepj-pcmh.research.bell-labs.com [135.104.47.90]) by aura.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id QAA06081 for ; Mon, 3 Dec 2001 16:14:33 -0500 (EST) Message-ID: <3C0BEB39.5AAEF78F@research.bell-labs.com> Date: Mon, 03 Dec 2001 16:14:33 -0500 From: Sandeep Joshi X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-3 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: unsolicited data References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit (Julian's reply did not get cc:ed to the list.) Comments in text.. Julian Satran wrote: > > Sandeep, > > The requirements for ordering allow us to overcomit (unsolicited data > conservatively committed may require large buffering space) without fear of > deadlock. Ok..but one cant prevent reordering in the network, and things can get worse for N connections to a session. Any target which juggles around overcommitted buffers might have to do either/both of the following, depending on its buffer management strategy : (a) drop packets _within_ the TCP window (or worse, shrink the receive window which RFC 793 doesn't recommend) (b) drop data PDUs in the iSCSI window At the very least, we need to expand on the deadlock rationale in the draft so that it is not the cause of further questions. > > As for the allowance to send data not right after the command I think that > you stated correctly that matching data to the command will not involve any > expensive search (at least not on the fast path) as the data must match the > first outstanding command. > > The reason we did allow the command to be separated is the old "seek > separation" reason - allow SCSI commands to start executing > before they reach the state they need data. Agreed..how about adding this statement to the draft..? ..Though in most cases, packet arrival rates should be much higher than this setup time (assume network is faster than the fastest SCSI device). I am not sure one may be able to achieve this "pipeline" effect, add to the fact that this separation is not even recommended (a SHOULD) Regards, -Sandeep > > Julo > > > Sandeep Joshi > -labs.com> cc: > Sent by: Subject: Re: iSCSI: unsolicited data > owner-ips@ece.cmu.edu > > > 12/01/2001 01:36 AM > > > > Julian, > > Perhaps this thread was missed..could you please elaborate on this > deadlock issue..when exactly does it occur? > Note that I am not asking for out-of-order data! > > There was one more question - regarding the allowance given > to the initiator to *not* send unsolicited PDUs right after > the command PDUs, which raises persistent questions. > > See http://www.pdl.cmu.edu/mailinglists/ips/mail/msg07930.html > for the latest question on this issue. > > IIRC, the reasoning here was that this helps the target in "positioning" > operations - since it gets a few commands first, and then the data. > By positioning, do you imply disk/tape seeks or something else ? > Note that the draft must atleast mention the above rationale if we > wish initiators to behave as such, and also targets to optimize for it. > > Regards, > -Sandeep > > "Mallikarjun C." wrote: > > I however could not really see a deadlock per se - my comment was to > > understand > > what it is. More comments would certainly help. > > > > ----- Original Message ----- > > From: "Julian Satran" > > > Mallikarjun, > > > > > > The deadlock free requirement here goes a bit deeper than your comment > may > > > suggest. > > > Unsolicited data needs are very hard to predict and ordering them may > > > remove the need to do so to a large extent. From owner-ips@ece.cmu.edu Mon Dec 3 22:22:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26139 for ; Mon, 3 Dec 2001 22:22:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB42KQc22443 for ips-outgoing; Mon, 3 Dec 2001 21:20:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from localhost.localdomain (bay-bridge.veritas.com [143.127.3.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB42KNl22439 for ; Mon, 3 Dec 2001 21:20:24 -0500 (EST) Received: from localhost (pms@localhost) by localhost.localdomain (8.11.2/8.11.2) with ESMTP id fB3NgeK01134; Mon, 3 Dec 2001 15:42:40 -0800 X-Authentication-Warning: localhost.localdomain: pms owned process doing -bs Date: Tue, 4 Dec 2001 05:12:40 +0530 (IST) From: Patrick Stirling X-X-Sender: To: Julian Satran cc: Subject: Re: iSCSI: abort task & abort task set In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk I've been lurking silently on this list for a while, but would like to throw in my opinion here! I agree with Mallikarjun's proposal that the iSCSI target layer should not send responses for individual commands on receiving an Abort Task Set task mgmt command. I think it breaks the layering (command responses should be end to end). Julo commented: > +++ The whole purpose of requiring the target to send a "good status" > is to allow the initiator to send the response immediately and have > the initiator mark its internal data structures as aborted - but avoid > reusing ITT untill it gets the good answer. This way initiator can > make progress and it can be sure that it won't be surprised by an > "old" answer after it has reused the ITT +++ Perhaps I'm missing something here - when would the initiator send a response to the target? Surely the Abort is intended to kill the command immediately. Secondly, the initiator should not reuse task tags until it knows the status of the previous command - and it can't know this until the target responds to the TMF. With a 32 bit task tag I don't see a problem with running out of tag values! So the requirement is that the target abort all commands with a SN less than that of the TMF itself, then respond to the TMF. Receipt of the TMF response indicates that the initiator can clean up for all aborted commands. I don't see that it's an undue burden on the initiator to retain the per-command information until then. As an editorial aside, I find ACA and TMF very confusing - anything we can do to simplify them is good! patrick Patrick Stirling VERITAS Software Corp. From owner-ips@ece.cmu.edu Mon Dec 3 23:18:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28836 for ; Mon, 3 Dec 2001 23:18:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB43VBr27265 for ips-outgoing; Mon, 3 Dec 2001 22:31:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB43V8l27252 for ; Mon, 3 Dec 2001 22:31:08 -0500 (EST) Received: from ahganemw2k (sjc-vpn1-201.cisco.com [10.21.96.201]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA21292 for ; Mon, 3 Dec 2001 22:31:01 -0500 (EST) From: "Ayman Ghanem" To: Subject: iSCSI: NOPs on discovery session Date: Mon, 3 Dec 2001 21:30:22 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I thought we agreed to adding NOPs to the operations allowed on the discovery session. I couldn't find that in draft-09. Thanks. -Ayman From owner-ips@ece.cmu.edu Tue Dec 4 00:54:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02049 for ; Tue, 4 Dec 2001 00:54:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB44wFB02882 for ips-outgoing; Mon, 3 Dec 2001 23:58:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe14.pav1.hotmail.com [64.4.30.118]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB44p1l02455 for ; Mon, 3 Dec 2001 23:51:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 3 Dec 2001 20:50:55 -0800 X-Originating-IP: [65.115.68.98] Reply-To: "Michael Sebastian Smith \(Hotmail\)" From: "Michael Sebastian Smith \(Hotmail\)" To: Cc: References: <034670D62D19D31180990090277A37B701C1893A@mercury.corp.iready.com> Subject: iSCSI: v9 concordance Date: Mon, 3 Dec 2001 18:52:57 -0800 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.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 04 Dec 2001 04:50:55.0744 (UTC) FILETIME=[4242A800:01C17C7F] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit iSCSI: v8 concordanceI placed the concordance of the iSCSI v9 Internet draft at http://www.iready.org/iscsi/iscsi9concordanceV1.doc Aloha Mike Smith CTO iReady ----- Original Message ----- From: Michael Smith To: 'ips@ece.cmu.edu' Cc: Michael Smith Sent: Monday, October 08, 2001 5:36 PM Subject: iSCSI: v8 concordance There have been several comments recently on this reflector about the use of terms and definitions in the current iSCSI Internet draft. I have created a concordance for the iSCSI v8 Internet draft. You may download the concordance at http://www.iready.org/iscsi/iscsi8concordanceV5.doc This is a very large file (10MB). A concordance is like an amplified index. A concordance is an ordered list of the occurence of every single word, term, and character in the iSCSI v8 spec together with it's context (the context being a certain number of words around each occurence). Why is this useful? Let's take an example from the iSCSI Internet draft concordance file. Take the term "barrier". It often occurs as the term "barrier list" in the current Internet draft. But how is this term used exactly? First, look up "barrier (exactly as I have shown it here) in the concordance and you will see the following: "BARRIER................................................................5 layer. The "barrier list" described in the following sections is a 7370 "barrier list"; 7382 a) if the "barrier list" is empty or ExpCmdSN is less than 7392 a "barrier list" including the referenced LUN (or an ALL 7420 a) if the "barrier list" is empty or ExpCmdSN is less than 7428 This means the characters "barrier appear five times (lines 7370, 7382, 7392, 7420, 7428 as numbered from the .txt version). Each time the characters "barrier occur as "barrier list". Continue now to look up just the characters barrier in the concordance. You will find: BARRIER.................................................................5 Note: for clarity, the barrier list contains "items" and the 7387 the CmdSN of the oldest item in the barrier list then 7393 b) remove the oldest barrier list item, and remove and 7395 the oldest item in the barrier list then skip to step d; 7429 b) remove the oldest barrier list item and evaluate all 7430 Thus barrier also occurs five times (lines 7387, 7393, 7395, 7429, 7430). So what? The concordance has told us: 1. If the term "barrier list" is defined the first time that it is used. (It is, sort of.) 2. If the term "barrier list" is used consistently each time. 3. That the use of quotes around barrier list is inconsistent and therefore perhaps misleading. I hope that, from this small example, you may easily extrapolate to other uses of a concordance in reading, understanding, and editing the current iSCSI Internet draft. I have found this technique useful in the past. Aloha Mike Smith CTO iReady From owner-ips@ece.cmu.edu Tue Dec 4 02:36:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18435 for ; Tue, 4 Dec 2001 02:36:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB46oq510152 for ips-outgoing; Tue, 4 Dec 2001 01:50:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB46onl10147 for ; Tue, 4 Dec 2001 01:50:50 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id HAA15168 for ; Tue, 4 Dec 2001 07:50:39 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB46oxW86954 for ; Tue, 4 Dec 2001 07:50:59 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: abort task & abort task set X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Dec 2001 08:50:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/12/2001 08:50:51, Serialize complete at 04/12/2001 08:50:51 Content-Type: multipart/alternative; boundary="=_alternative 0025731D42256B18_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0025731D42256B18_= Content-Type: text/plain; charset="us-ascii" Dear all, On a phone conversation we have agreed to change the required behaviour along those lines enabling the initiator to drop all outstanding commands after a response from a the task management abort/clear-task-set is received. The iSCSI target will carry the burden for waiting for all outstanding statuses on all connections to be acknowledged after receiving the abort confirmation from the SCSI target and sending all statuses before returning the task management response. Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 12-03-01 07:53 PM Please respond to cbm To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: abort task & abort task set Resolution of this certainly requires an offline discussion - which we two plan to have. But one comment to make my proposal clear to the list. > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ That is not possible since as I said above, the 'abort task set' TMF response is sent only after all StatSN "snapshots" are ack'ed on all connections. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 Julian Satran wrote: > > Mallikarjun, > > Comments in text - Julo > > PS - I would like also to point out that we may want to consider a > very simple alternative to the barrier scheme outlined in 9.4 > - that will require less cooperation between initiator and will be > simpler to read and implement. > I will outline such a scheme soon. > > "Mallikarjun C." > To: "ips" > Sent by: owner-ips@ece.cmu.edu > cc: > 12/03/2001 01:33 AM Subject: iSCSI: > abort task & abort task set > > > > Julian, > > iSCSI currently requires two responses to be returned for an aborted > task - > one for the original task with a "good" status, and the second for the > task > management function (TMF) itself. So, the following legal behaviors > are > required of a target - > a) plug the CmdSN gap if the command was not received, > b) send a SCSI response and TMF response if the task still is > active, > c) send a TMF response if the task isn't active (if already > complete). > > I would like to suggest that we reconsider our approach for case (b) > for > a variety of reasons, to change it to: > b) send a TMF response signalling that the abort is complete, if > the > task > still is active. > > Here are my reasons - > > 1. Target iSCSI layer would need to make a SCSI response up on > an abort of an active task. It then follows that the iSCSI > layer > may have to make up several SCSI responses on an 'abort task > set'. > > 2. The current approach also creates a side effect that isn't > readily > apparent for 'abort task set'. Initiators would need to stall > processing > 'abort task set' TMF response till task responses (to account > for > all > the tasks in the task set) on multiple TCP connections > (possibly on > different NICs) are received - which I am afraid would > tantamount to > an initiator scoreboard. > +++ That is not entirely correct. The whole purpose of requiring the > target to send a "good status" is to allow the initiator to send the > response immediately and have the initiator mark its internal data > structures as aborted - but avoid reusing ITT untill it gets the good > answer. > This way initiator can make progress and it can be sure that it won't > be surprised by an "old" answer after it has reused the ITT > +++ > 3. The current approach complicates initiator implementations that > want > to process a successful SCSI completion even after they > initiated > timeout processing since on an 'abort task set', initiators can > never > be sure if the response was pre-abort, or post-abort (made up > "good" > status). I believe it is worth preserving this implementation > choice. > +++ see above +++ > 4. I am further concerned that iSCSI is possibly in violation of > the > spirit of > SAM-2, rev20. > - clause 5.6.2 that states - > "When an initiator causes its own task(s) to be aborted, no > notification > that the task(s) have been aborted shall be > returned to the initiator other than the completion response for the > command > or task management function action > that caused the task(s) to be aborted and notification(s) associated > with > related effects of the action (e.g., a target > reset unit attention condition)." > +++ I did say explicitly that the good status is a "good-will" message > between iSCSI target and initiator. It does not have to reach SCSI. > SAM also allows statuses that have been sent before an abort was > executed but received after the TM response to be delivered or not at > initiators will +++ > - clause 5.3.1 that states - > "GOOD. This status indicates that the device server has successfully > completed the task." > > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ > > This gives the determinism to initiators that (a) abort task set TMF > response > signifies that the entire task set had been dealt with, and (b) every > task > response > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > doing > away with SCSI-response code in the target iSCSI layer. > > Comments? Did I miss any corner cases? > > +++ see above +++ > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 --=_alternative 0025731D42256B18_= Content-Type: text/html; charset="us-ascii"
Dear all,

On a phone conversation we have agreed to change the required behaviour along those lines enabling the initiator to drop all
outstanding commands after a response from a the task management abort/clear-task-set is received.
The iSCSI target will carry the burden for waiting for all outstanding statuses on all connections to be acknowledged after receiving the abort confirmation from the SCSI target and sending all statuses before returning the task management response.

Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

12-03-01 07:53 PM
Please respond to cbm

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: abort task & abort task set

       


Resolution of this certainly requires an offline discussion -
which we two plan to have.  But one comment to make my proposal
clear to the list.

> I propose that the target deliver only the TMF response on an abort of
> an active task on an 'abort task' TMF, and not transmit an 'abort task
> set'
> TMF response until all the current StatSN's on all connections (as on
> the
> completion of "abort task set') in the session are ack'ed.  This ack
> may be
> solicited by way of a NOP-IN with valid TTT.
>
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status
> for a "former" task - i.e. non-deterministic behavior +++

That is not possible since as I said above, the 'abort task set'
TMF response is sent only after all StatSN "snapshots" are ack'ed
on all connections.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
Hewlett-Packard MS 5668
Roseville CA 95747


Julian Satran wrote:
>
> Mallikarjun,
>
> Comments in text - Julo
>
> PS - I would like also to point out that we may want to consider a
> very simple alternative to the barrier scheme outlined in 9.4
> - that will require less cooperation between initiator and will be
> simpler to read and implement.
> I will outline such a scheme soon.
>
>   "Mallikarjun C."
>   <cbm@rose.hp.com>                       To:        "ips"
>   Sent by: owner-ips@ece.cmu.edu  <ips@ece.cmu.edu>
>                                           cc:
>   12/03/2001 01:33 AM                     Subject:        iSCSI:
>                                   abort task & abort task set
>
>
>
> Julian,
>
> iSCSI currently requires two responses to be returned for an aborted
> task -
> one for the original task with a "good" status, and the second for the
> task
> management function (TMF) itself.  So, the following legal behaviors
> are
> required of a target -
>    a) plug the CmdSN gap if the command was not received,
>    b) send a SCSI response and TMF response if the task still is
> active,
>    c) send a TMF response if the task isn't active (if already
> complete).
>
> I would like to suggest that we reconsider our approach for case (b)
> for
> a variety of reasons, to change it to:
>    b) send a TMF response signalling that the abort is complete, if
> the
> task
>        still is active.
>
> Here are my reasons -
>
>    1. Target iSCSI layer would need to make a SCSI response up on
>        an abort of an active task.  It then follows that the iSCSI
> layer
>        may have to make up several SCSI responses on an 'abort task
> set'.
>
>   2.  The current approach also creates a side effect that isn't
> readily
>        apparent for 'abort task set'.  Initiators would need to stall
> processing
>        'abort task set' TMF response till task responses (to account
> for
> all
>        the tasks in the task set) on multiple TCP connections
> (possibly on
>        different NICs) are received - which I am afraid would
> tantamount to
>        an initiator scoreboard.
> +++ That is not entirely correct. The whole purpose of requiring the
> target to send a "good status" is to allow the initiator to send the
> response immediately and have the initiator mark its internal data
> structures as aborted - but avoid reusing ITT untill it gets the good
> answer.
> This way initiator can make progress and it can be sure that it won't
> be surprised by an "old" answer after it has reused the ITT
> +++
>    3. The current approach complicates initiator implementations that
> want
>        to process a successful SCSI completion even after they
> initiated
>        timeout processing since on an 'abort task set', initiators can
> never
>        be sure if the response was pre-abort, or post-abort (made up
> "good"
>        status).  I believe it is worth preserving this implementation
> choice.
> +++ see above +++
>   4.  I am further concerned that iSCSI is possibly in violation of
> the
> spirit of
>        SAM-2, rev20.
>         - clause 5.6.2 that states -
> "When an initiator causes its own task(s) to be aborted, no
> notification
> that the task(s) have been aborted shall be
> returned to the initiator other than the completion response for the
> command
> or task management function action
> that caused the task(s) to be aborted and notification(s) associated
> with
> related effects of the action (e.g., a target
> reset unit attention condition)."
> +++ I did say explicitly that the good status is a "good-will" message
> between iSCSI target and initiator. It does not have to reach SCSI.
> SAM also allows statuses that have been sent before an abort was
> executed but received after the TM response to be delivered or not at
> initiators will +++
>         - clause 5.3.1 that states -
> "GOOD. This status indicates that the device server has successfully
> completed the task."
>
> I propose that the target deliver only the TMF response on an abort of
> an active task on an 'abort task' TMF, and not transmit an 'abort task
> set'
> TMF response until all the current StatSN's on all connections (as on
> the
> completion of "abort task set') in the session are ack'ed.  This ack
> may be
> solicited by way of a NOP-IN with valid TTT.
>
> +++ that may result in an initiator reusing prematurely an ITT and
> being hit by a late arriving status
> for a "former" task - i.e. non-deterministic behavior +++
>
> This gives the determinism to initiators that  (a) abort task set TMF
> response
> signifies that the entire task set had been dealt with, and (b) every
> task
> response
> is a true SCSI end-to-end reponse (not generated by iSCSI), besides
> doing
> away with SCSI-response code in the target iSCSI layer.
>
> Comments?  Did I miss any corner cases?
>
> +++ see above +++
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747

--=_alternative 0025731D42256B18_=-- From owner-ips@ece.cmu.edu Tue Dec 4 02:37:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18511 for ; Tue, 4 Dec 2001 02:37:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB474v910987 for ips-outgoing; Tue, 4 Dec 2001 02:04:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB474el10971 for ; Tue, 4 Dec 2001 02:04:54 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id IAA04498 for ; Tue, 4 Dec 2001 08:04:30 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB474n291160 for ; Tue, 4 Dec 2001 08:04:49 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NOPs on discovery session X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Dec 2001 09:04:39 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/12/2001 09:04:43, Serialize complete at 04/12/2001 09:04:43 Content-Type: multipart/alternative; boundary="=_alternative 0026B7BB42256B18_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0026B7BB42256B18_= Content-Type: text/plain; charset="us-ascii" Ayman, It is true that I agreed that we may want to have it. However some members of the list have expressed immediately a strong opposition to it claiming that it was no strictly needed (true) and that discovery section are meant to be brief. I felt thus that we don't have a consensus on that and we may want to try again. I assume that the main concern was that this will enable discovery sessions to be become long lived and be used as a back door monitoring channel. Regards, Julo "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu 12-04-01 05:30 AM To: cc: Subject: iSCSI: NOPs on discovery session Julian, I thought we agreed to adding NOPs to the operations allowed on the discovery session. I couldn't find that in draft-09. Thanks. -Ayman --=_alternative 0026B7BB42256B18_= Content-Type: text/html; charset="us-ascii"
Ayman,

It is true that I agreed that we may want to have it. However some members of the list have expressed immediately a strong opposition to it claiming that it was no strictly needed (true) and that discovery section are meant to be brief.
I felt thus that we don't have a consensus on that and we may want to try again.
I assume that the main concern was that this will enable discovery sessions to be become long lived and be used as a back door monitoring channel.

Regards,
Julo



"Ayman Ghanem" <aghanem@cisco.com>
Sent by: owner-ips@ece.cmu.edu

12-04-01 05:30 AM

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: NOPs on discovery session

       


Julian,

I thought we agreed to adding NOPs to the operations allowed on the
discovery session. I couldn't find that in draft-09. Thanks.

-Ayman

--=_alternative 0026B7BB42256B18_=-- From owner-ips@ece.cmu.edu Tue Dec 4 06:45:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23641 for ; Tue, 4 Dec 2001 06:45:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB4AemY03864 for ips-outgoing; Tue, 4 Dec 2001 05:40:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB4Aekl03860 for ; Tue, 4 Dec 2001 05:40:46 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA146356 for ; Tue, 4 Dec 2001 11:40:33 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB4AelW151132 for ; Tue, 4 Dec 2001 11:40:49 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: unsolicited data X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 From: "Julian Satran" Message-ID: Date: Tue, 4 Dec 2001 12:40:36 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/12/2001 12:40:41, Serialize complete at 04/12/2001 12:40:41 Content-Type: multipart/alternative; boundary="=_alternative 003A7CF842256B18_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003A7CF842256B18_= Content-Type: text/plain; charset="us-ascii" Sandeep, I assume that TCP will not overcomit (this is also a commitment that is easy to predict and small in size). iSCSI in this case is on the safe ground whatever it commits. I agree however that the deadlock statement has no place in the draft and I will take it out. Julo Sandeep Joshi Sent by: owner-ips@ece.cmu.edu 12-03-01 11:14 PM To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: unsolicited data (Julian's reply did not get cc:ed to the list.) Comments in text.. Julian Satran wrote: > > Sandeep, > > The requirements for ordering allow us to overcomit (unsolicited data > conservatively committed may require large buffering space) without fear of > deadlock. Ok..but one cant prevent reordering in the network, and things can get worse for N connections to a session. Any target which juggles around overcommitted buffers might have to do either/both of the following, depending on its buffer management strategy : (a) drop packets _within_ the TCP window (or worse, shrink the receive window which RFC 793 doesn't recommend) (b) drop data PDUs in the iSCSI window At the very least, we need to expand on the deadlock rationale in the draft so that it is not the cause of further questions. > > As for the allowance to send data not right after the command I think that > you stated correctly that matching data to the command will not involve any > expensive search (at least not on the fast path) as the data must match the > first outstanding command. > > The reason we did allow the command to be separated is the old "seek > separation" reason - allow SCSI commands to start executing > before they reach the state they need data. Agreed..how about adding this statement to the draft..? ..Though in most cases, packet arrival rates should be much higher than this setup time (assume network is faster than the fastest SCSI device). I am not sure one may be able to achieve this "pipeline" effect, add to the fact that this separation is not even recommended (a SHOULD) Regards, -Sandeep > > Julo > > > Sandeep Joshi > -labs.com> cc: > Sent by: Subject: Re: iSCSI: unsolicited data > owner-ips@ece.cmu.edu > > > 12/01/2001 01:36 AM > > > > Julian, > > Perhaps this thread was missed..could you please elaborate on this > deadlock issue..when exactly does it occur? > Note that I am not asking for out-of-order data! > > There was one more question - regarding the allowance given > to the initiator to *not* send unsolicited PDUs right after > the command PDUs, which raises persistent questions. > > See http://www.pdl.cmu.edu/mailinglists/ips/mail/msg07930.html > for the latest question on this issue. > > IIRC, the reasoning here was that this helps the target in "positioning" > operations - since it gets a few commands first, and then the data. > By positioning, do you imply disk/tape seeks or something else ? > Note that the draft must atleast mention the above rationale if we > wish initiators to behave as such, and also targets to optimize for it. > > Regards, > -Sandeep > > "Mallikarjun C." wrote: > > I however could not really see a deadlock per se - my comment was to > > understand > > what it is. More comments would certainly help. > > > > ----- Original Message ----- > > From: "Julian Satran" > > > Mallikarjun, > > > > > > The deadlock free requirement here goes a bit deeper than your comment > may > > > suggest. > > > Unsolicited data needs are very hard to predict and ordering them may > > > remove the need to do so to a large extent. --=_alternative 003A7CF842256B18_= Content-Type: text/html; charset="us-ascii"
Sandeep,

I assume that TCP will not overcomit (this is also a commitment that is easy to predict and small in size).
iSCSI in this case is on the safe ground whatever it commits.

I agree however that the deadlock statement has no place in the draft and I will take it out.

Julo


Sandeep Joshi <sandeepj@research.bell-labs.com>
Sent by: owner-ips@ece.cmu.edu

12-03-01 11:14 PM

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: unsolicited data

       



(Julian's reply did not get cc:ed to the list.)

Comments in text..

Julian Satran wrote:
>
> Sandeep,
>
> The requirements for ordering allow us to overcomit (unsolicited data
> conservatively committed may require large buffering space) without fear of
> deadlock.

Ok..but one cant prevent reordering in the network, and things can
get worse for N connections to a session.

Any target which juggles around overcommitted buffers might have to
do either/both of the following, depending on its buffer management
strategy :
(a) drop packets _within_ the TCP window (or worse, shrink the receive
   window which RFC 793 doesn't recommend)
(b) drop data PDUs in the iSCSI window

At the very least, we need to expand on the deadlock rationale in the
draft so that it is not the cause of further questions.


>
> As for the allowance to send data not right after the command I think that
> you stated correctly that matching data to the command will not involve any
> expensive search (at least not on the fast path) as the data must match the
> first outstanding command.
>
> The reason we did allow the command to be separated is the old "seek
> separation" reason - allow SCSI commands to start executing
> before they reach the state they need data.

Agreed..how about adding this statement to the draft..?

..Though in most cases, packet arrival rates should be much higher than
this setup time (assume network is faster than the fastest SCSI
device).  
I am not sure one may be able to achieve this "pipeline" effect, add
to the fact that this separation is not even recommended (a SHOULD)

Regards,
-Sandeep


>
> Julo
>
>
>                     Sandeep Joshi
>                     <sandeepj@research.bell       To:     ips@ece.cmu.edu
>                     -labs.com>                    cc:
>                     Sent by:                      Subject:     Re: iSCSI: unsolicited data
>                     owner-ips@ece.cmu.edu
>
>
>                     12/01/2001 01:36 AM
>
>
>
> Julian,
>
> Perhaps this thread was missed..could you please elaborate on this
> deadlock issue..when exactly does it occur?
> Note that I am not asking for out-of-order data!
>
> There was one more question - regarding the allowance given
> to the initiator to *not* send unsolicited PDUs right after
> the command PDUs, which raises persistent questions.
>
> See http://www.pdl.cmu.edu/mailinglists/ips/mail/msg07930.html
> for the latest question on this issue.
>
> IIRC, the reasoning here was that this helps the target in "positioning"
> operations - since it gets a few commands first, and then the data.
> By positioning, do you imply disk/tape seeks or something else ?
> Note that the draft must atleast mention the above rationale if we
> wish initiators to behave as such, and also targets to optimize for it.
>
> Regards,
> -Sandeep
>
> "Mallikarjun C." wrote:
> > I however could not really see a deadlock per se - my comment was to
> > understand
> > what it is.    More comments would certainly help.
> >
> > ----- Original Message -----
> > From: "Julian Satran" <Julian_Satran@il.ibm.com>
> > > Mallikarjun,
> > >
> > > The deadlock free requirement here goes a bit deeper than your comment
> may
> > > suggest.
> > > Unsolicited data needs are very hard to predict and ordering them may
> > > remove the need to do so to a large extent.

--=_alternative 003A7CF842256B18_=-- From owner-ips@ece.cmu.edu Tue Dec 4 12:06:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01819 for ; Tue, 4 Dec 2001 12:06:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB4FldA23152 for ips-outgoing; Tue, 4 Dec 2001 10:47:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB4Flbl23146 for ; Tue, 4 Dec 2001 10:47:37 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id fB4Fkgd27328 for ; Tue, 4 Dec 2001 10:46:42 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 4 Dec 2001 10:47:07 -0500 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YHM7QSB8; Tue, 4 Dec 2001 10:45:57 -0500 Received: from cse-ns-laptop.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRGWZWDV; Tue, 4 Dec 2001 10:45:56 -0500 Message-Id: <5.1.0.14.2.20011204094522.01ca19b0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 04 Dec 2001 10:49:34 -0500 To: "IPS Reflector (E-mail)" From: "Franco Travostino" Subject: iFCP: Minutes authors' confcall Fri November 30th Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_95463969==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_95463969==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Attendees: Charles Monia, Nishan Systems David Robinson, Sun Microsystems Mark Edwards, Eurologic Franco Travostino, Nortel Networks Much of this session was devoted to address David Black's comments. Some of his comments have already been addressed in the latest iFCP draft (07.txt) submitted to IETF at SLC cutoff date. 1) What's new in 07.txt CM quickly described the changes that made it in (see trailing list of changes for reference). None of these changes were controversial. Security and QoS changes were left for later discussion (see 2.4, 2.5). 2) Open issues wrt David Black comments 2.1) CM recalled why the use of an IP address to identify a remote gateway needs to be reconsidered. The ensuing discussion reaffirmed CM's motion that we need to attach that gateway's TCP port number to the definition of N_PORT network address. iSNS supplies port information as part of the query response. 2.2) Broadcast support. The existing definition has weaknesses in reliability and fragmentation (IP fragmenetation being problematic with firewalls and NA(P)T devices more than anything else). CM's motion to move (back) to TCP was unanimously agreed upon. Discussion arose regarding the nature of TCP connections, static vs. dynamic. DR highlighted the scalability merits of a publisher/subscriber approach to the broadcast service---e.g., use this flow to send me data whenever there is a broadcast). Liveness of the flow may be an issue. TCP_KeepAlive being frowned upon for some good reasons, it appears that we are better off using a liveness token of our own design (a message structure closely related to the current CBIND). 2.3) Stale frame propagation. CM described the consequences of using propagation delay estimates that are either too high or too low. FT recalled that there exist feasibility proof points based on IntServ or DiffServ, wherein an upper bound for IP propagation delays can be established with good confidence. Still, we need to define stale-frame ground rules that can be applied to the capital-I Internet as well, no matter how severe these rules turn out to be when the IP propagation delay exceeds the estimated value. In addition to the requirement for discarding stale frames, there was consensus for an option to terminate any outstanding session upon observing non-conforming propagation delays. ME mentioned that MIBs can help with cumulative statistics of mean and maximum propagation delays. FT noted that stale frame semantics are germane to FCIP too. 2.4) Security. FT described the security changes that made it to 07.txt. Those changes were prompted by either the Aboba draft or David's comments. Among things, we now endorse David's hard line against DES, thus overriding IPsec normative text. In the minimal policy section, text was added to indicate that a gateway SHOULD at least authenticate its iSNS server. Certificate text is still missing, and, to the best of our knowledge, is the only TBS item in the whole security section. FT also noted that the Aboba draft is now a standard track document. The Chairs have not yet described the bearings of this resolution on the individual encapsulation documents, and their security sections (i.e., they stay or not). The authors' preference to keep the security sections in the encapsulation documents has been brought forward to AD/Chairs in several instances. 2.5) QoS. FT reported that MPLS is now mentioned with an adequate context, after clarifying David's review comment. The use of SLA was discouraged, in that the A of SLA has undesired connotations (legal ones and such). David proposed to use SLS and TCS, DiffServ's new terms for SLA. SLS and TCS appear to be DiffServ specific, however, whereas the QoS section in iFCP is entirely DiffServ agnostic. For further research. 2.1, 2.2, 2.3, and 2.4 are on the agenda for SLC. -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Investments Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com Major changes in 07: Section 11, Security -- Updated to reflect the latest security text specified in http://www.ietf.org/internet-drafts/draft-ietf-ips-security-05.txt Section 12, QoS -- Updated per review comments and subsequent reflector discussion. Minor changes in 07: iSNS -- Added new section 5.3 describing the role of iSNS. 4.4a) -- Added FC Node definition 4.7.1 -- Added description of address assignment for fabric-attached loops. 4.8 -- Added description of class 4 and class 6 transport services. 4.9 -- Added description of FC logins. Figure 7 -- Changed "IP fabric" to "iFCP fabric." 5.2.1 -- Added description of how supported transport services are discovered by an N_PORT. PP 20 -- Corrected specification of requirements for Address-translation and Address-transparent modes. 5.3.1.1 -- Added material describing use of iSNS for domain I/D assignment in address-transparent mode. 5.3.1.2, 5.3.2.3 -- "SHALL" added to requirements for rejecting incoming frames having incorrect address mode. 6.2.2.1 -- Corrected per review comment 6.2.2.2, "Use of TCP Features" -- Revised per review comment 6.2.2.3, "Error Recovery and Cold Start" -- Deleted per review comment Sections 7 and 8 -- Order reversed per review comment 6.2.3 -- Identified entity being terminated or aborted (iFCP session) per review comment 6.3 -- Qualified reference to point to appendix B of RFC 1323 7.3 and 7.3.7 (PLOGI) -- Terminology: Augmented ELSs are now referred to as "Special" ELSs. 7.3.5 -- Fixed description of FARP-REQ. 7.3.8 -- Deleted description of REC ELS. 7.4, table 4 -- Modified table per review comment to delete references to "y" entry types. 8.1 -- Added Connection Handle reference. Appendix A -- Summary of Link Services. Deleted Link Services removed from FC-FS spec. Appendix B -- Deleted. Spec will be revised to include a reference to published material. --=====================_95463969==_.ALT Content-Type: text/html; charset="us-ascii"
Attendees:

Charles Monia, Nishan Systems
David Robinson, Sun Microsystems
Mark Edwards, Eurologic
Franco Travostino, Nortel Networks

Much of this session was devoted to address David Black's comments. Some of his comments have already been addressed in the latest iFCP draft (07.txt) submitted to IETF at SLC cutoff date.

1) What's new in 07.txt
CM quickly described the changes that made it in (see trailing list of changes for reference). None of these changes were controversial. Security and QoS changes were left for later discussion (see 2.4, 2.5).

2) Open issues wrt David Black comments

2.1) CM recalled why the use of an IP address to identify a remote gateway needs to be reconsidered. The ensuing discussion reaffirmed CM's motion that we need to attach that gateway's TCP port number to the definition of N_PORT network address. iSNS supplies port information as part of the query response.

2.2) Broadcast support. The existing definition has weaknesses in reliability and fragmentation (IP fragmenetation being problematic with firewalls and NA(P)T devices more than anything else). CM's motion to move (back) to TCP was unanimously agreed upon. Discussion arose regarding the nature of TCP connections, static vs. dynamic. DR highlighted the scalability merits of a publisher/subscriber approach to the broadcast service---e.g., use this flow to send me data whenever there is a broadcast). Liveness of the flow may be an issue. TCP_KeepAlive being frowned upon for some good reasons, it appears that we are better off using a liveness token of our own design (a message structure closely related to the current CBIND).

2.3) Stale frame propagation. CM described the consequences of using propagation delay estimates that are either too high or too low. FT recalled that there exist feasibility proof points based on IntServ or DiffServ, wherein an upper bound for IP propagation delays can be established with good confidence. Still, we need to define stale-frame ground rules that can be applied to the capital-I Internet as well, no matter how severe these rules turn out to be when the IP propagation delay exceeds the estimated value. In addition to the requirement for discarding stale frames, there was consensus for an option to terminate any outstanding session upon observing non-conforming propagation delays. ME mentioned that MIBs can help with cumulative statistics of mean and maximum propagation delays. FT noted that stale frame semantics are germane to FCIP too.

2.4) Security. FT described the security changes that made it to 07.txt. Those changes were prompted by either the Aboba draft or David's comments. Among things, we now endorse David's hard line against DES, thus overriding IPsec normative text. In the minimal policy section, text was added to indicate that a gateway SHOULD at least authenticate its iSNS server. Certificate text is still missing, and, to the best of our knowledge, is the only TBS item in the whole security section. FT also noted that the Aboba draft is now a standard track document. The Chairs have not yet described the bearings of this resolution on the individual encapsulation documents, and their security sections (i.e., they stay or not). The authors' preference to keep the security sections in the encapsulation documents has been brought forward to AD/Chairs in several instances.

2.5) QoS. FT reported that MPLS is now mentioned with an adequate context, after clarifying David's review comment. The use of SLA was discouraged, in that the A of SLA has undesired connotations (legal ones and such). David proposed to use SLS and TCS, DiffServ's new terms for SLA. SLS and TCS appear to be DiffServ specific, however, whereas the QoS section in iFCP is entirely DiffServ agnostic. For further research.

2.1, 2.2, 2.3, and 2.4 are on the agenda for SLC.

-franco

Franco Travostino, Director Content Internetworking Lab
Advanced Technology Investments
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com

Major changes in 07:
Section 11, Security -- Updated to reflect the latest security text
specified in
http://www.ietf.org/internet-drafts/draft-ietf-ips-security-05.txt
Section 12, QoS -- Updated per review comments and subsequent reflector
discussion.

Minor changes in 07:
iSNS -- Added new section 5.3 describing the role of iSNS.
4.4a) -- Added FC Node definition
4.7.1 -- Added description of address assignment for fabric-attached loops.
4.8 -- Added description of class 4 and class 6 transport services.
4.9 -- Added description of FC logins.
Figure 7 -- Changed "IP fabric" to "iFCP fabric."
5.2.1 -- Added description of how supported transport services are
discovered by an N_PORT.
PP 20 -- Corrected specification of requirements for Address-translation and
Address-transparent modes.
5.3.1.1 -- Added material describing use of iSNS for domain I/D assignment
in address-transparent mode.
5.3.1.2, 5.3.2.3 -- "SHALL" added to requirements for rejecting incoming
frames having incorrect address mode.
6.2.2.1 -- Corrected per review comment
6.2.2.2, "Use of TCP Features" -- Revised per review comment
6.2.2.3, "Error Recovery and Cold Start" -- Deleted per review comment
Sections 7 and 8 -- Order reversed per review comment
6.2.3 -- Identified entity being terminated or aborted (iFCP session) per
review comment
6.3 -- Qualified reference to point to appendix B of RFC 1323
7.3 and 7.3.7 (PLOGI) -- Terminology: Augmented ELSs are now referred to as
"Special" ELSs.
7.3.5 -- Fixed description of FARP-REQ.
7.3.8 -- Deleted description of REC ELS.
7.4, table 4 -- Modified table per review comment to delete references to
"y" entry types.
8.1 -- Added Connection Handle reference.
Appendix A -- Summary of Link Services. Deleted Link Services removed from
FC-FS spec.
Appendix B -- Deleted. Spec will be revised to include a reference to
published material.

 --=====================_95463969==_.ALT-- From owner-ips@ece.cmu.edu Tue Dec 4 14:06:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07128 for ; Tue, 4 Dec 2001 14:06:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB4I0cf03787 for ips-outgoing; Tue, 4 Dec 2001 13:00:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fB4I0Wl03776 for ; Tue, 4 Dec 2001 13:00:32 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fB4I0B830401; Tue, 4 Dec 2001 13:00:11 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fB4I0Bs14809; Tue, 4 Dec 2001 13:00:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15373.3882.892047.656552@pkoning.dev.equallogic.com> Date: Tue, 4 Dec 2001 13:00:10 -0500 (EST) From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: unsolicited data References: X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Julian" == Julian Satran writes: Julian> Sandeep, I assume that TCP will not overcomit (this is also a Julian> commitment that is easy to predict and small in size). iSCSI Julian> in this case is on the safe ground whatever it commits. I assume TCP doesn't overcommit, but that doesn't help. TCP worries about TCP resources, and iSCSI has to worry about iSCSI resources. You may be tight on iSCSI resources and still have TCP buffers. A way to avoid that is to be aware of how TCP manages resources and manage iSCSI resources "in parallel" and more conservatively. If so, then you are never "overcommitted" at the iSCSI level, and you need no flow control in the first place. The reason for having iSCSI level flow control is that the above may not be true -- i.e., TCP may have resources when iSCSI doesn't. So those cases where iSCSI flow control adds value are also the cases where lower layer flow control doesn't protect you from getting in trouble if you overcommit. In other words, if you want reliability, don't overcommit at any layer. paul From owner-ips@ece.cmu.edu Tue Dec 4 14:47:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09037 for ; Tue, 4 Dec 2001 14:47:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB4IjDx07499 for ips-outgoing; Tue, 4 Dec 2001 13:45:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB4IjAl07494 for ; Tue, 4 Dec 2001 13:45:10 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 145113262; Tue, 4 Dec 2001 11:45:09 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id A385059F; Tue, 4 Dec 2001 11:45:08 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 04 Dec 2001 11:45:08 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:45:08 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0092B2EB1@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: smithm007@hotmail.com, ips@ece.cmu.edu Cc: msmith@iready.com Subject: RE: iSCSI: v9 concordance Date: Tue, 4 Dec 2001 11:45:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mike, It looks like the URL is missing a 0 and should be: http://www.iready.org/iscsi/iscsi09concordanceV1.doc Regards, Pat -----Original Message----- From: Michael Sebastian Smith (Hotmail) [mailto:smithm007@hotmail.com] Sent: Monday, December 03, 2001 6:53 PM To: ips@ece.cmu.edu Cc: msmith@iready.com Subject: iSCSI: v9 concordance iSCSI: v8 concordanceI placed the concordance of the iSCSI v9 Internet draft at http://www.iready.org/iscsi/iscsi9concordanceV1.doc Aloha Mike Smith CTO iReady ----- Original Message ----- From: Michael Smith To: 'ips@ece.cmu.edu' Cc: Michael Smith Sent: Monday, October 08, 2001 5:36 PM Subject: iSCSI: v8 concordance There have been several comments recently on this reflector about the use of terms and definitions in the current iSCSI Internet draft. I have created a concordance for the iSCSI v8 Internet draft. You may download the concordance at http://www.iready.org/iscsi/iscsi8concordanceV5.doc This is a very large file (10MB). A concordance is like an amplified index. A concordance is an ordered list of the occurence of every single word, term, and character in the iSCSI v8 spec together with it's context (the context being a certain number of words around each occurence). Why is this useful? Let's take an example from the iSCSI Internet draft concordance file. Take the term "barrier". It often occurs as the term "barrier list" in the current Internet draft. But how is this term used exactly? First, look up "barrier (exactly as I have shown it here) in the concordance and you will see the following: "BARRIER................................................................5 layer. The "barrier list" described in the following sections is a 7370 "barrier list"; 7382 a) if the "barrier list" is empty or ExpCmdSN is less than 7392 a "barrier list" including the referenced LUN (or an ALL 7420 a) if the "barrier list" is empty or ExpCmdSN is less than 7428 This means the characters "barrier appear five times (lines 7370, 7382, 7392, 7420, 7428 as numbered from the .txt version). Each time the characters "barrier occur as "barrier list". Continue now to look up just the characters barrier in the concordance. You will find: BARRIER.................................................................5 Note: for clarity, the barrier list contains "items" and the 7387 the CmdSN of the oldest item in the barrier list then 7393 b) remove the oldest barrier list item, and remove and 7395 the oldest item in the barrier list then skip to step d; 7429 b) remove the oldest barrier list item and evaluate all 7430 Thus barrier also occurs five times (lines 7387, 7393, 7395, 7429, 7430). So what? The concordance has told us: 1. If the term "barrier list" is defined the first time that it is used. (It is, sort of.) 2. If the term "barrier list" is used consistently each time. 3. That the use of quotes around barrier list is inconsistent and therefore perhaps misleading. I hope that, from this small example, you may easily extrapolate to other uses of a concordance in reading, understanding, and editing the current iSCSI Internet draft. I have found this technique useful in the past. Aloha Mike Smith CTO iReady From owner-ips@ece.cmu.edu Tue Dec 4 19:57:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19945 for ; Tue, 4 Dec 2001 19:57:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB506Gg03179 for ips-outgoing; Tue, 4 Dec 2001 19:06:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB506El03175 for ; Tue, 4 Dec 2001 19:06:14 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA04343; Tue, 4 Dec 2001 16:06:05 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA14719; Tue, 4 Dec 2001 15:50:52 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 16:06:04 -0800 Message-ID: From: "Mukund, Shridhar" To: "'Paul Koning'" , bernard_aboba@hotmail.com Cc: ips@ece.cmu.edu Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I Date: Tue, 4 Dec 2001 16:06:03 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul and Bernard, Comments inline. -Shridhar Mukund > -----Original Message----- > From: Paul Koning [mailto:pkoning@equallogic.com] > Bernard> ...Given that 3DES-CBC-I has already been > Bernard> standardized by ANSI, > Bernard> it may be feasible to get an IPsec transform document > Bernard> written and adopted as a work item by IPsec WG. If this can > Bernard> happen, then it would be possible to argue the merits of > Bernard> this algorithm versus the other ones under > Bernard> consideration. Given the prevalence of 3DES-CBC however, I > Bernard> suspect that the argument would be over whether 3DES-CBC-I > Bernard> would become a MAY or a SHOULD implement, rather than a > Bernard> MUST. > > CBC-I is no less a hardware change than any other new mode. So it's > not clear why it would be useful to work on that rather than on other > new modes. Perhaps if there aren't IP issues with it? > I agree, this issue needs to be worked in thru the IPSec WG(and saag?) I have nothing against other new modes, assuming: When AES-CTR is approved, AES-CTR becomes MUST and 3DES-CBC is demoted to MAY. On the other hand, if both are MUST, then there is a problem. There are no IP issues with CBC-I. > Given that IPSec acts at the datagram level, you can do interleaving > on a packet basis. In a high speed implementation, it is reasonable > to expect that there are several packets awaiting processing at a > time. If so, they can each be run through separate processing > elements. So the CBC bottleneck applies within a packet but not > across packets. That's not to say that new modes aren't interesting > -- but it says that you can continue to improve performance in the > meantime. > Paul, it is difficult to argue the above issue without getting into more detail. I do insist that the "additional" and "otherwise unnecessary" cost of interleaving on a packet basis is "significant" at say 2G thru 10G. Let us take this off-line and follow-up on the IPSec reflector. -Shridhar Mukund From owner-ips@ece.cmu.edu Wed Dec 5 02:16:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15662 for ; Wed, 5 Dec 2001 02:16:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB55wL124907 for ips-outgoing; Wed, 5 Dec 2001 00:58:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mercury.corp.iready.com ([65.115.68.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB52Rsl12102 for ; Tue, 4 Dec 2001 21:27:54 -0500 (EST) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 18:27:41 -0800 Message-ID: <034670D62D19D31180990090277A37B701C18AB4@mercury.corp.iready.com> From: Michael Smith To: ips@ece.cmu.edu Cc: Michael Smith Subject: RE: iSCSI: v9 concordance - the correct URL Date: Tue, 4 Dec 2001 18:27:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17D34.6807FD50" Sender: owner-ips@ece.cmu.edu 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_01C17D34.6807FD50 Content-Type: text/plain; charset="iso-8859-1" Sorry, Julo and David. Thanks, Pat, you are right. Somehow I sent the email out, an erase and a keystroke before I finished. The URL is http://www.iready.org/iscsi/iscsi09concordanceV1.doc (careful with a double-clicking, it might be better to ftp this, it's 11MB) All: let me know if the Concordance is useful and how it might be improved to help compose the final draft. Aloha Mike Smith CTO iReady -----Original Message----- From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] Sent: Tuesday, December 04, 2001 10:45 AM To: smithm007@hotmail.com; ips@ece.cmu.edu Cc: msmith@iready.com Subject: RE: iSCSI: v9 concordance Mike, It looks like the URL is missing a 0 and should be: http://www.iready.org/iscsi/iscsi09concordanceV1.doc Regards, Pat -----Original Message----- From: Michael Sebastian Smith (Hotmail) [mailto:smithm007@hotmail.com] Sent: Monday, December 03, 2001 6:53 PM To: ips@ece.cmu.edu Cc: msmith@iready.com Subject: iSCSI: v9 concordance iSCSI: v8 concordanceI placed the concordance of the iSCSI v9 Internet draft at http://www.iready.org/iscsi/iscsi9concordanceV1.doc Aloha Mike Smith CTO iReady ----- Original Message ----- From: Michael Smith To: 'ips@ece.cmu.edu' Cc: Michael Smith Sent: Monday, October 08, 2001 5:36 PM Subject: iSCSI: v8 concordance There have been several comments recently on this reflector about the use of terms and definitions in the current iSCSI Internet draft. I have created a concordance for the iSCSI v8 Internet draft. You may download the concordance at http://www.iready.org/iscsi/iscsi8concordanceV5.doc This is a very large file (10MB). A concordance is like an amplified index. A concordance is an ordered list of the occurence of every single word, term, and character in the iSCSI v8 spec together with it's context (the context being a certain number of words around each occurence). Why is this useful? Let's take an example from the iSCSI Internet draft concordance file. Take the term "barrier". It often occurs as the term "barrier list" in the current Internet draft. But how is this term used exactly? First, look up "barrier (exactly as I have shown it here) in the concordance and you will see the following: "BARRIER................................................................5 layer. The "barrier list" described in the following sections is a 7370 "barrier list"; 7382 a) if the "barrier list" is empty or ExpCmdSN is less than 7392 a "barrier list" including the referenced LUN (or an ALL 7420 a) if the "barrier list" is empty or ExpCmdSN is less than 7428 This means the characters "barrier appear five times (lines 7370, 7382, 7392, 7420, 7428 as numbered from the .txt version). Each time the characters "barrier occur as "barrier list". Continue now to look up just the characters barrier in the concordance. You will find: BARRIER.................................................................5 Note: for clarity, the barrier list contains "items" and the 7387 the CmdSN of the oldest item in the barrier list then 7393 b) remove the oldest barrier list item, and remove and 7395 the oldest item in the barrier list then skip to step d; 7429 b) remove the oldest barrier list item and evaluate all 7430 Thus barrier also occurs five times (lines 7387, 7393, 7395, 7429, 7430). So what? The concordance has told us: 1. If the term "barrier list" is defined the first time that it is used. (It is, sort of.) 2. If the term "barrier list" is used consistently each time. 3. That the use of quotes around barrier list is inconsistent and therefore perhaps misleading. I hope that, from this small example, you may easily extrapolate to other uses of a concordance in reading, understanding, and editing the current iSCSI Internet draft. I have found this technique useful in the past. Aloha Mike Smith CTO iReady ------_=_NextPart_001_01C17D34.6807FD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: iSCSI: v9 concordance - the correct URL

Sorry, Julo and David. Thanks, Pat, you are right. = Somehow I sent the email out, an erase and a keystroke before I = finished.

The URL is http://www.iready.org/iscsi/iscsi09concordanceV1.doc (careful with a double-clicking, it might be better to ftp this, = it's 11MB)

All: let me know if the Concordance is useful and how = it might be improved to help compose the final draft.

Aloha

Mike Smith
CTO
iReady

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com= ]
Sent: Tuesday, December 04, 2001 10:45 AM
To: smithm007@hotmail.com; ips@ece.cmu.edu
Cc: msmith@iready.com
Subject: RE: iSCSI: v9 concordance


Mike,

It looks like the URL is missing a 0 and should = be:
 http://www.iready.org/iscsi/iscsi09concordanceV1.doc

Regards,
Pat

-----Original Message-----
From: Michael Sebastian Smith (Hotmail) [mailto:smithm007@hotmail.com]<= /FONT>
Sent: Monday, December 03, 2001 6:53 PM
To: ips@ece.cmu.edu
Cc: msmith@iready.com
Subject: iSCSI: v9 concordance


iSCSI: v8 concordanceI placed the concordance of the = iSCSI v9 Internet draft
at http://www.iready.org/iscsi/iscsi9concordanceV1.doc

Aloha

Mike Smith
CTO
iReady

----- Original Message -----
From: Michael Smith
To: 'ips@ece.cmu.edu'
Cc: Michael Smith
Sent: Monday, October 08, 2001 5:36 PM
Subject: iSCSI: v8 concordance


There have been several comments recently on this = reflector about the use of
terms and definitions in the current iSCSI Internet = draft.
I have created a concordance for the iSCSI v8 = Internet draft. You may
download the concordance at
http://www.iready.org/iscsi/iscsi8concordanceV5.doc
This is a very large file (10MB).
A concordance is like an amplified index. A = concordance is an ordered list
of the occurence of every single word, term, and = character in the iSCSI v8
spec together with it's context (the context being a = certain number of words
around each occurence).
Why is this useful? Let's take an example from the = iSCSI Internet draft
concordance file. Take the term "barrier". = It often occurs as the term
"barrier list" in the current Internet = draft. But how is this term used
exactly? First, look up "barrier (exactly as I = have shown it here) in the
concordance and you will see the following:


"BARRIER..................................................= ..............5
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           = layer.  The
"barrier list" described in the following = sections is a
7370

"barrier list";
7382
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; a) if the
"barrier list" is empty or ExpCmdSN is = less than
7392
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         a
"barrier list" including the referenced = LUN (or an ALL
7420
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; a) if the
"barrier list" is empty or ExpCmdSN is = less than
7428
This means the characters "barrier appear five = times (lines 7370, 7382,
7392, 7420, 7428 as numbered from the .txt version). = Each time the
characters "barrier occur as "barrier = list". Continue now to look up just
the characters barrier in the concordance. You will = find:
BARRIER........................................................= .........5
          &nb= sp;           &nb= sp;           &nb= sp;            = Note: for clarity, the
barrier list contains "items" and = the
7387
          &nb= sp;           &nb= sp;           the = CmdSN of the oldest item in the
barrier list then
7393
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  b) remove the oldest
barrier list item, and remove and
7395
          &nb= sp;           &nb= sp;           &nb= sp;            = the oldest item in the
barrier list then skip to step d;
7429
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  b) remove the oldest
barrier list item and evaluate all
7430


Thus barrier also occurs five times (lines 7387, = 7393, 7395, 7429, 7430).
So what?
The concordance has told us:
1. If the term "barrier list" is defined = the first time that it is used. (It
is, sort of.)
2. If the term "barrier list" is used = consistently each time.
3. That the use of quotes around barrier list is = inconsistent and therefore
perhaps misleading.
I hope that, from this small example, you may easily = extrapolate to other
uses of a concordance in reading, understanding, and = editing the current
iSCSI Internet draft. I have found this technique = useful in the past.
Aloha
Mike Smith
CTO
iReady

------_=_NextPart_001_01C17D34.6807FD50-- From owner-ips@ece.cmu.edu Wed Dec 5 05:15:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17809 for ; Wed, 5 Dec 2001 05:15:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB59M5w06984 for ips-outgoing; Wed, 5 Dec 2001 04:22:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mayfair.vxindia.veritas.com (bay-bridge.veritas.com [143.127.3.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB59M2l06974 for ; Wed, 5 Dec 2001 04:22:02 -0500 (EST) Received: from RAHULB (rahulb.vxindia.veritas.com [10.212.80.59]) by mayfair.vxindia.veritas.com (8.9.3/8.9.3) with SMTP id OAA24164 for ; Wed, 5 Dec 2001 14:52:04 +0530 (IST) Message-ID: <00e201c17d6e$7606db80$3b50d40a@vxindia.veritas.com> From: "Rahul Bhagwat" To: Subject: Session state and Text Sequence Date: Wed, 5 Dec 2001 14:53:11 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DF_01C17D9C.8F064ED0" 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 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DF_01C17D9C.8F064ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have two questions here 1. The description for Q2 state for Session says "at least one = connection" "is XPT_UP" A connection goes in XPT_UP state means that only the TCP connection is established and no login PDU is received. =20 In this state, it is not possible for a connection to belong to any = session as such (It is possible only after receiving the first login PDU = which means the connection goes into IN_LOGIN state. So the description for Q2 state should be "at least one connection = is=20 IN_LOGIN"=20 2. The specification says that it is possible to split a key value pair = across multiple Text PDUs. Consider a case where only one key value pair is to be sent by the = initiator. How should the target respond to it ? Is the following valid = request-response sequence in that case I -> T Text Request with partial key=3Dvalue pair F=3D0 T -> I Text Response empty F=3D1 I -> T Text Request with remaining key=3Dvalue pair F=3D1 T -> I Text Response for the key=3Dvalue pair F=3D1. Regards, Rahul ------=_NextPart_000_00DF_01C17D9C.8F064ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have two questions here
 
1. The description for Q2 state for = Session says=20 "at least one connection"
    "is = XPT_UP"
 
    A connection goes in = XPT_UP=20 state means that only the TCP connection
    is established and = no login PDU=20 is received.
   
    In this state, it is = not=20 possible for a connection to belong to any session
    as such (It is = possible only=20 after receiving the first login PDU which means
    the connection = goes into=20 IN_LOGIN state.
 
    So the description = for Q2 state=20 should be "at least one connection is
    IN_LOGIN" =
 
 
2. The specification says that it is = possible to=20 split a key value pair across
    multiple Text = PDUs.
 
    Consider a case = where only one=20 key value pair is to be sent by the initiator.
    How should the = target respond to=20 it ? Is the following valid request-response
    sequence in that=20 case
 
    I  -> = T  Text=20 Request with partial key=3Dvalue pair F=3D0
    T -> = I   Text=20 Response empty F=3D1
    I  -> = T  Text=20 Request with remaining key=3Dvalue pair F=3D1
    T -> = I   Text=20 Response for the key=3Dvalue pair F=3D1.
 
Regards,
Rahul
------=_NextPart_000_00DF_01C17D9C.8F064ED0-- From owner-ips@ece.cmu.edu Wed Dec 5 14:36:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05733 for ; Wed, 5 Dec 2001 14:36:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB5HN8e18852 for ips-outgoing; Wed, 5 Dec 2001 12:23:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB5HN5l18847 for ; Wed, 5 Dec 2001 12:23:06 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA05826; Wed, 5 Dec 2001 09:22:56 -0800 (PST) From: Keith McCloghrie Message-Id: <200112051722.JAA05826@cisco.com> Subject: iSCSI - structured values To: ips@ece.cmu.edu Date: Wed, 5 Dec 2001 09:22:55 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The following ideas came up in a discussion I had about iSCSI. The first issue is about the algorithm to use for allocating the structured ISID values, which contain three fields: - The Type field identifies the format: 00h - IEEE OUI 01h - IANA Enterprise Number (EN) 02h - "Random" 03h-FFh - Reserved - The Naming Authority field identifies the vendor or organization - The Qualifier field is a 16 bit value that provides a range of possible values for the ISID within the Type and Naming Authority namespace. The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify: (a) As noted, the structure of the ISID namespace provides each vendor with its own piece of the ISID namespace. In effect, this provides for a vendor-partitioning of that namespace within each initiator. So, this puts the onus on a "vendor" to come up with the vendor's own scheme for allocating ISID values. For the situation where a vendor wants to assign different values to different interfaces/HBAs, the simplest scheme would be to use a unique value which is shipped with each product, such as a MAC address. This would be simple because it would obviate any need to coordinate between different interfaces (even those from the same vendor). In fact, the first three bytes of a 6-byte MAC address are an IEEE OUI, which is exactly what type=0 specifies, except that the MAC address has 3 more bytes, and the Qualifier field is only 2 bytes. So, in order to allow vendors to adopt such a simple scheme, I'd like to propose that the Qualifier field be enlarged to at least 3 bytes. It probably doesn't make much sense to make the overall ISID to be 7 bytes long. So, how about making the Qualifier be 4 bytes so that the ISID is 8 bytes long ? As far as I'm aware the performance impact of this is virtually negligible, and so I can't really see any disadvantage in doing so. The second issue concerns Portal Group Tags. It seems that despite the difference in terminology, that an ISID and a Portal Group Tag are corresponding concepts. For example, a SCSI Port Name is defined as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag". However, a Portal Group Tag is defined as a 16-bit integer. Now, I understand that an ISID was originally defined as a 16-bit integer, before its format was expanded (as discussed above). So, with the correspondence of ISID and Portal Group Tag, surely it makes sense for a Portal Group Tag to have the same format as an ISID. This will allow vendors of iSCSI targets with multiple interfaces/HBAs to use a simple scheme as and when they need to assign different Portal Group Tag values to the different interfaces/HBAs. So, whether or not the ISID format is changed based on the first issue above, I propose that the same structured format be used for both ISIDs and Portal Group Tags. Keith. From owner-ips@ece.cmu.edu Wed Dec 5 21:15:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25161 for ; Wed, 5 Dec 2001 21:15:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB61EVE25873 for ips-outgoing; Wed, 5 Dec 2001 20:14:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f228.pav2.hotmail.com [64.4.37.228]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB61ERl25859 for ; Wed, 5 Dec 2001 20:14:28 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 5 Dec 2001 17:14:22 -0800 Received: from 131.107.3.72 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 06 Dec 2001 01:14:21 GMT X-Originating-IP: [131.107.3.72] From: "Bernard Aboba" To: Shridhar_Mukund@adaptec.com, pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I Date: Wed, 05 Dec 2001 17:14:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Dec 2001 01:14:22.0198 (UTC) FILETIME=[56546160:01C17DF3] Sender: owner-ips@ece.cmu.edu Precedence: bulk >When AES-CTR is >approved, AES-CTR becomes MUST and 3DES-CBC is demoted to MAY. Doing that will create a problem in interoperation between iSCSI HBAs (which might have AES support) and software-only implementations, all of which now support 3DES-CBC. So it seems like 3DES-CBC has to be a MUST. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Thu Dec 6 02:01:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07621 for ; Thu, 6 Dec 2001 02:01:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB65cdY14177 for ips-outgoing; Thu, 6 Dec 2001 00:38:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB65cVl14167 for ; Thu, 6 Dec 2001 00:38:31 -0500 (EST) Received: from ahganemw2k (sjc-vpn1-754.cisco.com [10.21.98.242]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id AAA23334 for ; Thu, 6 Dec 2001 00:38:12 -0500 (EST) From: "Ayman Ghanem" To: Subject: RE: iSCSI: NOPs on discovery session Date: Wed, 5 Dec 2001 23:37:34 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C17DE5.D0EE3760" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C17DE5.D0EE3760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Julian, I would vote for allowing it. Is the spec going to require the initiator to logout immediately after the SendTargets response is received?. Should the target drop the session after it had sent the response?. I am not sure how the discovery session could be misused. It has been authenticated like any other session and has only limited set of commands. One could also argue the need for logout on a discovery session as opposed to just closing the connection. -Ayman -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, December 04, 2001 1:05 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs on discovery session Ayman, It is true that I agreed that we may want to have it. However some members of the list have expressed immediately a strong opposition to it claiming that it was no strictly needed (true) and that discovery section are meant to be brief. I felt thus that we don't have a consensus on that and we may want to try again. I assume that the main concern was that this will enable discovery sessions to be become long lived and be used as a back door monitoring channel. Regards, Julo "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu 12-04-01 05:30 AM To: cc: Subject: iSCSI: NOPs on discovery session Julian, I thought we agreed to adding NOPs to the operations allowed on the discovery session. I couldn't find that in draft-09. Thanks. -Ayman ------=_NextPart_000_0000_01C17DE5.D0EE3760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Julian,
 
I = would vote for=20 allowing it. Is the spec going to require the initiator to logout = immediately=20 after the SendTargets response is received?. Should the target drop the = session=20 after it had sent the response?. I am not sure = how the=20 discovery session could be misused. It has been authenticated like any = other=20 session and has only limited set of commands. One could also argue the = need for=20 logout on a discovery session as opposed to just closing the=20 connection.
 
-Ayman
 
 
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Tuesday, December 04, 2001 1:05 = AM
To:=20 ips@ece.cmu.edu
Subject: Re: iSCSI: NOPs on discovery=20 session


Ayman,=20

It is true that I agreed that = we may want=20 to have it. However some members of the list have expressed = immediately a=20 strong opposition to it claiming that it was no strictly needed (true) = and=20 that discovery section are meant to be brief.
I felt thus that we don't have a consensus on that and we may = want to=20 try again.
I assume that = the main=20 concern was that this will enable discovery sessions to be become long = lived=20 and be used as a back door monitoring channel.

Regards,
Julo



"Ayman Ghanem"=20 <aghanem@cisco.com>
Sent by: owner-ips@ece.cmu.edu=20

12-04-01 05:30 AM =

        =
        To: =    =20    <ips@ece.cmu.edu>
        cc:      =20  
    =  =20   Subject:        iSCSI: NOPs on = discovery=20 session

    =  =20  


Julian,

I thought we agreed to adding NOPs to the = operations=20 allowed on the
discovery session. I couldn't find that in draft-09. = = Thanks.

-Ayman



------=_NextPart_000_0000_01C17DE5.D0EE3760-- From owner-ips@ece.cmu.edu Thu Dec 6 06:57:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23649 for ; Thu, 6 Dec 2001 06:57:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6AKeK13589 for ips-outgoing; Thu, 6 Dec 2001 05:20:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6AKcl13584 for ; Thu, 6 Dec 2001 05:20:38 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA10356; Thu, 6 Dec 2001 05:17:50 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB6AKa8135850; Thu, 6 Dec 2001 03:20:36 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: NOPs on discovery session To: "Ayman Ghanem" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 6 Dec 2001 02:19:55 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/06/2001 03:20:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fB6AKcl13585 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I do not see any reason to keep the decovery session up. Why would it be needed to stay up? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Ayman Ghanem" @ece.cmu.edu on 12/05/2001 09:37:34 PM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: RE: iSCSI: NOPs on discovery session Julian, I would vote for allowing it. Is the spec going to require the initiator to logout immediately after the SendTargets response is received?. Should the target drop the session after it had sent the response?. I am not sure how the discovery session could be misused. It has been authenticated like any other session and has only limited set of commands. One could also argue the need for logout on a discovery session as opposed to just closing the connection. -Ayman -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, December 04, 2001 1:05 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs on discovery session Ayman, It is true that I agreed that we may want to have it. However some members of the list have expressed immediately a strong opposition to it claiming that it was no strictly needed (true) and that discovery section are meant to be brief. I felt thus that we don't have a consensus on that and we may want to try again. I assume that the main concern was that this will enable discovery sessions to be become long lived and be used as a back door monitoring channel. Regards, Julo "Ayman Ghanem"         To: Sent by: owner-ips@ece.cmu.edu         cc:         Subject: 12-04-01 05:30 AM iSCSI: NOPs on discovery session Julian, I thought we agreed to adding NOPs to the operations allowed on the discovery session. I couldn't find that in draft-09. Thanks. -Ayman From owner-ips@ece.cmu.edu Thu Dec 6 11:34:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00018 for ; Thu, 6 Dec 2001 11:34:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6F8mI01409 for ips-outgoing; Thu, 6 Dec 2001 10:08:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6F8kl01404 for ; Thu, 6 Dec 2001 10:08:46 -0500 (EST) Received: from ahganemw2k (dhcp-161-44-68-153.cisco.com [161.44.68.153]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA15932 for ; Thu, 6 Dec 2001 10:08:40 -0500 (EST) From: "Ayman Ghanem" To: Subject: RE: iSCSI: NOPs on discovery session Date: Thu, 6 Dec 2001 09:08:03 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit If the initiator choose to keep the discovery session up, the target could use it to inform the initiator of new targets or LUNs it can access. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Thursday, December 06, 2001 4:20 AM > To: Ayman Ghanem > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: NOPs on discovery session > > > > I do not see any reason to keep the decovery session up. Why would it be > needed to stay up? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Ayman Ghanem" @ece.cmu.edu on 12/05/2001 09:37:34 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: > cc: > Subject: RE: iSCSI: NOPs on discovery session > > > > > Julian, > > I would vote for allowing it. Is the spec going to require the initiator > to logout immediately after the SendTargets response is received?. Should > the target drop the session after it had sent the response?. I > am not sure > how the discovery session could be misused. It has been > authenticated like > any other session and has only limited set of commands. One could also > argue the need for logout on a discovery session as opposed to just > closing the connection. > > -Ayman > > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Tuesday, December 04, 2001 1:05 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: NOPs on discovery session > > > > Ayman, > > It is true that I agreed that we may want to have it. However > some members > of the list have expressed immediately a strong opposition to it claiming > that it was no strictly needed (true) and that discovery section > are meant > to be brief. > I felt thus that we don't have a consensus on that and we may want to try > again. > I assume that the main concern was that this will enable discovery > sessions to be become long lived and be used as a back door monitoring > channel. > > Regards, > Julo > > > > > > "Ayman Ghanem" > >         To: > > Sent by: > > owner-ips@ece.cmu.edu         cc: > >         > Subject: > 12-04-01 05:30 AM iSCSI: NOPs > on > discovery > session > > > > > > > > > > Julian, > > I thought we agreed to adding NOPs to the operations allowed on the > discovery session. I couldn't find that in draft-09. Thanks. > > -Ayman > > > > > > > > From owner-ips@ece.cmu.edu Thu Dec 6 11:38:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00366 for ; Thu, 6 Dec 2001 11:38:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6FZpn03534 for ips-outgoing; Thu, 6 Dec 2001 10:35:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.san.yahoo.com (mail.san.yahoo.com [209.132.1.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6FZnl03529 for ; Thu, 6 Dec 2001 10:35:49 -0500 (EST) Received: from bursar.muttsnuts.com (193.120.246.22) by mail.san.yahoo.com (5.5.054.2) (authenticated as marke@muttsnuts.com) id 3C0F50F0000058B3 for ips@ece.cmu.edu; Thu, 6 Dec 2001 07:35:42 -0800 Message-Id: <5.1.0.14.2.20011206152927.02c08800@mail.muttsnuts.com> X-Sender: markemuttsnuts@mail.muttsnuts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 06 Dec 2001 15:31:19 +0000 To: From: "Mark S. Edwards" Subject: RE: iSCSI: NOPs on discovery session In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 09:08 AM 12/6/2001 -0600, Ayman Ghanem wrote: >If the initiator choose to keep the discovery session up, the target could >use it to inform the initiator of new targets or LUNs it can access. > >-Ayman SLP and iSNS will already do this and since SLP is mandatory to implement, this feature already exists. Discovery sessions should be short lived, they tie up network resources. Can you imagine 1000 initiators with long lived discovery sessions on a target ? Any sensible target will probably implement a timer on a discovery session anyway. Mark. From owner-ips@ece.cmu.edu Thu Dec 6 12:28:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04837 for ; Thu, 6 Dec 2001 12:28:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6GJBR07099 for ips-outgoing; Thu, 6 Dec 2001 11:19:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6GJAl07095 for ; Thu, 6 Dec 2001 11:19:10 -0500 (EST) Received: from ahganemw2k (dhcp-161-44-68-153.cisco.com [161.44.68.153]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA24313 for ; Thu, 6 Dec 2001 11:19:04 -0500 (EST) From: "Ayman Ghanem" To: Subject: RE: iSCSI: NOPs on discovery session Date: Thu, 6 Dec 2001 10:18:26 -0600 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <5.1.0.14.2.20011206152927.02c08800@mail.muttsnuts.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit That is true. However, this is an implementation issue. My point is there is nothing in the spec that requires either side to drop the discovery session after the initial discovery is completed. So, the question is: if this session can stay active long enough, should this command be disallowed?. The key "SendTargets" is also mandatory and there is no restriction on when/how it can be issued. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Mark S. Edwards > Sent: Thursday, December 06, 2001 9:31 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: NOPs on discovery session > > > At 09:08 AM 12/6/2001 -0600, Ayman Ghanem wrote: > >If the initiator choose to keep the discovery session up, the > target could > >use it to inform the initiator of new targets or LUNs it can access. > > > >-Ayman > > > SLP and iSNS will already do this and since SLP is mandatory to > implement, > this feature already exists. > > Discovery sessions should be short lived, they tie up network > resources. Can you imagine 1000 initiators with long lived discovery > sessions on a target ? Any sensible target will probably > implement a timer > on a discovery session anyway. > > > Mark. > > From owner-ips@ece.cmu.edu Thu Dec 6 13:24:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07006 for ; Thu, 6 Dec 2001 13:24:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6HMUF12549 for ips-outgoing; Thu, 6 Dec 2001 12:22:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6HMSl12544 for ; Thu, 6 Dec 2001 12:22:28 -0500 (EST) Received: from cisco.com (dhcp-171-69-79-34.cisco.com [171.69.79.34]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA25264; Thu, 6 Dec 2001 12:22:20 -0500 (EST) Message-ID: <3C0FA930.CBBE038@cisco.com> Date: Thu, 06 Dec 2001 11:21:52 -0600 From: Mark Bakke X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: Ayman Ghanem , ips@ece.cmu.edu Subject: Re: iSCSI: NOPs on discovery session References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If a client wants to receive async messages when new iSCSI targets become available, or wants to poll once in a while with SentTargets, it is better to keep the discovery session there. This is useful in cases where iSCSI gateways are connected through firewalls; only the iSCSI protocol needs to be allowed through the firewall to do this type of discovery. -- Mark John Hufferd wrote: > > I do not see any reason to keep the decovery session up. Why would it be > needed to stay up? > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > "Ayman Ghanem" @ece.cmu.edu on 12/05/2001 09:37:34 PM > > Sent by: owner-ips@ece.cmu.edu > > To: > cc: > Subject: RE: iSCSI: NOPs on discovery session > > Julian, > > I would vote for allowing it. Is the spec going to require the initiator > to logout immediately after the SendTargets response is received?. Should > the target drop the session after it had sent the response?. I am not sure > how the discovery session could be misused. It has been authenticated like > any other session and has only limited set of commands. One could also > argue the need for logout on a discovery session as opposed to just > closing the connection. > > -Ayman > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Tuesday, December 04, 2001 1:05 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: NOPs on discovery session > > Ayman, > > It is true that I agreed that we may want to have it. However some members > of the list have expressed immediately a strong opposition to it claiming > that it was no strictly needed (true) and that discovery section are meant > to be brief. > I felt thus that we don't have a consensus on that and we may want to try > again. > I assume that the main concern was that this will enable discovery > sessions to be become long lived and be used as a back door monitoring > channel. > > Regards, > Julo > > > "Ayman Ghanem" > To: > Sent by: > owner-ips@ece.cmu.edu cc: > Subject: > 12-04-01 05:30 AM iSCSI: NOPs on > discovery session > > > > > Julian, > > I thought we agreed to adding NOPs to the operations allowed on the > discovery session. I couldn't find that in draft-09. Thanks. > > -Ayman From owner-ips@ece.cmu.edu Thu Dec 6 13:40:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07456 for ; Thu, 6 Dec 2001 13:40:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB6HXxI13545 for ips-outgoing; Thu, 6 Dec 2001 12:33:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB6HXvl13540 for ; Thu, 6 Dec 2001 12:33:57 -0500 (EST) Received: from cisco.com (dhcp-171-69-79-34.cisco.com [171.69.79.34]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA05771; Thu, 6 Dec 2001 12:33:49 -0500 (EST) Message-ID: <3C0FABE1.B3D1A622@cisco.com> Date: Thu, 06 Dec 2001 11:33:21 -0600 From: Mark Bakke X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Mark S. Edwards" CC: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs on discovery session References: <5.1.0.14.2.20011206152927.02c08800@mail.muttsnuts.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark- This is true, but in cases where iSCSI is run through firewalls, it may be easier to just allow the iSCSI port through the firewall, and not allow the discovery protocols. This makes SendTargets the only way to do discovering in this situation, and to use an async message for discovery as targets become available requires the session to be kept around. Keep in mind that this may not be the normal, everyday way to use a discovery session, so not all discovery sessions will have to be long-lived. I think that this is a necessary option to provide for the firewall situation. -- Mark "Mark S. Edwards" wrote: > > At 09:08 AM 12/6/2001 -0600, Ayman Ghanem wrote: > >If the initiator choose to keep the discovery session up, the target could > >use it to inform the initiator of new targets or LUNs it can access. > > > >-Ayman > > SLP and iSNS will already do this and since SLP is mandatory to implement, > this feature already exists. > > Discovery sessions should be short lived, they tie up network > resources. Can you imagine 1000 initiators with long lived discovery > sessions on a target ? Any sensible target will probably implement a timer > on a discovery session anyway. > > Mark. From owner-ips@ece.cmu.edu Thu Dec 6 22:24:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23208 for ; Thu, 6 Dec 2001 22:24:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB72U8Y24819 for ips-outgoing; Thu, 6 Dec 2001 21:30:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB72U5l24812 for ; Thu, 6 Dec 2001 21:30:05 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA18570; Thu, 6 Dec 2001 18:29:55 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA03508; Thu, 6 Dec 2001 18:14:39 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Dec 2001 18:29:54 -0800 Message-ID: From: "Mukund, Shridhar" To: "'Bernard Aboba'" , "Mukund, Shridhar" , pkoning@equallogic.com Cc: ips@ece.cmu.edu Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. 3DES-CBC-I Date: Thu, 6 Dec 2001 18:29:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bernard, > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Wednesday, December 05, 2001 5:14 PM > To: Shridhar_Mukund@adaptec.com; pkoning@equallogic.com > Cc: ips@ece.cmu.edu > Subject: RE: Choice of ESP alg. for IPS/IPSec - 3DES-CBC vs. > 3DES-CBC-I > > > >When AES-CTR is > >approved, AES-CTR becomes MUST and 3DES-CBC is demoted to MAY. > > Doing that will create a problem in interoperation between > iSCSI HBAs (which > might have AES support) and software-only implementations, > all of which now > support 3DES-CBC. So it seems like 3DES-CBC has to be a MUST. > >>> Yes, if we do not prep appropriatly we are inviting >>> trouble down the road. But then, we do agree that it is the >>> charter of the IPS WG to enable low-cost iSCSI solutions from >>> today all the way up to 10G. >>> The IPSec implementation(hence interop) complexity is really >>> around yIKEs! Given that we leave the mathematically inclined >>> folks to invent(and standardize) ESP/AH algorithms, software >>> implementation of these algorithms is the easy part. >>> One of the important motivations behind AES is to simplify >>> s/w implementation. Since 3DES is compute intensive, >>> s/w implementations will transition rapidly. Even today >>> several implementations taut AES. >>> On a lighter note, those who resist small s/w changes that >>> bring significant value are not in this audience. iSCSI >>> is about change. -Shridhar Mukund From owner-ips@ece.cmu.edu Fri Dec 7 12:06:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24601 for ; Fri, 7 Dec 2001 12:06:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7G6r726223 for ips-outgoing; Fri, 7 Dec 2001 11:06:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7G6ll26197 for ; Fri, 7 Dec 2001 11:06:47 -0500 (EST) Received: from breinhold ([140.186.40.85]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id fB7G6cV09905 for ; Fri, 7 Dec 2001 11:06:38 -0500 (EST) From: "Barry Reinhold" To: "ISCSI" Subject: FCIP: How many LEPS are there in a FCIP entity Date: Fri, 7 Dec 2001 11:05:13 -0500 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.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am a bit confused between what is being shown in figure 4 of draft 07 and clause 13.2.2.2.2 of FC-BB-2 (rev 5.2 Nov 30). One appears to say there can be multiple LEPs in a FCIP entity and the other appears to restrict implementations to a single LEP in a FCIP entity. If it is multiple LEPs in a FCIP entity when would one use this? Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Fri Dec 7 12:59:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26112 for ; Fri, 7 Dec 2001 12:59:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7H1IO00536 for ips-outgoing; Fri, 7 Dec 2001 12:01:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from falcon.vixel.com (mail.vixel.com [207.115.190.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7Gv3l00194 for ; Fri, 7 Dec 2001 11:57:03 -0500 (EST) Received: from vixel.com ([192.168.1.184]) by falcon.vixel.com (Netscape Messaging Server 4.15) with ESMTP id GNZGEX00.1BL; Fri, 7 Dec 2001 08:56:57 -0800 Message-ID: <3C10F4BB.81E8523E@vixel.com> Date: Fri, 07 Dec 2001 08:56:27 -0800 From: "Ken Hirata" Organization: Vixel Corporation X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Barry Reinhold CC: ISCSI Subject: Re: FCIP: How many LEPS are there in a FCIP entity References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barry, There was some discussion on a subject related to this at the FC-BB-2 Ad Hoc meeting this week. I'd say FC-BB-2 rev 5.2 imposes an unrequired restriction on number of LEPs per FCIP Entity and should be corrected. Ken Barry Reinhold wrote: > I am a bit confused between what is being shown in figure 4 of draft 07 and > clause 13.2.2.2.2 of FC-BB-2 (rev 5.2 Nov 30). > > One appears to say there can be multiple LEPs in a FCIP entity and the other > appears to restrict implementations to a single LEP in a FCIP entity. If it > is multiple LEPs in a FCIP entity when would one use this? > > Barry Reinhold > Principal Architect > Trebia Networks > barry.reinhold@trebia.com > 603-868-5144/603-659-0885/978-929-0830 x138 -- Kenneth Hirata Vixel Corporation Irvine, CA 92618 Phone: (949) 450-6100 Email: Ken.Hirata@Vixel.com From owner-ips@ece.cmu.edu Fri Dec 7 14:27:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28431 for ; Fri, 7 Dec 2001 14:27:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7Iatv08008 for ips-outgoing; Fri, 7 Dec 2001 13:36:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7Iarl08002 for ; Fri, 7 Dec 2001 13:36:53 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id KAA06504; Fri, 7 Dec 2001 10:36:40 -0800 (PST) From: "Murali Rajagopal" To: "Barry Reinhold" , "ISCSI" Subject: RE: FCIP: How many LEPS are there in a FCIP entity Date: Fri, 7 Dec 2001 10:35:55 -0800 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.50.4133.2400 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barry: We have a productive closure on the FC-BB-2 Model this week at Austin T11 meeting and I will be putting out a new rev with the correct model in the near future that will have the corrrect descriptions of the number of LEPs. But here is a brief summary: There can be multiple instances of FC/FCIP Entity. Each FC/FCIP instance, can multiple instances of VE_Port/LEP. Each LEP can have multiple Data Engines. Hope this helps. -Murali -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Barry Reinhold Sent: Friday, December 07, 2001 8:05 AM To: ISCSI Subject: FCIP: How many LEPS are there in a FCIP entity I am a bit confused between what is being shown in figure 4 of draft 07 and clause 13.2.2.2.2 of FC-BB-2 (rev 5.2 Nov 30). One appears to say there can be multiple LEPs in a FCIP entity and the other appears to restrict implementations to a single LEP in a FCIP entity. If it is multiple LEPs in a FCIP entity when would one use this? Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 From owner-ips@ece.cmu.edu Fri Dec 7 16:42:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00763 for ; Fri, 7 Dec 2001 16:42:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7KmkV18390 for ips-outgoing; Fri, 7 Dec 2001 15:48:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from abaqos.com (adsl-64-164-218-74.dsl.snfc21.pacbell.net [64.164.218.74]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7Kidl18074 for ; Fri, 7 Dec 2001 15:44:39 -0500 (EST) Received: from abaqos.com (IDENT:wangmq@[10.88.88.119]) by abaqos.com (8.11.2/8.11.2) with ESMTP id fB7KiXT06423 for ; Fri, 7 Dec 2001 12:44:33 -0800 Message-ID: <3C112A31.7F7C7ED1@abaqos.com> Date: Fri, 07 Dec 2001 12:44:33 -0800 From: Menqiu Wang X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-win4lin i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Questions about Multiple connections in a session Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I read the iSCSI draft 09, and I get a little bit confused about multiple connections within a session. (1) As my understanding, this means that during a session, there can be serveral TCP connections co-existing at the same time. Is this right? (2) But how do they get connected? At the initiator side, they use different IP addresses, and at the target side, they share the same TCP port and use different IP addresses? If this is right, it sounds weird because usually storage devices on the network only have one IP address. What's relationship between iSCSI TCP port and SCSI port? (2) What's the motivation to support multiple connection within a session? Just for performance and reliability? Any of your help will be really appreciated. Thanks, Mengqiu From owner-ips@ece.cmu.edu Fri Dec 7 16:42:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00777 for ; Fri, 7 Dec 2001 16:42:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7KfnX17830 for ips-outgoing; Fri, 7 Dec 2001 15:41:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7Kfll17825 for ; Fri, 7 Dec 2001 15:41:48 -0500 (EST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA29503 for ; Fri, 7 Dec 2001 15:41:41 -0500 (EST) Message-ID: <3C1126D7.118D93AC@cisco.com> Date: Fri, 07 Dec 2001 14:30:15 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: IPS Subject: 3DES Re-key requirements question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit While talking with Paul Hoffman about the security draft, it appeared that our requirements for 3DES re-keying are likely much too strict. It is also making me nervous seeing comments on the list calling for mandating AES and not 3DES, since we have to work with what is real. Section 5.4 of the current ips-security draft contains some information about key exhaustion. The section suggests that SAs using 3DES CBC mode (the most commonly implemented IPsec encryption algorithm) will require re-keying very often; every four minutes for a 1 Gbps connection, and every 20-30 seconds for a 10 Gbps connection, and that it would be more prudent to re-key 1 Gbps every 4 seconds, and 10 Gbps every 0.4 seconds. While hardware is easily available to accelerate 3DES itself, many implementations do the key exchange in software. This takes quite a bit of CPU time, often shared with many other tasks. This makes re-keying at these short intervals impractical. This all seems to point at using AES-CBC instead of 3DES. However, I have a requirements question. The formulas shown in the draft specifies the number of bytes that can be transmitted on a connection before it becomes probable that SINGLE bit of information is leaked. It does not leak any bits of the key itself at this point. When doing disk or tape reads and writes, a single bit of information is not all that valuable. One would have to leak many bits of information, probably some of them sequential, in order for an observer to make actual use of the data. Furthermore, in order for the observer (Carol, right?) to do the analysis to recover the leaked bits, the entire data stream must be stored and available for processing; this cannot be done on-the-fly (Storage Vendors - here's a possible new market :-). In practice, this sort of cryptanalysis is required on many stored terabytes of information in order to recover a handful of bits of text. Anyway, I think that we need to come up with what our real requirements are for "data leakage", so that we can decide on what the practical re-keying times ought to be for 3DES. This should help alleviate concerns about 3DES' effectiveness, which are probably a bit on the paranoid side right now. How about stating a requirement something like: - The key for an IPsec SA shall be considered exhausted if: - More than x bits in y gigabits may be subject to leakage This should relax the re-key requirements on 3DES enough that it is practical to implement at 1Gbps, and perhaps 10Gbps, without introducing realistic security risks. Of course, AES will still be the right choice moving into the future, but there's a lot of 3DES out there, and AES has not yet been deployed. -- Mark -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Dec 7 16:52:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00881 for ; Fri, 7 Dec 2001 16:52:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7Kmlt18391 for ips-outgoing; Fri, 7 Dec 2001 15:48:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dogwood.cisco.com (dogwood.cisco.com [161.44.11.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7Kmjl18384 for ; Fri, 7 Dec 2001 15:48:45 -0500 (EST) Received: from cisco.com (58509@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA08691; Fri, 7 Dec 2001 15:48:34 -0500 (EST) Message-ID: <3C112873.DD91497F@cisco.com> Date: Fri, 07 Dec 2001 14:37:07 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Keith McCloghrie CC: ips@ece.cmu.edu Subject: Re: iSCSI - structured values References: <200112051722.JAA05826@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Keith on this; the new ISID format went a long way to solve the problem of a single initiator name being "represented" by multiple interface cards; I think that the same thing needs to be extended to target portal groups. Expanding the available identifier space in the ISID (and target portal group) to at least 3 bytes allows the convenience of a MAC address to be used for these identifiers. This also allows multiple gateways to represent the same initiator or target, without having to create different iSCSI names for each representation of the same initiator or target. I think that solving this problem (which we almost have already) would help these solutions scale much better. -- Mark Keith McCloghrie wrote: > > Hi, > > The following ideas came up in a discussion I had about iSCSI. > > The first issue is about the algorithm to use for allocating the > structured ISID values, which contain three fields: > > - The Type field identifies the format: > 00h - IEEE OUI > 01h - IANA Enterprise Number (EN) > 02h - "Random" > 03h-FFh - Reserved > - The Naming Authority field identifies the vendor or organization > - The Qualifier field is a 16 bit value that provides a range of > possible values for the ISID within the Type and Naming Authority > namespace. > > The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify: > > (a) As noted, the structure of the ISID namespace provides each > vendor with its own piece of the ISID namespace. In effect, this > provides for a vendor-partitioning of that namespace within each > initiator. > > So, this puts the onus on a "vendor" to come up with the vendor's own > scheme for allocating ISID values. For the situation where a vendor > wants to assign different values to different interfaces/HBAs, the > simplest scheme would be to use a unique value which is shipped with > each product, such as a MAC address. This would be simple because it > would obviate any need to coordinate between different interfaces > (even those from the same vendor). In fact, the first three bytes of > a 6-byte MAC address are an IEEE OUI, which is exactly what type=0 > specifies, except that the MAC address has 3 more bytes, and the > Qualifier field is only 2 bytes. So, in order to allow vendors to > adopt such a simple scheme, I'd like to propose that the Qualifier > field be enlarged to at least 3 bytes. It probably doesn't make much > sense to make the overall ISID to be 7 bytes long. So, how about > making the Qualifier be 4 bytes so that the ISID is 8 bytes long ? > As far as I'm aware the performance impact of this is virtually > negligible, and so I can't really see any disadvantage in doing so. > > The second issue concerns Portal Group Tags. It seems that despite > the difference in terminology, that an ISID and a Portal Group Tag > are corresponding concepts. For example, a SCSI Port Name is defined > as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag". However, > a Portal Group Tag is defined as a 16-bit integer. Now, I understand > that an ISID was originally defined as a 16-bit integer, before its > format was expanded (as discussed above). So, with the correspondence > of ISID and Portal Group Tag, surely it makes sense for a Portal Group > Tag to have the same format as an ISID. This will allow vendors of > iSCSI targets with multiple interfaces/HBAs to use a simple scheme as > and when they need to assign different Portal Group Tag values to the > different interfaces/HBAs. So, whether or not the ISID format is > changed based on the first issue above, I propose that the same > structured format be used for both ISIDs and Portal Group Tags. > > Keith. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Dec 7 18:12:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02224 for ; Fri, 7 Dec 2001 18:12:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB7MDHg25112 for ips-outgoing; Fri, 7 Dec 2001 17:13:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB7MDFl25108 for ; Fri, 7 Dec 2001 17:13:15 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 17:09:07 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293726F@CORPMX14> From: Black_David@emc.com To: wangmq@abaqos.com, ips@ece.cmu.edu Subject: RE: Questions about Multiple connections in a session Date: Fri, 7 Dec 2001 17:02:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > I read the iSCSI draft 09, and I get a little bit confused about > multiple connections within a session. > > (1) As my understanding, this means that during a session, there can be > serveral TCP connections co-existing at the same time. Is this right? Yes. > (2) But how do they get connected? At the initiator side, they use > different IP addresses, and at the target side, they share the same TCP > port and use different IP addresses? If this is right, it sounds weird > because usually storage devices on the network only have one IP address. Sharing the Target TCP port and IP address is allowed. Different IP addresses and TCP ports are also allowed. > What's relationship between iSCSI TCP port and SCSI port? For iSCSI, the SCSI port is a software entity that binds all the TCP connections together into a single iSCSI session. I suggest looking at the naming and discovery draft for a longer explanation. > (2) What's the motivation to support multiple connection within a > session? Just for performance and reliability? Yes. --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Dec 7 22:42:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07383 for ; Fri, 7 Dec 2001 22:42:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB82Zir11966 for ips-outgoing; Fri, 7 Dec 2001 21:35:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB82Zhl11962 for ; Fri, 7 Dec 2001 21:35:43 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 74F3C1F7B8; Fri, 7 Dec 2001 21:32:18 -0500 (EST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA10666; Fri, 7 Dec 2001 18:37:07 -0800 (PST) Message-Id: <200112080237.SAA10666@core.rose.hp.com> Date: Fri, 07 Dec 2001 18:48:34 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: ips@ece.cmu.edu Subject: Re: Comments on ips security draft References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard, Thanks for the response. After reading the dhcp-13.txt document and your clarification a couple of times, I am not quite clear on a couple of aspects here - most possibly because I am not that familiar with IPSec.... Additional responses to comments below would be very helpful. Your reference to the desirability of not changing the existing security gateways below makes me think you're visualizing a scenario with two security gateways operating in tunnel model in the path from a initiator (with a DHCP-assigned IP address) and a target. > For iSCSI with dynamically assigned addresses,... You sound like you're referring to the original routable IP address of the initiator itself being assigned via DHCP, but refer to the dhcp-13 draft which has to do with the "virtual host" receiving a DCHP-assigned address. Also, in the two-gateway scenario, would it be the gateway (the tunnel end point) that receives a DHCP address, than the initiator? Or, are you referring to a scenario with two DHCP relays in both security gateways - ultimately with the "virtual host" in the initiator? My reading of the dhcp-13 draft is that it is predicated on the requirement - "making the remote host appear to be present on the local corporate network is quite useful". Could you please comment why - is it because the routers within the corporate network might discard packets destined to non-local addresses? > ..., and we would not have interoperability. If I understand this correctly, you're referring to gateways receiving dynamically assigned addresses (than the initiators). Since iSCSI does not really require/prohibit external security gateways (since it's really product packaging), I am not sure that iSCSI needs to say anything about external security gateway compatibility. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Bernard Aboba wrote: > > >- Section 2.3, page 10. "Conformant iSCSI security implementations > >MUST support ESP in transport mode. " > > I assume it should be tunnel mode.... > > There is now a discussion going on on the SAAG mailing list about whether it > should be tunnel mode or transport mode. We'll talk more about this at IETF > 52. > > One significant issue with tunnel mode for iSCSI doesn't arise in iFCP or > FCIP, since with iSCSI initiators, addresses may be dynamically assigned, > whereas with iFCP and FCIP, the expectation seems to be that the IP > addresses will be static. Static addressing for tunnel mode is a lot > simpler. For one thing, since the addresses and configuration are static, > you don't need to configure tunnel addresses and parameters on the fly. > Another implication is that you can use main mode with shared secrets, and > have a unique shared secret for each endpoint. > > For iSCSI with dynamically assigned addresses, life becomes more > complicated. The implication is that if an iSCSI initiator with a > dynamically assigned address were to use tunnel mode, the tunnel mode > gateway at the other end would need to assign an IP address and otherwise > configure the tunnel. The IPSRA WG has recently put out a Proposed Standard > that addresses this issue, draft-ietf-ipsec-dhcp-13.txt. So if you want to > do tunnel mode within iSCSI and have it interoperate with the IETF Proposed > Standard for Tunnel mode configuration, you'll need to sign up for this too. > > The problem is that the goal was to be able to reuse existing IPsec gateways > -- if you have to significantly update the gateway, then this cancels one of > the advantages of doing tunnel mode. In the absence of referencing the IPSRA > WG standard for tunnel mode configuration, there would not be enough detail > to ensure interoperability between iSCSI security implementations. It would > be highly likely that some vendors would ship; their existing gateways which > typically do mode config (a proprietary protocol that is not on standards > track and may never even be published as an RFC) while others would do DHCP > config, and we would not have interoperability. > > Given that configuration is an essential part of IPsec tunnel mode setup for > dynamically addressed hosts, it is probably required that we reference the > proposed configuration method normatively. This would imply that if we go > with anything other than the IETF Proposed Standard, any documents, such as > iSCSI, which referenced these proprietary methods could not become IETF > standards. > > So if I believe this means that if we go with tunnel mode, we probably need > a normative reference to draft-ietf-ipsec-dhcp-13.txt as well. As the saying > goes "think carefully about what you ask for -- you might get it." > From owner-ips@ece.cmu.edu Sat Dec 8 02:17:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23491 for ; Sat, 8 Dec 2001 02:17:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB86ZSf25032 for ips-outgoing; Sat, 8 Dec 2001 01:35:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB86ZPl25025 for ; Sat, 8 Dec 2001 01:35:25 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA102578 for ; Sat, 8 Dec 2001 07:35:13 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB86ZZu99252 for ; Sat, 8 Dec 2001 07:35:35 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - structured values X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 8 Dec 2001 08:35:28 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/12/2001 08:35:30, Serialize complete at 08/12/2001 08:35:30 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that the 16 bit qualifier is good enough for the vendor(s) to define a dynamic locally unique value. The rest of the fields make up for the need of the vendor to assign a statically unique ID. Add this to the initiator name and you have a large enough play-field. On the target side - cooperation is not hindered by a requirement for APIs. The naming service does to PG allocation. I find also the header increase argument perilous - as somebody has already pointed out we are moving to a headers only protocol world - who needs data? Julo Mark Bakke Sent by: owner-ips@ece.cmu.edu 07-12-01 22:37 To: Keith McCloghrie cc: ips@ece.cmu.edu Subject: Re: iSCSI - structured values I agree with Keith on this; the new ISID format went a long way to solve the problem of a single initiator name being "represented" by multiple interface cards; I think that the same thing needs to be extended to target portal groups. Expanding the available identifier space in the ISID (and target portal group) to at least 3 bytes allows the convenience of a MAC address to be used for these identifiers. This also allows multiple gateways to represent the same initiator or target, without having to create different iSCSI names for each representation of the same initiator or target. I think that solving this problem (which we almost have already) would help these solutions scale much better. -- Mark Keith McCloghrie wrote: > > Hi, > > The following ideas came up in a discussion I had about iSCSI. > > The first issue is about the algorithm to use for allocating the > structured ISID values, which contain three fields: > > - The Type field identifies the format: > 00h - IEEE OUI > 01h - IANA Enterprise Number (EN) > 02h - "Random" > 03h-FFh - Reserved > - The Naming Authority field identifies the vendor or organization > - The Qualifier field is a 16 bit value that provides a range of > possible values for the ISID within the Type and Naming Authority > namespace. > > The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify: > > (a) As noted, the structure of the ISID namespace provides each > vendor with its own piece of the ISID namespace. In effect, this > provides for a vendor-partitioning of that namespace within each > initiator. > > So, this puts the onus on a "vendor" to come up with the vendor's own > scheme for allocating ISID values. For the situation where a vendor > wants to assign different values to different interfaces/HBAs, the > simplest scheme would be to use a unique value which is shipped with > each product, such as a MAC address. This would be simple because it > would obviate any need to coordinate between different interfaces > (even those from the same vendor). In fact, the first three bytes of > a 6-byte MAC address are an IEEE OUI, which is exactly what type=0 > specifies, except that the MAC address has 3 more bytes, and the > Qualifier field is only 2 bytes. So, in order to allow vendors to > adopt such a simple scheme, I'd like to propose that the Qualifier > field be enlarged to at least 3 bytes. It probably doesn't make much > sense to make the overall ISID to be 7 bytes long. So, how about > making the Qualifier be 4 bytes so that the ISID is 8 bytes long ? > As far as I'm aware the performance impact of this is virtually > negligible, and so I can't really see any disadvantage in doing so. > > The second issue concerns Portal Group Tags. It seems that despite > the difference in terminology, that an ISID and a Portal Group Tag > are corresponding concepts. For example, a SCSI Port Name is defined > as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag". However, > a Portal Group Tag is defined as a 16-bit integer. Now, I understand > that an ISID was originally defined as a 16-bit integer, before its > format was expanded (as discussed above). So, with the correspondence > of ISID and Portal Group Tag, surely it makes sense for a Portal Group > Tag to have the same format as an ISID. This will allow vendors of > iSCSI targets with multiple interfaces/HBAs to use a simple scheme as > and when they need to assign different Portal Group Tag values to the > different interfaces/HBAs. So, whether or not the ISID format is > changed based on the first issue above, I propose that the same > structured format be used for both ISIDs and Portal Group Tags. > > Keith. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sat Dec 8 02:18:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23561 for ; Sat, 8 Dec 2001 02:18:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB86iAS25506 for ips-outgoing; Sat, 8 Dec 2001 01:44:10 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12805.mail.yahoo.com (web12805.mail.yahoo.com [216.136.174.40]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fB86i8l25500 for ; Sat, 8 Dec 2001 01:44:08 -0500 (EST) Message-ID: <20011208064407.66896.qmail@web12805.mail.yahoo.com> Received: from [24.42.134.59] by web12805.mail.yahoo.com via HTTP; Fri, 07 Dec 2001 22:44:07 PST Date: Fri, 7 Dec 2001 22:44:07 -0800 (PST) From: Luben Tuikov Subject: clarification please To: iscsi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello, I have a question. The draft says: - the CRC register is initialized with all 1s (equivalent to complementing the first 32 bits of the message) Those two are NOT equivalent, e.g. if the message started with 32 1's then complementing will yield 32 0's, and this is not like ``initializing'' the CRC with 32 1's? Does this mean that the first 32 most significant bits of the message are complemented, or does it mean that the message is _prefixed_ with 32 1's and then the division starts? If it means prefixing, could you please use that word, as is customary in computer science literature... and to diminish ambiguities... -- Luben ===== -- __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Sat Dec 8 02:19:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23698 for ; Sat, 8 Dec 2001 02:19:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB86fjD25364 for ips-outgoing; Sat, 8 Dec 2001 01:41:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB86fhl25360 for ; Sat, 8 Dec 2001 01:41:44 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA127294 for ; Sat, 8 Dec 2001 07:41:36 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB86g0W138550 for ; Sat, 8 Dec 2001 07:42:00 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Questions about Multiple connections in a session X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 8 Dec 2001 08:41:52 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/12/2001 08:41:54, Serialize complete at 08/12/2001 08:41:54 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Menqiu, 1 - correct 2 - connections particiapte in a "session". At login any connection that is not the first is created with the same session-identifier. All this is explained at some length in section 2 and you will find there also the mapping to SCSI port 3 - the motivation - "only" performance and availability Julo Menqiu Wang Sent by: owner-ips@ece.cmu.edu 07-12-01 22:44 To: ips@ece.cmu.edu cc: Subject: Questions about Multiple connections in a session Hi, I read the iSCSI draft 09, and I get a little bit confused about multiple connections within a session. (1) As my understanding, this means that during a session, there can be serveral TCP connections co-existing at the same time. Is this right? (2) But how do they get connected? At the initiator side, they use different IP addresses, and at the target side, they share the same TCP port and use different IP addresses? If this is right, it sounds weird because usually storage devices on the network only have one IP address. What's relationship between iSCSI TCP port and SCSI port? (2) What's the motivation to support multiple connection within a session? Just for performance and reliability? Any of your help will be really appreciated. Thanks, Mengqiu From owner-ips@ece.cmu.edu Sat Dec 8 16:57:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04318 for ; Sat, 8 Dec 2001 16:57:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fB8L4OI22893 for ips-outgoing; Sat, 8 Dec 2001 16:04:24 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fB8L4El22880 for ; Sat, 8 Dec 2001 16:04:23 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id D5BB31F80F for ; Sat, 8 Dec 2001 16:00:48 -0500 (EST) Received: from swathi (pal1nai161126.nsr.hp.com [15.244.161.126]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA05611 for ; Sat, 8 Dec 2001 13:05:38 -0800 (PST) Message-ID: <006501c1802b$dfff63d0$7ea1f40f@rose.hp.com> From: "Mallikarjun C." To: "ips" References: <00e201c17d6e$7606db80$3b50d40a@vxindia.veritas.com> Subject: Re: Session state and Text Sequence Date: Sat, 8 Dec 2001 13:04:06 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So the description for Q2 state should be "at least one connection is > IN_LOGIN" You are right, I will change it. Thanks for the review. >Is the following valid request-response sequence in that case I believe so. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Rahul Bhagwat" To: Sent: Wednesday, December 05, 2001 1:23 AM Subject: Session state and Text Sequence Hi, I have two questions here 1. The description for Q2 state for Session says "at least one connection" "is XPT_UP" A connection goes in XPT_UP state means that only the TCP connection is established and no login PDU is received. In this state, it is not possible for a connection to belong to any session as such (It is possible only after receiving the first login PDU which means the connection goes into IN_LOGIN state. So the description for Q2 state should be "at least one connection is IN_LOGIN" 2. The specification says that it is possible to split a key value pair across multiple Text PDUs. Consider a case where only one key value pair is to be sent by the initiator. How should the target respond to it ? Is the following valid request-response sequence in that case I -> T Text Request with partial key=value pair F=0 T -> I Text Response empty F=1 I -> T Text Request with remaining key=value pair F=1 T -> I Text Response for the key=value pair F=1. Regards, Rahul From owner-ips@ece.cmu.edu Mon Dec 10 12:53:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06714 for ; Mon, 10 Dec 2001 12:53:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBAGBIt14775 for ips-outgoing; Mon, 10 Dec 2001 11:11:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12903.mail.yahoo.com (web12903.mail.yahoo.com [216.136.174.70]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBA6Shl27862 for ; Mon, 10 Dec 2001 01:28:43 -0500 (EST) Message-ID: <20011210062842.40150.qmail@web12903.mail.yahoo.com> Received: from [64.166.225.174] by web12903.mail.yahoo.com via HTTP; Sun, 09 Dec 2001 22:28:42 PST Date: Sun, 9 Dec 2001 22:28:42 -0800 (PST) From: Mengqiu Wang Subject: Questions about implementation of Multiple connections To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I have several questions about multiple connections: (1) Are multiple connections between initiator and a target common? I mean, how many applications will require iSCSI implementation to be able to handle multiple connections within a session? Can anybody give me some overview idea about the application of multiple TCP connections, like: is it an exceptional case? or common case? (2) Consider a hard drive on the network. It only has one hardware port. If we want to develop a iSCSI box to handle all incoming iSCSI commands for it, is it necessary for the box to handle multiple TCP connections for this hard drive? How? Does the box need more than one IP addresses? Thanks, Meng __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 10 13:21:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07764 for ; Mon, 10 Dec 2001 13:21:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBAHNFB20811 for ips-outgoing; Mon, 10 Dec 2001 12:23:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBAHNCl20803 for ; Mon, 10 Dec 2001 12:23:12 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBAHMjd14422; Mon, 10 Dec 2001 12:22:45 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBAHMjK11670; Mon, 10 Dec 2001 12:22:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15380.61285.65099.651496@pkoning.dev.equallogic.com> Date: Mon, 10 Dec 2001 12:22:45 -0500 (EST) From: Paul Koning To: ltuikov@yahoo.com CC: ips@ece.cmu.edu Subject: Re: clarification please References: <20011208064407.66896.qmail@web12805.mail.yahoo.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Luben" == Luben Tuikov writes: Luben> Hello, I have a question. The draft says: - the CRC register Luben> is initialized with all 1s (equivalent to complementing the Luben> first 32 bits of the message) Luben> Those two are NOT equivalent, e.g. if the message started with Luben> 32 1's then complementing will yield 32 0's, and this is not Luben> like ``initializing'' the CRC with 32 1's? Luben> Does this mean that the first 32 most significant bits of the Luben> message are complemented, or does it mean that the message is Luben> _prefixed_ with 32 1's and then the division starts? Luben> If it means prefixing, could you please use that word, as is Luben> customary in computer science literature... and to diminish Luben> ambiguities... It does NOT mean prefixing. The wording about "complementing" comes directly from the Ethernet spec, and is common to all recent CRC algorithms. The wording in the spec implies that the following two descriptions are equivalent: 1. Initialize the CRC register to all 1s, then process the data 2. Initialize the CRC to all 0s, complement the first 32 bits of the data, then process it Consider a packet that begins with 32 bits of 1. It's obvious that the second description will result in an all-zero CRC register after those 32 bits have been processed. The first description has the same effect. For each bit, you shift out a 1 from one end; that is XORed with the data bit, resulting in a zero shifting into the other end, and the other bits remaining the same. Do that 32 times and you end up with an all-zero CRC register, just as for description 2. Incidentally, this implies that this CRC will not detect the insertion of any number of 0 bits immediately after a packet beginning of 32 bits of 1. That's a fine tradeoff, since that error pattern is a lot less likely than simply having extraneous 0 bits at packet start -- which is why the complement was introduced into datacomm CRC algorithms. paul From owner-ips@ece.cmu.edu Mon Dec 10 20:37:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16328 for ; Mon, 10 Dec 2001 20:37:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBB0VrL24411 for ips-outgoing; Mon, 10 Dec 2001 19:31:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBB0VpZ24407 for ; Mon, 10 Dec 2001 19:31:52 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id BA4061F7CC; Mon, 10 Dec 2001 19:28:23 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id CF7DA1F516; Mon, 10 Dec 2001 19:31:45 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 19:31:45 -0500 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF29D@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Keith McCloghrie'" , ips@ece.cmu.edu Subject: RE: iSCSI - structured values Date: Mon, 10 Dec 2001 19:31:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk What is the problem you would like to solve by applying the same scheme to assigning Target Portal Group numbers? The problem of ISID assignment was different than Target Portal Group number assignment. Since I don't see a similar problem with targets and their portal group assignment, I don't see the need for changes regarding TPG numbering. Marjorie > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Wednesday, December 05, 2001 9:23 AM > To: ips@ece.cmu.edu > Cc: kzm@cisco.com > Subject: iSCSI - structured values > > > Hi, > > The following ideas came up in a discussion I had about iSCSI. > > The first issue is about the algorithm to use for allocating the > structured ISID values, which contain three fields: > > - The Type field identifies the format: > 00h - IEEE OUI > 01h - IANA Enterprise Number (EN) > 02h - "Random" > 03h-FFh - Reserved > - The Naming Authority field identifies the vendor or organization > - The Qualifier field is a 16 bit value that provides a range of > possible values for the ISID within the Type and Naming Authority > namespace. > > The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify: > > (a) As noted, the structure of the ISID namespace provides each > vendor with its own piece of the ISID namespace. In effect, this > provides for a vendor-partitioning of that namespace within each > initiator. > > So, this puts the onus on a "vendor" to come up with the vendor's own > scheme for allocating ISID values. For the situation where a vendor > wants to assign different values to different interfaces/HBAs, the > simplest scheme would be to use a unique value which is shipped with > each product, such as a MAC address. This would be simple because it > would obviate any need to coordinate between different interfaces > (even those from the same vendor). In fact, the first three bytes of > a 6-byte MAC address are an IEEE OUI, which is exactly what type=0 > specifies, except that the MAC address has 3 more bytes, and the > Qualifier field is only 2 bytes. So, in order to allow vendors to > adopt such a simple scheme, I'd like to propose that the Qualifier > field be enlarged to at least 3 bytes. It probably doesn't make much > sense to make the overall ISID to be 7 bytes long. So, how about > making the Qualifier be 4 bytes so that the ISID is 8 bytes long ? > As far as I'm aware the performance impact of this is virtually > negligible, and so I can't really see any disadvantage in doing so. > > The second issue concerns Portal Group Tags. It seems that despite > the difference in terminology, that an ISID and a Portal Group Tag > are corresponding concepts. For example, a SCSI Port Name is defined > as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag". However, > a Portal Group Tag is defined as a 16-bit integer. Now, I understand > that an ISID was originally defined as a 16-bit integer, before its > format was expanded (as discussed above). So, with the correspondence > of ISID and Portal Group Tag, surely it makes sense for a Portal Group > Tag to have the same format as an ISID. This will allow vendors of > iSCSI targets with multiple interfaces/HBAs to use a simple scheme as > and when they need to assign different Portal Group Tag values to the > different interfaces/HBAs. So, whether or not the ISID format is > changed based on the first issue above, I propose that the same > structured format be used for both ISIDs and Portal Group Tags. > > Keith. > From owner-ips@ece.cmu.edu Mon Dec 10 20:55:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16414 for ; Mon, 10 Dec 2001 20:55:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBB1AgK26850 for ips-outgoing; Mon, 10 Dec 2001 20:10:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.com (040.dsl6660175.bstatic.surewest.net [66.60.175.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBB1AdZ26843 for ; Mon, 10 Dec 2001 20:10:39 -0500 (EST) Received: by homer.lmg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 17:09:17 -0800 Message-ID: From: Dean Scoville To: ips@ece.cmu.edu Subject: iSCSI Marker questions Date: Mon, 10 Dec 2001 17:09:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The iSCSI Draft 9 Appendix C makes the following statements about Markers and the Initial Marker-less Interval: "The offset to the next iSCSI PDU header is counted in terms of the TCP stream data. Anything counted in the TCP sequence-number is counted for the offset. Specifically this includes any bytes "inserted" in the TCP stream by an UFL and it excludes any other markers inserted between the one we are examining and the next PDU header."... "To enable the connection setup including the login phase negotiation, marking (if any) is started only at the first marker interval after the end of the login phase." I understand that markers are not inserted until after login phase. Am I correct to assume that the placement of the first marker determined by the TCP sequence numbers on the final Login Request/ Response PDUs, or is initial marker position determined by the TCP sequence numbers at connection establishment? Assume the following interaction: I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? I-> Login Request PDU, T=0,CSG=1,NSG=0: InitiatorName=xxx TargetName=yyy SessionType=normal ... FMarker=send-receive RFMarkInt=512,1024 T-> Login Response PDU, T=0,CSG=1,NSG=0: ... FMarker=send-receive SFMarkInt=1024 RFMarkInt=1024 I-> Login Request PDU, T=1,CSG=1,NSG=3: SFMarkInt=1024 (64-byte PDU... TCP sequenceNum=1301-1364) T-> Login Response PDU, T=1,CSG=1,NSG=3: (48-byte PDU... TCP sequenceNum=2201-2248) The above interaction designates a 1024 x 4 = 4096-byte marker interval in both directions. The first PDU byte sent by the intitiator in full-feature mode will have sequenceNum=1365, and the first byte sent by the target will have sequenceNum=2249. Assuming the markerless interval starts at the end of login phase, the first two markers in each direction will have the following TCP sequence numbers: TCP SeqNum of TCP SeqNum of First Marker Second Marker ------------ ------------- Initiator: 5461-5468 9565-9572 Target: 6345-6352 10449-10456 Is this the correct interpretation of marker usage in iSCSI Draft 9, or does marker placement depend on the connection's initial sequence numbers? Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" considered a reply to that offer? If an offer is sent with "FMarker=..." and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or BOTH "FMarker=yes" and "SFMarkInt=..."? Thanks, Dean Scoville QLogic Corp. From owner-ips@ece.cmu.edu Mon Dec 10 20:55:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16427 for ; Mon, 10 Dec 2001 20:55:54 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBB1JJ727361 for ips-outgoing; Mon, 10 Dec 2001 20:19:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from calliope1.fm.intel.com (fmfdns01.fm.intel.com [132.233.247.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBB1JHZ27357 for ; Mon, 10 Dec 2001 20:19:18 -0500 (EST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.46 2001/10/25 21:02:55 root Exp $) with SMTP id BAA09540 for ; Tue, 11 Dec 2001 01:19:16 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2001121017202509856 ; Mon, 10 Dec 2001 17:20:25 -0800 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 17:19:16 -0800 Message-ID: From: "Yao, Xuebin" To: "'Mengqiu Wang'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI- Questions about implementation of Multiple connections Date: Mon, 10 Dec 2001 17:19:11 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Menqiu, (1) Multiple connections are common. They will provide better performance and availability. Multiple connection is more likely invisible to your application since there is still single session for your application. A lot of storage application need the high availability. For iSCSI aspect, your network link could be a weakest link and have multiple connections could help to reduce the risk of single-path failure. If you don't choose to implement multiple connection, you may need to implement multiple HBA solution for muti-pathing/failover which is more like traditional storag flavor mode and still achieve redundancy. But in that case, your application (like LVM, file system) may need to aware of the duplicate path. You could have your multiple connections in either active-passive mode or load-balancing mode. However, I didn't why you don't want to implement mutiple TCP connections in load-balance mode which doesn't sound any more difficult than active-passive case (which you mentioned, exception case). (2) Your target side will not be only a single hard drive. I didn't see why you want to just attach a single hard drive to network ? Are you going to try to implement iSCSI on the single Hard Drive? Most time, your target side will be a storage subsystem with intelligent controller. Your drive tray/JBOD or RAID system (in your word, the box) should have the iSCSI target module or you can use a iSCSI to SCSI/FC router to do that. Even you don't have the scalibility to put multiple network portal on your target side, you single network interface with even one IP can still handle TCP multiple connections. Only drawback is, now the single point of failure comes to your single network interface. Xuebin Yao >-----Original Message----- >From: Mengqiu Wang [mailto:mengqiuw@yahoo.com] >Sent: Monday, December 10, 2001 12:29 AM >To: ips@ece.cmu.edu >Subject: Questions about implementation of Multiple connections > I have several questions about multiple connections: >(1) Are multiple connections between initiator and a >target common? I mean, how many applications will >require iSCSI implementation to be able to handle >multiple connections within a session? Can anybody >give me some overview idea about the application of >multiple TCP connections, like: is it an exceptional >case? or common case? >(2) Consider a hard drive on the network. It only has >one hardware port. If we want to develop a iSCSI box >to handle all incoming iSCSI commands for it, is it >necessary for the box to handle multiple TCP >connections for this hard drive? How? Does the box >need more than one IP addresses? >Thanks, >Meng __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com From owner-ips@ece.cmu.edu Tue Dec 11 19:49:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28811 for ; Tue, 11 Dec 2001 19:49:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBBNoW810807 for ips-outgoing; Tue, 11 Dec 2001 18:50:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-68.crossroads.com [65.68.235.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBBNoVZ10803 for ; Tue, 11 Dec 2001 18:50:31 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPSEC: IKE preshared keys, ID payload, and DHCP X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 11 Dec 2001 17:50:14 -0600 Message-ID: Thread-Topic: IPSEC: IKE preshared keys, ID payload, and DHCP Thread-Index: AcGCnpQ2ssPhFbqmSsOHbpqCy9ydJw== From: "Michael Klock" To: "Ips Reflector (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBBNoVZ10804 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I searched the archives, but couldn't find a discussion directly related to this topic. Apologies if I missed one. If only the required IKE mode of preshared keys is supported and ID payloads must contain a single IP address (ips-security-06, last paragraph, page 12), how are DHCP-enabled ports handled? When setting up the preshared key, an administrator needs to know the IP address since this is what the ID payload will identify (and what is used to select the preshared key). But can't the IP address change for a DHCP-enabled port on a power cycle, or lease expiration, etc.? Is there an assumption that only ports with static IP addresses are being used? In a related vein, will the IPSec DOI definition be updated to include iSCSI names for ID payload types? I think this would remove the problem with DHCP (at least for IKE Aggressive Mode). Thanks for the help, Mike. Michael M. Klock Crossroads Systems, Inc. (512) 928-7292 From owner-ips@ece.cmu.edu Tue Dec 11 20:50:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00010 for ; Tue, 11 Dec 2001 20:50:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBC0s9j15053 for ips-outgoing; Tue, 11 Dec 2001 19:54:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBC0s6Z15043 for ; Tue, 11 Dec 2001 19:54:06 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id BAA19656 for ; Wed, 12 Dec 2001 01:53:56 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBC0sLE130372 for ; Wed, 12 Dec 2001 01:54:21 +0100 To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Dec 2001 02:54:16 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/12/2001 02:54:18, Serialize complete at 12/12/2001 02:54:18 Content-Type: multipart/alternative; boundary="=_alternative 0003B8BAC2256B20_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0003B8BAC2256B20_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questions Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. --=_alternative 0003B8BAC2256B20_= Content-Type: text/html; charset="US-ASCII"
----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


        To:        IPS List
        cc:        
        Subject:        Re: iSCSI Marker questionsLink


Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 
 
> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).


 
> Thanks,
> Dean Scoville
> QLogic Corp.
--=_alternative 0003B8BAC2256B20_=-- From owner-ips@ece.cmu.edu Tue Dec 11 20:52:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00048 for ; Tue, 11 Dec 2001 20:52:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBC0s9H15054 for ips-outgoing; Tue, 11 Dec 2001 19:54:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBC0s7Z15044 for ; Tue, 11 Dec 2001 19:54:07 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id BAA24564 for ; Wed, 12 Dec 2001 01:53:55 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBC0sKE130370 for ; Wed, 12 Dec 2001 01:54:20 +0100 To: ips@ece.cmu.edu Subject: Fw: Re: Questions about implementation of Multiple connections MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Wed, 12 Dec 2001 02:54:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/12/2001 02:54:17, Serialize complete at 12/12/2001 02:54:17 Content-Type: multipart/alternative; boundary="=_alternative 00036E7BC2256B20_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00036E7BC2256B20_= Content-Type: text/plain; charset="US-ASCII" ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:37 ----- Julian Satran 10-12-01 20:05 To: ips cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Questions about implementation of Multiple connections Meng, owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42: > I have several questions about multiple connections: > > (1) Are multiple connections between initiator and a > target common? I mean, how many applications will > require iSCSI implementation to be able to handle > multiple connections within a session? Can anybody > give me some overview idea about the application of > multiple TCP connections, like: is it an exceptional > case? or common case? > I assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it. > (2) Consider a hard drive on the network. It only has > one hardware port. If we want to develop a iSCSI box > to handle all incoming iSCSI commands for it, is it > necessary for the box to handle multiple TCP > connections for this hard drive? How? Does the box > need more than one IP addresses? > I don't think you need this for one disk although you may want to admit two for recovery. > Thanks, > Meng > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com Julo --=_alternative 00036E7BC2256B20_= Content-Type: text/html; charset="US-ASCII"
----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:37 -----
Julian Satran

10-12-01 20:05


        To:        ips
        cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu
        Subject:        Re: Questions about implementation of Multiple connectionsLink


Meng,

owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42:

> I have several questions about multiple connections:
>
> (1) Are multiple connections between initiator and a
> target common? I mean, how many applications will
> require iSCSI implementation to be able to handle
> multiple connections within a session? Can anybody
> give me some overview idea about the application of
> multiple TCP connections, like: is it an exceptional
> case? or common case?
>

I  assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it.

> (2) Consider a hard drive on the network. It only has
> one hardware port. If we want to develop a iSCSI box
> to handle all incoming iSCSI commands for it, is it
> necessary for the box to handle multiple TCP
> connections for this hard drive? How? Does the box
> need more than one IP addresses?
>

I don't think you need this for one disk although you may want to admit two for  recovery.


> Thanks,
> Meng
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
Julo
--=_alternative 00036E7BC2256B20_=-- From owner-ips@ece.cmu.edu Wed Dec 12 12:51:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14347 for ; Wed, 12 Dec 2001 12:51:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBCH8vo25605 for ips-outgoing; Wed, 12 Dec 2001 12:08:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBCH8uZ25600 for ; Wed, 12 Dec 2001 12:08:56 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 12:11:24 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937282@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Framing Update Date: Wed, 12 Dec 2001 11:57:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The issue that necessitated removing the iSCSI Framing Requirements agenda item from Tuesday's agenda has been resolved. I'm sorry that removing the agenda item was necessary, but would ask for some understanding that AD and WG chair work overload were significant contributing factors to this. In the tsvwg meeting on Tuesday, it was announced that the TCP ULP framing draft (draft-ietf-tsvwg-tcp-ulp-frame-01.txt) will be advanced to become an Experimental RFC. My understanding is that a combination of technical concerns raised in tsvwg-related discussions and the observation of the difficulty that the ips WG has had in determining the appropriate level of requirement for this mechanism contributed to a conclusion that an Experimental RFC is appropriate at this time. This is not the last word ... FWIW, Explicit Congestion Notification (ECN) started out as an Experimental RFC and has recently been updated and reissued as a Proposed Standard RFC. Since normative references to Experimental RFCs are not permitted in standards-track documents, the strongest requirement that iSCSI may use for TCP ULP framing is "MAY" (MAY implement, MAY use) - "SHOULD" and "MUST" cannot be used. I am also going to exercise my prerogative as WG chair in the area of framing mechanisms that are independent of the TCP implementation to announce that at most one such mechanism will be permitted to be specified for use with iSCSI. This means that when the details for the word-stuffing version of constant overhead byte stuffing are worked out and made available, the WG will be faced with two issues: (1) Which mechanism is to be specified (markers or word-stuffing)? I don't believe that WG rough consensus can be obtained for not specifying any mechanism in this space. (2) What level of requirements (MUST/SHOULD/MAY) to impose on implementation and use of that mechanism. As I said in Salt Lake City, I do not intend to allow these issues to remain open beyond the February interim meeting. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Dec 12 12:59:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14508 for ; Wed, 12 Dec 2001 12:59:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBCGqNO24383 for ips-outgoing; Wed, 12 Dec 2001 11:52:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com ([128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBCGqMZ24378 for ; Wed, 12 Dec 2001 11:52:22 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 11:52:16 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E02937281@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: SRP Intellectual Property Slides Date: Wed, 12 Dec 2001 11:41:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk As promised, here is the complete text from the slides on SRP Intellectual Property Rights that I used in the meeting yesterday morning. The information on Stanford, Lucent, and the possibly applicable 2001 patent is towards the end. Please read all the way to the end (last slide is titled "Next Steps") before responding to this message. Thanks, --David SRP Intellectual Property Rights David Black, IP Storage WG co-chair December 2001 Salt Lake City, UT Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session. - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB, or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function. Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group, or function are not subject to these provisions. Disclaimer I am NOT a lawyer This is NOT legal advice If you need legal advice ... - You need to talk to a lawyer If actions or decisions based on information in this presentation have legal consequences - Those consequences are YOUR responsibility - The IETF and yours truly disclaim all responsibility IETF Policy: Intellectual Property and Contributions RFC 2026, Section 10.3.1, Clause 6: 6. The contributor represents that he has disclosed the existence of any proprietary or intellectual property rights in the contribution that are reasonably and personally known to the contributor. The contributor does not represent that he personally knows of all potentially pertinent proprietary and intellectual property rights owned or claimed by the organization he represents (if any) or third parties. This is an obligation to disclose. How to disclose: www.ietf.org/ipr.html IETF Policy: Intellectual Property Rights Claims (I) RFC 2026, Section 10.3.2, Clause (A): (A) Where any patents, patent applications, or other proprietary rights are known, or claimed, with respect to any specification on the standards track, and brought to the attention of the IESG, the IESG shall not advance the specification without including in the document a note indicating the existence of such rights, or claimed rights. If rights are known or claimed, RFC will say that the IETF has been notified. - As of the date the RFC is published - Nothing specific about the claim(s) IETF Policy: Intellectual Property Rights Claims (II) RFC 2026, Section 10.3.2, Clause (B): (B) The IESG disclaims any responsibility for identifying the existence of or for evaluating the applicability of any claimed copyrights, patents, patent applications, or other rights in the fulfilling of the its obligations under (A), and will take no position on the validity or scope of any such rights. No IETF obligation to identify claims. The IETF takes no positions on validity or scope. IETF Policy: Intellectual Property Rights Claims (III) RFC 2026, Section 10.3.2, Clause (C): (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. Attempt to obtain promise, response not required. - Promises are recorded at: www.ietf.org/ipr.html . SRP and iSCSI Context iSCSI currently REQUIRES SRP - SRP = Secure Remote Password, RFC 2945 - Rumors of patent claims covering SRP Goal: Avoid basing decisions on rumors - Make information available to reduce uncertainty Non-goal: Determine SRP requirement now - Insufficient time for technical/legal analysis of new information by WG members Stanford Has filed for a patent on SRP No cost licenses are available - http://otl.stanford.edu/pdf/97006.pdf - Explicitly references RFC 2945 - Unidirectional license, not reciprocal Lucent Elizabeth Rodriguez, speaking as a Lucent employee: - Lucent is researching whether the EKE patents (US 5,241,599 and US 5,440,635) or any other Lucent patents are essential to SRP implementation. - If patent(s) is/are found that is/are determined to be necessary to SRP implementation, Lucent will license the Intellectual Property under normal Lucent licensing practices. Intellectual Property Rights notice is expected to be sent to the IETF in the near future. One More A patent that may be relevant - US 6,226,383 (2001): Cryptographic methods for remote authentication WG chairs take no position on relevance - The patent might be relevant, or it might not If more information becomes available, it will be posted to the IPS list Next Steps Clarification questions: Ok to ask here Technical questions/discussion: IPS mailing list NOTE: cryptographic and legal expertise are needed to understand these patents - Request (1): Please obtain expertise before posting - Request (2): Please wait for summary of this talk to be posted to list (will happen in next day or so) SRP requirements level: Feb. interim meeting From owner-ips@ece.cmu.edu Wed Dec 12 18:25:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20987 for ; Wed, 12 Dec 2001 18:25:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBCMLap21259 for ips-outgoing; Wed, 12 Dec 2001 17:21:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBCMLWZ21252 for ; Wed, 12 Dec 2001 17:21:32 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 49E3F32F7 for ; Wed, 12 Dec 2001 15:21:31 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id CA04412A for ; Wed, 12 Dec 2001 15:21:30 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Dec 2001 15:21:29 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 15:21:28 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF757@axcs13.cos.agilent.com> From: vince_cavanna@agilent.com To: ips@ece.cmu.edu Cc: vince_cavanna@agilent.com, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: effect of initializing CRC reg to 1's depends on implementation? Date: Wed, 12 Dec 2001 15:21:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1835B.51D2DA00" Sender: owner-ips@ece.cmu.edu 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_01C1835B.51D2DA00 Content-Type: text/plain; charset="ISO-8859-1" In working with Luben Tuikov to document the math behind the CRC I discovered something that surprised me. I intend to study this further but hope someone can save me work by pointing out that I am wrong (or right) and offering some proof. Consider two ways to implement the iSCSI CRC with a serial divider (see PDF file): 1. divide the message directly using a serial circuit that, when its stages are initialized to zeroes, simultaneously multiplies by x^32 and divides by G(x). 2. pre-multiply message by x^32 and then divide the results by G(x) using a serial circuit that, when its stages are initialized to zeroes performs a division by G(x). The two circuits, of course, produce the same results when they are initialized to 0's. In the approach in (1) initializing the register to 1's appears equivalent (produces the same quotient; same remainder) to initializing the register to 0's and complementing the most significant 32 bits of the message prior to processing. In the approach of (2) such an equivalence does not appear true! This means to me that it is meaningless to specify that the CRC must be initialized to 1's unless we refer to a specific implementation which we did not do in the iSCSI spec! What is troublesome is that I have seen claims in the literature (and in one textbook on data communications) that initializing the CRc to 1's is equivalent to complementing the most significant n bits of the dividend for both implementations. I have also seen the same claim with no reference to an implementation (e.g. iSCSI) which would imply that the implementation does not matter. The implementation that I have most often seen referred to is a parallel version of (1) wherein n message bits are processed at one time; fortunately, for such an implementatiaon, the claim appears to be correct. Thanks. <> Vince Cavanna Agilent TEchnologies ------_=_NextPart_000_01C1835B.51D2DA00 Content-Type: application/octet-stream; name="Scan_Fro.pdf" Content-Disposition: attachment; filename="Scan_Fro.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJSDi48/TCjEgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL01lZGlhQm94IFswIDAgNjEy IDc5Ml0NL0Nyb3BCb3ggWzAgMCA2MTIgNzkyXQ0vUGFyZW50IDIgMCBSDSAvUm90YXRlIDAgL1Jl c291cmNlcyA8PA0vUHJvY1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0NL1hPYmpl Y3QgPDwNL09iajMgMyAwIFIgICA+Pg0gPj4NL0NvbnRlbnRzIFsgNCAwIFIgIF0NPj4NZW5kb2Jq DTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmozIC9X aWR0aCAyNTUwIC9IZWlnaHQgMzMwMCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEg IHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4 RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/ luKKMs5Sv/6+8S1Frj5ZD1B7ruGvYVvlqGvbu6xblkq4cQ3JsakMEQRmJDtQFLZAIt1gM5Nsk7lu qAXTorrWWYCBSl8LZ3TtVBOpkqd2lZZMNKHLcsBpJRW6lcS8rqSYahFDpYRAjEugtP3UrgRkfQgk 6IP4R0SqOuNQQQkELCIaFj4IFBXKH1arSgnCENwgkWOFghCVKsyCldFdQGaEEw6IUNCKX9DWix4X hBI6kVLTSWnQQ0E8IEI/vaogQP24QKtJcr1eEQg5zlOU9AvS+13SYifVN0F6DI6Lpa1lDghCh6C6 K4jI4Zl52W76EJBdLtC+EJ2aojojt8ILvVYJ5miOCZkLBnUi6NrSS6S4KdoQTI4KHMhsDCmEhegk FevzvECEaDOwXUg+gQWSYL0l9fUELMltdkpDNNYEEuGjpJ9JaIKIKHP0mc61ogxwJQRAiKpJPX5Z AQiT4QpewiKOToEzjkIXILr5SomnevhYyDYOao6UWOVsrdrQsIiDRMmQSQ5Pca79eOiGpcbKRFOj eCKcb6hBCEyPhFDhBA9JIiiS/R3687hHqTcgvMEK+9g/WgqFCESnXrTW6BquVWylAwCCZpodBiIh sl6H3QQUFdlQtKoYXshgcperreSUFyOKO23pvrVBAlCw/VNBPQka59naq9cIijlDggsqwr711+oV Iixh/Vr4M7K35UJOg2avjggURHeGw07bRMeoQSC4JtA9LbCTwyDRsDB9Jp/0CIg4QilhhpKg+r+l O0Kudwa0So1ojoJcMMEyHkqO9s77W9PQQusPwXS5CjddVdWH4J0SokC5bgQZoTyKh6/CeVfp3CT2 4a3puyBA5xCr/UMPyJgitheW4qCg7tJphb9VyIDupBsmLCBf6osdqksSEIWlpLQb8Fq0+W5UGgiS I6I5prr+dcpPRG/BBqoJhEQYdQYbrCcqEw2lTMDdXZBqm9/wkw1I2lNTMZHQJ3YS5bhYYBBMSIMo g/8L+E10t09VTyOgqSXqDaqlfWG0tJUlVtwuUBq0xC5bkgcEL0CfRC2/1CaoLVdQmmMNNtW1pbVA m1WyUBl1a9JJA3QSImevXDaeiJVUIJrT010nwtKqba0giXq7DeiK6V9LIWGhQw+tJJ1Cq3INLvDC 4cJ2gh0C+tV1+Qj9V3C6WE6Ft0lVvSytAwgfartvSrCaX4NohO9YQQS/TC6C6CIo4nfqCIUemml0 m6tpJPT9ZNAoYNKsJJOqVtsF6VW0R6dKq2/VXpLiNZFHpNq6qjj+rJdO4SWr0sOwd9JIL8JuasuE rVbaCD6WEFa+iMeqr6Ix+lhLXC8UmMLI66CWt627IYGvhK/pEh1Yn1bhB90v00lf6deF6HpYQXSq 1SkI003hpLvnZPSfDIMJOkgq6VJux1QfbSXSpL7VLCIj9UlrSUJU7hU1XdBEdKhTVb66YZTvXCpL eEF3Wmt0EF60F/pYS9LeRB+lpdJohHXgusYKgrChvtJtEx2LD+ILC1QXb25Hjq3QS0tL/S0EvSqi zkUHpwgWieHVpBdNHVBI+k2qMwdhJfxWrYN+lglbgl94QJhkdLdQt+kv9YSfSrx1Q/HCrpk4ZxaT il0ruFhJhg3XCSCXYStg0m9i6rSTSS1+6tpLGtVoKQfTxC/LhlnEusKt+rCTZ0RhkCL0sEvS4e6h +6gqH6v6VJb12hpQ+FSxIbB9+wvr2nCCZCDlW974WCXhBcPTQTCSJsnW6CCfS0/7CXpe0wk68z69 eqhJr5UXZzCTEXV1pYILsJYYPboHSH4IKq19CtAqMdKvVUw0EoqyCgcKGLp0woWC5EDp8JMQtOIV kcM/ggtgyOiOknSBpZb6JNUktJfr+tBPpVV1R9aCGH1BLeCWagtWpSIIIMIjQnxC7CBZG0xEnrTo VoOIhP4V9qIWFyPfvVMNLTqQxp7DCYS0tlAYYTpKCCIQQjpaSYW2cDFArIZSEw3raCVdfqFFcetV VwlSBFDoNIFVMEPYSozAgWPSEQQXwXFWEmQzfsNqsOF+FPL+qphK3TVBhmE1pBBONC41BmAYzYbP MAhS8EnZY9kOKWE0QYjDvEILYQVOXWFH6/P1ZEdUrYmiZQ4ToER0MJ/DFYQJ4glBJawZMpsJQQQf BgiOlwYRHBDQKVwwwU3/wqx2yOgtBrgxEVCHVVpRTCaiQoF8eFnVBAgeoy6WyhwYSBkEKFGhId6/ TVfEGeCY0GFGO9wUhoHKkci7ghRJX4YLKARqoy6SsMJMmOUW+tK366DUUwg4aphC7CkMDghDPvzD mFv4Mocw0wgRlgIrGYVbCWO7C0nXa8WhEYQpMFiIjxWIpHAQy0RHNsGhQUMhnqTZLiawmNW6FrYW w2kQrcNY2iEX5ggoMhljhMMkBjwwSX47VUGCkbevxBA6cMVITltBket93BkLImE2GccFjwhOyODB RXj9CoaaoRXQIYNMKqrfEdcIFDIKFZAuoq1jtN5kIB5bigcNO0Pj0gogyCAfb0WP0oMkKQwl48Fj Qv+EFH+gt99EO+9XhAltdYS4/hBJfVEVCr637oJV/QVd9BLybAaXS7ST0gliNa5aFv+goXtrTG7w u0KpGRJ1rHapUqW31rS6/bS+t6S9/0vpe/ul7SsLSi2FxVrUMLwwrUf//ICDC8TNR////LLnyyDu JNw0Yy6IhEdJy0iUzMG0RrEgWOWO8goHEXRCjnMFwUOiyhSoIREoiODceJTn+/+/nHaxfgtb7OP4 /6/yCfyVCdtP8Nff0SgP6Qb/T+yGat906rlnM7bBHHheV9YxlkIRcUjg1FxkfI+XifIaNo2vQsJe JGbmZTiOIiJEgRJ4U5Wyq6FZEw0UQ2G/mHIYg9RxxEg0j0GEJHBMcqCrPhW6eW6zmQw1S1KvINA5 TlcUbJDedzPkY5Q4kUcREREREhRyY54IQqurCpCG3iIhnER0aIzRhE6KdHYPNikdGRNnXBCIiIiI iQ2Dmc4Nt8JNMaERERIMDkLhhyhyMrMOQg4iQbjleV54NqVBQZhyK5dkWCgZ/ESB4NQ5xzDkNA5V mHESHd2kDBNQ8REQZEoIRIKBxERIYcRHEREgeBu5ks45hzuQwORIJDjbSG2QVBzuYd5aCB4LTnHO OUOfxERIHgoHIMDljluQQcg0uCERERE4B4K7aSyGmMWinAzBWoREnReNwmSgQjgfMfIZiZIyLZHA zAuiS6wXaaygi9xJhG0XjNFwPBXMBkAykdBREl0RwII5NYjxERIjMIwjaJw0y4IQNGMuDYYRdEeI 6I6Loj5xkdkdlxCOBgxm0IiPSXERE1BliIiIiIiIiIkNCP9TLVH0NIP4j/9P6olAfrS/vQbrqla/ Vv/v10r70rf9J+qpaWumv6j16/tZZalqxx99f/68suv9IZXtf4avll1VD8a+UK1kCy4MniO8ItUy LyDaORcLHM5Djq7ZHQZsK8lBQ5blCSFbYiIiNIO7p1LM5G9qSHk3SehEYQd+U2GRHtyBY3K6yimK gYSdeIIGuvCf+4dKncswIgibh3S8E86IwExraDUXrpQ6Da1dPb1/tv9NN9LeRsyuWot1XB3X/2g9 167SmRZewwevj3e4X01rTfreFqdeEr18NKt7v95xwTnaVlzgl7t/YjnZIiODpJf3XLOp6hCzi//+ LhU9Un/6hPSq/v5Zhc8EQT/X9v+HwXep2ru+qO67lkSJPhBLWgT7pVCe1VwgQQS0oJ/+SMLybBcO mkfD2uC9LZ13TQfJsWiKqCYL0jsPCBNP6q6kGiPkcJwTSVIfzuYEJ6uEsGYbKodEpwz1JsLAxU49 K/BHHIOBotwdfpaDKuy4e0+CSS9J9Hbgw2ED1/ZEB1RoOPUoDLtBBQq0ulCBZXFY2jGE+lBK4MXE dQuybGAIqtb6CIUcFZhG2V6kXqI5QyPhdSDD4JUDBi2shodcEFBC8KlwkpBouCoQehFaGpqd0awz 66BrIkJEMeuEQXZ/ayx1qEQjoULJBBMIqAgTnfqnqSALxVomOG6SpLwQWl/UENF0CFIQhET+t0l9 bB36IVHSBdd/UMK74TusggbLDhv1hBHNquFpdekyCoPCIWQISCiLi9clIGOzML0rC9wX/rCJYiOR gQj4gihwkCI+kJOk9LIogQX2xC6HoETY0el/wYiGEKEIKISBDcJMiPBCEuG8Iodflm47+P2QilBA sqL/l6hIJrD0hX1C6+lIYLUkSoMFAQlmlYSa0hGlw+q9L6+2QzlGCJSGgIGRrI4iCVQ+Fp/iE9vC /XTIFxKEgqDKsF/CUiQtBMjc9F2Fq9Jb9eyGWBUEFCgoVVhDpQRHQ2pjcE6vyHNlhr94YeEjVKiE HdVhOsJCPSUV+0DVtL6O0Bs6VEIORR0ggbCIOO9aXQXHSCfw0/p87EB7SthBQ0MEDqwiOqwsNsJb Trd7/9TtWLQQWkOloh4EIKKhJEY+QfYJXS2Q4QPp6nTwkuG/UILhBYJAgXSSCtMgRsmUHCC+Ek3s tzN3TrhXwfhKmuXDOlYzjwoS7uK6DCDvwrJzKHcJb1+1CSULCrBB6SBJLg7gn4VB+kj1ZEbg+4X3 4QVJaaSGKBQgqYcG0rQMocFUPluUajhnbpKqlf+lC3ao9qCQJUGDbBLcQwWndBwnH7Cf1pBJJVZC jEE8oDScigMBsEtoaD9tBfuiEH+u0v844IjrCBMER8EFg8Qsjoe6tpL9ggvdaUFpXERYhREhoHCa B0rV/aSWsMJdWUrQXgunsscKCSEHDC6+w1X2GCT6wwnpJa2EOCoHYVYLeGktUxC8Ow0vBcEnIGDs JhCGcc21rlXglsN0lrCTtWDBSMuwRBd8cME5AhuS8ECid/ikqphMO2wYMui7I4I6xCg5BgfZGBTg oYK6EGginWw510hwwqS4iIUbBQTuwZODkdWDKNnpiPDtIMzCA0wX4aahW6hiCFsaoah4oTtQFe3B hcFULph3+2hGs7oFDsLDVMg3HCeu8NgnbHDJp0DBbKHCElyutoOEvio4sh4/9Ex8ImxgMusXyExd 16QYYYImyQNT2sT1a/WxOwXPJAyky3UluOwyXCf0g52lBnRBV0BWg+uGEv4SbRBqwpc4jFhDhhmA b/0g2dqiRDWXQRpGOxIED+ulZ2LtUQ2xyhyl4k6JcMsuehX9IOgwRT2IkLZ5KsQyGgcLw7/S3EWK sjoigcawyDccL+guGGQQgOhFvJYC4/pJ3hmoGuF49VSphhsiMjsjxHDP/vsJC7DERPAx6/0FZrCA 3/v0m2ww/8dKG2yVAhIX78ILBsloUf36Tbgw38eEru16qk5dBwYa/dBWL25Ci+kkHsG8JfuvDegv 8K2w3oL9NPvoKu47bela8mwsZHRsFDfqRvr+TYbBtI63baVJa5NhGbAnI4pfBFP9VXupNkZHA8FT 1CSXVwQ/Ck7/6cg2EfIzLo2KRx+kl/RDMEnebBTNoqAQ3F0YzwIRxFtfXohnU/DQkHcRERHaCrNh COdWpHtOQIi7Ebf8SGGgD1ZWwSpVFIZAZQ+1WpDTaC+2J2ULyFYyGeZUHHPZTnsscbaXyBuOU0Gv j6cjgxaQaRyvKIIx/VnBeJEZVQq+r06EraI6MIxiIkSEYathB9rW1e0xERlj2KjzQGZte1Tv7+Rg MsVfVvSetSJg0v19qErsLFr/uOHhOH7X0vLwrSP/p7SHquqXdcN/Vd7wq6j3S2QpuCLSdEx3vCap JKretv0tIN/K/ho0kurF6pKvba0/SbSfr6SpPluSq6SQSaoPrRcfQWvggQ6sjxlUj8eyOiPEP6ST 60FSQhkci8YyPmES6JKZHRcM5HBmLjKEuEqSFR1EREWXBcSPEdEdEql0IiRjlLwlCCunrEhx2EUO OQg5WEQcm7BCJA4HEhJLektUrow4iIiIiIgwloJ1fxILcOYoK4iQdyhyKOXtOazxUJdL0Q2Dn87k DwbMKHIZg5xzDluRuVYkM8Hc/CIiJCufyUFDkoIYcococ5BMcR0Ev7zQhEjERwOCOBAiIiIkuEI4 ZIF8JbT1boT2VYMEePoTWjYZMoILq+hQiIiDSQSx7GDIZAMo6wgrrCK5KCkdQPDVI6D0Eqsm4xaL cJEcysRHBcp8jgwR0OmECv7QiIiI0EjUGPHSSQIF9tQkfDRd2qQp+VyERxqEQ0lz3j0gmRFl9JBS DBX6yGWuIH7kM66R/ZBFxJFuIXaIjK4nWPgggQlcCwqJDlDk4IKVyOuIjCDCEToj2bGYxHhxERHr f10/jyziSLIBriSyBMtArcIMm5QJd1BFDvqmhkQiXSfLOJrW00HxwSvhGER16JukDQX10hEm4KvQ QQXybkvX0kl8ydXj2gRB4HenVXYJAn1XTuIIJEV93rXJudQqpAiOqWr2IQJxxqk0ugltevlmaOFv f9sKgvo7F9KER87Jx5EdGP61+diaREroQZHkRR8WvJsDBcLC9QQ6CEM7Qgggtkcu3DUEvztIBGW5 aGwEEIaX615bi16VAuRTNoEQ0PRFcRFdbotxISvVEGB5myP4UECUyBUdoDNBNmctyk87Wa+kCaX4 JDEYIY5JUagLkdozluKEbOy0V9hlj2ECKHD/0ChlEbRHwibhEdWdBwYQQoRKdKEFmQqPiZmwkOvw RDjnHBMQbhMRI0jp6DVhIiDxVFoYQP0KhdaSEYhBMIXYTtEIOYc49AgUdRT6haS1hUgRGgy9NkSb G4rN5g6JEaknXUqEvTggRFgy4SmoZA/VBjVkdYTsiNckCJ3oIhjoV/VBMLChEEBkJuKa2hBkdRFw ZSL0H/SUQl+ggYKlCDBEx+FTqIeCa1nwYU3EdV0C6hfzQdytAjrIg3HM4QTBFjjdZId8jHIMF3Bp +p2BovyP2hJNzWtBL69Yj2iEEnFKiHtQgfiHYQelpnasEQQdO6UEklukw7QSaLHKFaVQnhEdPhh5 w4dkPuwiCDndhENANRe8mwo4S6ryHKaWmQdpWlca7DiCh99QhwQNJa4Wgtfog3GvUJVkUcodKgtQ uDJjtENl0S447pOtJsIikQt6LcWyNaSpJKl7IZROkqSdQUQohJUFxPhioKhvtWIToIpzpGH9MLrS Wvl0w/XCVUgRHXxSUod0CpMPBcMK4WqUli/r0EqXxYfS5rCpWo0p9JKJ4SHSV4TwkoIJJKoaVbSp arS9tvCSQLxVKXYpOHiqDaqu0kqLHinXsJbWkq+dgwUUoK2ZhogoWg3dpLbwXS4ShJWPtpLQ1hez tJEcH3CUdXVtK6XuFqFaSSVJe0sMIJUqdEDQnhNQSaluU5lDrQLVkO/Cx7XQSCC5b+2EqFLTqxlP TjrEfhQs7RpLSgqIZx2qVJAoJJb8MNLrRFf4h+pBRG20oTXatS7ufDOgnVpcEkF/9BJILS699kCP w2HoKFWEqcImOghsJB1ThIFCXhrhtXSUEvdaZDOPRBxwSsMl96ceiMCYoU1h1aWkgSSw1q0h9Jr1 4XjyC+HsFVwoXYUGlSYK1Hswi4Neo9sJJYQXqdowtwoMeLEW6Hhk4YrYSTFJREguOFv24VEbsJWe t8p8JUwu+92Qg6WEwmCD8JpJbtpJFJBFD9Lr4ZIBhWC6cO4xCqpDQnTXBIL6sVmjQimwlrtsj4t1 jVMF8p1UKCggqSIMICX9ZdEcJ6C1+wRQ4hfsodBxGQIHC1DKHCEMEsgg6YKvtRGFwS0kuIljgusZ McOwih0I0IYLQUkOUOEKC37pwohRtOxTVYsqChw8QYIj9CGsRGqT90tU0kd1sjhxaxFkIGmUOU4Q sJqhVh+9qnGkVhTlbW3BgoiIjXD6aC2ChYiOGQYHjUMu6p0tY1HUQ9om4cFbCqwZh1XaUNwS0wko oQwukG0RQlhDbsL0w2FQ4MEGTb9hJsmyRFzKMuiOjUgwvDO6HdNjiIhBCfyOGYLWI8JNqVCMAq01 0mGpsD2wl4SDBnYEokFNyN7C+k9sg2jcfhW02QwtL9BqyJKT3Fek3DJMWv8JrCIELnqTdUVdBDog YXu4/phyDSOeSVX48SCSC/+UPQP/7f9e279f8l4eSsLt8W7I6ZI7wg8s9NK7bFhGHlOiOiOD/3/Y TYicCdb9SbLBEcMozPxYdokDwyPcmxSjgLKbYb/Y7RNvzbM0byO0IvDdZ8tqmTY1AguB4aTbeQ5h rad47D8MINKg/V7vBFjinQXRA8OO217CQa/yBxxRMi3burCsK38g2pZCv120EGHjdkrO5D7V9vbQ SdcRM1vq2kt1G7bOqKgEI++lft/I4dEKOW4kLBrO5VZygqu2kiUfW8REREZHiOGWRwzCOCYYr+93 ETDiI6S84yOt/G/0hJpkT3b30k5DCZA/pECR7x6IGBzJmvu2QfQqDuYc8FVFQUOVhQ5nINY9OuLI 4KC77uybxERERERKtFSReI5kc+uIkRMAlqtOdhoREdBtcHd33HTDBZDArq/jybsbNQKV069XyXDW q6f0+Ol1pbfdV3Tf/S1fvr6Tf+lX/aS06Tde9ev9UurV7XXS+gdJJdQvBrpai8EGTdWBGlr0ybkA 0YStK6ZNgoyOy4yOGqkl1yvMGgmwkyOB4bqlVfJtQDwzaCVtfK4IZjMRpF8uyPmYLl0bjGR0bA8G 5gUJBLHJvV0GZCSI5EcQjowGCEDIBTSoEn06IKrlywziIiQUOQyAanJDlASChL4eJF4gw5Q5Y5IQ VZ1UiDiJDIBgcykkEEEuniIizCPAYBCQyAONkJQS8IOyNxEg1uXqQPBsGEoLHKcjcgkFUKHIfZhU EF6dqIkNXjcWMIMSSwgkEE/JwHdENEFjkMgFC61SNQZ+1h+EJnmA2GIjgeGsYQSokA3XoMGWkNvF CT4kYiNhtDCoIJ9IkDQZdcRBkFDkm9SBIzAvlYDRhs3oehFI2ggyOBjJUGlUHp6Q0ILIECqrFw7V ILNYFFBu7TSINK5xIa45I3GQyh0TZRyxyY4cNQUhlL6kFQcqCnM5S6Cl09/BiDlcYKTcTUg3UipC ZBrBouhoHMljFQ5kWd2fQhhcCIaHKNzO90G6lepBFDxDMzpT/BlDsbGR0LtePDjQrv/p+3luJLfh JTIK0Hvf9P/+nf9eq/nYrdoLDKbk+7giPql9dPvotxtWP9fQSvdq/6v9/6f/yMXvV9+x2rW+unp9 GQju+3/6h/11mRHpWdlOv+W/0/tMN/6da9bI0ocP99/9NhSNL3//35LR6ZEI2NB3fVf39NhpAhD3 XT3/baqGwSTu33v+/SbYSW4f8hSI7rO9ApHWtrhO0CkSdFj2/uCENNwhD/dJMjW2CokRVw/pQih3 2EyOFf12wiNQE3u3e7CG+ELMprNr7CcMJ/h//fUij0iOiOCjUiSCInbY/W9yLslWaruFvQIoDOU6 JggQiD9NW0DhU3SV5L5PhELZwNheq6cES6I4iYQMIOyR8QnRIciGQSfpg3oNC70/r0EhfTXykVJO Eg3Vb1pmBVBbX7df6pp+n10w2F6pWd2GnfgvLWFE6X1WneqfCsKDdVpBWyZBtJ+FNXUaIECjpL1Q LbXV0m01WKsrIKy3qSB9Ov/RETkGCwgo46fppVoJwv1YLIVyhyh9+vLWSWkSm+vhBBsqDjlTQ+Fv 9wg/SaQghF21C32SETo2ERNAgRH2Na0lER/C9aTYJ9dyCq626ChPoHqwRSGCCjr9KEnT69aTohMa mxVhdNPcVXkMDn4pxhhFWMEIxXS1CkV7WwnS9cK4hppnIxGyDaVbqE9MRHBAhJuVdpL6UjY68EQ7 +lSwobjkFxxEPkNdwqpvT/BIocofgij/9EslOjgPvglf+qC+K5DMcpOtuQwOU9e1SEQQjX6VEMUk YIVrhJrpYQUJPSQbkHPH7xpPhrQXpaUIYgu8jhnVUq1QIG+EsF+3WEQ8eWsKsjhp8Fr/oF8QTfhJ UgQV0iGW5gPI66VtoER0oSfiGQy7SyQ4JLCrqiBA0+t66IYJhtqSsiDmHCHHq3odBdy1gsNg7jem 6VSEHOKp4T+k4ShXCoREP+9R9S1iREci80kukkuiMcIdUF3SQUJU7OW/VtukFfFx2grYTulYQ+wv hbFIKxSS99JJvTV2FwiK/9L4K/0FCfX4MjhGoXvyQWnaWYWtL8EljTKHChB2tvY6oN7ThnkE7W0r XrtaYJ/SSFqq/qk9eEKsEUORI2CsV9wyOtofqIJxr3qE33tGdSFgw4p2GYB96piQiChkV4TCST92 km/xEJiPYhaS8Q/xDBCvtC1/agkHW12Qaf2zurI+lq1BP9oGUOg9UKVlDI42FXiKXQMoc4rhkc/w QsFhgvYcUyChQvCXiLTEhHNIR7Kc4EWOFChVTFBoVbCXoJj+IkSEI+2GRiKwiDB+66Fg/sqThNQi BdZblGCT8hnHBexEaHuKTsN+mCSsEumF8GiLrYZbmATwyMcF7LcJG0Owcm/aEbTiKtiihwVDTLM4 yYlaDiN8s43kYDWaA+v9M8B76euhbq1+vBhe5Bscg1m9dIV7ISChyRgocg7r/wQiIta10F9fryBJ V7qo1X90l1v/v9Im639ryb0WVyzV17rfpDX9u6r37fhSbmWF/TeIS6pZBBG7cm4EFv+ED2+or2mr eGv68aCr6uzDwaf8knsY19JXr/kSAgjitv9Io3IQG3r5G+gg7NAKHHWZpbC1dfQYTj0+n2lV767S fRBqHIKDYQv2lXIKEyDXbp+RBySZAn21DIr8GEP7SH/4bS8P/SSsdbaXlmK1vY+hrsLv7///VtL/ unvSbadb6avp/U7Et1f46I3fXWmHV90mh/1fybpLVv4J0k39dW/YTum/XpN/vV/+gr+F6f691/VJ rul4/d0uqXX//pYa+ko/d39fr1OL1xfpStgx3zWiTBp/iZozBsqlRLoIJrsJMjgeL6LewPBi9AiB 4QcpMpW0iBYmiFFkFccpNA+QzwbCk0UtszMJnaZRj6v9S2o1/6Tvqu9/+k8uqpCPveV3X07oseut 7qWuJ668tYoMIOtL3f3dwmt9Q3eEpQ/trhwQgi65Nxv78EUPTunZqSRDWkkhke0ocnGiLUGQtfZH AjabaIcGEEQQpa5kqIIQRhFIdVTCahNMlxdTIXRHZdBNiwle3tL7rIxRCBOIkMyooeS662tWFQb1 mR0XwihxEicSHDLpCxI+Rxeraa2ZsjxHpQ7tVUEIiQgdhmAzkYkOqsXVBCOJUUGShAihx2ZGuCIO OVazwZy4OCFnU/yE+kuC8scp3xWRs0MRcoDMCKH3pJoOsg46CaVUOROdIhEsIusMjHOOQowa/QTa wgnWl4QnHXpkw0hplHQcL0mnSRId16agjj3STUqBIViCRvBEY5Nyn3MiP90oQZQZFtWmmoQL6tUw n0GFd3Sd1SrXGWDHGxBVwiOgoUiih2CKHSoER0hC4t1fVaVEIcJPTVMUQLiKEILCExTVkx/W+upI eiDqyhxBHJpJDWD0iOgVIEdxYQ+1pesIIUzDhRItBD5DA7kWIZQ7wgo1QQKkvST9dXiiE1Rx2oVo IJxDIZRGPiP/pL6QapiFF01cIHJoGzSQ6/MPCu/wVEQGcwiOyPGxFgnUKGvCr69JpO6HOpEcGm3C WgmzuwfUxhFO3vSWq68QoTpQlqgb00wlCr9oLbI6J51bRTkG4atfU7IE0Pr16XFlwlhTpMaQfqkm 330RGdbp9wk8dqZoEU4RHTCQQ2gtQUPogw5HAlD63XaSVeYkIxgq6WkyS78hxwToJkHjeviqasIR QZDA4KQXKUXS+CdhXoUIIMpzOCu/XTTTIV0DKctwhgg/C8ERR+FWCDCEReyFf7YQwUQQwQoIRpJC NIIoddCoYNf0ggyY6BkCB0LBVUhsHwycE2Uq00+V1a7oRhJTbolhPG0O/UX0mgwhOq1atEY4TUIj pvuNJNM44XXC2IQqLT1jDJERGqhOgoZUS/EUFwv/9ikGcc9VrH6ViNhhXC5Zk0XRVhJd1NaNxtJM ijlbVlTY8s4rFOiOBI+VwRYhAi+kCKdhnQVswFezwHrUaERFxGqqXBmI5LbC/sSDS5Av3ocySL6I PZQ5XlUO5RyhyhyiG9af5FHBDkeEIEIl7xOZHUFf3VqEIiIiIivfa7r9WEtf6eK7+tNXX9U6Vf29 f/YV9/pgiP/+sRrax/q+rVtfT+l7kTr/69V7+/v3S1XP7X/010rvohA/+7votxZdfvSEugX6Uw4d +1+0zA63/q3eW4uF7gih4cN1VXTCGvtLXOQRN/eLCvppU65Z1L5NxvqwQXYLj79eIXRQ8J7aC2u0 u6T10121hAwX0+KFlDrLh/7CEdEC8GTIhwlvxIo5aZP/xEhUzHpPJjkCRMGfZXS1poSBWmFhVH5H Yd1daNQK1dYeVYad6W3HrSJRW79fVL4fetQ3/9+vpf69h/9JvvXX/1f6X198JP7SBFRxXWKginv2 dwraX4+/HDCy2CRfHHv9X7d//X0l32YClrX64sflSDWJuZomwKt5LopwV0yUIeEQXcUTcn4+JBmN yhploheja7T0yDK5bnc7kx4kdHFSr0RRzuQyxzgUR8tzGTF9pxGlxte0PpoHkJV30TH2kvF/7PKr 46TwxXvX9fLMBEtXSudjdx96rC/S2U3H6ddcVwpAz/WRtVaSftdPqFeuvbtU7ZaxWuly3S/4SCr6 6r6tctWMfSrXhN8E+le2tfpuqQ1+9oF9U18H6+k16Q9fSX6phbiF/fCISOpkWEUo79K6C+gTBEPs EX10FVIIKEyOklkNG8wkl5Tg4UIQ7K7rBA1thBLoEnfeS4NP67BBHeupVpM8yC7IEDkWRWsE/pVQ SIhLrYJ2SgGs7r/CINDgiPkqFS6CWwVMqIE5HCtEJxxxqCa9SBeo4p/VUFvVBA0sITgJ+thENhdh PJeOxyuklYRBIS2EkhpBZCfSRq761pV6S4QWnQJV1XYYWEyI/kXuE1ULWFm6IWuEquEglwSwmnVA yj8g8LppekLkEPXCCS1QXRjIfWFTvGrVEPD0gvewk6rC30lxUgw5HRH9QpUdL4Qr1NY0uKglhdBf UF5QgRUZPZTXu+6YL0gTW6YIhiuugqXQVY6fqqW+m11QTS9ggtUqX1VResKFT11QWqSaXUEtER/C r0FbpXohHrVdNQl6tBVMitIhMguEl69Kkl60sIiDv/zCqtIKgqiiR4IgxHS9JWvrT9BfSS9qKS1/ dKggXhL/vpardKgk9X8iapdJYL1wvSr6XXVdCtL6+qS+l9aBegur9aql4SpKv9Kl1wuklIuuK1// Wumgl+lVUkqyY+vSkI0FwvvI1vSXWtKgq0tUtLVKU4S2+k4XWeXB5SFB/rXWvr+klTSiPSpVrrC2 w8EtdA1WvQS2F69LX7ilwutdvBV3IiI6ta6ivLo4F/SCX19JRuFhLYeEtbOgSGlkQtKFxFelr19a WqitvBJqkQo4QbC0IXqj21+qBfZEt+qtwVU3YSrYphglharCX9UEq2wt6S9gqpuz4EX8VVcER0qT S96XkegwgvpBcaaDxSVUGtlD/GKa9rS0NkGB03bSQXQmkG4XsKUOh2klhQXhrQXsSD6ekukyVLCa WCaGtrD+KFVUL5lphVtgmKhbTTjUKEDBV01sFdelcXgtQyIOCIkIsEkO0gQ0DIEKN8JS39MKsgaE M0hRD4eCYQYLpCEkF4YTCHEfUYJoemgh8MIMocm3E8Lxe6XgwQikL96hNY9JXeq8NP1EaoVrdGVe 1S8RFf5ka9IpnVEYiuMWPLOCopcWhaQiPyziYZpFAQshIhroY//SX/hsMsYUOQ1xyY6qCKfQnQHI +O+PEaG3rrv9f+vV+/0vt/WyUL+mla1P979L/3/Va///+vS3rP319M1arf8L9X8L11bbBBX9/X1r 2gv/ugt/+v+ttKv3xCf+TcGuh8s1K9DtB9/75aA8f0PVdcb99f9Kg/un/kna/Vuv0w7rpN9/bctR WvpN1/UOmWjpf03pj/fvrXw6WrXDLQUsjrvjk3CbDLQJgnWvbLQBBn/+RSYa/F1waBPlnn16YaXj /iTcnr71UV2/2yGLnR9dbREDgg9eqk3OyPwS9P0YfLHsWdrPBa/tLSwbuFra+r2wdRBJfkdQaT+t hb7iFXr6QU16pElDOlrVrQ/sjaOBpE35Jek+CuRNeI9fvyuJKnC/irSSJsYRK1aQpJBP0Gn1EacI LJMP5A8ZuTxZXJLpcl0C8MgtQC0l9OjWGi5Zy1kcNQjkPWqw1IYKOIicSdN9Q8+GVUs6UjRG0R0b RohcIJ6+jYZRHXLOpoRERHXVbQgh5XDxwgv2V2uOEFriTlBdwXS3RBQbV+ElKAh3irMhtKGQYNi9 Fma+CUWSvQaWgdQW08IgjyuCq0wmU6Xh1OOSNgJJOwQSnVHYriCKdPw+87wUR64QTppmQ4Nbau0d iqasrSBd+gklzslSWmIUbTtLhWIWq3BdkYqWHEFa0FpkIN+QLksLDWjITEKR/SBAtSnBwpFLRBgz cjfaRJrbBFO6qkCCtI6hoDkZhPZD7ignYevKHYQtheibhQEYUJ9hMgazVdd1eLYWCI68Im5YDelX 01M/T119ttBMIfQS0k9Qna9dcNUjo0mwghtVIEPVV+1T/XCDS07JdIodoFWoXShExyOfwut/Sp+r nUOVeNhLjBXoij0oQf0QsPT/SSkoB0oQdAg9sECqGRo6XCUGtJL81rq/CT6raauEFx9KqofQTeqe vStMGtJ4TBWIXLM1Z2VLiuq+F6QT910g9a4VWuE/pRXVJ0P69LvM9I4CF3p1W1Hrp4r2u9VSB9dB XqrWk3qlWr9fpKE9BLCXog/FD0ES5V1uF7dVVe30rqF0ndBC6hB/90qqtfrwkqcaFegQdIFBdV18 io/r6VOCtQTxV0FvoLp+kuRB1gq+lQVKrhcIEwiKO6mRhMFj5Luq6SQMuiOH+lVarrUoBQEg3vFP wt1pbEfelQSaguglng0GCV+L+dRKpPrfVKwkGFW0rRgFDoK/8MFf66VuKhkcGBa4SoSGc9Jv9xC0 lpWnuoggwXhKtJ/21TVK0GC6poelgtJul3RJfrrBhesFhFDoEFCdK7u2GFXoLEX4ULQpJkMCGEE/ EHkMb/Cr3hMInWzjEyEUabqWYnYlOLjqMUGT3roEpIcLSb4TGmqSFUygFxHSfptD/IQcKglcOFGn pitJ4X/YVJPpL1hKk3utrYIlStJ+klpBoevVX0GRdukF9BVqOv0F/VVuFuqSC/Bel76GtKkhthrS T6Q4Wq+ktbwkgvWF2vQSx+kl7OxtBJbeEISVeF9wwX8UtYX5XS1WyzLyOiODBHiyesUuWdUR8Ncp F6XLOWgVkgL4SuhQ11xSuiDSOW4IjpKsgxBQ5Q0Q0DoVuzEhEcrqC3iP/wl/S64QX6S/oLXpfsGC 9Y7/WVt/yWQIPt9hf6V9fXv7///7KivvFJ6XqtvJFaT1+gl/s1a+WcaV/C/f+wveP9Lbr+rw/7YQ Vg//VQ3f20Fh67erv/YhUv96X/Qr16XvtBK7+F66Dr/wstJLX0w1j+THDS/rY1S8N++E3f02/9N9 9W/9P19+9bf1V6r093Xf/jRaNV/sfVP9pb45aC366Z2tr1k3F1pmTqFX7UhaT7/4pdcVTIysrjgv 6yyJa+6QZTrXoNdOwUSXX6TtYaqJBb9prsPRE9J70DBFDvroIj0kXgn3JkGx5nWVC0EkCp6si4Kl LqPCCQKn4h/fhIJAt7gpN/X0jCaRN3yyDaaS/XSEECQTfLcbxgq160kkm+2DKHIMo5BfPv+kEQil fiJ4MEcIKk3Ayp670kFTfEcINbXVcIJL6RN1AL6/6SCpv4T/6DpIIW9BoIw+ulULoJ9ihIQevu7S SWW62uiIOVP1aS+k2OkEOUi9etJK6YQShP2vfSe1BJN19a4S+q+tqsJJSE+oQQSBfXKytnkFaTb+ G5x5DlSjQZV+qRCNBJ/Sxwn660d0S5IyODpX3aBtV9fsijhvnwb02RBt8JevSRrinWqYQYLms8E0 nC9JLVdV4d1QJhVBB4Xhgk9/SX0UP/UFTC4J6pOEvmRlJBaC6R2YRHBdb8E1SdMjKpAjFthBfC1q vndYZv+U4aFSdOyrNZF1VNhBXTCWqped0DV3woQSoJOwq40ul6MiQXWl9L+loJaquqthBPwgkjok lXUL6VBJUFpqv0xC7ggkhC0EooIgXHL5fqlVOiCPDVrq0vCWqSQI49EM7x+1pEPaWFoiUeFdagn4 IEoKkiIOiTGRxUQXiKX1oJUguk9IkPvVV4IitTRKULSwS5ESP1VAlQVKk/v1QT6mQoEwkMUkF0Ek +rwkioSSTpVhLv0/mQ0EwiCPqgiY7qF+klSmuBCCqKvS4fp/RNqJEktaHtHRAvq6hUIVE6prS20k giLb+OCWZ8KkKSH7SWgsLGlsJqw/CTfyuSLBBa1og70gTTcL0CsJKlwk8g56pP1K4KCRC4VJIhOu iI6fS0Nr1s+DqxeEmHw4IOFQwsjnCVTUkFrFXgycOqSoJb6CbWEUPkWwcLONgohlyCQTcQqtLUgQ 8fpYhbdBJusVYMhTBNpKAsIoeMkPSYQXBK4bW1/STCcNaBN/gz4gVqIqmJ3DwRBB9AihwvhSLRbl Od0lCzspBcj+kw/YYYYYSQVRCFirhhCnqqhdkMVA8JMLEdIPVpsjoNgrChQqeQkLL+08iosGCTB0 rXoLXgxDDISYTBbCrYhX7CaYSxTbQSkUcEuk/TYigylYQwnqKEcXrFKUPGug1VphDTC4K4W1ZSkE hDBdoIfgwqrYKnWnVIfpLgwTQZY5VSax2E+CVuPwYLERYINbkd+gqtLlvgZxMhTI8cSTbI/HYJK6 7Bl2xEWrFqGCWnVVDY2yQ5x8QttLStuDCiW6a2/034RxzjiVtwVQaX3xiJW/SsgRuiqEmHjW/+3B k95aS/0OwkrpNtJAwl+5NxCLIlIcUv4iqXsun0uw87GLUmxotXjQQQ7g+ku2RwewS7FKguGuC4ao eGC9CTcQl6ZMgerdkgNhIRcMr+bA8syMKpb2okGe6j2Ubi4LrYyDORfyCg5DKqS6kHJnEveQmx30 2CpLluYTC+5biMe/lvdf909dKqdv/t8kj6vr19bv9bXakW10iyAq3/n1WWmDLH7umvyED+7+1wyG LRZQa/+vhilr//bKHT1btfSoWUPHfuaZr9bNpxqH9VTSTi1LTFkRxdV7a6FuNf3VL+Zn+3+wlpY3 /0l1gl66/3bS20FyGB122K9Kihj0mthhV/1xC/uW5ATphfUGY3J2ENcNjtfUt0X/W8L9/T/Tff9d P+9IlGupXEhLTVv+uCKdJNjXK5gHxdLXhArtK+4QXW98Jegm6qECtQrfdEWFvX9DUjehT94kMsch sNgXa1Bi6eoRQ8rqwPDVr4uVxUDwMJPwih0W+oFyPEgv8XIxNU+WlT61Q69+u/SWv7Gu//7Sqibh SLcTXp/wn1XOxxcmRp5NwNX8paBcJrle0NdSsAQKle5JR/kEDMCBAnXd3IqGqoXcrqZ3SykBWJuC aCO3QVBcOFfIwDgECzaJUi6UUfvp3WjMD8RERoUq4dccm5WkFr19EFIco9BkeyaMv/wr8g2BJNwP I8l0EU4fWV9dr7INylE3UKMEUZxHb1ZTIp+yDjlMhyoK/6WdrOo/JuWIREf8LXoSyVr+1+o/0mu6 /17TCLT9/2lnYxVFPvKdVWpkB/LMT6e+N1SYW6d//65Q7Bf/VUloYUK/f/+ybrIPf9el1rv/69Iw /CZdf6pWlDuSpEfyvgaP+vdfHlccMqtKtLpRrZklA1rv/WmW7VoEECHr66prJ12Cg+dwP+obhC/6 V4JX/WibQ/8Ihp05MQJ1d1VhXj8gQOeCMPkuFC/rx78MiafNQLhZAjdMg8iPS7sarVIiQZmiBiT/ uRC8l+7wsIgYaeiDRsz3LM1atplH4T+gqIcbD0+oVbTfwm/aByKKdI7USXCZblSXTHwXyIWiC94V ZQRHWg+4US6C6a6+ahkDLRDjgvZAwOSHBZ8MQRHSfdRVtfCfgoIPSF6ZDPCDBAkOgYMnxKCtgbut LrWFI3+CYIPglhkrRwYiOg8R66S6+ClIHIuE9V67F9BkJYT7wu0/CkIDAT9U1Stv01wvXd1rRDDw mE/CkORCj+qYP0/REHf2ly6RCD1cILCYT8FiCBD62/v0E/xXtJs32hBUFC6SILvj/h+iIgof8L+W oDSdsU91VqQ2E/RBOv1wfEEINrpP1FEIP6sHqk7XiFbT2oYfQf0v6W6V8K+wiDDvr/wyDA2vSpL+ lxTdQtK0QengiOuF+w7r1q+6XX1pMQV+NJEtW6hv+i61f4S6b4TUiuQcYvq4Ie1DfVa9f0urSq6G F8LkrJ7v4PWv5Gpf5ZgeR9Jsq079L19aishYsO/x7rroaCxpja6r6WtjJfD9KuG176a/98F8L3c+ kiXH/4br+qS07Va99d4S36S6Gv3oLKE+1cOva/cFX3WDyYX+klcJ7jsHS9d7Hf0lqJEtNe6SEb1s giRU77B7IMDhYXcz1p6pf6e9SGgcpP8eQYgyXDCewXeGEqUeumkrXsQ0la2LwynLmpCD3GGlXr+k 99p/23EaiuN0sF/StNYeqD/VV1XZwO5BV4StENNbVY7u7W0H4qx5XNOChDjgyKOE92whaDW0O0ug QZ1RdiiBEFOVxGOdcCYiL4aGQ0CumvIqLwnGyHTxeqBlWmQwOnYTtOVYZ9ptyKDRA17iJlNCIYQ1 lOi4N/DthWEHsFiLBZQGb7scJuLwtEDGxo8hWrvUr4hBhZwMuvb6YjELt/hZDN2V6/hQiGVtZKkY fcsgNGbcJHYHhEFDcnvlkrDOoSUIhoHBahNk3qBrNM0BocEFCLJUgiBDcUTJTUpNyAPDPwhFEMNy ilacIgeGB1wjJJzDlXvBPhAq2EIj1F1VXhPfdELZUEDdDaDMuYKZiz7DWEJV5HRtkcOSOhEyFUPT h9CIiPeVC7IY5TD8m9qsKZWuGNfyKrx+7/hb/hpLxPodsbg1/Y9IGn8SOizma7lvqJ9/7EehIoh/ 6T68euSUEybgt709fWStrwvun0P9IIhx9/6kWuTdZXzsVzIGPphH/Um6f/r+niIWooP7Xe/kUu0/ 4fT2PHnZaof7+hfIcEE21lrj+2Hdhdrqt9pbWPDIEG6jhBbeWsSLyBg3rtrrY9B9pX129sIL+4fi lvqGtpr7QadhXrTkQ3MXarLMFUTf1cG/F8Rq+nf7tayb1rt6DYX3b5GO2nGrek2Pq9IPzIlW+kw6 pO2+/G70m06Rb8GjSvJulLlczYW0E3p7Q134PXpPr2TdUrfBFnMdcoC9eTcWVFesi3Brvvr692nX fhP+2vf+/TVv+rfTVfmRUv+/jrtivt/YJVNFv+u8fHMgLvbnYmpQ+39GH6bZks+tYvv0vN6eu0W4 /F9rqv9v/td+u9r/aVU7XQWtblT79acof//q4VV2uNP6W47/4Xp/pam13f430gRT9dxTfX+3+sLX dJ+yuaIqq/+djhNc2pMeHta8f1FFZRHDQL4+PqVhHZSs6oew1yFg0elWQ14jiW4RUUOoM3rkURHB t/8T6Lr8bYYispAJP1xEoX9Q1IeDj1uvH8twP4NRG3W/rjwZCG4ggeMcq0XVf/rDmtFcyUgtOfRQ 7OBgjryp+dmF1luWriMgqQcDjEeleE/y3KENOS47kKOdVk3MBp/pw18Ssr4iIk3CBrnUaqvD/9ZZ BsFRWP8+v1u5ZCYMoJkbS+2OuPaCqEztQDlOumEfXX8EQ2vppndYZ1XaHztQ8qa2MhqhwqnYYKF8 g8hSGsqhEmEohS/IZbglRCXULdZ0SIg5hQjU6kKChdghK4WryGiicJNqCKHS5qREg4gjDiwn0UME wqiOpEEespwXQ801UpAIYtMpEc6IusEGFXo49lGKDS1C61ZBg3TTwREpHCYVc+WLHaS8IhnxJfhb ITUISGI4VKsED0ugiOvkEQvVIKsXaqmqCUIM76/FDtIhBwv+0QIeuFrCpSE2oFhO/W4QQ1/ohjKy EfHGlCyYMJ162klS0qCIc6uE6dkdJIK01K4w/11CC96wvp0Q8KQzvFatNSrS364JL9dBUiT0tEWm E9uoUE0xv6SJpylUIJV+ktMw6ptXha3IYh2vC8LxSCrpcKsTxL0DoLW0gddTpfr6C+vQXFLta/hB 1RCjpwn9esL2q0tmF6JvWFq3Taxap/rWgWtL1vrXWvJDunVcL/SpIEQXH+vgsarVBYWmfGw69dP9 fmw2Wra1BmwYhk6r9EIP1CmAjdOF9f/xVeElimNbrCVEGqwQhX3S63/4XUU9wdL2Esa0QynCYa9S N0q1LOULy6uHX19/4Sh+RwzKevSD6IQfDj91IXZqF7QaZDY9hdcV8SVkHoE31JAafQVwucw18Nhf QtU1T8LaSZEDTdKuULS/gpHS6WQfBZxdVbT1a70GasJ/pRVL4IQW77iGCsVaDCsMJhNRCxoWE9L1 FfLXGIjojpBDj53iYTwgyKcIjok0R0I1UINNulXXwvFXhoR2hjEYTsIXpfq+GImHVK5BpqE01sIp SI6VpLs6fmQqvKicdYiItQmhQjFc1uKQT/Udui+LQkNa2C1//V3YW4ShnMEqrGo7TQna0iuLIaBK IqFX8RMIRDnaeCVNJfLWM1iGlBBNVTmQsqjg1HQYVd/IxBgqYTC7/iKCaFpoy0u9UGF2I1GgwTC+ W/JhCPwQNkLLsOEQwOUmnMOeR8IoeEJGmyOO+4Tfsi4v0Qyb+JZoLtexGr/93bq3fLSmqtidraJu Lr5aQmjv0FHsMRHuQEVKrlMJedledUdEN23OxiER6ZbE4rKEewybpMmyoi3MIR4dSNIi+JF8miH3 EgiuW9SNozRA1Q3K62BeQZoZkGhERGuTe1FjyuZhoKhDWi3gFx5XNVDLciWLjJmCeSbTWsSjI4Fx natbiTonceh/forrS/f5N9FCKHp+sf9br5NlRVWQeCjcTkLF7rsQeRTCDxGoMHpmwY9FvYPVhLLT DXBvjwlsGHaIaB+N3SkODluJorlnVtuET1iZJX3D1S1jCX0E776pLrtfBerlu4Z+OukCC/raVePa siOrpA179y38SyOk5Bgf1DoQ1hf7bSkhz0/0wuPk3VVbbun8e3DSS8sif7bNAate2WrRV1YoaxE8 v7W4/31/tVlkEu+4a3JuLLLcW/q3VdZV1QlpjYiq3LfATv7qVzMM+nqtwgu9atSGDcCrrU7q8Mij gtEbg1JuqLSimI9W1nRFQkYf3dIN2NjXV1V7JvNdfXSb8lO2VylJa3fbxcQqXlurvav3Y9FcQgg6 pJBrJuBLU7rXpBbsV/dj4rU7DRkltFjoMLt6XW4mSyJ0P3/I387rQTY+2/0h4hOvf9Lpzb7+61bV PyG3b+vb7pivr5HFe0+uuu/r9Ha19Um18KUhumfCBMINLnZdV/phBk8QZHZY+IoJrfp9dM1YTsIg iQj2PzvmRwaCOiOiPEaUH7Gve1tA4aDQMFJCWIQjiiDEkLu/k3OrRDj2k20wmUgUKLws7C0g18N3 Ut1hbwm4hpqdewg15DK0pyMdmof4YUm+hoMjQNFiMQvu7VQlyGgRijwgRBNls+MuqsPQi6pZCYkZ 3JXiwoQVvZq6EJnaQ0Ivxu9aQ7dA72gWdl7CDoJnYPQh8P01wttQwpCdpBfhaTK1EuMjg2lYHbLe ARxrrvGm7QXerkvohPqC5VAe0W8x9JJbdUFkIOUPr9aiCzqFUKwgg6iGQUxyC5uCrU66vuXDyXpI gYv4XhBSgCNIGQzXBBB1LOVxHzghHRHRHy6N7ObpVJKKI6fQ+EgiYAj9Vo8HCDLyQSBkNCXtCIiI iIk3U+sJNt/pUE/1djQtJAiMFT2OkFd1qyPoEkEyXP1CIkIgxNJdBNEDGR0iCdv691uI6gh7paD0 lSQTkYBdEIHhLVFv3tBWkFX0lQaUJEQ/pQqCDw2tBBV9QnrC+gtPQSCNYqUF4SGpb6rVAvu4V1rx WnyQ5DhoOq+ldlNOKQ19SKOUKV165L+kNfVPXHq624Q39VWkvULr6XlvX6pW/TekiI/q0gXrT4fV dtUvWyXS/JWFX+EK1SVfkrIxyga8PWq3NWm5UJth0GRBiXqv6WmH0Ir27r1tPyIheHikix/XWl/D SVLw9fWGEvJCI4vD6XX2C/XYfhK+WbPO0KKOJbVkLFcEIRI3Ydqgr60F0miQ+r8mAet40vaxT2bB 62+KX+T3NYJrqH4MlwY5b3rgjjx1CvUQSYKw26S9e8JhL2+DNERwL8tzUDGNOxTrUbdwl6/UERuG EvfYiQwP4SGq2E0wt7SX/8JMV4fhVcIKiHu06UE4bbCKHQX/dwgvSfZBo/tEFDTHi9NK1T2hH19W CCa99kFA4XVkRp6RaDCcjphbsGaIjou1Oir7asJNeu414dNAwktggwlYiIx+sYoNeQ9cGQdP4bpo RFhA0awxINL9q7aYL1WhWt7CImhEKyBccEyDvEYcOEQYnSgl9oPYqd8DcONew2h/I4YS+3WduBhk F9VVSDGy4LeIXVtvGiTZH2ErthhYtNdWDzsTUhncIRDC4QaHhDXK4Ii8ckH2d8MSXQa6fYT3K4mC vuRfESrXi1sE171cRzIDPEeGSHuJAkOPSEzzaI+XDQWarWNdsRE0BLoqqOwf9RE7DWNZ2Kpb+OPc bILkHmpEy+q7YiP//9DS37qudumv918tw3uK8rrTBB4rwVOiyqir9vr1vureERR/a0uvbCX9vitt rhqtdNi1v7LNJFXYRHnxDC6643ityAkBrbRH0stsuhrT+TdOGC+R0YVmSwtXhLBCIkK1BKUtDuNe QUhztA5TVm1FJISFNyQqTzuvqGuQPBHIQ2WimuCZXSwuidChz2W4stxsxJ1y3NX5HRdCINn0RwJx E75baqxN5dCYaKmihDwzIndShCIidUR8uGYR8buEhxE0RQQlqV8yM0otYoIsoUi3T4xdLCKHYjWs aLTCl63G4/UshUteV9UO3x6Jslf/1ZUl+qIKkHfb4vqnaeJZ1T06//otMEJ7+6Y/kY+062SFSkhr fq4WZg/a8NYW6fZ1xTBQ3e9BobmV/JsLqr0ybGqc7E8LVJ+tMsuIOFW/dqlSYdV4rpKNj16DfaWv t1RDLHd4S72kiD2qLINaVV1faCKHVFkjX11eqCFrzX+tVq0mFSYXXOzNaVN3ShMIvuo6Qr34pIRU Eq9Kt4YJsm4EgS/WH3HUF1MjMvr1qEElSDI/SX2uggvQjrXVCEFkUXa0/0EuW9EshlarRbhS1wgs VqQanK7fI6Kyn8IiFGtiSH8RFUHdUuGUOPb+ljieDV6+TYa0F4ZDjngne+iQ/GvkYhFR10r0Flco 18iB/V8txVHYKtSQggfWE/dXiCBcPzKjkLsc4VIXrhaVK7iMPEJhM1CKRszGEQLjlKOkn+tZBBaR I1qD0IiwnWFIGO3/bILjCDQMphAkGpIdAl4UIH9JolCaZDPoQ1SJBcqJZFCA6CcEFXUL/Edg5Da6 EwmqTDVYIKUiIhHQ6pEOPXRb1FtYZBR9BErECoiulYeE2CCapgtqgTrst0B/UGDwgiUghH1S6lu9 QZDYTIPFUgg6wgsL0GdhqtybqgbGQ1BwSCBDWEKSng+mS4dL9PoJYLyutmpBUiTdLfZNyUCAyDdy tUfQRBceq1g2qlIQQJNVCfpfaUJiVYWmqJulAuSDFIKCCvpJJvXQKv1UJL75FeE8cH0rCBJLVYbV ER+gvUIjx+l9cJN65ZIF0lQLBFDkb/SfSekFqkk/EKoX6e4PDapYQSoa2lvpWqX1Xwuuq7fYeklQ Whr7xXpUkqCv+RWTOq7ylIjgYfS5E106SvX0nqr8IEUPQXX27IGMjouCr66W99dAjj6S10u2h/6V bILjiP4XBK/gukPdVpJN9V3tdYomy0tKlS6sqqBFDwVfpJUlW22EvX9Vg0tegl4jRGAutPpfST2w v7FatNhc0VAq1JDgm8hhguYWlXCqhXYYKj3+knoehUjgRhcbRDjhWlW9BKqeGKlyQdWskqeTHIKo 5G5GOW4RHRoihJKTqOwS3iFha1oKklbTEE3aaoQ5kC7TKc45Q5Q5Ic/EbmsIMocKUOCDojHKZDX3 oMF7hQwSr4ZmC/W2vWlDlbQiLjbiDKGkJN1hILbWPeExVfH05BphbB5Ts7Mk0XVA0RNCIiIk3Alh KxkNg7e24KutVSUQaqHjMIQy9UI4qkwW/bCqr26psYTD4jQhBUwtkNDpsqE7ILiAmt5AuPVLq70W n6CWyMifbC7BKwwmhzfsF1WwnrSQSxsEg1wyQK53yYVAgQqwvq2CauJN0tqCCqKDIs7EI3uIYUW7 BMNWE2Ia4T0ErCHggRQ4eGEqsK98yFHwpNzRYJdbshBzZGnGqFxK2umOThjYXCiNrafGpb+1koCp hYYQelqvt0TdZ4gsaadqg4tXtKoLwyKMTTi87JEtnYNUMIcQ4sIPGsYRbkswWVgHEe3CQQYLBhWy utDtqhxJuXVUHYidiF/C4/dfH791+Fkh/2o7Jutvp+d+HI+E/T0CEGR1ZbkL/oSZsoj7cJSDUbCP VjZDTNql+mDVbhoMi8HWdja0GE2SAz1j2E2dQXBr7J7VsjA492nBh0WRVVRbB/q22v8N/dtstJYW PMo8N/aJIhbbGtiV/e2Ta9aq26f5Ecg+9LYUslfRZANXQkNm58KOvkGyCjK2nX4k1m9ND4ZCwfCj SRAnFr92Q2cyNgX0FCaJZOjI4Lgk3WtsTgIiCgppfDZJiyJ5wTCt71JpTYWuwgh0CqrhKhLJX2/R MdPX3oREyTqviOrstkoXfH/7rbdfXsNS1kjLIsIyAleIRNzNFn5Jk2CsiaEyVh6TnZGR2JZQ0NvY T7R3AZybCAI0x14aJQynDKJsQDX2TYtQoIjrhhIUCINg5TOnndaFL4M44J0IM1IjsshYnC0EENsR YRNr4i7a8codBkM0cpyjYgMJmEIMJNAqGDJORufEIxBisLjKNhMgQOTmVZVhbBXEEUOQg5TlDQRH ShriwgoiRQMseuW9SrJpY1O1r8dItwJd7vsl/KvJtCI64sHVqkZBeFCoXOwVN5NF5brSxW/jSaD9 aTXMi1EdJ30/Eyoa66Gl74RH8IH9aaVX6HBPS1V6ZXWjur4frWwuuvhB9dqNHHpkML1V6f+lzYZ+ Ha9eliqBBJVohKAiOvouv8Qv4QjXbNX4eFb6S6EjDruC8rCbr4Mj69KH5Fu9LO1CI6whDzsmqvJ2 /hp9EUPOxDSwg9U/mgJrabpBEKuJTvUS9DH+HvfUm4WsFo7IBcrYzi/rhuHt33QTwRDA4QRBHKEv zsUveQc2nIa/8KoUVHRBqHVR7bYPsp5tv0lMosIKtkMocFr6dkM5sPtbXTwiHuUiPkQiztApfwgo WyELyFuveyDduZ8JU25gX0EoTBQQanfhlEu0EiKWQ1nWW7t4bW1s2mceoVigkCrYXCoNAn6UEwWv 2D7pYQYdj0CSVMJ6hBoFakhdBU0vZHXvhJVwukEgqqVYMKCScK8fCa/Y+a1fx4SK+vSMPCUWqDpb QJNzqtQmvWG05m+3VIJV1QSVQVMg9NSTaSf6hUkjt7hg8R8EFxBfSFSMdhVoEDRDB4XVEh2orSrh byGH4bUJY1oJCR5REuFwTRC1K4pK+tNTtWRdm0pLpMhohGR1divS0FoQq0tVtLWEk3+FzsYGqEqC hCRt+V90oSXCStBa0mglX39VU7DDaQZrSSYJkDXDCOyEsQkoVMJKklXTSDStJN60iCRXVNcIME6h zsdC9afCq0uQg5U0knCWqpv4p6OzgrfWq8t/GgzeCKfwRHXsFTFaQwWqS+r+gtV/1W4xBl0O9CyC D3kxeloI+tURccJWq/69JVpdfEO6eE+lCpaH6DrolZxPTfULSkGHNgXrUiTa0iutSfy9ATXrWgtJ W1XH31r0QdR0u8kMII7mut6wTC6opHWtecSV0tUr/WqIUwltKrgkEa0CIsifyY7poafyEHwq1XSe lvr9hdILr+wuEGRaBB9dvCivYWFSpBaGnSCw6Vb6rpQut2KCQbYT3e/feag6r66t5rAiQXg+FDOF rpaha9cguroNVr7+pN9ZShQwWqToKkl4WItcFva9JQdfdBXhaXhrttJxZCuutQS98EQw/8JZTqyO jiYWgqS9dhrD04fwwWuPEKj6SSwvXZHzAZ+FWC4QXEGIpSPeqX6290l/3ok73qhqsEkkuIra48Jv +vrsNK46fsP3Lr2C34YX+t+sF+6+1qHrILv9q37/sJKqj0uCpglp0uoaha9Q+iQ4aCD+tvqP2qFr SS32CdhYIEwuQff1W0rJCbSoNoFf23tbrYTjIaInF/CwyKNL1YVl1IEbhhd6oQw/bhV9bre8iQm1 hPraxdhYUYbINaqwn2ln02krdf97r8WE1FL0GFidVCwl8MIhx12qgk/uEv3/v4sFXQsgieLCiER0 1yGELS0ohB/dK7R2V9P+R1ftVtFa9hUMJpiq2+g6X1VtzKEprHddD9i9CLgwWGmqf0kg9q2ldIQh ZwCGGF9/rEYQvTXHCINN221CqmhyHHW/tNVCKomEwh6ojDXhqvaaY+ncXeFYMguOVs1VNUkEuOu4 MINW4aWEK0IsL1CHWktFDsMEGCoRyy0xQQtBqqVhVX6K5KEI6DBeWRIsJAwQhhaQa3q3BCOvRNga UGcc45e6aSF66vuI6iIu8EwnS62fRtZZBNCrTVY9/UECXJunzWhSaFhBhda0IrI4WhUMEGYyX15T hRiZF9RE7HaX9CGS6OIvk6N4TFEIPHvVWQ0IibQxcL61shgSoLv5M/gzyI6NowCql+6TwxERpdfu EDIH8AksyUk9xsWCI6ErmqJteTY1XiwRHXZCGy0EKeKWI+yNIGQ14Kc7nX08L4ZDCgGTYCDKI6ER oa+W9GyGdytbKHO5G5pzi9vQQYYixERHH7YTIUGqTYEQ/0w5XtD10way1DVFJ/0RR2VgG4lmgShw /9Nk0RHQuHe6ldVvES0xPF7+qtiL/XstQr3/0+Qvvve4jfv9v1q2w//lkLE3+9zu0LbkbX6WHevf ohZSK2RoHpXteQzu5xx1XSuNiurdJBsGUPG+qRFMGh6sUEgQMGF30TFGymytqrCFMR7p7hZamnoM xJHj9rhrhq9UU9bwimBNdK/Ra4sh+Phf6kS/RAgvFB8IH4dHfJ+GW0lrHgw1vYce21XDXse32+92 6sP2WmTXbHTB8LybJwX4UtoaVUluCIVtFTrC+33YZNlMMwstqqlcTMNk20yHnAVR7hBt2eQQs9k2 rS1QbbYQkFMcWLW5BfYo4jG0GQz7G3k2Tormq4MNuQ0nOgqfHQMho2kDkC5UxqGQUb1DkEWfDIZV RZK2Rdj+DINHN4L7KHGHSybELs0ImQV7Gm2fBoHKWYIqPcoAvp/DPoE2Sxp/DOnBcP6UMdb4OHe+ +JHWnb1QfssevYPxrpvc9sL8HMhtfq+scp9wt3eSNyjcUvClcq2RDcUeEr7lcbBDcDBkeI4ytGbR Hjz747hCQg5uEWVQGn/6EjH/aXWMPdpN1K4oBwDLHXeGUPhyuCIjg2iSB9pFzHqJpkcMsXB0Le4n gYIXFIX4W4hMIPu04IodKE9tURX+7XtQuWh0Tc1WN5PA9uFC8fpN4YpLG/Xog3HKpqure0MFd/7Z BHClDr+k/Ig4QiPW+8NC9yuFKt+1LISo7CLgnf9uI0UPXS9eNf73ZaxdV329PLcIhqutaeP29eTd /QIunrTVvh1Eqdf+71SMZmyOZSC/ut+9wQhgr9aTfX0MOktU3ltKq0opX6YSuyzVXZUljbQVrX34 28ME3+kjD3HTZ1DNvo7Vrp7/kmHYYSSt0hDd1bDynFYqEn7TbYtVX+7bcbSf7bYYWk19tx6HLKsr tt/9WG29Y9tvp7t2tLww3en7beKlk1XYbe2PDB3rUMG9maNaIEjaBFPI6u22TYrWR8JEdAgTKHKm ZysPAQsEhHwweKERZdF0R/EREMEIsOrILjlewQiIiL4MScFQruDEV927lvMC7KH0w0IZNzuXGpb6 h2hE6IwCuXocXEjUR2R0JXIWhER6Y1LWKloswHE3IQ5Q7CY4wuUPLMDDx166StpVQRaQH+Ce9DTS 8FarY/8gNEKpW1/LOIZaiohtCFWpS0o3FardKnRZRP/2ksrpFThP/x7jwfiWgW7aVIb1tlmVukF6 k3Wcs2ipqK5Q6C9ulpIIbpf2GC0N/UgIGlx9sswujmXjY6RZmuRwaybjauWcsyTRgG0S3hVCIjlD lDlDjMhCHoRESDI5Q5x0NUQJ00cGCI+DIbc5dF0SFiy0FiKzBlDmsw5Y5Y5Mowo4iIiK9b/XSuHv oKksPIUXvCd0vCKH3WYeELMEWh++ELQgxyh+nwh1LvLHWd/CaWQg50yC0Fx4gh76wsapLOxVO+3F 9KUO+pL6Q3XFIHrogiHfJRq9He4L+NM6sIJaLV9d0wsI/V/tJkV0hjf4UELX7oaJsrX8LrXDpBxv codhBMqGTYzVGH7GLjY+stU1RN9f7X13rLJCx9vajqrybBa97eL1u8b9+6knfStJO7KH6CCDev0f F7EofqnWP27rpP/oN/1fu9NdbSab9b9roU/Yv39/S/O/eKd8Kv3692t//MhWyn1LVU0eVUumGWaq IftWIUR45SwILSU13I7I+YzyJMGosonjnHcRERjY0qTXqpZyuI4HBHzQridEXRgZHIjjL5HQvcmy ViIiIiNXLcWXEb/+v/rf8tQC7jRh+K1u9d3tUim1a2PLbKFxrugsP3v6/KHWMtMn7G1y0zHy0yIa dcb+lf/BEfoVv/7vqih5bYUsY7LMEgpHi20/os6WinRsGksgWvlnCwPZZCpD7CDH0mWcxvuQPDd+ N0QN08YWRIKchmAUt/VZiZyqNyzlCof3+Eo9uu3rXa+t+6/f/kEHVVTNa79kgrJul1XljzMSkrSu 6BZNwaHeOEFY/VBVXSQS/pL+Eq/9NdzroJU76DSvqtpfrYZr0gvfDYQoE+92kEOtB0iOIYDYTYWX 2whTjvbRMcJ67aCQQZIcq0UtfbSZac56lqmS+xiLiP2EsPtde/6f9fap9Xlu/6TffVv/TfpUm7/t vvSb/8Pow60m10vTDctQdWN1DePWm8sxLVdQ35NP9BvEb6t3Wqf3q01dcbr6Xvb+va4XXaX4t/O+ 0HVSZZHBR6KoiOGp8lYMnziMZoyOB6vSEMuB4XvGTcQjtC2NluUYjqQPEHvbDIFfFeVaHk2M0DIa bnFlSEtyUiOiOi5kdi1sRERHKHWL/16/loF1BxrXW+WyqdW7vctkZjUeU648tcp6KH9DGGqOO7FW ymEtVLbFV1XuI8tgDWh3q3UtUD6hLpFmrC4jf1MiauP9K+6fv9b1/e9a0UPuWcziPmdyzrQK2yzq oE/LOFAWZh4RAgdFmja9AiCKyqEblWiuk+haIggqkRBJxuECEXHUFduC6Y+rtlnA3f3rfcs89/Q7 7b/p/q+38rQPvC5h+S0l+6D7Gqcn3uo9FD09v9I2cm6dXxSUaudNe6wzUkl7dhUFlphSv2qS3VJ6 X6tsNQko29ukEcL0raxom/OPdvSrLUJOG1bVBVv3bqEkowVY4L4fDsnXb/Q1V3D0v8XJtV17+H7x +nwva+5Y976t3T0n4a1b4Xq8shj3ST/e1vG17fC1T99LevT/0n/qN//6Xb663/0stBCtbWPoX+v+ t///X71lukzstXvob+P3hVJSihL0QowrioPcECQh9kGAKYBr5kppkMyxdPY7Qzdyn0SA2iPmtF1H LcCZHRHhIhkdkdk6ERgjvLcIGgRESbFasaY3uq+yAwT6u+UOi3glHFhB/CbNZ/V0xGtb7T/5Z1j9 pAtqRL9Xgi+6jTx/sLr/8V6r9VKYE+ih/jHp+q1SrnZlnZJheop121S+VweFXLVBFXWD7vayC4z+ 0ob/sJX1e+6GFbCTv7SBxynUNIqwl9BCW0FLc47QSmSFrY6Hu0N9hfa/W0qvrxTqn8tQH3CIjsap P1uHSbhUmymUtZQ+my6MlcRwg41uzsbZCwb1QTGmSwNPr2EQZAGKj0HtEDgBgLYQVtkbAgj5Hzga mt2wiC4Mg1gMFem7smM2Bgt3AitO6DEnDYR0V1gFQsoNeg4bhkqDYVwQCdf9zDhgwyuUAWFkAkOo QabE8i4IQQGCuNhlnsuiOiOIRwXE7UK3i2J4IVIEK6sMwREQzuxqwjsXziL5cMbDKoFK6cMshoQ/ E7DA+hkkFK4YKBNqibgq2W6fLojgeEBhtyDC0EOyuNspwPDbDtyTmNAVIrmAcjmRwPBSDYbghvSE W7f+220u6IHgXHKHI3MOUi231nHogeCKYbt/jK4MiODKR2RzlxcN6+JDb2rd/lrDa6JjD7VG7d/U Rbv8dO7eRY+923pmpdFDsN7+Ti+K27btfu75KaCq3fDMgoZHD8F6duzJApDyOGl/28KdlQHg1q5s 1rup2MA8CdbCd/sGzuYHgz1FfulJoB4UwCgk2lC++VUFyCAsF0dM2hVKuvaINA5A+srCtiTSr+6E gSDlOfZJSru3cgeGJGs0kly1H7+yEHIK8hGyGIfDFcL2GFIlkOgqQHbBI2GfH7pA0It2EJBx3/0r 7CI7IEDw9/8JdoKQfHdZx+6VOxoFFXj7SGw1BP3/6HSpPpdNd167DC/urpi/paVffpPJu/r+k2v9 LW/pa3Td/esK3XpUug/f/Sb7/6TD4VKktf5XSES6LhDgLkoiPmaJ369N+jIKyERcDwzkdGtF8wDa q1FfsyKQPBYI8R0XA89d7uQVGeQMOXythkgiVUGqyDA0JBxyY4kQ5hyDp1SpfkGscRESGyK1jdCJ A8Dccqi0qy0jGWWqhkMkMWUEPBgQg0DmcocpBblTpJQdD5DIBXGE9ipQ5SVSWschxyxysIahBAhz 6lDghEQaoIL6JCZHsSO5DYvdJKF7EQyHXOkglV8fC1XLpJIECq6j6ULuqQIIaoodVglePUIIrgm+ 0qCCT9KEgQLvdUCCvyh+oQSB+KSSCCZDgpTg4b0ggmUOQXExcJJJAgQsgYr70ggTFFcs7qp5Akyh wQ1UiqCCI6QgiPieBlI5+ooQgQlunDUGqSRgMFuJxcM96QghHpBBV0F6UtsEXVENADdaQUguA0Yd mSVAoKLjJDnAaTcRr715AZauNS2BiqPtcswN7CD4J9bSdP/pfW6uwqtetNbZTWLDMgLiP9/WpAWH UOOrZbCmoRQ6EsuqxZZgd3QY9Pp9PrlD+hr4V+sjTQScdtWN+Pr//DwpZlauP3oyKz7fEtuauN6V MsxFwg4PZZBtQVPh16p9cdTj/HRQ9BRuvBWkFWqwrhqpZJobY/W/C/W/fW/71/9b//3rf/+ih3Gv CwctIJQVss1aV2hqN/63/2QFBpaZS7plpDePS4/RZhQiOuI/+yh+P196/lkIv3aqN6lsLfofb5Zo uuWbZlx3sIX8J37yOqrF2ruv7kK5V+lI0K7KfC6xcKF8Scfpahss2weqpGO9Q7aqhd8sxUm+2sg4 9aRZAXBYJOjtZVMSuN4JSRDbG9pMEqRbaX+wkIeh7aCIkgRT29WkQIEvdhAiY4SRZqWtWEUOkKDj dtCmvhuEgvsMEmFVW6RIcIbhiCaGtDtrk3JzXd+K6vt8swGwfe31b/fSb4RQ9sv2ib/oUx7Ju4wr 8mxmHQT8my2C4V+TZVBQl7CpB9AmvybFYaUJrk2Fw16G4LC5NgIMsjghhkntVJsoDNQTQJpVBJIQ ih3C5NqwzUEEMdBAgggXYIhlkJeEQL1hLybcDcjpIJcEQzjghQSIccoBhlluaBoFJBCTYERe0gkk ETYEBOCCSQRlPJGXRgIamR8vnZkCEczqGXwgSSR2tBsNoECiJBdxEhLLmU5SmUOVBQ5oOgmOIZHR dGAai1wJcIFSR26MZSIui7I7I7CERoQYQkvKDI7BJghDkY4kFA4iLGoQSoIqiLhlEMMgOXQQiIiI q4QVUUkYZcMgNBHDJItoqXQKkinyOGQGvIHhB49AkqIYHgrkcFYjhkkRzI6Low+EtBlwPAokY5Rz YRHKDKHIo5OCMchByrI7OOQ0nILjkDwccIREeECpCQPxypkxyDccnZW3QiIs+hBuOXxUHGGHIaMO OW53KcococjHOOSTIpoJKQ26ihYkOVImUqnw6aGYQVyGmAxSVBUibkM4DEq0vDIQBr4QKqHqq2oX 1QVJeF/S0vr9L/Wl//WvXrr/+rluaouiOBBHRdEcJ/MojQzYaZVgeGeup2tZHA8z2R0RwPDL6ud6 mRzJMMgFO+pLxHDB/KgMwvEcMgCz9moNQwz6CESGQGkO68hhxESGQDcchtj2Qg/XGGQynM5eIMqw gynS+QyAyxyrM5PUqCxyGcaKHKHMOCI6QIRERafshkFQpZO54BCIiIhL6IZY5BQ53KcgYDOOROKc uRbvwSKcpyjBBBwQiI9PZCOSHQiJFsV/CER9de3Hv2vDb8N1lsCq32ymcLDd0O+/vbC52tI4iOra 2dlaLo8QIQZHRHr+d6ozRHR8EI6iIg7a532R0R9TCCZfBCIdt3JKiPF4uFwhBEcCi/ZrR5EdGpGw PBqt+eiOGQO3uhIHgy6PD7kDw2oKLlRKaOt/IHhswoTKohu9sgswZzbHVveQVNk8NvDZcnWHht7t vbd220+rex9tMNXDu9btvt3fu2+w9h8MO2+GG4N9u78HYYeW1r2HbD+w7DDI/jDDbi+w0SHYdIty Sgw3bt4Vh24fGGD7DfYN2wdZZQMGLYb8MhnIbDfgyBexhrhix7vLKVhtrZQ65kUoWQaY/d3ItxJu GCgfmWIm6qBGsQYJWo4/ev9/W/q5TZUv1H2///f7w/othT9D7dL/ZaldJuC+NPt3uiul91H1f/b9 9+9ROyTvde6f+WUvf9+54MF1ybgUdp7UjgXctUf4TsnDTTHZExQmpwGyrkDBFrvZDwTT0vphNVgk iup/dNdlDkGiSmx9pmvC6EgoktbeiDEbCmfyHHJrjrtwQbuQru8MufLZCL6BcUt2K4+KbYVLVLth dfv+v/X9dL95agoV6utV8L6dKq652aNXXX90PrpYX//Sv19Xrav+l4Wv+6g03C/648+Cf+6j3/16 W/pwn9r2v+9B37v7Cf4vIg6gny3K/vEIMmKLLcU+4yI3t4/oY/f/+39S0gRe79Dorx1bRCjlOUpP xEht/0iDPG8d1KaFLbjcLaDxl3widEdEcNhgGmECERE6RHRsJZWxwUmxKhGP//yAspry01JDH//I C5ooy1Sa8SbU//H8tMGtx///LNLrxlnFV4yFfjIDAVePLYKeJEKP/lpjPUf//////////////+AC ACANZW5kc3RyZWFtIA1lbmRvYmoNNSAwIG9iag0yNTAyNg1lbmRvYmoNNCAwIG9iag08PCAvTGVu Z3RoIDYgMCBSID4+DXN0cmVhbQ1xIDYxMi4wMCAwIDAgNzkyLjAwIDAuMDAgMC4wMCBjbSAgMSBn IC9PYmozIERvIFENZW5kc3RyZWFtDQ1lbmRvYmoNNiAwIG9iag00OA1lbmRvYmoNNyAwIG9iag08 PA0vVHlwZSAvUGFnZQ0vTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQ0vQ3JvcEJveCBbMCAwIDYxMiA3 OTJdDS9QYXJlbnQgMiAwIFINIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8DS9Qcm9jU2V0IFsvUERG IC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQ0vWE9iamVjdCA8PA0vT2JqOCA4IDAgUiAgID4+DSA+ Pg0vQ29udGVudHMgWyA5IDAgUiAgXQ0+Pg1lbmRvYmoNOCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajggL1dpZHRoIDI1NTAgL0hlaWdodCAzMzAwIC9D b2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCAx IC9MZW5ndGggMTAgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAv SyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/yAoW8f8sAirH8sqOJaaRWU1iB8shR08O uy1Ei431avu8P4lmKXGTYmFk2LgxJtWDeC1JtaLMNEWdKUm0waU0xohoHko07hEMTCUyPwzuncEC CCCa6k2/egkSTnUHH9abDhAkCI6wkOwuhhELoEIp45XE/oJBQS3eVyVwQQiqqq0CrvboLpJI7HRk C76WlxHpV19Ba+0WSeW5U9ekdg14QKGCdJbXrQoLqqobTwpSqvog9lbLhcIJAg6Xlcui4Zl6RXGj V9LoX9BEM4WCI6CLHe6wT9QQNBDF4V5XDIjhpZDRdEc1oJoi7H1rjTPARqCoI7mPBr534ajC1CTe QRcvwiBccjidjikcNKtIIJ8g3XInefMOagQZSJS5E4HDMilEcHwiCQVeryGUvP8IWhFCJh1ZkBsj hs0EJOi7V7B/isSGwcIyW5I7CtDKvMIjSMCpIEIwrsGdjYVdSqvkM0cEJ0ylIwt7CmtGFaDBC9BB J4YYQb5UZ2ke+TSI6PojpGggR5QFJhEIi6wv5FwbkdEcghHZLhs0kmUO5brQZgKQ8lRqtptLhCyP hYwZVENj3+togx2CjCWECSeTaA2BB2RQK/pq2a1klEI6DCCwQ9FJCIgytlV1kTQQgRTlDkQcoIQX XykksmxwwShEnqoT/O/17TwgQJiI9t2RjhqqBChEmkC6Sbk20BCkDChEGHWvuoW3TpCFvdJv6CQQ RBJYVvkgquDDBA9EHo8KvenkIL+EC7h3dumggiKBhAiLsd1Tw6eiFD6IUe+p0iTtEb8EHSkJWlC2 GoXXphIESyTaVeGwtwg6hBA/4XVLwTtQTKQegVqw3910kC7tBQng3IJD0EOEF/phOkvC6ppkYirt JPT8EGsmP1QWmQnqpNO7oikdKkCq/VbQT9qmEwna0ixwT7aDVeukFSraUKvsNBP1pKu6YXS9aVJN yPJ2mlTbSokOG2k3ZHXCztCRHdh9JEU17oIP10vpKtUuERHKH6p2NhVW7BvCq6p8SQ5kiVLhWget JhJ+kuqoLfdEY8Lpfsw/UFV0nhPV+gvS4kKMVKqTynB+sNeG6Xq0r9OvVaoIR6SIceuFSUg9LD3J D4TD/ZDMI/1phhrXaCu4SC6VBBL+lhXQVLrI3l0EC9tXQSf3QQIFaSvSwyDT//1Yeva/oJaXT/SW iIP9XXXELrapp/tpoUmmG9Kw3StKlpN+SppNq+6C/pL+k4S00FrtJaC1SC1S1YdoJNJaS5KURwMK 2uqpAw9IE+iOgv1CWkqXevhBU+vJjmHWlhLfXSTdIl/0EtB7rE9EcCO16pJvcigegxaCUtxrvQSj r39LSvVJUhlDkQdXWEC4WEvVaUjq8JdJulkGhPBnbqtVD5ApQVQbCCf6hBPpJL6VpV1vQn8VXqpd ljhcjHKf0q3b/raSTiSgEYPVUkr1IpZrjCBOk08ZbleE8Eq0lfddBLGqWNBKO8R0/wV6oJKgq3bS ztxGDI6+lw3QULlAat2k9NsIodHAYX1XWsJdU/EJEH06hAus6AvqkUBdLSelT4hr4QSWva+GIXtC IqulfitBZhYSWuoaKHxaRQvPIwGdOrCoQlVvO0iSfBg/VKE+ggrrVLtAv0/4rGvTqFjaCceIkEfV xVVXpr7IMGNYVf+5Bov/g0Frhe2FUHl1C9KoSdJLucWnX3dxTaYZQ7W6QS/QTeQyp7DCI6eZWJBo k5BuJrsL9QvRFHXuwles+ksL/UJUva0Tdiw/wlXqiT7a1UUqDYYVgvwv9Vsf103X7IKMDHaqF0/W FbBv0KUL6XZGDfS6DhhIMhCzBwzAaDiv2qzxdpVUGglTSQUPVprhe1pMMhYTSgsL6C2xVr+wyECs FvEgkNL6QVVOLJ2q2HCoJUGQTRNck5GYVWawmQjqwSbIeYwfb6CXQL7qEGtMMg3DTZCFStYX9rx7 KeM1TSTkfa0iISsm5Q4UIdiCpPCWawlNnMIJkEfDD6oFgvgk22rYQdXBiFZ1BOmFG/VV7In+h4sb SGhEaopDF0wtkhBadJJiILX0gS7S79PqdlCBhQZmC9bBUvtbjFDtNRwXik4IodYIdeTCBBNJtaCw QLwl38i2+6YZQ4Jir2C36FqnZQLBlDhY18GCFUCQsegiXBcEk4hYJbhLYNJsIEGQcSXxahbQZhi/ HaERGFtcVYIER06gggZGLXpiF2EF3+HWGYdJgwQYLUfw1bBUI9YUfMA4ggqWF4IK2D9LqLBZ9E8R 4leXGwqprocMh5K9zjhMSC+xdRCJlmwx7BdggqYew0EGljiYRHDiJFgX3rGgyh7BHYGsMgQNkCNl oTCwkrLfBbDBBZGtkNiddMocJLR8M7IQb0OogypDVeqFkTcCccigXVkIKuIWCTIF9LpCHrIo7F2m 8RrYUh5AwUSxJeDMUpqioFYdQ8UoQ2h8XZEFwQzjgvodgkyMCshm+HDaWVy0Noe8GU4UEI7+wsEQ mwsNXGFBBdOIr/hgsoDkdB61yGq3p66jcMoThBCHwcugtEGtvr9OtoaPAgahWNZDNbiFjjQqCIeR +5HaU7W9kFBuaZY/iCI6MhDsMZjS2di2yDDJf+EIi6Cgqpmo6j0gYYSI6t/fyFXTwo8rWR8jmul5 kXDidwoIj/KoiODFL9BcRtoXvt4QQ8Eyj1esJc0gmmr+oWnYTT9/CV880QzueKvj4S+EHCEN/3SI WPtNev1CVeL9LXwl32Q7ta69EJT7nHWuu+gS1xq0vuqC9uQ8P/68IKqpPSaWt3oKu17gl/1S3S9i np2tL/e1qvpL4XQJe9ul/4rXSahIKtPBWquKV6I6fpwr9f1WFDBKtUuNaCY/r/sFT+lX0SHKA0Oq V2txYTuvp9haVcYWGC7Xiok3KV9dy3KMfW6hB1pVe2n4a7JZwtKO2E+0uwePXBu8Ldh52Yd127dt KodxsLysTdxW5Fs7ljka4G7a8REg45Y5WwMw5UH2VOQzufDjmbBmvEQzBnZqKXBoI+bTcREiudsE oVqJBysqBEWTp4g66BkaQIOJF3zDIMrYCl2DI5EcZ8Dw0yPNsgcNgECid2GSEL5dAnDGVylEDZHA 8GouyOB4NyOiPmM2E2RdHETMDwhiEnA8GUOQIG8txMGQuQkSy4HhrWRMCIZDUHK3pbIsDEtywMF8 joTsCy4HsNkrBIiIlIGYRwfDDlkIR5kYbYNxHwYO22DD2THbB21cMH3bDB3HDB7bDIEANq3DfsMO +GHuww+53AYvYP8GGR13DFmQF7TD38Nv7e7uw3+G26dhsf3fRTuWQtXY3/bLatR9xrJjsgSIWmy3 AkTPPFeMRbLcY0Q24KV67cRJQVV/oResqu2iFAst1Ve26CKoGZHkx43ndojouf87mncR67jf/29f e27XreU76/iq6Xtf+3/1cH6S52T3uu+v//d1LUJVr03yWH3VD3yUBfrpD3jrW2HyuVxe+HojHD8S IupBUgTpBvogXHOuLSH5A0lmpQm1oQZHRHZjVutTuiOZoyPGEalgmkHaxESBDkoIlnHKGiUrt2Kk lyOi4E6keLvv7oRERIZxz7VEOEiCIjgeVISDA5Q58Io5tkuGCOPC1ZeFDiRqpUEcGHKHKc8HMaTC ERSERIsEeyi4XCXoTMMgZLhDDI4NhHI2iOjaqkCIsghEgocpycFjlbt12RwtkEy6qRUMkNi0FEIR ESQ5FwjLLrFKVYZvIWZ4M5HMjhkBqKoIESkMwxmIhokI1IvmwPBYI8Y99hNHBmwbeIidMjhkBmUs hgcocrghERESfL5HRHBcjguXA8G5HGbRHUOGkwlQh8SUAeBPoIk0IiIiInRI7iIjdIGC/mQwD8zR HRcGjBBCIk6LojghfMAeDtqPIFaYGUZKMj5JoRBlYUPoJCIiGcc+W0tkNROtiIiJQLQJCJEI2Cqx XIZqYC1S0EJCAYaUh5tXS0EW5WdYjqkgQX/SwgluvSQQWn1VQQLT+kkCCpEof9IrAMWk2ulUIL3+ ggih0ECpJv+4QSpN9UiGkEQoCH2/hLSCSpX6UclYaNJ0q0kRcNlJN/SSBBEkWtf0gSHSH0VxZILB Av+KpEIjAGC9kdNVK4G1SUp0CEE8Ya8bSR8NYcVq8SGkbAX4ggS9ot1YKf3RBWNirlMCy8g2mwLx sMMg0mxL7luYiOZHyOrS4iI/5DjkDw6ZnUfYVwz8fyY5CnKOfihyIOqDERERENGatY+u/H//8swQ y1ik+g4fQa9O/YTupaikr+RTLU4Oid+WSicEy1DVAge+/oIQ6cgXxUNFctSfr2hUINfvVyMcqgfS fDCzItSQnQJ61ZTdRTMuoQPQ/LOpIe09tUrjhb7+up11TDfXLMBpTtaCwVsKUOm/5NgQggbnaqDC S0LbVLybFQdNTsL0zi1XYa1wW9DVKvdteTYTDOuEQwO763w/wkuiEP1XTda4IhnNhvwkrpfsL8my sCKUIEElr93+CBVaR9EdBBekdkzpvruEQXNi0JUExCvwTv3+kgtIMrRKkC19/RBDYLSO+hus71QJ X+vgh9JfOzoEILe+toEgsJX0EJCgf/vBHsf1U7sNHf/oeFfR2OBBxfX9cLM61CILlPVc71PaRN8r hf0iFdEIjAhHoZdEcibOvcp1p/CDaS9cIIUIiIkM4QpcTIzlbWa4JZO16Ic2S/qvyMbZDCmQWiOI YwmOuvhPoGtrvqgqI+EjIsSEw7TI+E79LYRH0yDy4t4a9OvwmwWKiLU1/WglGDKTPBFBCHW10oqt SVhrEcwRDwgjweMrKhNVsF5EBy6CDU6g35bmiTT/9skoy6FBChiJRJJvREBjCVQYoT41KAy4bCci jlDtf7ShtCCISSmEOnqQwUauyhw2Ca14WCE4LelXshgtQIJBIhL3pLhJMYMQbRCPRDOOUOqluLrg g6//IZymkSsHIegSCwXriqCB8LkMDofSYQQv/T0yBcSoESoM4IhygpzrMq0kJ8CNchSCXJODtUgi CU7hwtL11DIZZiiRZCBkDBFTSXSyVAXsOGH0siEBe0tqyH/eDDwprQVBlQgqBWFDTpMmPIoiOGXu ynfrQR25K7aVSI3EbpKs7qBd0kwoVDtUg6hJggQlHQQrxt0lgqpsNJQZ26ipD9fOy4dUlRDOPRCw wSSwtNqIiEC0w3FJY3bVIfvCV0dkxcIocK5CDxQIHTSTWR7U4QVeHpe90vjrWDfFKgg1CDohRzQC I/pBaVWElhul6hhpBKlwvg/WgtAgqQcIIaVVcIKccmOend4hX4o6pL7W07wkEkER0rmGYDwW6SSI 3oh9hVKx3wWnuHQYVvwX+qWh1Q0EEgghUJBaYPCCF1L7YLSe3hmwSuGiFH79oIJIJekhHCpchn2U Ql+hW/DbEJewQX/Wv01R7I6oEgRQ4SUPCWxuEE3dOtWGCXWq0CSrVUoqCQQp2Gdl+IXC0rqmwVUy HcJ7ylpJ1BKk0wyxzhECBNEgNASpkDG62wl2mQQG7omO6pKKvbgwSWgvWI2EszDUcgaI4Z4aT0wm m6atsEOwV1sNfBKk3YhRCoTgLwwl7Cab0kwwwQgwX7DCRGXhEMDtQlaUhmwE0GgxStMhBpPtIOJ2 Wx/DBXeGRZp6UJbG2QMEqhIILBeGU5Qon6TYISS4sRwQ5voCq8MVGxCh3DKgCITQetoRVB6SbRDN XViQ0G5ByaSbYTyBFFIMDpsERMchs0PtCDCsXD1SDohpjlDnXIDEdwa632DMIuC5fs7cHEWC1buE mzsWaEaIKhcqDm43wZQ5DjSYKmuIoWzvER0GUOba3r1WgwyBxhUiQgyna1iLsFQYVMJhiIjX7S25 B3IbQ+RhBFq+KhgsMhoHCDfkCqqEE9hs+yOGk5vNojA1PD44aEH1JdFwxqt2xPg1YiDIZUXcawyh wT9CUFwkLDYYMoc7mHBwZEwY6oPiNt8466TsMREzAhhEsPERyNNfoeEmzWEIsGECH2GFSxqk2eRH TYN77DBL+gmxw2GD9WKtK6uCBC5BQj3/0gQUMQ2GGtdftLLp29PBp/VNi3e+GVBCDglXoJyOnBhu uM453CC1/puwbWsRER6vXt5VP/8LbDeQov+o+6pe9cmwkIbyOEI8X3w24S6/k2V5cGxW70C/9k2D GEJBlgoDb+l/8m1APAubwX9BX76JtwHgpfkbX/+Q1Qyh+6ppJewuiGWJfVJLXHogir7IcXRHDKSJ 2FXoNeT3UUOQ2DvsuBwR4kxSBNda8eInAphPcRIYHEhnvaVfcf2I7pXOL2L5CtNtLVEF2gr9aTkF 4KOUOUOfChysIUffXIGGgb99Nk1QSDSOU5ODD2wkrUg1NCvdfskuYRHRjLoj5HMRE/m8jkeyOiPE fI4J9miTkFdoPr7eIiIiIiIiInBG0s2E5AoHOyma+Trb5Y9jYuoka4Ec2J+4+/sLszAsS/XpJP3l OCkR0CBD4a/sLeqJjI4aoilRBDcs/iu1iZo4yPkfI8c+n+wtqQQiIiIj3pVSUNzA5aFhLK4lJr0L 2vD6H6WnSxVel7/qlhJ062qutaJDtdqzQ1SSXDfhqlINzcT6Wk2ONKGR2R0bRHSVBJ6b+hEHEGXM g0UtHDI+bRF7VL2/TGgZHDEmOctBKRwMEcUjg2kcjCXS1+oIocRBEcGC7MIuIR8ujAUjm8RESNzw YcpeaUJKkH7TUREREREREh5GWknp/aIGLKcjHEhkAtSWOglX+yxyGE4OkglpML6VEUA8MGEZsjhl EcDwyyORHyYzYz0YRHzGR8LhJ8V8UTNEdFwblwQj4iJFgPDkeI6I4KZfIeQaIqwRQ+klS7FCIiJ2 WgeBcjgeEI7I+Qwy8IJ/LSFForlYZAZhcNRQlq48rgoZALVBK67CB1CC9dFdZRgy+XDSOoHgb4QS 18REjIuZCwPDmh0EuuHETt8kw0KoIJx8kOhFUgQI2tqPQU2gQSr9IKkZgw7d/TiCI6HXpBCEO/VA vJvWvSINQ4V3k2El0qFsjrEenIZS5cSZJ7yDDlLmCDAU/siQCFEGS/og8joSOo+yhwjWiPDpn0/E QghBlDhDQlcjLteIiOmyY53NniyvBCJRGEXy4GCPmLiIiIiP/ICoa5ahaviP5Zgfwg9J9d5NyztK TcoHvBb0Fp0pLrtE3GwYTIyvCLczQW/iW5J4IIveWVZ94hBL63EEQwO1SW+TdKUJggQ70+TYGy6E s4oCWRx3mT6fQkJsuU3qLN9QrN/aZbqVRf3iFCBY9ekGUyk9MKgXCqnof6Xqv9zsulQXdqFXhm+k tX118Q/UL1OyhVrpRhFuLtBdZ2KaIqddejstUIKqXghqv8Wi3Gwwl9HYEBG6lcWXzsuxCKHf6hEH H0SxKdq8+jf/UXrXOwYZ6NGR9yKsS3hIhjehG4v/QVLrhBRQjI0MIKLCDI4i/wRx2v4IguMDgiPl vAbCPHeYRQ5Haa+oQ69JEOTLHIZbniJkqI7QBikIlONRrUhhynS16CQoIIjoJkTz6PeU+RJGsFBH IIocp2yhyhyhwX8JD/55AjjkY4TGwkIuyGJBpAwkkIj4L5bikQOVAk0usYoWUOkERIMrT0CFCRXS QqdrXrWibC/CrSWgkIYKEC2E02RB2mGhzsFMjr9pYJoJUv4QYJUzoFKSI69g1nygiOhwhb+0l5Hp /WmWORwCo6YSCDIwPgnBgytKIkygKERZsyFj9pUulVelQilDkMsdIMIjH+opWOczDQLBB9sJKdpE tBVXzyYd1yLUFCUIsceqd5HsE02Ekg634qkl94yHKXSYQIRCx6IceiKO6iRgQiyMNWyQiO0+2Euq CVJLnlIZxOlraWgg8K+QbqCx2EGSaVUINP6VPSWr5HQyBcCS1RLyIUegmqeEGuD7TV8EH8MMJK1V Ktewf2gSaIo45CjpNBL3sscONg01dNP3VD0qriw+kqWKkraq6pYeGmcYQfWE5Fcoeby64dJhCEqS 6h3S4LVLEJcLxIccNQgodkP+ztQiOEQIQ4QklylpMJClr2D6gqmoE9AqSwXBlOU45BvAgiOk+1sI h+oSC4ROnUNwksLedqAb7hKiGC9R6ZyiqET4YptEfHHdJ9ILBA0ovtpVSfnYoF8EmzMNEFBQqBAq TBnd1UIbX0ITYIhXMO16tpQtER/g3pBJClukHa0PRHRHQQSV4Tp9EUOkndil0usP2R0CvIdQ06Gs HiI1YenyJq0CJdql6Swl0ofiKWTGtINp2kqDeCSdvS1MOR57VYSq299kC8L64S6XuteEtUFddutK 61XZDP+26hJavhtQXqqSRh0NpVtImMjmqCz+vW8Et3wmFnaEsgg6UK4VKFoJQvHtPJ8IU4SS/O0Y KlIYzC2Qgw3OoTC0wqsij2gVCQR2tXQSCXVpNQQfYQTaTvkYgih7bWbQMpyhzjhcgxBhytGuNVCa RMcJJTQCEl9JJUEkiY/3GnhLVeDKAYqCsRER4u2ChdkYEaDUVBlwb02talOFBLp+ESd2lhBYX4RH YRMdbC929rwRQ6oOxwk6p6BUl/pBtYVgl1TsQ0Kx+nx20MNaW2tYSCQQVb7ph1UQo/iC+mrcZFwF woTBYUUnChLw10g3X0wqYXWGUOEGqjrYVMaqfwUElx0FtJYKhVkUcKtRZxy3DcaqoUINcREFX4Qb JsYUK4TtM8T0I4g4YNMGFUKQ0Jwn5DKdfsJMMZB67VCIi2LRHsIijnHBEdeDCYJLgoSr1bJsrRHM 0pCF01WhI5qOd0IpSFUqUhnoq+EEwY4nEdER0fzXl8juSUYTCUMZXUzTegZZKEsFC30oc7MKhiIi LhYYQvKHUECTCENDCQKQtZaf2wk3ak+bRHAoDWOMm8REQ0ExVq60HhkCRtREUcQtJMUwg1CVfWmI yCs5EHNBUFXBAhrDjQ030E1ZJishmFsYWGh4P0DWiDr6kex44YXDMfobQMj0FWVWSYg/BNoQf4wl 47IaWFSJfi/sISUlKuwvKfB/hhe2/6HXyKO/vbt0fDXX7Qt5HQZZ2+lXYsjvOgN8liLr9k3Hy6OG R/hBMjsj5Jh8lAY/k2BAOHbEQ33/JtmXI6xHRHRHA8Nwnhvr+W5oDBgDwa3b5PCq5VqvG23qOK3W wb2/6ht8kWeLLPRZXtVkD7Q7vT4cNe8byCqWFDlOVm/ynBF/7LwzkOOdz7ghIuFMgLWGETgVtrxE GCERfbHcJBhcVx22+0E+//2wlelu/IaLogRkfptJdvu8RIxyNxIVyrPZ3K2HdJO2tXcREWEMjoj5 gOR8vEdGeXRdEdEfLswttKSHdLbd2IiIiIiIiIMjiF7YpJ//xEdb7X9Wus4MftpukuiHTJ/2QcYU OUOSc2ntLkGEzm3sm7EREiYy+XCkcUvkfI4KTcdyChzphK1XcREREiRkdEcInVIQZHBuc+7VNCJ4 9riIZHVfsdBhpOIe9a0TdhgqJAFhNypX//GzWCmXQ/10ncGCH3/t5EkYR9EdFqpL1rq3iIiv1rrx 316t+Gkq6T9A+v/lcUQQNdLSb4p1hevhNUq1rhMm5iSwlpfCk3LojguqXsL5N6Bm66QvCZNhcGdJ Ba+ybeB4ZlJaXRAklURRyK5WEQTIaHKc7lDnHPBY5uLHIxzjmguynKHShL7yBRBTkEOU59iRQ4iJ BjynERERERERERIHgXhJBeFkUybrCsRESMgrCHBRIG44kMgFiioEraxHIxxEgwKCQyA2OT4oTQSC WOWYFqHZDIEHO5Q5A8CccgeGpZxzrUJBL71IZ8ERINsEM45KyhyGYrJUIcci+VBG5LD7UBYQLx8I 65HDIBgREM7kLI0SQJP7UTMZBooZHBQRwWS6EUkgRQ6XJvosUIiJwFQj4oKohfZaphaBkDFlt6oQ RqDY+gY3EUFkgG/hPVBJBLaDsJJIEccLeSHcNZjCEQTqgocrlg0KQLKkjMGFZQ4fqslQaVDD9Ig0 rokCBVSBh1DBIhlr1shgV93GQUWUvqJA4HBJGoUj9SbjakMfEwjikNscpyhyhzuUOVxRuXxfEGdc XINcFHi4iR0JIWXT8SuWsjhRERFITyDZ2po7JUVxVcRoQ4iV6I4hKtXw0IiTYFd9syWUWUIk69WM hG9Xuq/+H8dP/D+nLcocH18W++of6luNLb/RkFoaBlD/nYr2mdgsot/hrpu//06+9zP136p/wS/9 V1393vpP6/7hfv/VLHTp9PluKdkZ/+9fH6JD/6X+7f6376pJTINdB3r97p+ZCNBr9e1T1VX/v+9b f/6rT4Z2Up0//70toP/lSnv7uiCHZAtNt+5LUEGgs71Ca/hNtMk7YfqwgohwednQIP23VNtSX5GK O+mqFtaEGEUOK+gocKCENP//oRv6dhBBbe9af/6bYSTv/hb0SPUu+kyNdhBSE7wf20vQIjAQp4pB ndWRwMa6thKTDomPB//qkVYuEGhD8iSRCQ1hhAq0m7fuktV6YIHkNaaBaDYYWrV/1kw0vWlCYW74 p0DDFb7V+y1iaWIIjp+vu9ST0kg2iC5ml9t2/D8SULpL1/XhYRHbgvwreRYyOitekRRk61BOL/kW czBhLtPrphh/aSfIiNAwbyB6e2DwrBEVCtaVIIQg5DZM6daaq4SDaCS1W1TTVV8gxZnlwYDBEmKC OOSdaWqSlSRmxtwvWobqr0rBDCd2nqIioJAiOD0vXSY9a16CcJrWrZSwbVvC/ZZhkdi1+kveE9K9 sF9CsrIKq+F26UUR1X9KRdfgvWk6aqgrCq3hTVcMKgiFHBD9aSI4kDRHGuoL/uCIccP9whIg5X78 kD0WsKRHDS4rSX0CJw5rIjhh60QR31SC0RRwg3mx9cgqQhdtIKuxlDkMscK5EULXSoSgC5H/zwL+ lqqdxDC0S+6VbaQST0IModDwWqr0o94S/WEtA8aDNhsb6vsKvE4i4yPEf69a1RDQOCW4p1pdQQV6 HyGuOE9NxrxDCEegthdLkFxLwX9JBQgr4TaIZjnThben/cJuulSIQp00+kEsJBBA3VPIOeKTw5B3 QT/kQlC6+skWeQxrf6BUC6RBrGrCX20w69NsoGLa2ERX/wvo2vpLJwxhh1JOQIF8lX1eFhEO7+me Cpp+3aWr8EK8KlCTXVHROOgm20lCT/YYIt02QwcwcMoCWkva7BP1sUlstz2eAWK/vCiE13QibQhR wthglDeu/heKoJAg4iIpNfb139tjRQ7iv+DI66YL6YUJvCt7d0gv7UJthf8SKgoYmhW9IWktVyOl qFethBrqqrYh4/UFTVPsRwqf7QYIOwnFcpzDX8JhNj/tJXvBlDZQ4VMJLhk4WvxBkJsaC+2lpv2I zjll4YJ0mGb0gyGwcE1udp4V6DsKFfxERqoiiIBcR7FLVWqe9QjouEDCS0noNDCuuKjCHwt4ZIcL fZZ1UDBUH7C20vEYKGX7lnA2eA93sFSYS+E3Ijnka0pHA8JidUSjMRhK2Eqp2LusViIjwy3FQROx i/Xh/2CI/5BByhzDlhCGWb60mQjcmFpBvsjCyoKn9sIhjYS7BEf6CEafaZIddBhD6+rLcDWHO1Tv 1q0LiPdehX961X//+l/+l/69f69dE3mtavlSWyp1XuSwLf110D2fmlV1T31Wrrw9KvoiP29Sbpen +CJ12pNxtBJ69pDsYQof/kT+iyGqC/I2qyoDUDyh0nVdPJzycDhxp1+f/W09gorSoMKmXDtQ3H36 CY9P7vadL9UthpO2iBgcpz2fihyFNk+uk2k/Ig5GOUbLKa72EpCDpQaERa6vhnHKx7X9tBCP/36r Dj1bXca7f/biq7pNL12vu366w1vXv/hN736+tPrfbvfRJw/qTcmtJx+EHaTfoFpXvp9N/XSb/erf /pv66T/C6V9/p6qlr3f9rr6QaX1qL9Lqv+n0tp9VtVV8VvW9a8tARf7H1yFTIR9SDzcR0XRGBo9N k6wgguJgNQtBRVhIIUIjI4No9qzeYRHBn9FvM4iKuIISB7HLZhgppD4RA8kyCcgyDlJodJkMsctN J7JuNKQRNC1CO/9VLONoswH8fltWr9r/6r07/6V6epHUyqWoe9tKIxv1e0THRXf5NwPLM6JKdX9M twJIO4wnpMQ2miT+qdhOEq3UN9v9dNJa6boiD+odUg2aDSBzQ/C/0QQuEKkcyWSqZLSCBEfLrqmF oIWE3aiIh+m00rSIMRNMIpw+raaqn1RkFIwkIIvEm/T3VmkR0mg/MhZkdAqcYS6sa4JkcpT4PUjM MRHJDkG+pQ/1Ik6SVKhKemShBDzKcXDPK4M2kLIhF0XRdekg3ToWCXJxWrInhCRBy9CbwQJlXFUI P7CdUWOF1SWGkgmdkwYI6BJhZ8PGEEU4EHX6XhKg16+RIUjhVIRLYjhlOIhIw+DvTTrikq2oK/pk xkdIFiGRYIQcIECBDTr+ly6BXqqO90gmEyEEhY0KBAha+l6VIUKiiTQThJNqoT8EEeUSFHKdJ+r/ +Q9ohAXpZQ6ChU9FOk0Rf0v7S65nqIRB5ukI05BQIxSoKKvVfXoU0kCr8N4QWECJjhL3Rh4S01RO 8IEVAJB0iC48IhHhh4SLoLCOaO7Xpf++GCqJMcK+ngmythsLrCCQtXQwtX8Jbri0S6I4UIQzYhgI qBWEmUOgxpxSl0EIVQ6W4S90oZIRHQKxHuk9Rh30IvhWu6qyQ70QzjiIVB6pUE53CI4JpL3vwk7Z Hy8F9iwinIKEU0qhY3qbQIpyMelX8JaERSYJHWDGgg/XandAvaFsb8OrEJJtvOZHQIFJjkGMQ6Wk 2H0I0rjrTBaERhiQjgpBBwmHSqoPyDQPhV4QaqQrnHlIiOSCxSQXn0Rwj6IMQShkcC6BemELBMRI NxqIpEdBhdUhklvZCz2bDkdF21e0EDLHCcZE3gS5gQuOgXhQ4KRXQug/pCIZBeAoSVIRqrwmEIir ZCl+qaFVkNg+ygEWEwWw0/GGmccKthOhVCOEGvLOL5Bo8iPkciXC4Mw5WoVJVyMcpwmmw66CmgM8 w7ERrhXEY0/vMAecVVQWwsNvWJBadS4inCdJMiERx9ZDKHOOeh4KHKHIJ7rSDO4JWsYJbUhNFTZe QRHSsoc7lUKuQitNRFsMLHrJAaERxSEIIjofLor15Iz6zXnEoZC7G9ehEXHoRccRdn2UIiEYRH4X pehDKK44iI/6x3vb/qWcGtV2u409foyJyXV/Ttf9U7Hy39P3rO6qK/1Ff//Xx7d2/2FTciU36/+s yG19fSH+f/7V2n/v5ED0tL032t/D6WzP6kx3/Qp7SDetXVdvpa5VhXbX+TcbTnpFvr8tylJZQ7Qe mEuH9CXS41WwgvC9ClcLuEqYrEtytAih9U+0utCK67pOwqrS7aVMF1/YoRsjhwYV135BRB0yOq9V EiJhb+nuQ2xzpgKDf/EjTBWq6ZHXIE7lJgUetRM0pIBkr7DGiXDa6SSuRQDGvk35LFvVW1GwRHVV UPofhJv9b/+1DfutW+0l1ft+vrWFD/nH6VfoMLx/i6/FWvt/8GF6x9/1fX27XsJupZxJLWh0/yDd M63mEQQNbWJEgUuCFU5A8M6ZJuyB6HMORUyBpFlUIliZBkcuyuCCZcZPk3NO4jJWUOUOU5AgWiTc nFIkz6MlarQiIpY2KRXTot9VevxG6h30xuLWtOF+hSst1tFvyvomPTT+lw1r7wa/S0HXLSHXXqVF x+4dJ2tKml/7pJe9ciSa+vVpilnY33LcDWl9OE+JZgndKvrChB6peqZE1cL60rpAg+F9LLcyT6CT qF/FP1XrahBesLuEQj+guvwugn4hb6Ce6CX/vvhBVpGQIiPaTSv0ukEhZSmvDwfpdhIyLA4RCbBP pDVBJYQQUF/q6C8EEqIZ9lK9TsW/pYQR3VKEGvudjYtaXMwYIiKjVSrWad+RzLpI7UAR0FVBVsJ6 aZgUls5HMySkqESW8neoZdUlwiCRVQsjvyFtrkoUSCiRS8hAzVKWCtepCy0YQVXgkgga0CIaI4ew Qs7q2sjA0si6I6I5kcFjlkA5pOIWuEoQ8IdfU5YJkE1Iwy4Hg9xFOC10vhZUL1x5BogEeQIhYM4i qqZTDGFwgkiOuggS3SnXT0QUDGdETowGQJdMEFSpIEo6wukFhMl16BHMxm0hEQXzI1QRBxldKukl op+SH4TCZF5SOjGRwIPhkilx1REyEKsIiD+CrVBfjJjlwUOaD7EBhVOgLYbl8joJ9EjztbQXS+F9 ILs0y6TxEROwwXCoSGSBwMXQWEJBH4S+l+lofoIRIZIFYkr+EC8JdJa6Xi/ILZjkGILcJLoJJEEp 0tap+l/kMkFo5CasLSS19BL30kkkq8hkhOIMOSsqCVQQTS3pFRSLrwl+sP/XkMgNQcgoHKc4ZC0j pJoK9aaC4qq69LquQPBpHIMsGsEZo2j5sEMKqhKiKOuKSwXWnd0tJKtSB4KDk05ICiNBaXWRR8VV U64Wc+HkCr+kvkGcMupfFJL0ENBdJa4WtsHv0l6ShkDgRf60l+C9Y9KF7yoFh/peDKcgYHIJa19U ER1VJa9V6itg6CWvBrWIZFmIX1VViFukq6S8KqD4JLuS9ar0/S/SVJLJv9JBW4KmoeC62dREGlVV XDC+lQQXqDKHBJdJAsap7LovpNUiFcodBsKt1C8zCf66VCP0l6EN2KlwI9iKbCTQKsJKNV0kF+cX sJLwgeIhL1GqX57qtVSrxrSSJj+iJl0/tV1CwQX9YS6U2gRTvhL8Y4KuEDTTXCtLJCv0kvsSk0n4 Sgvaa6ZAhQELSVIbCHp8IJLMJsKPVIX6hUk01XVBpetJ8KwZDRzBBXWttlDhSDBjhgg0KVVBVtUl ocREJ7peNMKspEDC4UIH8UK9kM3X5hYLBlDhHYtDiNDCIovhNVCviGEos+wopUC1HahDQYJ9C0Ii l4dBUDIYJ4braSGSJAgZcFAbhSzigZyIRGmJXIWL4OI/CGdAbj+N7jSaV/0L+oYpfk0FOQU3LZSs rcyisrUo3La7cSnRHZHB8Ts1QiJ2Jo7xGUIgiWtYiOR0IiPV+khHHX+//f+tL//3+te8PXJQsSud X06Gukfu/dX9U/9dftevX3//npV6XZ1v/6fSl1+wS//2Er8btul117S+9egquq7r121iFv0qafS9 0N33p/StD/X3r/v1p/e6+iMd/6b9qrfp6Yf1Sfr9/8N/0m/0r/6f9//p/xj/y0Zerh+Tdd1ocm5d Q/1cHrtW/+RSb/6bD364NFoF1q8m8/TaLQJhfXriWgCDP09tU17UHrgvW9GHyx5ZStJ3cpQO9Oli FqgZHRGw07X8m4a/EXFe4RGbFyDETqvtWl2drCkOeUC9ybwv8m+rtEXWvZA8hyjf2k+kHTlp99kG c31FKl+KhdlnCkR2cIwzkGm9U8JesRCKrPQo3FahTidV+IQQkdGGJtCsYnZSjtOiPdBBTX4iIvQn kVhCGypKGQJLj0tIRFOhzI1RrQQRHz6MJzWjy/S9CISERxHbYSusJZJsjxHuWaWIySlSuukkCEd1 HCBP0nmsNlIswNjYS/h5IAx08Euu0jMMv+EtMJXmwzOuFtJtYgqp4Ig49SgTwzZQK6ThBVFkrRVp JRf0uEFnSOxZHa0rTCZGJKg3IFxym6WtRBen9psoStvCHpVprglp2lmQ3JMgwbX1C1VTMNJtb9A+ QQ2nwgQLUlwj8LtuuwRTplDkzYPom6qC6pAgwmRVchlqdXXwhiPom6kGfCnUNmRiBPRAgc63W0tM rSC9hE3LAMa2yh9hMjS2EOiN3DrtBhKo1SgmlpprhlDlOC6dtSr+QVAYheQzj8KumqeZrEfS78qW czxHEp2URIyOZHA8GXULiQzuQ0oKJEQ/CdoPpv77KRmwPMjg5cFBiOZwUuRHCGAyAUEczmR4jj5Z mp3nERwPBQXI99eYSrepzQhmeEQIHKmkjrlwMw2jC4ViIiJC2ZDHCD9fIIj+XRHJCIiIhkYgphEd EcDQEqEybi4ZAKCOGCOjCLhQiHeNp2ptFRlwwRwNgZpHV+IiIjI6Na82zGbRHAlfU9sYoJCIiQJQ MNx08UQyQL8bhd0mIkFsCgchkA0Dmcg8HHIYHIIOQ+pXlDkx3SYUgV2VxJyiDQYcgaASDhI8Hwhk IcvAQiInBUEIidER0RwPDbvLNwUgqTCI6FoREkI8BpkfI+bQiJGIuZ4GgwzAhhGEXzZl0bzaLoxi LFCJJ5HA8McWSg8Fp9Dia0RyI4ZIaRHBrI+R0fGXRHyOB4cREXkMrVCIiIiItCZo4jgLVWEPWoiU 4YI4ZAKpJx4i6I5CLBCJmRsFyODSeNwoShCJDyODLx2ugZHMocgeHHIH45Q5Y5RZpoJ8sdHQCHVE F/0S5tCdAQwGeqj5B1CyEOQUxwgZxyRyIQT33SpYqtuCc+kgThCD3vsL0ahlxkcFAi2cBO/cFYUL oIE2KQJ499zqJ055Moc7kIOo6dJBKq1fC6ChP/DNA+qiIhrr9Kgk0k8U9AmYS0vsjgR1rT/S4LTB aVJAop8swY3uK6Wuv0sEEGq2EuZhnI5IivuC8Nrqva7QqKGugrRhEcG7YSb6bTtVV1QYUJagmccL aWIgg6V9RDsgvvrwSiGChvwhHwkEuE31DQYWlVAyknphdLBYL9RHGsfqF0CCgrpu9UuLoEwlBLhN IJusJoajDCagiOggmCUK3wgh0hWEISZCE6Cf0rXDKAwGWB0m+lXyI6FUm/BfxC0vwt1DWgm+P8FQ S/6Vahv/hhJoKvVJAyJt1TdfoVSq+69da1pBdx6VJ/rX/SqmvhJVHuEv3pKlrBUoX0qflmCFhJR2 WYOGacRZf87GgxXLOCIjgb+gvhCGSAg6CCV0PDI5CetYZUhdeQzYMOU54WP5blWcqIMOFYS8IRBk J8shav+ONL/0F72kuuKXfXqklfdKtX38Jf0vlLWl8rI9L5K2E9BV9VSvpK6MOqf3p2t3wa+sz8f4 pL71/kjun+nhV/dJf3OmR109/CH2tfS7/67b/sJXDX9pYf+6CUG++6Tu9Xj3/bCa/10uR1XaFK/w gte3C3zKi00q691/04Xx7a7KH6JDhhq6HpONf4f62/Wgn9rsNb2od/03+t/Xv9Vf9b+/Hqtf19Fu nVBrre18cf63V61/7qpaC3/p1/O1tZQ/9PH6r2oPUyNf53AYLIsO8iNfBkUBVtbT/Gdk0npQ8r8v pFvNEGlOy6J0mSH2mVxwx2hETsQjUk8do6ojERC7c4kD7BCKQ0IiPeIKRpH/hFWQPN1zPW1CiJCl xBkNKyoPMpyz5MevjSIQczoJ8sw1QiIrt/6I9KfHS6/hJEoadUnrVdJSKChPuErWvQQQQVO0HJuk Er38JBBAt1EEHvS0uEECCRJ3wT1v2khCChfRQ8p1/roJBJN3CE47GtL7wiEUk30yPHjX/VIILDdQ kNFQv9aVJJegsS90/XSCSbuggoX069JAhepZphIKuvXdJBN8UlfWtVwk/pwRh6/W6SV8JIER+M6X R2IUX+gv1Tcp4XUcrK6SVvSioIFqn+mVfTel3hKI69FOFCV+qpN9c0WuiK7zX6akVyJojpaSKi6p KIUKR0XReJ0bBXKqgv1YQcaqQiq774QMEIiI2UQlIz1wQYK5TqiHkcHSTfpBTQQIbKp16CphaOou Zg3SbIT65ToIRkLBpu9SEBcKlYQebDKqwT7hCKJYGpt+RgaMJYT12wV6lrAuXDIDUC7qFBJVeyMi kSqk2ldwQ116QWgsJqE9awSe5XChCOlBEDA5McqF/qoS7BU6kIGlbCC4UrlgLohkAQOdyPCrCRY4 IEpVFTqkklCVVXGkmwgvyKOQRpFJA8Noc8FWcchXIu8Ehxyq+nWEQ45Q6SSdEEHg0v+gXqzwQgTR TkDwai70QhP61QtaWgTap6SsQm7sMzFCcSCyOUghiEETH1BLuuECTQSWgT0q+1XDBsMJMgbnKoqQ 9BLrWwSQSpQkH0SH3pMK6YYM+QKiBA5IcpyC+QlC0Ka/WklIgNCT0aL19ektMNkQ4KRcCiIWgj3V SGB6gvhLwkagUVFD6Tt9BX3EVCBFDuqS0lMJELY6OqW3VOgsF16XdKvoMIGxYTCvFgog4JJK0RR/ YS1BahV4SpvpNdgwhFBUoZWhBjAk+kn4+LDS62E04fhEUd/BprL1DIrnHDYQT8Evr5Q+qrBJ4eoS DfwyGa0hUFEcIEInfgiCD3ZxwlqvEnPoLgglZBefCCb9Fu8RwYYVMQhivWrhtcgw99pJsuDGx0Er +IZscFSBU3cbtJQYarIx2krEE7ekG/psMMFRFya4hZdJNNQW2Cw2EklhpUEw1qkHGELC2vdhcE9m gWDVJhYfCV/q+E6BRjBNBn0wZHDDdJUp2VBgutBBh+1DbCYKgwWNDxVtBJgsR0E3Wlb4XCaq2mxC Upywa0nSvViItbtU6iin7SCa+uyhyFVoU4VlaQQQj3T/psT6Pqt9NL0EGq3uIvgyPiCDpwk/Qrqy 6sWxYpQQS216sXvYYJK4pbvsqYcjnFdpdsjpWmU4gqX/F0qSIu7BPaC7ZgO4hhVTDXseNKw6000Z TdSBGz9gwRN9E0Nulot9Qgik1Wx2El8yqJekKXLOCrS2W+Gmd3mFhK45xGMuGgqEXDHVYaERFnad EdUl4oRLIoRX0RA0VhJggrSIHn0REdfXQQXkC45UHHIZmq0FbkMKChy+KCUgYVFDotxFIm344y3s 7gr+rhqvaZ5a66cftrap9Le3f6XakktL/6fW/39tXkWS9e/TrT/fZuXq9v/9V/XXLOULh6/X/7+1 1isL+Z5rlS9KH/tdQRB6S0wfwrr66Hgg17aXYS/ZxyEmrxWqCI6QrFiqtdhRlj8Pet1/RQ5Q65bo E7QSs1kQdYjXGnSoQwQ4P+PrLTFRblui4UJeCpWrCHUd7hrfVql9fTr2VxTI/et/BC31/gvp6XBL 0Ru69IFek3XwS+n/oF4XH4JWCKfV+0QoXHSbXyGwcqZRyoOOccrOk36DEREREgyGwXS/g3G3XK4m B4ZcLy0iFyulAf12PLfQUjZK2l6qn+tV1vr/9UH60OPa0Ev9/119Yfrr/6wX+TMPXySho0uStEcM 22+RsG0m4J1zssWQgKXbwghz6MAzVqgrSGNtUEMgsDlDlDsiSpYyConQk35EeIsjnfkMoVQwhQRb 6KqCOxdMgQCIIITCEe4k26Em4ojHa8RLIMSikEEdpTzjvQRHQi0XsZa4aEREeP5ZlfoE+F2npd/S 6Xr1eFVLtFrBfsRtV9yzNXwXheE6qW0qr0W5YkH4QhvUId5bli7BDx/LUELQlcWW0+1xvyzEDqvy 0kLpj0uWcta6eFy3NcUthMiOuCDOg/pugvds6aT9wxvfW393/vvV/wrLUu00/elT7uWQYC4crp1T fJvqDWUgF7T/ghtp1tQiB4aGQp5bltdh0CIHgw9Vvsg/5BB1k3J/3wyDA9AgZArdIMuofkNfDFQi MRIzYyOCWwhO3VkK7UTsDPO8zCtPQiIoKh3zsNHdojb0HoQ+DUzxVxoRuu4dQYS736oPT5b1Cark KWUi3T74/uriklf9p185/3sL6vukvoi32C7+3jrtXcFx/TI9/TdOVySr3tLvhbxK5jW30W4i2ut3 s7q19ZWA/DtLWnfT1qV0vL+Fwn/qt19XQtyVHfeurpZ2LK7O0pL1O0muq/1brthB/9XWHtIiwcda T3r+nSa96rBFP4RHQj//+nfa/EOKpKJuwtnSqtV1SSC107faC/oNf6/w/6Yf2v6+ZjSa9LX/ZFdu yJvbvC6fpuvaWkv1Ctl/Xj179M7W4oS+sLp17wmJGOc3ESRJO1rhO/QiHkTL/1/jEH2C2GtEQf/h OHoP61/6D7CC/30RB3rkubDVOtUksJl77+lbWF/brRCDtB/aa152B+hIh+g+2lT8LdLvQWmQRBkN upW6lKvKH3yGXG2D9qqeEm9J6jVMS5MocpwXapAg0sJpMPjqyO1toJ/S721S0yUBgRBmc0HI5poi u6UJ+g9h69hi+EF+q63wtMg8EGIi6mxGvSCeoTVg3fvsVd6C+F/2p8MpcE6b1906ZCVwe7e1+l6v 1psMEcd8Wt4STqk5DRsmHcuhCxNfVu2FVa9pN9a8f6tpGgObSQRAjb05DK2DD8cLph/voKzcxV9e xINx37qhQIQ81BlqoQMG/UE++mNa4Tp+tEY9kCEfjrSQPRBx2a0gzshsP6X3relF9rSXwV6dUnSe gmwTTCb/YXbeg2tILTevigXyC90tBwrQhOCaaYf6C69OFSBkcMrbquqrRBJtYXBPtptpt/p9vkbt q0KrTr61diCSRBOChO1+ER6f1qW/Bn0g2P09VuEl4LCCgpwNSoIIOT9JcORNTud1T/hSn7lcyMF0 mHwnvpbrqmCBJBXiDBCNYVxEQl3qEQ8IIiLmqoXq9QRT26XyE8ydLtBhGEEFV9UrJjlD6hf6WF7u gm02Qai7q/2Lqumhrt9BJiO6X8VrqSHXt1Io6vb1S6X2wSq296bX30CUE7dFAdQk+zCO9pPt1W0G QmQkt2qS/S91gn9+m7HVp1qgwl8RtaynV8JUtIJfWEvvpP97G0oME0v/i/pWlpXSX/+rrVr8mD6W 5DxdSGrqlrSX4Vft8K96QuNC1C20CyQE1b2gkuoJNXWt9vhdbtU97bJnYRN5mgiBDo0bel/QST6V qu/vvh+FVWLhJCI0m6oEus8iODvoLDIIvn/6+1i04by4VhbahhJepHDP9cmuHu/Q6sIMLGtimEwb eJ8F14r666p7+HFzutuHphQ287IReLhsYfC9pf2+O4i9W0yhwTHxEF8LIjpql+6+ItQQyC4E9hJL CwuPf7fcWmF1XUg4FIYv+3+mhEPcKuRBOC+3r/F2mccJrHBbWH1pcNBoQynKHC7sJVTe/1aERFph 4QXd9u/LIa5N1uHiE9MHa63y3ohYXSw+2tLYjCHet1fQQJ26ZXQmGpNw9LpAkg99ivBRLc6CQcPc Q1GVkNmgQtaBrJYGnpDsGCoiYKpZXxCCMhnUYZ0zgFClfEvzaMlmOyFEY6IQelcUELigv4yB5DlX LMoggn+iBRB0Q0XSpKt5LCGVZRREsoxOR8ytGarGudcj40IiIlchIF3cREUrMq4yhfLIZppxHuKX XS+Gq+WcXQ18a7j1/zsFWWgmq8p4/0imBK4xv8thaVLxGuWusL4nYLrUthbQmQGquWuSoRWrO3IK ZFhVSC1D0d38KoiI8tck7v1qpZoGvCG8OtezJbXxK4tmEV1VctcaRdZCZSLEj49CDURoalriAXzI bV8EFlTQj2EwiOh7IyYzvTqEeAUIk0N6FlK3xX0WqWdDy3w87qx2CZHi+IleHcIRl5rSFjtMs2f2 RX16JxBrgwi0ifXFb4+/XYfb/31dW+3b9Bv2Wk69+7LNE0NWxMjVaBFOxuV1sC5NyeWpahW1O+S2 yuqIGpGOQjkxyQ5ISYk07idAwSpRERIMYVVWdlKy3DxK5SoiGW5QjiLIJXGhHK5KhEqEdzRBo7W9 bqkInVCImXqy/d8RxysozXkY5XHenQiTe1eEImrNERwaSyVvsYWhE8ZHAhTslR2lf2yuS7iUZhk2 7CKHaapVfx37/6SriPfqTcpV7bXu6cayDm5R7W0kuyGc3EuTaeutqWU16hh+K77d3BlWDp5Id60o XiaB8qSI7ybTTXf6dQ3ZFMEINMSU6uvT929MwDDX+q4WraWE8Xvd/u/Fa/6pd9fatV778hYK8L7T b6Xr4hBDddJevXhINdb9UqluOGfQS5bjSvSf64SLcqVYT9akh9vrpK7oFaF+PS+jjtrqy4YulKla +tjLeworHS6dOmdqSyuJ9aB/9JZMernQx9dv1f/9J5OJaX8iK/bVD001VP9w7pdLfpaCyEb09uGs gvH1QSlWjz9PTta2gwlIg5U+WSF60JcISx/4QaDMiyru2sEPk3MwnVWCYJ+p3qE1TMhYWoO31rRN 1oGiinVAmn9ndAxp2ZDQIfReI6LyUJ6DSftSRLeFJdBfUjSI5kdhLTKRGOyBR26KwDBcNhqXfk3a 16X5E1gnYJ+mCEQ1jQkpCTTIGgTBCygfXdiunBFD1STJNEcM6qFIwGNVCeEDJcegZL4QZHYIMq1h Uta0Gvir8ENbwXRCvCdyGi4TTIV2mR44gQiHBmoVW6/4+CKHII5TrIarBV1XS1RC2UOkFKHqmRtB PQyPspzj0wQNMJ1wuGq4kQOoTXVdQuuCCI6hIVCHVNO5F+kgYYNQnIMRXqEt9YRGD/wSVQiC49Vh cIUlrXwtBtDT9LCkSaUOW7hjBqER1oKqtdQvIX9YXRBxzAQTOtqwTVVdJAgoVNAiOqwn6K5mGd1b elVUlCIKHXcI2tap0rUL/d3twr1hDIpyx1hV2EQYNwLYwlWv0QwhBBIUKrpaIXuEkECKfqq1giGc dNohXUgg9gsR0KvCVOGkF6XglkMsIqkEHx6QToIKh1TtN8zSFLCEIKmugXlc0ZHVXwl9KkFohoHK MBJyJelQScQqX9fiQ4whxzDnHpQgmtqlUR06SX1VhBKRHCGEkmtcIL6TpJL2FcRPGlBfqF/3rSpa CWEDSfHT4JpJLWumpHAuGukO20lvojcPoIiD11ugVRJgGEuqQ22lr10PTS7vXdpX4SS2qrC0EUOu 6XTSpBSTqr5BuOlWkm4eteg3VBL0wqByEjQQpfuGCeFkM4hOhIg/LhrIIKq7etqqbtQlfpOx0RsC /wqsoDLqpKzuUQX/CvEgXtKFrYYdL7avtAk/GgsEcciDlcVMpwlkNA9eDCIUd0uqkcULDRQ6rkMu lQlVAindvIEQvq32eQQXtUyBcfUQYQUkOK9utEFA4suDHSERFRH6BJUC8kOkm25DO58LHKH/Lej0 n4YIQu4XWMREg3fVdbCaDdBKpDYITaBVlw0LVAobdiIil4IOt+Kh01TXUKj2R0GCdq6hO0rUMjsj 5wIRw+gVRXYaqnSe2CxT9e1sLYLkIPFhWlwTIEa+kCQii4ZWyI9dIFDBJNt0/TqutWhJcLwoUUQ9 usNMIjoNlawk3HpNe8ggR29JdPHp/GmQaalCI6H6kTVDaYSprSBUkEp0DYdPD7CWq1wXsKwwQyMd C3WS6DBB6SpkNSF/1ZtGAzSOEhvs0IPe62qtrDKHIg5NSFPqJVoMoeoIJggZY5DPqE3FbURFyCPM 0rEhlOCWqIr5Y6wwTWLiDOlBO1iPpBkQcwsVNV0sFIZbhRmwYZBQdfq98m6xtPiwrHM0FjBoRHfp BPWoZGOU5xbdJ8cRpJhMLI5CFoaVhUwoKEyKPxEX//4ihDBYSXSsFQajqUOp2hXTf5MvcqYwWmE2 wVEVRHQNMocEGqjj1rv3IUlHCV2CoRoWtljljhPVBP4i6TVUg4WwQYIqAcGMauGG/7VMJ21XEGEL XQafuGCaggwrfDJNyew0tWhaDKkXa41h/jCHcPbDH4ZEHMuYapaaJvqdkrRsZ5ZaRaiOhZx1Uo2K 1BoIREXiIax5b+NtybjaLJND8axOy1EhFcDQvd2hESuSpMy0WsRxqHOzJVDZZygORwyy8R8jg49Q RTIVFM013Eflvqi0yb62ZKqeu9jdpnkqb23aXt/UMa23/+mWkFJf38tzUDFVcJCtQgi1Cv9oF1qQ nlNIaKkMrRh+I9Y2y0zCI667Yj/bLTGIqa+2Gy0yEIpVScRG7DLT1XYMtP/OxT2VxNkdFwzkcF6E qFXCERBiR0IlWsINspuQU0iSGVxeI6LhqsrYsU1UmImsG4SCCHlvwVRuNe6pHYsq930vj87LrtlV Q3oTsHctyH1UrrLBBuPCaY9b6r9Ebstii9ePtW++5a5qt9WPr9ZH/t1/W/fvSVytfs93j26Slpiv 31r6EVqQpesm4gKR8wibmSxtA6ghEgg5RuFSW10wYWVx0hIg5bJrXlua9cSHZO/HFEHHILA5RuS+ ZGnZbjwWXSDKcSY5CG5QnuHfzeIgyhyhyrF9RCQsJMSOi6MK1BFOUOVD1mU96oREjoRERKERwbS3 EkR0t30sRJAKCOiPhBCJHRHyNo7To33RKEZUzaIsorTnfEFEREREaxEECESbcuKTj5QhEyDXf9lN bXT/H/f+v9dZbha734QfT/S/+t3Kkv1LKFL5BB+qrSVP/zskXe7XCCwQP6tbm0TxdIKwgv6uCERk eO1hVoP3ep4NQOg0FhfUjHumCBCEHqvskaWUBYkGnZoGkVzCpLfsLBSbi4NgQemqWqsVCRNxrI4b ZOapXdXvOsmCk3VgrhNP6Spu2nGTdODaR0R0YNbStZFlTXwmTegMgi4TOxZJ5OH3S06epN4BkI61 TRFHOPzgEKvr0smywCwKraCENKRwb5NnzY9KZAi8NpJSDJmkRR/COjjsIRVRtfTRDaI6TtpZCxSC MJ6pad1TkMtJVBeobBBqCXnFW7bSkF3IQfSRQunIPaoSUAQFXx/6wVVIZxyhuOlohN89NQiDXviL smSSS3ULa/aUKsm7ofSwgbakCRHwqCRDMUHCwwTaK88jojx96DS9OkwmsECH0tOsqwcJBJEC6sNB gnoREiDlLDh1XukEwRhYpaWt0S4KFQSIaAIGEztAEAih0heUWRRGBmER1XuNhCt9Ja0kddNEE+kg RMBns7zCXkXFzXG9QQOyry5IRY6ppFGNqkkiLfVBpoiEBJQlQYISCCUjeCYVD02Yc9ljhBXbIzJP veNeuEPqNBBUFP8KQLUIhgVIO5QMUdiZ6DdMREGEEIwo76tesL8g49JH0OXCF1CawiNBmAinRFsr AMGOk1VIIIj/y3KBdp+PqOOFQLWoQk5pAkHEiFIZMDjkQVunCRQ5AwONdD/UJJqqVIwl+lGRigZ8 HNwJgg1RIo66ETuCyntukktdboIVCrgoQVWlkmGAqdIhIarQSFcnP9v101VJqukix6Cg0CyDDQtr CD6eiGi0mqf/1VFjnHCWklRnQTVhAgTTSEEoKC9QrQ1QIugWlCddBrRDVUrsrdeER1WlYXYLpKF6 1VPfIPw0E0F/2v9CLSJwRB4qEKpGfUuhRhVbIMIKcLBVZD+UOF/IYykgQWrT+vjVaqZqWOCyGDqF 9RQSUg40ekTwRUQzvVBCKq3CMJ3VJaC316Vd7ERwgXBfhKkQ2CuEqCwr19DqgQLqF1ck7wRT61Vh mpHAheI4MYQUPVBKweqwvfXp+CBUkP0k/pa1SDJwhHBo0m+wklD6CSCwUNdOl6hKuq9uPVeyDuy4 Zmkw9hpcHSQWCVJ+tK9QqX3V/9eI8ECGGqDIMa2sJJEVwtpbS4XoVrbLfQXr0q9WtO+wlV9BKElo Fv9JfUgvekCa/6pdSDQPNpUCYdMhjkoPqC0NJU2kqXpE7XfZXMkE9Ida74TIaB4+3xVHYsGfSC3w uyBH/00ElQLuCanZFuaLqk/YJkHHBcU+wlOy0P4SvgrTS1pdKFddVCYIPx/ourNT2QIDBDwvgkjt TGlRHBv8gg3bJcJX5tVQS69VIjwgy3WF18KOLwZxyMuWH32sN8aDWTFDXbCC1poEEPIF4YQXC+mg m1GvSH6ER+6DST8g3fD6QRH7kOOTcFrS2tUEFwkvr3/1VcEjukwyBBdfWUGRwukRsh2I3Wo+Qzzk cWoXtJJ7x2FVDpJB6IoHztIarC0E2C5SBH9LS6jprvVbfik/rWyhyoKJqEC0gsEmyOD/tphRqpBA 1TXVP7Uj/TXqFoRFUgS2lMDirIwMbCdatphNffX4/YJKsJVWdECSyHIp9keBBbVqHoaEVq2lt/CY XSFOkiGHFbUUGosILaiglwv9JBbKzEcGCOMWQsklqh26oYTyGBwsMgu4LaQV/itIt1NSC9QixxSq K6DUQsND1DpdPWLFdVCqg7BUdvl1Q9NbaSDa9cErTtYi+/VhbTk2q7hMIMFwiBiQumgwq+Y1eF0w QnZX1CBoMLaEU7QYIaB5A4HIxzDoaEdrBkOTsL2NCW6qpblDmsw5hyChxM4sjoj5HRciOyPl0fWI 4Mswce1V0hERoOz2U5xzDlYVWEIjCGhI6Gy3VFihUpwr+IiIiIjRhCJZBNHZWky6OiJCOIrgSJ0P 4r4IRE7AkLWIiVwiEuhOxiOiOizyI6f+IqIiIjiNFYQvCtKGEJkaog0troGhFrZb+iyUXi1SQYJr /bJupoLpD0GKe9t1/trmRqupXS+11W5XWBLhUP0+v0twv6vXVV2l73jXWSH/3jfSq6nfl3/O4DZ9 WkkQyzYaOzkmr2R0FZBoNlYf9iKgwvXDCDBkdZNyQ6XhpkWYtQl92CbJAEYQL+yLsuzqC+wX1O1l ME5GAlDS8RYYN11fBuv02GybTX9w2Kr9ulq23+yulPDZaimutJtvpd4ZgEtu+txBvw6WkiGvse2W ko7WvIKy3ybXDpd4PcLFJVgyWAu4TddSGjgyKBssLBV0StkgG4JPj7w2RAOEsKusNkIERDYVOmqf h5a3SG+2gmF0WUoVVcKLoIdegVUWRUU7KlfwQwSca2xH967d69rZNxJ+6qRWcLd106vSr4YS/sfB 6aOzmkiGxnF22CO7DP0R/g0SkiGiOGXoVUMKIy0rVNaFomyjI4hH01rhgibVmRwbkfI6vDIIOC2G QMGwEIiDWibluCQ8tzJG0dEEQVRhZuSVESbJPTKiJxE205AkHJjvwT4iJ2qpNCL9eMZEJdLlvUpA iCvK88SOhJss5AlQIp5NyTQV4ciiyFzwy+MIuhSK0i3oky3JOu3RKwyxiIkMPxVNL+VXLkYaGbxU rkSrTQZS/EaiQknJtwPrWuHBEdaDQaQXWm2sa4Qa6VaK62fq3CL+uQ1rtb3pkD0OhSpIf0p0QVbT kCccEJdoJdKvnMjgvwWGQ45TkY5DjoQTS116ghCoK0IjLGVRG3Gl/eKUHuqTpa6uwWl9KQLOw9Ja +sFt6qFBO6OxGq6+/60gg9U6/uiUB2v6prS66wuaAm/6Ij0/JQKpGJL6+/trStraRG0RwwoU7QlZ Q63vhu8i0df00Co1hofCGQLVNPMi1BC/rh5BDZG0+sLqlVIagtAn62tth7af0kqsZrzMG6qQJEca 0of9/DX9VSpVTCaqCEGjjpQv+m9kG7c0t3+l1UYVU69f924byRf1SC66wkCQIIdJfS/hvzWiOm7/ SwappEKOlCipMDIWsJf+HYa2wgovfWK5DjqqSTVPCZKQ9EbiOoedpwMKS5dukePoQu82dJLJRhaB EdK0FSJdZIwnIMdKQEKRJ7GE+GDwyvCu1TZx8Q8x1whHoYWktpXYIOgmE0RjhYbWFvEX0nLmOkq1 S7BKqIg6kEuNKFh4XKqq1OxIGkLDsUlpIUl/WlQZB3CrS0RDtUk0GRySsoGXRIDQk3g0iMd1dt1T wl9brJ+hWwkqJaa00MK5cFNV5LRQnu0d0VWlSkdBL6NFp9DCiFrXpoi3UJBJK38L8MK9tJYiF8IS Okr9eoWlyI9AiQGxequjutfS6LfgjduqSWqj3pJUqS6hAg8IpwYWKp09JJLqJ28cxq0F0h1nOH3C rsnDr1qQYIkgktx3XvEGR/4SCSqoqQX2QlKdF/hJYLWgm6DVSDKOUCX9UshBaldZkL2Okqaq9soo 0ER+uwVVSpKEgkhq/0sEQXbq37T/oeHyE4U1VXH0r6VSCoSb/SUIOFTvagi66p1Q1ZUwrSPJKKbS WpE8ijknKHKsEgn8wkkqRAw3Gay3f0LId+l1SXUh8Kthar+Qg5huIiI7rrhLRFO++2CKjTCgg0tN cJxqGEEIcJKr6SIylL8ekqBAt13H4KEpNyfTOOgfapgsZAiBC61CwvvIRVoKkOt4fUWE/QjCUNII bkHHVJIJcL69GrI5Kqqlvtr2sWE7UFsEwh/oNnUGFS3UIdOgqQWq2FqOJ3VKwhZQ5acFSpOgzeEQ 4+0sJZoGKSCSsg3bk+1b7UcjY2gYLqFoRVWRFuC5wCKwlojblf7er4iLCWlfQZIFpSPFwxkcNFRV V62/6rYJ6wxWhFRCev37aokO7oUhqlQSClDoJCgku19/l11VME1XvTXd730mPrapWFQ0goVN17/e hxZBgNrwggmEsM2v+/eTdWmCDqwVVCHDEiNyeVwWo1Cv9P4gyQhUlCRDOOF3cIQzCI4MQ6LdLWvi IVkEA1BQhoN+IthhRum9hPQYSBbCoofTFU+mJA0YxGswxxgwXe7iMijhR8GEGv6YIEOFwZB9iCFN uu6aCba8j2BBcJ3a2F8VxUsgL7Q+8dRCd6fqUPqkuL296Sr9velOC91p5h1mBvbUmVxxD9Vapl0T oujaPI9nEbRdBP4aT9lOVkWUDEfxb2IsRIeYBr/IU2F0DIGHMOKvhhkCTQYiu2yGFANqQPoBOVyl VLfxshnrYgwQ42gTBjJsrBXI7I6+mDTKHINEHDj1QZCwahDKchBzjlNYtCtojHYMI7DQiIkhDUrq qw5WsjhxEsk1oJ04iN0lvd7ZaYhf8de+ER/3x/dK0nhu9TuFCVVw/a5CjkYDUvb9EF8DLc0RZQNf WoxHd0FDZZiktNpBIikDV9ikECYML/MKhkCh20KY0CI6aXFhq7jWnu9QYW2tL0t1ahV+leq18jR+ gQPiiC7WNTtJKwgx8k79Hwpahj+DZafIJ1sN66dof20t7H7/b/fVv7DWrZaY67ti3SYMtJL/RHQL TDsodgovQsK52MWgkDCBEI0kvRCNYchhpLPCkM7SVXtg6lcUYbBvYQbDLWDHaQbZHx8G4k2BWfyO MjoshSVIMgvsSDJsRERkfI4aZQk9gyDGwN5oBwKfBg27MAei8vZDRtWHEdcMgX2GHokP0GDI6IZp sgqQVmrps44kb3kDA5xuvxncYakEHKUvfzwNYPIiWVDSa7ZQGULLHCF+9BlBhKP/Z6wn0qyh7DHv TKXW28pQ/aTpDZLF/rbK6zkf0DT9eo26e/S2g32n//7+lqFDOble3ybCX0t3Lr+wv5JCuVytRbos eUH1qkVMH5XFzZFNxTCbC49YTISqVxoNhHwyFHOOSNxEdLXpU9oSFwRZVQzLKfIhLe2pqapBMgna QNQnrH5N0tMUE81HhK4Kxu+len6rQSuDlcpBlB+0kLBEJRX8IFeHK6kDYdjguvMOsEQIvkM62Cmv cr6IKV1sMsW7Q8IHQfXQQqaq8ZbmqI4pfKnkD+6dEQc44/rBFD6Tb4iKZVi7aRqCoEJwF79sIeFb 2mEH3RhukH7VTUELireQfpVw6EPQQNP1oEw6RDOIlOE7ojd9qnQP2tFAoYPg7IYL/hBvvCpVulhB UqJDg7CD+k3uq691ggT1gzjg9fre2qIj/t0sIkEa0JoI4RCc79Pt0k6r2uCBW6t6BBu9/cUl0F26 iEmlsO0n+l7IbByqfT9aRN35BjVLhSuFL29oYLVWuqW123S6gn+7II4UK9JbS1f/SvX/oiDghhfJ vt9L/eKyuo791qHEawl7aVO/apb76/u9L2Oo8NhaobSurunthK6r6TBKvrfr7YSy/tbWwZmD0tNB euvDCCf9thMJiEgvpOlvexCj6Z3g0LTVdTCJ0RMVv9Pa2E0IjIKNAl1QnAwv1yTtw1i0GEwmt5tI gop/tLVkWtBwwQrfEIYb11bcGCxMow5GwnurS6pvFoYKHWwwTfSpN9CG9OdA0r6fvaBu9kIDtpah L2E/cHhql7bYv2w3OOK9Jh4ftuIaptBPje7caw/CthsMLSu9u46t1dtvS+kw2+mvt2qQYV3DDd8a 8Nvq+3a78MG319v2uoZBK24r2/+wbduWkSK4YZHzCI7I4njUtxwIFhZdEdF8j5tF8g0aIvm3cOGO I1EIIQzwU54KgodBBCgi6EEHUOCEjHEGIiJtCIyh2VzJHadVDUREQxEtFfDg0mNS30DDey3UJ6iH 4ZOCnKHOPtUIiUZHRHA4Juaqm0IlOGYYRjW4nZriPcUq1yzAeNwvC1Kqizqwnwt0l3roUqoK3C6C 17SrJJoQ0wqjbLWWvCfY+mWZo+mW2W+lG2tQl+6XrpeiyKX2vg38eih/Q/lmDFmV/CePC9036j1n ZUuoulVK9VCXYXBrj//SLXB9sswrQw5ZgwM2FLMQDZyzlYQjojouCxwQiL8gzDmfDhkFdz1lL8U2 itBFnF2eMjgoI+GVx6HTIVDxNaERvaipaizfx0l0/td/Kmqow+iCjWxqn/sFvuiCDk0yK+E0If1s 5+kbKJjhDXFqJMcscpMlCrsQQwb1QUF0v9Xq0pTv6Qp/UN30QRH5KNXLKFr51gW8a6YIJJf2FaaM ir9poEiEHR8HT7t0GCFa9aQtDf1qu2gg/tlDwk3a3UlBb4rr132utu96tMtzX+/Xu3X1eNe0u2m3 +HdpUTh1T0ofp8Nt/Sdfq2/6f7pB7qu123SrosdK4a8W7CG72L9/S/1+/b/t/S6t1fLNFe/vfxq/ VOH8mYL+GcRhEsBReIkFESbT6xQ3cjoyn+hqpZyvI4LRcKJZTNQ4nREfI4aYNDUROZtG0ew1xERG vLWNVdaj+W2GuN62qW71v/yAkJrj/T+t/2vC3//vX35AUJVMliUYJcEF0C4QLpdL0sX5TKWq9x9q n/rf8ySfpY5ZgOMByOLyzqQOfBV5ZwQDy8PSd5Bn50yyGSkGXyiNxRGcgYGtSzlHNvFfrLWEKV+X jjF1/8LXe/r+v2vyCP9IOvpmqv9lA/8zwSr74RH+uOEC/pILvpUnfSSrWl5ZRip50kksfcNK/1DS /4bNVCC9dtCgT/thIERRxw3toQnpbaLHCf7hKCZDj/toKEwVdWOYYc+ntCP9hd/9f/T699vRY76W k3eZ+k3WL8N9rSh39W+vTff2/6Tf9IMP/tvXSYa3SSDb19v+kH//10g1d/Hrp1df9wr/T/FfX1O8 BCOu5VQ1CzUpXolCMArjC5wZuI4Hj/Bx3LKIQxXEl0vG+GQPDcc/FOuWcLDXcQcmxYi39cs5IjZl 0R4uxoRK4UuIiIiJbgahRvD0v+WuB/+P9S11hcb8ppUVSzVlfEfa+6lmpS4/W9W/W9b+t66/p/w5 bCqq5KVstcyQjq7j7+E9f3ruzjquWnUsXzIkpx0WdKDLHoWWdVBTtNlnCgK44LaCIPUeCnIZxwuE QhQXRbRHUVWVqd3SQIRGEW6l3QJteKj72WcCnvd6vpt/27v7/X7/TlbBLdgvoghp1tB8PpsnmFVR y0wJQ08t7rCegvG+P/IellshS+g0lWRVB9s6aWMftVWih+2qC8Xvqv2GgkEZ/Dq3qYFurtqhSLdU lvQSWWoYUN4bqFVj9jQLqF3kWr69lDlCF29oRr7tj5Q/8tdUVDu7H999PqTY1XLH+h1b/pN9v366 V/9v+k30cfpd2Olevdd/SdrWkGvpKKdFD/e7aWW2ar1WnvrJstKr3WvWh0kFrxG9/+F+/01yzBTr 9yvC/aj+V1BjpSJKgwryHHKsqsFZHRhF0Yy+YBcdsSY5QGIiQ2JkFaLcmRvYi+W4MNl12eaumJIy OGkR4wjUVFD8TWhEb2NS3j7hEUjwnUKEwytMPY9VqD3lctVfHyLDrwg6+n6ta719CvbWoWu6+lWq X/2V1RBLuE6rquWyOi3C1yuDwmlqNK1g8belILjNbShv7Svh9b4I4+Gk7UewkDjXSKsJqHCGD2lK +qCs7ir7X6vTC3tV1tCvXafREH6QV5Q7Vs7C1XSbHVJNlqoVC6b7hcj49BMWdjTKmDH9MEQLgNh0 EHslQatQrbaIK8hIpN69dkSDQRw1B9O2EQX1IaYDBbpttSERcMwshpUqdtMQysB1fe4YlAbK9NPZ Kg2XVoQ3PzbK5KGaR+rY2JDCEtRHDBXCgZRpluLIxng0m2GJ4KVygCykW7oiAPEYZKUDDK42DSRw 0sw8rgSLxLgeDaR0GGIYZXVhlkIjeRwfGhIQct2HBsr6ZcMwjoz8TgW0hGw24kCAyiClHOPTBw3I MLKxaIHgyjtt0QpoTTKk0iB4O5WFTKJ3Yc2/VQiB+aO3+qIo5Q5hyGdzjncw591lw3bS+GVL2235 TAWoOLbv4wRT37/He9r222+u9w/yh7eHyL93d7wg6pNv9/7e7NBF9vDwdcm60tvpmS03DySENbbC nYXlxTYbDoDXwT98HOwZngPBt9P+mdnA8GdXNn38qoLkzA8FcjgYXC9W9ENg5wyoLORjkDwQcjQV BDBgElH/tCIiJDVsibAklCyvP/yB4ZWyWlWVaq+2yB4g5pD0oVCNfZHZBUkEmmkv9uEyRgqQ1s6C GZ/r0sbhhIEL7+oV2wmC/d6rsIjcSGHf11DKHC7CCkGIvddaEXY4KHaUP6WwoKK679tC/erXr/9a Ya6rr7XeunTHLVL9u9JU8YRQ9LSbRK3dCv6/vVJaTf1+1b9lfRFDIPPI+jYjqvQbq0ZFpFOi4NRH ZHBWItEQl60vyC4qQwYITdiIiQUqinPBDQOTHIQhaWlfRBqwlAkNmFIOOcCERESBEa9W+xEREhjx qlFN9DpaeoaWq7yGQBuOVBBQTO5EHJhm1VLT3kkhDZZkEG45zkD2nI9pCGWOTHK8pyY5GPVJXqoi IkIi6I+eRdkcM0TsLQiIiaBYVY/ERETMGBBpUq+ZJ8ubnRJBBQ+ojjQX+kqCq8odVQWvHqCVUVyh W1oIJJbrShBVj0kgSp6+EEwvqoSHvSQIF9UggRXJO/SQIJe+kEF87WVpYQSD4gnhIIFBtw9UCTId TD0qRdBAmQwUh/CDLoKY5DKByzrS6ojhiEQT0DFFkdD0gkxBC0MLSQJAwV1Qgi3JgrFzpUgi3Eg0 x6SCLcFAgs6WvpCPSRDOmy0qQ2sKQwA2sOMhQGlweYcocFK5FiI47/117dfel+WYHXCDqWZ4e2vT r6v1v9XrwrtQrXgtD4NwRT4pVt1v/CMPLMD8ad04bQcJLlO07rX0u69XkaaEK1w+UPHHeuUPv5kl yx73ryzi6yh0OO8J2ibma48sxF0HdPp9ffWvXugvXroKsK3VYWhImuP9Yf13fVd//W/7W////WHh K/3S99+t/6//+9faqWdTUONeWQhFcVVRH3LQCdX4//3r/epahO2n///eupZBdFuBxvIT7eEJIZ+I J3XTztTXrg/uiC47sbp/15C/v8jQtvwn/k3ooQIKqqIgv8s3EF74Idesx/4uu5ZinXfUt1GdrECs hbfw0k2W63hUCCKi/xGwgpMN/vBIeukw6D7cr0XYQREgt8Qih6YQRGgTuLKHtoIgVBJce2ow7yud YbPiVmQF8duEljyuQtwsL49oJhJfDEJE16srkLaYIjr9tCLx3u/26+n927lmCEEe3wRT3b4phW/g k3yuhbVmFxcJMX8K19Jv6X8K91Sf9Neknb9D+qqwu6/heh6lmqqPB/lmmBC4aZEzMAhHfyzQ2eAo IgNouiIyOBBHP5ZnmXZHUSB4bjiIiQ0aHH8s8RgUwiPEcHLgpginEgeCyOPIvlDkGHIKGVIVoccr CEHERESB6IKc+GHEeIiQK3KGEGDcuQz0EREREeIkNg5OZDO5IuQUDk2/lFynKs45Y5hxILaL8REh hzDiQMLqaPgtgbkfJQDSXRjOuXA8MyxEgeIOVBOzL0KyRwWwJxIIC5HQiJODcjmdcjhrYiJFJkCI KkGaBGUswSEkjLoRM0XDMsocgrjlDncgoHJDlDgy6JANpuO1QDMKIiIkujlE8yOIbjAhHQiaBgRZ BpHERIYcgw5wMw53Ks2HwpwhGIiIhkgZBQQU5BrsocREREREhkY5DA5OCBA5FHLshkAofERNRCZg 0FCI+R8zBbBZNmYRjI+YQiIiZhmHmR0R0Xi6MMuB4y6GIiIlQjALYZhdCIiJ2oxERETQQj5HZUIx FwgxNSNmYDJDBPn88jcIoqCk0rETMNQujAORwPBnI6I4pHyPCIiIyyEjNhyPmEJqRyI5EdEcy4cj sjxHDUI4KoZThCMRERERERFlYQYdkcG5HRgxGJqzpHViMRH//+WcDUcs6ko//+V0tFkAlEm4VDLP SMZHRHRsyOrloS0KiKKAYBCIk3UlE1KZGeN4////+TZH/u1H+ZE1H/lMk694////LUE1LQI/Yx/l Nl+CdAqCwo/5aoTk3JO41H/KaJrcf/8tCdR8swDOP/5aZZ+P//y1S68SbT//om4vxH//8gKqqj/L NCLnZfjUf////////////////////4AIAIANZW5kc3RyZWFtIA1lbmRvYmoNMTAgMCBvYmoNMjU1 ODcNZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAxMSAwIFIgPj4Nc3RyZWFtDXEgNjEyLjAwIDAg MCA3OTIuMDAgMC4wMCAwLjAwIGNtICAxIGcgL09iajggRG8gUQ1lbmRzdHJlYW0NDWVuZG9iag0x MSAwIG9iag00OA1lbmRvYmoNMiAwIG9iag08PA0vVHlwZSAvUGFnZXMNL0tpZHMgWyAxIDAgUiA3 IDAgUl0NL0NvdW50IDINPj4NZW5kb2JqDTEyIDAgb2JqDTw8DS9UeXBlIC9DYXRhbG9nIA0vUGFn ZXMgMiAwIFIgDT4+DWVuZG9iag0xMyAwIG9iag08PCAvQ3JlYXRvciAoSFAgOTEwMEMgRGlnaXRh bCBTZW5kZXIpDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMTEyMDcxNTAzNTEpDS9BdXRob3IgKCkNL1By b2R1Y2VyICgpDS9UaXRsZSAoKQ0vU3ViamVjdCAoU2NhbiBGcm9tIERpZ2l0YWxTZW5kZXIpDT4+ DQ1lbmRvYmoNeHJlZg0wIDE0IA0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDAwMTYgMDAwMDAg biANMDAwMDA1MTgzMSAwMDAwMCBuIA0wMDAwMDAwMjI5IDAwMDAwIG4gDTAwMDAwMjU1MjEgMDAw MDAgbiANMDAwMDAyNTUwMCAwMDAwMCBuIA0wMDAwMDI1NjIzIDAwMDAwIG4gDTAwMDAwMjU2NDEg MDAwMDAgbiANMDAwMDAyNTg1NCAwMDAwMCBuIA0wMDAwMDUxNzA5IDAwMDAwIG4gDTAwMDAwNTE2 ODcgMDAwMDAgbiANMDAwMDA1MTgxMiAwMDAwMCBuIA0wMDAwMDUxODk1IDAwMDAwIG4gDTAwMDAw NTE5NDcgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSAxNAovUm9vdCAxMiAwIFINL0luZm8gMTMg MCBSDT4+DXN0YXJ0eHJlZg01MjEwNw0lJUVPRg0= ------_=_NextPart_000_01C1835B.51D2DA00-- From owner-ips@ece.cmu.edu Wed Dec 12 18:30:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21120 for ; Wed, 12 Dec 2001 18:30:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBCMtht23928 for ips-outgoing; Wed, 12 Dec 2001 17:55:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBCMtfZ23919 for ; Wed, 12 Dec 2001 17:55:41 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id B4B98330C; Wed, 12 Dec 2001 15:55:40 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 6837324; Wed, 12 Dec 2001 15:55:40 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 15:55:40 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF759@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Paul Koning'" , ltuikov@yahoo.com Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: clarification please Date: Wed, 12 Dec 2001 15:55:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Paul, I used to agree with you on this, and that is what I had also communicated to Luben ( it was I who originally asked Julian to put in the iSCSI spec the same initial conditions for the CRC register as in ethernet), but ... based on your description, the circuit you appear to have in mind is the circuit that performs simultaneous multiplication by x^32 and division by G(x). When you go through the same reasoning for the circuit that performs only division (and thus requires you to perform the pre-multiplication by x^32 externally) your two descriptions appear not to be equivalent; and that surprised me! Please refer to my recent memo to the reflector "effect of initializing ..." for details. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Monday, December 10, 2001 9:23 AM |To: ltuikov@yahoo.com |Cc: ips@ece.cmu.edu |Subject: Re: clarification please | | |>>>>> "Luben" == Luben Tuikov writes: | | Luben> Hello, I have a question. The draft says: - the CRC register | Luben> is initialized with all 1s (equivalent to complementing the | Luben> first 32 bits of the message) | | Luben> Those two are NOT equivalent, e.g. if the message started with | Luben> 32 1's then complementing will yield 32 0's, and this is not | Luben> like ``initializing'' the CRC with 32 1's? | | Luben> Does this mean that the first 32 most significant bits of the | Luben> message are complemented, or does it mean that the message is | Luben> _prefixed_ with 32 1's and then the division starts? | | Luben> If it means prefixing, could you please use that word, as is | Luben> customary in computer science literature... and to diminish | Luben> ambiguities... | |It does NOT mean prefixing. The wording about "complementing" comes |directly from the Ethernet spec, and is common to all recent CRC |algorithms. | |The wording in the spec implies that the following two descriptions |are equivalent: | |1. Initialize the CRC register to all 1s, then process the data |2. Initialize the CRC to all 0s, complement the first 32 bits of the | data, then process it | |Consider a packet that begins with 32 bits of 1. It's obvious that |the second description will result in an all-zero CRC register after |those 32 bits have been processed. | |The first description has the same effect. For each bit, you shift |out a 1 from one end; that is XORed with the data bit, resulting in a |zero shifting into the other end, and the other bits remaining the |same. Do that 32 times and you end up with an all-zero CRC register, |just as for description 2. | |Incidentally, this implies that this CRC will not detect the insertion |of any number of 0 bits immediately after a packet beginning of 32 |bits of 1. That's a fine tradeoff, since that error pattern is a lot |less likely than simply having extraneous 0 bits at packet start -- |which is why the complement was introduced into datacomm CRC |algorithms. | | paul | From owner-ips@ece.cmu.edu Wed Dec 12 21:05:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24869 for ; Wed, 12 Dec 2001 21:05:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBD15G502812 for ips-outgoing; Wed, 12 Dec 2001 20:05:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBD15FZ02807 for ; Wed, 12 Dec 2001 20:05:15 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id RAA23143; Wed, 12 Dec 2001 17:05:02 -0800 (PST) From: "Murali Rajagopal" To: Cc: Subject: FCIP: WWN short frame and IPsec Date: Wed, 12 Dec 2001 17:04:22 -0800 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.50.4133.2400 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E029371CF@CORPMX14> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David: Could you please characterize and hence clarify the problem with the existing use of WWN to add additional TCP connection. I am hearing different views of the problem from different people. I would like to get us all on the same page by answering: 1) When is this a problem? With IPSec or without ? 2) What are the threat assumptions? Is the rogue device a party that is assumed to be "trusted" ? Regards, Murali From owner-ips@ece.cmu.edu Wed Dec 12 21:58:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26532 for ; Wed, 12 Dec 2001 21:58:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBD2CWv07240 for ips-outgoing; Wed, 12 Dec 2001 21:12:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBCN8GZ24847 for ; Wed, 12 Dec 2001 18:08:17 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBCN26S32636; Wed, 12 Dec 2001 18:02:06 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBCN26i13168; Wed, 12 Dec 2001 18:02:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15383.57837.944421.365599@pkoning.dev.equallogic.com> Date: Wed, 12 Dec 2001 18:02:05 -0500 (EST) From: Paul Koning To: vince_cavanna@agilent.com Cc: ltuikov@yahoo.com, ips@ece.cmu.edu Subject: RE: clarification please References: <01A7DAF31F93D511AEE300D0B706ED920CF759@axcs13.cos.agilent.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Vince" == A-Roseville,ex1 writes: Vince> Hi Paul, I used to agree with you on this, and that is what I Vince> had also communicated to Luben ( it was I who originally asked Vince> Julian to put in the iSCSI spec the same initial conditions Vince> for the CRC register as in ethernet), but ... based on your Vince> description, the circuit you appear to have in mind is the Vince> circuit that performs simultaneous multiplication by x^32 and Vince> division by G(x). When you go through the same reasoning for Vince> the circuit that performs only division (and thus requires you Vince> to perform the pre-multiplication by x^32 externally) your two Vince> descriptions appear not to be equivalent; and that surprised Vince> me! I suspect that you're right. The circuit I'm referring to is the classic LFSR based CRC implementation, described in Appendix C of the Ethernet spec (and seen in software implementations in many places; I think I quoted linux/drivers/net/ewrk3.c in the past). That one indeed does the multiplication along with the division. I haven't seen circuits that do the division only, and I'm not sure I could generate an example of what one might look like. paul From owner-ips@ece.cmu.edu Thu Dec 13 00:26:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29864 for ; Thu, 13 Dec 2001 00:26:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBD4ZSD16244 for ips-outgoing; Wed, 12 Dec 2001 23:35:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBD4ZOZ16231 for ; Wed, 12 Dec 2001 23:35:24 -0500 (EST) Message-ID: <20011213043523.25481.qmail@web12803.mail.yahoo.com> Received: from [24.42.134.59] by web12803.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 20:35:23 PST Date: Wed, 12 Dec 2001 20:35:23 -0800 (PST) From: Luben Tuikov Subject: Re: clarification please To: iscsi In-Reply-To: <15380.61285.65099.651496@pkoning.dev.equallogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Paul Koning wrote: > >>>>> "Luben" == Luben Tuikov writes: > > Luben> Those two are NOT equivalent, e.g. if the message > started with > Luben> 32 1's then complementing will yield 32 0's, and > this is not > Luben> like ``initializing'' the CRC with 32 1's? > > Consider a packet that begins with 32 bits of 1. It's > obvious that > the second description will result in an all-zero CRC > register after > those 32 bits have been processed. But this is my counter example... See next message. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Thu Dec 13 01:16:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01429 for ; Thu, 13 Dec 2001 01:16:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBD5I1f18636 for ips-outgoing; Thu, 13 Dec 2001 00:18:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBD5HuZ18631 for ; Thu, 13 Dec 2001 00:17:57 -0500 (EST) Message-ID: <20011213051756.31365.qmail@web12803.mail.yahoo.com> Received: from [24.42.134.59] by web12803.mail.yahoo.com via HTTP; Wed, 12 Dec 2001 21:17:56 PST Date: Wed, 12 Dec 2001 21:17:55 -0800 (PST) From: Luben Tuikov Subject: RE: clarification please To: iscsi In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED920CF759@axcs13.cos.agilent.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1361544525-1008220676=:29700" Sender: owner-ips@ece.cmu.edu Precedence: bulk --0-1361544525-1008220676=:29700 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I've been sticking closely to the iSCSI draft, some papers I found on CRC and CRC32/4, some lecture notes, my abstract algebra lecure notes and approached the CRC computation from a purely mathematical model showing the exact origin of the ``magic'' value of 0x1c2d19ed, using pure algebra. The two methods which I refer to are not equivalent, since they do not produce the same remainder, R(x), when it is computed at the sender. Please see the 1 page worksheet attached for the math. In a software implementation: 1. I assume straightforward poly division (table lookup, shifting, whatever). 2. Premultiplication by x^32 (deg of generator poly). E.g. appending 32 0s. This is so that when ~R(x) is added, the message bits are unchanged! 3. Prefixing by 32 1s. E.g. CRC = 31 1's and then the message bits are fed in from the right, popping out the left. Logically this is s.t. a sequence of 1 or more 0s at the start of a message are detected. The aforementioned steps, get the right CRC for the all 0s example in the iSCSI draft but the rest three examples are not correct. Now if I stipulate step 3: 3. Complement the first 32 bits of the message and let the CRC be 0 and then do the division. Then I do not get even close to the samples in the draft. If I stipulate step 3 as: 3. Complement the first 32 bits of the message and let this be the initial value of the CRC and then do the division. Then I do not get even close to the samples in the draft. Clearly the last 2 are equivalent. In all 3 cases I _do_get_ the magic value at the end, and this is mathematically sound, since playing with the CRC is like adding a certain polynomial, C(x), and C(x)+C(x)=0, since the CRC is done the same at the receiver, and the coefficients are in Z_2. For any CRC, we have to have a solid mathematical model, in order to avoid confision, etc. We CAN provide a solid mathematical model for CRC32/4, as is specified in the iSCSI draft, but the sample CRC's will have to be changed. My interpretation (word for word from the draft) is: specifies CRC32/4, straightforward premult. by x^32 and prefixing by 32 1s, and straightforward division. NO! Prefixing and adding ARE NOT equivalent in any sense! I say prefixing, since it makes more sense to catch 0's rather than not to. As well as it makes less sense to mess with the message bits (as it would be for adding). But the examples seem to be taken from a different (Ethernet algo with CRC32/4 poly?) algorithm, or the examples were mistyped. If something else was intended, then so mentioned it should've been. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com --0-1361544525-1008220676=:29700 Content-Type: application/pdf; name="worksheet3.pdf" Content-Description: worksheet3.pdf Content-Disposition: attachment; filename="worksheet3.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKMyAwIG9iaiA8PAovTGVuZ3RoIDQgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp42uVa3Y/bNhJvX7evvXe/nYxb8/gpUgf0 IZfr9Vq0QNAu0IfmHpQ1vSvElheS9pL043/vDIeUZS/TdRNn2+QQIJbE4ZAz 85sPDlfMOPwTM1cxY6qZ5Y5xLWeXm7N/Xpz9/d/CzIRglTGzi1WgvFj+UHzt h/l/L76CUTcZlZKJUkeSbyLBdLqQzFgVCZ5ywzNMNOxCRpKXGR4lK8dxYCHm Cy3L4tl8IW3h8cUWw7Wnrxvf9/WVP4c3I4q6XWbWE1IwJ8vI8YvMihWTSj/c pq9867t62Hb4qoubQLRdv2q3m6ZeB1l4nLodrmlO3dPv0j/lQrd+Sa9Ni3uZ LSQ3zIJlFkIzrcuwjbCeKkVxU9MSvqN3VBM88EQhi2VXrwaW052STIkqCvb4 oXQXdrnut7TNicy4WZA5ELxWPtxGM9DcpqdJI3HTNgNomUb/NzcGFrqNY9vV AefH386B72PSsTCSWWOjjk3Ybuevmn7wHW47pz/DmU3aa3P+wpniieAzlMKC uFcZTmAIoaqHBrFC6GW9SgkmRXKq568RrUrcghmSDyDTFhV7u5lLF5DuyHgw EGyArtMMcU7TZp1aM6XVCUKR+h0KYdHbnGEOvGzqbf/xnSf7oaz4W9NP7zfN 4qbbkj+v6OMzFP8VPV9uW1TD0NXL5nJo4A0+l6CqOoZgpaYhWBgmTFL8TRd8 42XTXmW2b4CUJ/lGM+6zA1hZkUiWy5ERYGmiJ8kqkcC1RLfkpmi36GNcF62f Q8C6xP8wHHfN+lUOn5qB3iKPta+XpEutLRPO7UeuLWFgREtfb+JT5zd10y59 d54FBUQraeMa32adhHP3TjCBgKyc2JPj0RrjjOXFizmlAWUFqc/GyAS/q/oS UkHzo6dXkhke/Eswbt8jHjKSVpDTxEEmlnJmWWVH8GuQRUHMQBKekQTCWWXA AiPRicIGZDDlMNKi1EMUt24zuDKK6QQ+tOpNwBA8tENunRJCnL0D5ylDqQBk ieQ+fqZk3CZPQrdL+idgKjCo2XfyXfKQai95QBqnwKUSaPWYPOir7zY9g6St TPEE0N9HInAin+bVw45DRjQrGB9NfoS2DCsT1MPqtCBOC8kyFAG47xbcNawb VLBbf7ZQCkxb6b2MN1ZcGZw4Jk31wCH5nJIE1TQxZmSAplk5Zs97cWFgD3qi OuJ8kMNscdX5evD9QMMQxvuhplAemZY7f4QoZyDRo6+5wFdkFnawSUcO6Q4X b2nNSVmIn3dBoj9PNnNMWXtQCYZs29OcMRjBz2Xdpt1vburOjzrcsEyy4Jj6 mIOsjlyf7HLPP3KGwgiVVH5xHbKiUYCf4Zpy4RI/yCINUL2HX5a+v+yaWBYs aRTlx7GaXqnkK0PVgO9jPgWS75v1uqk3ke0OZgfepKCYS0B6hGvJ4gmkljWo E99U8cVts/Q0gEEMfz/vOkQOVO5R14AUK/b8419+oHRImVzB46O5NMX6CoL8 cL3pz+mjqCqVcxENdZVy0yIsE/05HODAxLJkmov7UkClyvtTQCI6WeXolIKC NlM3KmbcoYNX466J0W4/ueQHgQ1GJ5t+qFgDIJCy+FvOIg73/7CnpABBqKoM nOUXwjJILfEYkasXGB+zwbvW+slPIcdo/c2FslOh7mfzPMtGwIwJmy+zcu2K 8ZNiQMCRQIcwhCDQpwaB+S0QHCHI+4AT9Sc18MTI3DILHr7Agy+vTmxkOc2N lpWSWEpKLp9m1imZQsSVzBn7XoaDnJnhKCrUMWaWJ04sd42Azqw4xCbwaUEF 189Idvb5xZm0oH3s9kk4fjoo0Dkc4mciZIDOz1ZnInZ8kdCoCWHq+e4tlXq+ P/2YFoACIxyMXscXxiuU7zfZ/RKAaxhUM4BZWRJm/5KpKxcKGGrwnYUBkHOK YI9CMyJXWYIs1diz+JL5cKyiEnbtN55KcGxkTJsItsBitUvVupL4a4pvvnuW 69u5ijl7VIWlTlhhqdNVWPKDzPXirbz7D87SXDHh5HFZ2r51AMezptUUmj/K KkNbUEbFSqjGP9g0/fKO0x7q76PMQmZsIR3lHA8IowNDU9DY2fDjDJuFUJpx BB6cVrHT+s6Bd7LKQb1HwQVLB/l/BL2FKimcZeqTheRQdmAPCvK6AIkAoTxb SCyokhgJf2d98lq+sAEVsPzmFcq+EynwDgeFlIF9KjnpaSmni42v2/A4dnHh 6cW1b2m4pg/j1QW9NnEGli23Q7jcBNpVt93kLt6dYtwc1e93x/T73YmvCVGe gSR40azXuSskPblIxqujzP7wrwuSF7b+crxMCnzHu3RSc2pRW4T7frsz3hZZ W6zwjh1I9tqmtpw2IbEpb1wJ1qQeKbbnqvEaBjusNZaV/QHD2NyPn0N31trd rHChTo9BH2F0JwHe8jaf+M7TFUlksqLfbUuy8T2hbnufvb8rmZUuc3+3p1kN JSFP6KHu5QEfocNp46hbRQFely7y0u0XRFDjzF4nNPqHtLFzDhX62tcd3TaU Re997GkHT8n97QGcWcZw+IBJwrqUH/eiBsQUWVUzSBUlmeTJ3Ta/ZCUWIFDp GVKCEneCPMeqS1bkgs0dHhKETjJ9xrN6AU+SM8W0s/ckrOToTUZw4ILXlTui 83jTEA5UaJd0RhJ/7dkY2hVauMQTpWEWNgpRm4kKgjFTINJ+cFcconsVjlGg EbkL7xZ2WEG8msTiqCeN5UxVKjKdLoMyS0HKfN5uX+S6UhJUIvCUC1O53bHD Df8Krxi0omVuZHN0cmVhbQplbmRvYmoKNCAwIG9iagoyMDU3CmVuZG9iagoy IDAgb2JqIDw8Ci9UeXBlIC9QYWdlCi9Db250ZW50cyAzIDAgUgovUmVzb3Vy Y2VzIDEgMCBSCi9NZWRpYUJveCBbMCAwIDYxMS45OTggNzkxLjk5N10KL1Bh cmVudCAxNSAwIFIKPj4gZW5kb2JqCjEgMCBvYmogPDwKL0ZvbnQgPDwgL0Yx NSA1IDAgUiAvRjE4IDYgMCBSIC9GMzMgNyAwIFIgL0YzNCA4IDAgUiAvRjIy IDkgMCBSIC9GMTYgMTAgMCBSIC9GMTkgMTEgMCBSIC9GMjQgMTIgMCBSIC9G NyAxMyAwIFIgL0Y0MyAxNCAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0KPj4gZW5kb2JqCjE0IDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhzIDE2 IDAgUgovQmFzZUZvbnQgMjIgMCBSCi9Gb250RGVzY3JpcHRvciAyMyAwIFIK Pj4gZW5kb2JqCjE2IDAgb2JqClsgNjI3IDgxOCA3NjcgNjkyIDY2NCA3NDMg NzE2IDc2NyA3MTYgNzY3IDcxNiA2MTMgNTYyIDU4OCA4ODIgODk0IDMwNyAz MzIgNTExIDUxMSA1MTEgNTExIDUxMSA4MzEgNDYwIDUzNyA3MTYgNzE2IDUx MSA4ODMgOTg1IDc2NyAyNTYgMzA3IDUxNCA4MTggNzY5IDgxOCA3NjcgMzA3 IDQwOSA0MDkgNTExIDc2NyAzMDcgMzU4IDMwNyA1MTEgNTExIDUxMSA1MTEg NTExIDUxMSA1MTEgNTExIDUxMSA1MTEgNTExIDMwNyAzMDcgMzA3IDc2NyA1 MTEgNTExIDc2NyA3NDMgNzA0IDcxNiA3NTUgNjc4IDY1MyA3NzQgNzQzIDM4 NiA1MjUgNzY5IDYyNyA4OTcgNzQzIDc2NyA2NzggNzY3IDcyOSA1NjIgNzE2 IDc0MyA3NDMgOTk5IDc0MyA3NDMgNjEzIDMwNyA1MTQgMzA3IDUxMSAzMDcg MzA3IDUxMSA0NjAgNDYwIDUxMSA0NjAgMzA3IDQ2MCA1MTEgMzA3IDMwNyA0 NjAgMjU2IDgxOCA1NjIgNTExIDUxMSA0NjAgNDIyIDQwOSAzMzIgNTM3IDQ2 MCA2NjQgNDY0IDQ4NiA0MDkgNTExIDEwMjIgNTExIDUxMSA1MTEgXQplbmRv YmoKMTcgMCBvYmogPDwKL0xlbmd0aCAxOCAwIFIKL0xlbmd0aDEgMTkgMCBS Ci9MZW5ndGgyIDIwIDAgUgovTGVuZ3RoMyAyMSAwIFIKPj4Kc3RyZWFtCiUh UFMtQWRvYmVGb250LTEuMTogQ01USTEwIDEuMDBCCiUlQ3JlYXRpb25EYXRl OiAxOTkyIEZlYiAxOSAxOTo1NjoxNgolIENvcHlyaWdodCAoQykgMTk5NyBB bWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNl cnZlZC4KMTEgZGljdCBiZWdpbgovRm9udEluZm8gNyBkaWN0IGR1cCBiZWdp bgovdmVyc2lvbiAoMS4wMEIpIHJlYWRvbmx5IGRlZgovTm90aWNlIChDb3B5 cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHku IEFsbCBSaWdodHMgUmVzZXJ2ZWQpIHJlYWRvbmx5IGRlZgovRnVsbE5hbWUg KENNVEkxMCkgcmVhZG9ubHkgZGVmCi9GYW1pbHlOYW1lIChDb21wdXRlciBN b2Rlcm4pIHJlYWRvbmx5IGRlZgovV2VpZ2h0IChNZWRpdW0pIHJlYWRvbmx5 IGRlZgovSXRhbGljQW5nbGUgLTE0LjA0IGRlZgovaXNGaXhlZFBpdGNoIGZh bHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFtZSAvTVBDQUFBK0NN VEkxMCBkZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udFR5cGUgMSBkZWYKL0Zv bnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdIHJlYWRvbmx5IGRlZgov RW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5kZXggZXhjaCAvLm5v dGRlZiBwdXR9IGZvcgpkdXAgMTA3IC9rIHB1dApkdXAgMTEwIC9uIHB1dApk dXAgMTExIC9vIHB1dApkdXAgMTE5IC93IHB1dApyZWFkb25seSBkZWYKL0Zv bnRCQm94ey0xNjMgLTI1MCAxMTQ2IDk2OX1yZWFkb25seSBkZWYKL1VuaXF1 ZUlEIDUwMDA4MjggZGVmCmN1cnJlbnRkaWN0IGVuZApjdXJyZW50ZmlsZSBl ZXhlYwrZ1m9jO4Rql7aGqX5Fo9CqBSlzHJmnhMy+hbSZOy7r3jsS1HK3z1Rl HvIRhRFqaasQlu1LrS9kZjXgGbZBfMd7Uy+F2BHHDRQpoZpTB+9j61xeAsif xsIPbZ2J59kf5HC3K+/aI/Xfdr4Fr0zpMTeiGe2KBKnX1v3zfmt/zeDZC5hk I+WWCl2fu0yVZVbo35DL+uxHb6Nv2aXIF1ya9RP+2RnC3dJr3A2ZOYufTQPV mT38CTApeGbhzQoxm2sf2VieOUj/sLTnDyEuyXbWUJnYTg03p6dxwxAdatJq BRM3jyHsNkMHnuzgyatUtHcuXcqC0NSsx/QvtJOqBKO/ShvWBuzhhjFdvpz9 yxoDA+jT6DAnzTr6jwvUZqjoyg5xZM9VszL61DSCdI3Uocs/QMsfXmcZK4IW oNj+MPnwW/AW9bXMEwpLB5buBlSVQi+6Vb7pv9mdBEZNmHrE0jfCCPqGCxEu Vc57N4KjS8IuPeMXVdmv8Z5JDI5DuF4X7Oh/qLkUhYMWJNJPN8Ob+ZctdObs R4RyesALnEo609ocIr1pYX4K2vVUIvIqyl5NzU35/NGHpWa3+2YdBTBFTQ3W xsUKejh1xsv47Hdp8yofP3/BwHK63sl3lNTpDgA1KCoXBAI1blqc2avYCsQ0 KlKD5FinJpJS9FQcu2RSs57VTTNtCxmSjpzRqyatg+sgni7HUBGiZDgTBTtd uwJGCXxIIbXyySVU6RQL41stv82YgJqOyfyRD96eDYZFfHCssFbr+Q8kTcCl u9RV4V1uMYAxHVLPULC/fQp/ZPOhgh4K7bwue661Sf4dUQiMFTeZxuCJtdXW XhxOLStDDN8f+iPMsl2VXE3YhTEKcGsyCrJcjXQsbymVMlT6VNqu5g7Ud4d9 GbzSjpq1drDqCIFx/QALYNc7PFf3VLwH68m/dRt9KzJFnZk4YbfEsNmMQioR vs73b078DsruiXI+bO1T42eNczNjLfBorvD+fftXOTvapDmmpMOW+GAyqYAJ 6uEke33oOzvkbfKJhZj/XmymlTEnQy7WEeFdE34vHrvZkD8WBoODHGGEgvwh afFjN/iMQbD+7ps8Lt3QyqRwScJEbYwxdH2ED8VK/l0c1+AT0Gpfw86GaRKf hgxVrce1zGU0cTgQfeHFkgyXsWzwuZ3OfrDZJIdaMM/SryMrFRQy0mF97m+L q13YIcgzFcxaEb/KzWFJogGHknz4cXhpt+fclYsjTsnVOQusqDUuK6ZsUulb ccS59tvf8nJbxLCpnNlV36zdAHsoV2+MxwDPlNGi09UWGLWHtCM+aTCJDdMx LkVXTlQcHFEwqtgE01STNGNdvKlbKyB975CW0n09bcOjpu6NLZSH8+Fh+7F+ +p4ROq9A8pB1NZMBVxLh7sWh/YNULLn0olIszqTsoNexkK672gNQW5rJKk6z FKFZNZ5MtDU84nE7FZIPgxR2wls3NBd2puX97ijUE6HkzuA4muzOx1X0n35y YgcysPNUNWeu4XyItSS2LWnWmO63Z7FbX1TmB/0765udSyo29q0XCrEr8qEv KkvHdr2aPYZM4Lw2rgY/gJWaPGlVMhLADJjn8g1c1kVb0EtW9+T+UVzTvXHa S4xpEVv0oIFzGCrkg+adIi0McsoqXc7FyTdqly8E8TGHsFsL8Sza5zeBmM4e NZsolA+1FUSkJfXZLw1WqQCqFrg/o56d2k1CmPjf2UOYI7CfbyIioMeRusiM YoQHa9m66mTqcb2qpzRWS9mVobuIzjWNhuAkBNCjqV+bdZvogOvO8T2NVsK+ AXzf5/lElCYyjmyYNHXBcYX2XS7GQjsxBgSrG4K68kaIbvGtLWSMjxl7suap IwVMO84EdR+08aCC29tiSDkZErJuTVI0VyElLZyLRd2PZz14vFbe1s6QQqZK Px/xTIyI2dW1NJpvOK1g+2Fpymv0b+VsyPmi6+5Gi4g8qjhULs0iZIhArlLU Uj07CrK8z6nEfoeMZLKVZL5UYFTlyU7XiIABEyd3b3QNLHevAJKdaAtVZksN +dYKEYcqQ5c5EoCBdCXmnbTuBggWGKdgiUqvXfgXVjKXUo1lG42nn6HY1MfA CPkuuqt2/lxq5GsmLkLwuH9jYU9Y++NPvP2ogZR2r5lyShOItpI65KzsdGIL LWCd7f4VF8ZI72pOfrKcxVw96DDOs4UyazfSoEkUarI1dLgbNQGEuszVZB5S Bf/HEjGnMi2f7hhXzdDsWE1INfu3+2uk/wAYoFNbvJCuliinfzQbj0uU/1pw eLc0zk4X+U6rpG9kZADZLhqoOnIENwvrar1LTftQtWst7jpKig341Ui/F2tb d7+e1Lu6GuseGoaVIAL4CBhKu4raGEC6YbanMDKUD61hCqxm2u8jTYM8Vglt lsmR4xSqG8b0Ve7ttti0a/NR5yyNkuvqkbMGbrVImVBBggk8v8RN2d73d4FK TQp5bSC4WncChV4r9gNoe1PPRbArZGLbOl3ny0A8HKYhBlj/ZHBmER4FBOpb MFwHv5xxyStdGPhmxzkfvEQj5KYHSqV8hluM+8wzsOL/R4csHs5+WENbj3z/ neFWopQjxSL/wjjB/wCCZxoc8PwIZJTVLqNmYqn8ikJIS0slBUilO5+ZC9dY iT8S6PXu8W4k1ToTOAe+ZS9L6IJ/IEOYVWBo97i/FfYiLKIndknMBDKonung Xpihrs31TzNAfHU8XWv6mFkGGv9kAuAH9p1Cjp0+Wtipv8+4ORD8yf0p6agB COAIajoPDTyFjaQxo55BSam1/xhcU2/YIab8GXUB1jsOOe+Z+rxMKlH+Z2a5 SKnWQmwUmdp6Qi+e9HN/8Q7Hks0lvCo4e/CvUhO9ZLugdIFQQV5Qk3SK3Nfx RHP+0U0O+M3xZhKQXL9J3wjZ3/N6qrG42h6PExa0emt17hKMuAfMBoPjuIQH 30wawXBjjhNiFwpPL906DywdSvAezzeRArVQXkCyCchNYcXXdPMlL6w3NbnU ZmDojbW5xmwbaRcKXb9vAZQvimkWhJjEzH0gKDv1z04lftQEeSFGB+nmsqvk hoUwwVM9BqDxwyTEiPU97aqwpKatJBvY1ZA7YmtbSAdWoNJ+Dg+sibHGTmHo BB91GmztDuaibXmuKTS8eEiCPhA738Y1eyWH+EgppWuzq2byVhQeoMhGYoQ1 ookAaiRZqh4H8UIwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xlYXJ0b21h cmsKZW5kc3RyZWFtCmVuZG9iagoxOCAwIG9iagozNzQwCmVuZG9iagoxOSAw IG9iago4MTcKZW5kb2JqCjIwIDAgb2JqCjIzOTEKZW5kb2JqCjIxIDAgb2Jq CjUzMgplbmRvYmoKMjIgMCBvYmoKL01QQ0FBQStDTVRJMTAKZW5kb2JqCjIz IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50 IC0xOTQKL0ZvbnROYW1lIDIyIDAgUgovSXRhbGljQW5nbGUgLTE0Ci9TdGVt ViA2OAovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTE2MyAtMjUwIDExNDYg OTY5IF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9rL24vby93KQovRm9udEZpbGUg MTcgMCBSCj4+IGVuZG9iagoxMyAwIG9iaiA8PAovVHlwZSAvRm9udAovU3Vi dHlwZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRo cyAyNCAwIFIKL0Jhc2VGb250IDMwIDAgUgovRm9udERlc2NyaXB0b3IgMzEg MCBSCj4+IGVuZG9iagoyNCAwIG9iagpbIDcwNiA5MzggODc3IDc4MiA3NTQg ODQzIDgxNSA4NzcgODE1IDg3NyA4MTUgNjc4IDY0NyA2NDcgOTcwIDk3MCAz MjMgMzU0IDU2OSA1NjkgNTY5IDU2OSA1NjkgODQzIDUwOCA1NjkgODE1IDg3 NyA1NjkgMTAxNCAxMTM3IDg3NyAzMjMgMzIzIDU2OSA5MzggNTY5IDkzOCA4 NzcgMzIzIDQ0NiA0NDYgNTY5IDg3NyAzMjMgMzg1IDMyMyA1NjkgNTY5IDU2 OSA1NjkgNTY5IDU2OSA1NjkgNTY5IDU2OSA1NjkgNTY5IDMyMyAzMjMgMzIz IDg3NyA1MzkgNTM5IDg3NyA4NDMgNzk5IDgxNSA4NjAgNzY4IDczNyA4ODQg ODQzIDQxMyA1ODMgODc0IDcwNiAxMDI4IDg0MyA4NzcgNzY4IDg3NyA4Mjkg NjMxIDgxNSA4NDMgODQzIDExNTEgODQzIDg0MyA2OTIgMzIzIDU2OSAzMjMg NTY5IDMyMyAzMjMgNTY5IDYzMSA1MDggNjMxIDUwOCAzNTQgNTY5IDYzMSAz MjMgMzU0IDYwMCAzMjMgOTM4IDYzMSA1NjkgNjMxIDYwMCA0NDYgNDUzIDQ0 NiA2MzEgNjAwIDgxNSA2MDAgNjAwIDUwOCA1NjkgMTEzOSA1NjkgNTY5IDU2 OSBdCmVuZG9iagoyNSAwIG9iaiA8PAovTGVuZ3RoIDI2IDAgUgovTGVuZ3Ro MSAyNyAwIFIKL0xlbmd0aDIgMjggMCBSCi9MZW5ndGgzIDI5IDAgUgo+Pgpz dHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTVI3IDEuMAolJUNyZWF0aW9u RGF0ZTogMTk5MSBBdWcgMjAgMTY6Mzk6MjEKJSBDb3B5cmlnaHQgKEMpIDE5 OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMg UmVzZXJ2ZWQuCjExIGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAg YmVnaW4KL3ZlcnNpb24gKDEuMCkgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENv cHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0 eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFt ZSAoQ01SNykgcmVhZG9ubHkgZGVmCi9GYW1pbHlOYW1lIChDb21wdXRlciBN b2Rlcm4pIHJlYWRvbmx5IGRlZgovV2VpZ2h0IChNZWRpdW0pIHJlYWRvbmx5 IGRlZgovSXRhbGljQW5nbGUgMCBkZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBk ZWYKZW5kIHJlYWRvbmx5IGRlZgovRm9udE5hbWUgL1lCQUFBQStDTVI3IGRl ZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJp eCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGlu ZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1 dH0gZm9yCmR1cCA0OSAvb25lIHB1dApyZWFkb25seSBkZWYKL0ZvbnRCQm94 ey0yNyAtMjUwIDExMjIgNzUwfXJlYWRvbmx5IGRlZgovVW5pcXVlSUQgNTAw MDc5MCBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnW b2M7hGqXtoapfkWj0KoFKgFCZ7eQTrPA070Lg9iRAWymyktxKt6yWPqrmhMO 5gXmH3f8G3OKvHxRzUbvgXGQmNX+5nZg5pp6uRtY8ppNeeVwIveD6w+7ttT0 7DUBT9Ley6mUWaTFnfDG66FQKERU5wfcIQDBW3a0wZuENjdYRppsVYeFsiYz IVIQmHGpiDSH3XcQlJIE3c+DfmqHCLgr2/FvvHUS+qMIoJP+XPW4yruf/GzD 8emuMvI062D+feNJlbGs/1JCjqIMjtT9c+OTXOvUDg6tcMCIekUeGxrIR67e QZHM24thNF/QcP0wxPN12EGN3UVHKaJRs/YdrnyIgjhCgv3WECro7v7eZEdX avoYHyekghapytcwVhRp5HiyhvIjKPKuhO8YPeQRnEAncaJJqsH6VDVpCijR tHSGEGDIAA0/4b9FEzz4R6JLT4RkpjzqAeyEqiL9AF50hH4BQmtokJUafdH1 Cl8yheH5WPEfx/AO4m/ufGOZjqEyi8mEHFfICUbSwvyBNGJJpmTs+wiizgdQ Ns6nNZ/KHpDA9obDuyfu+kXVSPe9B0zmDmJqT4PGn+k6UyQTOng2LzCOjcyA 3QxJ4TfNyawIuuOSguJqek2MFZuV8ie9oqKBr6na6/MfUEOAsggSohHPn+sR LsKaP7O9PoGAn8YpNIenRV6zuHnStL1GlCuxJDiWJkciy1kUbD9lvVm5anSx K7KaE1SvF0kyIQxuGf5YSxsUwA50YInLsX5ohF17PqBRBe7kYeNpf8+DXL5t RsdVI0eOdmgydRz22W7DOL2tV9U7UvU0D6yf4EVq0TEBgkI0smKsDKukO2Lr 2jl5W65s/pdWOlCq4fGViIc58mdghqmBHlyaSn4L802hhbgWaDurIl8oV9Ua q9S+oZUerMV7+44zARquDdHnF5tq2IjWgp6wCUfLeY9mWLQqJOqj+qdg84oW cScymW+VcuRI8OAn6oN++tsv/RpwjwdqAw2OiE0xX1ZV2A81Fz64Dqdotk44 zYikPFTzCVrNL5Fysjv8ORk8cazsNN6IdfS12o7ua83UwYJXH4MytquoV02n 3xaOeIFbvneXT5rKU4jpx3+AVgQoSsYEgRJLhAnOBT57V7d10hO9y/PJMzUu pqlTz48MIunZfdrRJWuSIm878XzhttXRIAoYXonu/WqtS7ml6d9rD6mOrxEA WWgmZd3lFQeatszzx2ZqV+QO55kV/YqAfD70vzshJTlovx56XXbWgIPJ+BSi S+VUpz6jGTxzEkoflDc+la/1LcofkOV0PBeChFXFtZE/RP/Q6ZD7tmMzu4Fm lwaI7y2zEPs5KfhV2mCm2J6xLh0ENiI5g6tNBYEMhOqH+7RSLJcjOAQSR2tT DCTuMXL4DgkEpHXu3k5mqr3uBTbwtwlNt87AqN+4giLr/+FM0XttGJ9RFesF Yq9LWUuCdOfu8hfT4Xm+wS11GyKj7lYrvTB+nuLlkVb6Cb/Pk950EkQ0frFo tZI6WjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAow MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMApjbGVhcnRvbWFyawplbmRz dHJlYW0KZW5kb2JqCjI2IDAgb2JqCjI0MjAKZW5kb2JqCjI3IDAgb2JqCjc1 NwplbmRvYmoKMjggMCBvYmoKMTEzMQplbmRvYmoKMjkgMCBvYmoKNTMyCmVu ZG9iagozMCAwIG9iagovWUJBQUFBK0NNUjcKZW5kb2JqCjMxIDAgb2JqIDw8 Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0Zv bnROYW1lIDMwIDAgUgovSXRhbGljQW5nbGUgMAovU3RlbVYgNzkKL1hIZWln aHQgNDMxCi9Gb250QkJveCBbIC0yNyAtMjUwIDExMjIgNzUwIF0KL0ZsYWdz IDQKL0NoYXJTZXQgKC9vbmUpCi9Gb250RmlsZSAyNSAwIFIKPj4gZW5kb2Jq CjEyIDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRmly c3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhzIDMyIDAgUgovQmFzZUZv bnQgMzggMCBSCi9Gb250RGVzY3JpcHRvciAzOSAwIFIKPj4gZW5kb2JqCjMy IDAgb2JqClsgNDU4IDQ1OCA0MTcgNDE3IDQ3MiA0NzIgNDcyIDQ3MiA1ODMg NTgzIDQ3MiA0NzIgMzMzIDU1NiA1NzggNTc4IDU5NyA1OTcgNzM2IDczNiA1 MjggNTI4IDU4MyA1ODMgNTgzIDU4MyA3NTAgNzUwIDc1MCA3NTAgMTA0NCAx MDQ0IDc5MiA3OTIgNTgzIDU4MyA2MzkgNjM5IDYzOSA2MzkgODA2IDgwNiA4 MDYgODA2IDEyNzggMTI3OCA4MTEgODExIDg3NSA4NzUgNjY3IDY2NyA2Njcg NjY3IDY2NyA2NjcgODg5IDg4OSA4ODkgODg5IDg4OSA4ODkgODg5IDY2NyA4 NzUgODc1IDg3NSA4NzUgNjExIDYxMSA4MzMgMTExMSA0NzIgNTU2IDExMTEg MTUxMSAxMTExIDE1MTEgMTExMSAxNTExIDEwNTYgOTQ0IDQ3MiA4MzMgODMz IDgzMyA4MzMgODMzIDE0NDQgMTI3OCA1NTYgMTExMSAxMTExIDExMTEgMTEx MSAxMTExIDk0NCAxMjc4IDU1NiAxMDAwIDE0NDQgNTU2IDEwMDAgMTQ0NCA0 NzIgNDcyIDUyOCA1MjggNTI4IDUyOCA2NjcgNjY3IDEwMDAgMTAwMCAxMDAw IDEwMDAgMTA1NiAxMDU2IDEwNTYgNzc4IDY2NyA2NjcgNDUwIDQ1MCA0NTAg NDUwIDc3OCA3NzggXQplbmRvYmoKMzMgMCBvYmogPDwKL0xlbmd0aCAzNCAw IFIKL0xlbmd0aDEgMzUgMCBSCi9MZW5ndGgyIDM2IDAgUgovTGVuZ3RoMyAz NyAwIFIKPj4Kc3RyZWFtCiUhUFMtQWRvYmVGb250LTEuMTogQ01FWDEwIDEu MDAKJSVDcmVhdGlvbkRhdGU6IDE5OTIgSnVsIDIzIDIxOjIyOjQ4CiUgQ29w eXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5 LiBBbGwgUmlnaHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2luCi9Gb250SW5m byA3IGRpY3QgZHVwIGJlZ2luCi92ZXJzaW9uICgxLjAwKSByZWFkb25seSBk ZWYKL05vdGljZSAoQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhl bWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkKSByZWFkb25s eSBkZWYKL0Z1bGxOYW1lIChDTUVYMTApIHJlYWRvbmx5IGRlZgovRmFtaWx5 TmFtZSAoQ29tcHV0ZXIgTW9kZXJuKSByZWFkb25seSBkZWYKL1dlaWdodCAo TWVkaXVtKSByZWFkb25seSBkZWYKL0l0YWxpY0FuZ2xlIDAgZGVmCi9pc0Zp eGVkUGl0Y2ggZmFsc2UgZGVmCmVuZCByZWFkb25seSBkZWYKL0ZvbnROYW1l IC9CSUlBQUErQ01FWDEwIGRlZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250VHlw ZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVh ZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBpbmRl eCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCAwIC9wYXJlbmxlZnRiaWcg cHV0CmR1cCAxIC9wYXJlbnJpZ2h0YmlnIHB1dApkdXAgMjAgL2JyYWNrZXRs ZWZ0YmlnZyBwdXQKZHVwIDIxIC9icmFja2V0cmlnaHRiaWdnIHB1dApkdXAg ODAgL3N1bW1hdGlvbnRleHQgcHV0CmR1cCAxMjIgL2JyYWNlaHRpcGRvd25s ZWZ0IHB1dApkdXAgMTIzIC9icmFjZWh0aXBkb3ducmlnaHQgcHV0CmR1cCAx MjQgL2JyYWNlaHRpcHVwbGVmdCBwdXQKZHVwIDEyNSAvYnJhY2VodGlwdXBy aWdodCBwdXQKcmVhZG9ubHkgZGVmCi9Gb250QkJveHstMjQgLTI5NjAgMTQ1 NCA3NzJ9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDAwNzc0IGRlZgpjdXJy ZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK2dZvYzuEape2hql+RaPQ qgUqAUJnt5BOs8DTvQuD2JEBbKbKS3Eq3rJY+quaEw7mBeYfd/wbc4q8fFHN Ru+BcZCY1f7mdmDmmnq5G1jymk155XAi94PrD7u21PTsNQFP0t7LqZRZpMWd 8MbroVAoRFTnB9whAMFbdrTBm4Q2N1hGmmxVh4WyJjMhUhCYcamINIfddxCU kgTdz4N+aocIuCvb8W+8dRL6owigk/5c9bjKxqe+tdAiduUR/68q4RkQ3gdv JDEdlNB8rMMj82CIfx6hG92nkn/zMlmG/bCr38iOS0DnmIkh1VHsCGfrykTA Vlfw3JE+ezAEpfPhM3tph/68RfmJyNxtwK1XfpA/BdDVQgigrn8oxzTxMMEz tIQivtSGOaK3TkwI8ucQ4kqZ80fg9DlM5k6stUlXbokETlLqvllbyWQVbZ2M K6sPSWZOlR18Gj0XicR/A8cFGmPV6N8E+qxHNR6CyuB5SqlpLGRSaIp0p6an rQm4qXg8I17B6iFWJhuPszGCcUXeMVtuwbPYtnszI/dh6vTCI7shTExrBi0b KB9QQdBoMZ9JEQWDdtjvulmIS6MxjFvJVoTygeBZG8DRsqRZKhN/8wFhABm4 rEaubki8CR6IjkSHaINQ6a1QdO5ISCcc5KzDjYy8jz2zKBPd1bNBr5pmASga ujhKl4uYSDpj/MRY0OO85v2DDn4JsNuYemtjt0Y4/J8hpYxoR54ahSJWcNec 3eWsC3f1qZTKcAtfD/H5f8Y+/eAjgTXwSp0gwxmYsSrgZnbDYhQaqqOVze8K SeAUHTNZZfL7QZhJl5nOzMiqXSVSZHhM0wo+gpWIjvvCBgrd17rEWu7vm4b5 NDfXlQvBd6eY5rtxzPJjPoV5EIg2mtE2w3wE0OiHCmDU8M7/BQotCkU+6GAL UBrPwjVAWL8IkG145eAxYkBDFkSs1kQEeDNyC810GsxL+TCFo8Vu9CM1fqyu QACdBrO13HLo8tzfUya9hoOzFWCmWYtDbCE7/VS6/9+eAnuhPk1Yi4sHpyJf fLsjF3h3e71VSsBDvDMx8IuRSfu1bNRERAHVrRiDUPknxsPDqDdUhRGbmakB CPj+hPlyGaEBcHsBAma8aisHRasJ/RjVlff0PmqudzevZ1o2vy4lTEnUgtfP MjW7soZbCHuzu80IrTeRIkEag9iMoQirkzTDCQFLPAxhN8VgKQeDvK/nMwPZ W3ZxdN4Sx0J8op8FzsZmIsvITem1H9y6xXdUEimId2er414+Fp10lL/JfboM R+qWL+CrSFsPAJy83rr0gc2YJRTfwu4OYLwSNW55dyZIP4cuZm0M+b48rg0x pYyj3mw4OfZ8idxcddBr2tm1XxPzvSVmuN5lnNM+m7pyADkCIvZInk0zH0ez Kv95ASVZTMkhQENpDHJ6IO2qL02iGGrn5yNOMzAyfFOsrZwd1baRjzWyWWHo i6qi/aYFGtbqCFx3H/CkXmBiVIULnfpUamgM/8UBBgWcQlpb0mZin+AZKs5G R3dpd0D8cAs7rxzrc20vYJbvHt9X/OVwtH5aVvSoJHocch5Z/Pp2h9wd22xy VSJKxuR0wez1EWeDTVmzCI3KbblzOFwnlbo3r30zgOfvD2juhMhXGGx8O4Xr mn/vnw+03i8zt5HXpkKhx7NcPDW9/0hWJhnPPPl2dRz8WrDY7xF5X9WdI6JY pWFiHeRuNF6qg49SyBXypZ/Ptc9wliXnPavzEzjI6h6Dxh7wXC85s+q7OikC +XVHh9S3/xLAOKoktU21EpNybVWeG3siwA/GeD+FZSrEjR3PAxQcT7qSCisz izurn3C0AZEaVDnz82WuEtuCPLBuWn6opxuXghelAWCv+/aHJk+8Z6DVE+aI lY7QJ7CHXoLM6k2mM90fPlK3meBpx7uTZSn93YVGQXDLCbTVbUYu5A9dBj6w 161Mes+97qrmIaruri++Prt+fhp4uAe7Ffvg4dV8ClzH0GFCXplwpA60EXfr cPpzLAPLa1JNSBPI2SJf5MqueVLL5W1kvpDe45SEjYJ438UkafUUGJzFxy+G kvLM13N4qvEuN8S1eEB/TbUQGQpG5TTBGcPGBNFG/c/hA8AqK9tcPuT2BkAC gFLTsqo/DiBmWgHhQSMjf9RYhlezZnDePGKZeJZod9WnV32PVR86KKtovyl4 6nN9QVY18bmB2hmwTM2pSnRkrXXaIqlIYwhtBQOqDZxVrN4xpXdj5W5lLG1B hVAWKvt26g4Gsg5wwLIIOtN7fjfY/iqrZR+PpSOtK6Y1BKFQJSQKf8l1/g7B lVTbDQQM6ZnUP9GRJyCAferKtD7LR3+DdFL2q80GKuVPHo+VXBmr+3BDU9v1 D50tkr+NEV2k7HYDWzCqfn2nsfRos5cmn4dD9h0khtEj0EDdX0BzZusXXtmB eI9CE/47StByzTNwvvvgjGhdERSeoa9hLLCwglTCylUU3WiFqwDFecZf41vU Z0WS+AbiCncBAD/ANi/f/ZdKKJclSG5SJjfUofetZRhTkKXC7qvK2GaAQPvm 9wSa9qaQEsDUu5ryMpCg+bS8ThpwjsnY3MPuDD3SdGLRPm7PGySmYtb6WstP 8R13ikdEiWJztBRnNeXaTyJY+kTnTlMwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKY2xlYXJ0b21hcmsKZW5kc3RyZWFtCmVuZG9iagozNCAwIG9iagozNTA5 CmVuZG9iagozNSAwIG9iagoxMDA0CmVuZG9iagozNiAwIG9iagoxOTczCmVu ZG9iagozNyAwIG9iago1MzIKZW5kb2JqCjM4IDAgb2JqCi9CSUlBQUErQ01F WDEwCmVuZG9iagozOSAwIG9iaiA8PAovQXNjZW50IDQwCi9DYXBIZWlnaHQg MAovRGVzY2VudCAtMTc2MAovRm9udE5hbWUgMzggMCBSCi9JdGFsaWNBbmds ZSAwCi9TdGVtViA0NwovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTI0IC0y OTYwIDE0NTQgNzcyIF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9wYXJlbmxlZnRi aWcvcGFyZW5yaWdodGJpZy9icmFja2V0bGVmdGJpZ2cvYnJhY2tldHJpZ2h0 YmlnZy9zdW1tYXRpb250ZXh0L2JyYWNlaHRpcGRvd25sZWZ0L2JyYWNlaHRp cGRvd25yaWdodC9icmFjZWh0aXB1cGxlZnQvYnJhY2VodGlwdXByaWdodCkK L0ZvbnRGaWxlIDMzIDAgUgo+PiBlbmRvYmoKMTEgMCBvYmogPDwKL1R5cGUg L0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9GaXJzdENoYXIgMAovTGFzdENoYXIg MTI3Ci9XaWR0aHMgNDAgMCBSCi9CYXNlRm9udCA0NiAwIFIKL0ZvbnREZXNj cmlwdG9yIDQ3IDAgUgo+PiBlbmRvYmoKNDAgMCBvYmoKWyA2NDMgODg1IDgw NiA3MzcgNzgzIDg3MyA4MjMgNjIwIDcwOCA2NTUgODE3IDY4MiA1OTYgNTQ3 IDQ3MCA0MzAgNDY3IDUzMyA0OTYgMzc2IDYxMiA2MjAgNjM5IDUyMiA0Njcg NjEwIDU0NCA2MDcgNDcyIDU3NiA2MzIgNjYwIDY5NCA2NjEgNDkxIDYzMiA4 ODIgNTQ0IDM4OSA2OTIgMTA2MyAxMDYzIDEwNjMgMTA2MyAyOTUgMjk1IDUz MSA1MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSA1MzEgNTMx IDI5NSAyOTUgODI2IDUzMSA4MjYgNTMxIDU2MCA3OTYgODAxIDc1NyA4NzIg Nzc5IDY3MiA4MjggODczIDQ2MSA1ODAgODk2IDcyMyAxMDIwIDg0MyA4MDYg Njc0IDgzNiA4MDAgNjQ2IDYxOSA3MTkgNjE5IDEwMDIgODc0IDYxNiA3MjAg NDEzIDQxMyA0MTMgMTA2MyAxMDYzIDQzNCA1NjQgNDU1IDQ2MCA1NDcgNDkz IDUxMCA1MDYgNjEyIDM2MiA0MzAgNTUzIDMxNyA5NDAgNjQ1IDUxNCA1MzUg NDc0IDQ3OSA0OTEgMzg0IDYxNSA1MTcgNzYyIDU5OCA1MjUgNDk0IDM1MCA0 MDAgNjczIDUzMSAyOTUgXQplbmRvYmoKNDEgMCBvYmogPDwKL0xlbmd0aCA0 MiAwIFIKL0xlbmd0aDEgNDMgMCBSCi9MZW5ndGgyIDQ0IDAgUgovTGVuZ3Ro MyA0NSAwIFIKPj4Kc3RyZWFtCiUhUFMtQWRvYmVGb250LTEuMTogQ01NSTgg MS4xMDAKJSVDcmVhdGlvbkRhdGU6IDE5OTYgSnVsIDIzIDA3OjUzOjU0CiUg Q29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2Np ZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2luCi9Gb250 SW5mbyA3IGRpY3QgZHVwIGJlZ2luCi92ZXJzaW9uICgxLjEwMCkgcmVhZG9u bHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBN YXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVh ZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01NSTgpIHJlYWRvbmx5IGRlZgovRmFt aWx5TmFtZSAoQ29tcHV0ZXIgTW9kZXJuKSByZWFkb25seSBkZWYKL1dlaWdo dCAoTWVkaXVtKSByZWFkb25seSBkZWYKL0l0YWxpY0FuZ2xlIC0xNC4wNCBk ZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYKZW5kIHJlYWRvbmx5IGRlZgov Rm9udE5hbWUgL1RFQkFBQStDTU1JOCBkZWYKL1BhaW50VHlwZSAwIGRlZgov Rm9udFR5cGUgMSBkZWYKL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAw IDBdIHJlYWRvbmx5IGRlZgovRW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUg ezEgaW5kZXggZXhjaCAvLm5vdGRlZiBwdXR9IGZvcgpkdXAgMTA1IC9pIHB1 dApkdXAgMTA3IC9rIHB1dApkdXAgMTEwIC9uIHB1dApyZWFkb25seSBkZWYK L0ZvbnRCQm94ey0yNCAtMjUwIDExMTAgNzUwfXJlYWRvbmx5IGRlZgovVW5p cXVlSUQgNTA4NzM4MyBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRmaWxl IGVleGVjCtnWb2M7hGqXtoapfkWj0KoFKXMcmaeEzL6FtJk7LuveOxLUcrfP VGUe8hGFEWppqxCW7UutL2RmNeAZtkF8x3tTL4XYEccNFCmhmlMH72PrXF4C yJ/Gwg9tnYnn2R/kcLcr79oj9d92vgWvTOkxN6IZ7YoEqdfW/fN+a3/N4NkL mGQj5ZYKXZ+7TJVlVujfkMv67Edvo2/ZpcgXXJr1E/7ZGcLd0mvcDZk5i59N A9ao8FtHr5XvKKnFYdvcmMR89VJQAR0Z6TZutv0VPToQDKpiEuPV2TmQc3+N Mm00e37cQ5HJ30QChbj8FZ0OmNQlj8V4kt33U2Qs1Sapas7aQSB4jyKx0J8U l5TmbdGsLCs7xv7FnWJvQnzVrpxUx/ePYsNvSbPC5eYq+1bc7odEWhKpQsFK 5hjR/hsRqc+fqh8yYXtZjOUFhxXvMFHiKPcvZRBArZmnQfJHxoAH5oyE6dHQ v5mqXXd9iKfTztLqZ/SuYei8BJXn2jgugt2ysAndY1MsdOO+XsVVoBS8u2qz G4KG13EuDpJvhpaDBnK4IU6bXQdAwWrfCv1HxJOPNzV1xsqR5G2I3iTmgt7E S1fqivhOV9RWRgcyUNgsS1DLuws2mTJhgwHz1BhidxA7U7PJ5ttC1rMBFfZ7 nQeCINV1JkSTBkO9+frPaE6+E+ObZQVesb0FTDJJYgJex54dFVk2/jLZ8iJD U/KkbDVY7yFva7KjBLr3Ur7sNsREC1Vq7+z0VLp8u6dTe8sQ68IQRzM6iYk2 QZ2FfNn1nrogsKPZukoNM5Uza0zaS6ZFG25NE3D62b2rt/JxvBxsSNnfHlpv rniPVgnePEjUemcJfFR9mBetOJ/SRJTTZdYgFxgqvrzHnnEnrEFxl7YQkwHv 79YPo5QpjNigz6iGG+OBTgU2i0zdTtkB9MyqFF0MelpggGGKltWyP/qfcNyj vAwMm5RpqW9QEX1X+vrNyfBZz9gbULmhZUWT5f+i6QbzwLaGG8hc66uDRk8m wEnsDXDyXcnjmfy6mcTgJpU5SQKKa36S4Kn5ItPb270H2hscdr0dBa2iowkZ mowni2znaqNOyl+sA3BGlibAEUreG4dcFIOdewC7uRNUxzPCK/qCKZHVz7rg Z6YutXoQtjJOB81lC19kh0weMqsJ5XUW210NWSHsNkxKkhAQPWi9SGFl3ail afYrszL/QIMFUc1cqZrr10EpdX3pC7RIb3Y4QX4086MGQgfLz3f593NCn6xq bhlCqqjhXxulPEp9aVzdYuPiHEnyAXvK4SlIb9yDjGdB4vy+5MPdF+CM6/jB rG7a495Xq5WsjxUiEc5NTCQbbBA0Odj4g8ZLUQ3tIUq5xpsBKitSTDua92VP kOyjN70PHybXtZudP7dc0bXQlsfTACKg1mpBfO3qVE+vph2Q8LmL0R319qV+ y2NfjzLuUy758L0wdQhKSHyOfki+TX7a15WULUrT4eMUetdMlLzKFjWXLN9I jCs5tLbWZS7fqm1GDuHxw6VeWcFYfOA0VXjcVQUq9UScI0aMVhUmiiZdyPGv ydRglbiVwyA04sxpsa13waaePCP3azIzaAvBcv6VSwPN53xiJGXHOz71JsSY hq0tOFzLeze5N+rYBtiIZSZoPywrpBTnrVzuQj4qCP2DLMfQ9SiveoAylD/K we4yHN7Te0rflHjd+Z/ABTyJaEBZVYxKIPOF8IIkW9aKbWPGmOcJTuSx8CL+ 69eqRQZE+ZPWFf5bTooyUfj8hptz0ck2S/31Ilz3bydlE4yLjPncZxHHXh7X JtrgPeGBqwWTg1rzEfz2SDwxIF+8ozrPbJSyayjSg5j1xid62PwPv4os/35P +KWud2Sd8H1470WystNvZP3UKJk6mqurJZumTpkzzGQa0Dx3hqyXJGHdRIQR nrJZ/3wTBMQiHyEaci3fAEmCAYQOsSqaUtYCYyOxmKhRamH9dIEDgJiy+TfS d9gU3sord1K8wTM+P6I/o0TaumFSbCTXfEEDJlXN/4UARoaLgytRG59cfx7j /XuhDEnLK94igvdT6JndhFabF1IEGqrmsnYfe4j6lxMqrU4FOF2G/psc7yc2 GU/W8WHNyZiyUDehXRnHuSbU4U/wLV5qeT2xZ8JUfDxKZlLiHsswm9S2QdJH Dy4NA/fzSVnJg/vLzmTN7Oyy70OFDRvthD2m3SsakoL4j+whCUmztXNzCO4V prYUhpcqX3f6o5uBQZKaQPaNhMgpdQHC35UjDywWe/yHCBUjh6rgwkodk1Ew MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xlYXJ0b21hcmsKZW5kc3RyZWFt CmVuZG9iago0MiAwIG9iagozMDMyCmVuZG9iago0MyAwIG9iago3OTgKZW5k b2JqCjQ0IDAgb2JqCjE3MDIKZW5kb2JqCjQ1IDAgb2JqCjUzMgplbmRvYmoK NDYgMCBvYmoKL1RFQkFBQStDTU1JOAplbmRvYmoKNDcgMCBvYmogPDwKL0Fz Y2VudCA2OTQKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9udE5h bWUgNDYgMCBSCi9JdGFsaWNBbmdsZSAtMTQKL1N0ZW1WIDc4Ci9YSGVpZ2h0 IDQzMQovRm9udEJCb3ggWyAtMjQgLTI1MCAxMTEwIDc1MCBdCi9GbGFncyA0 Ci9DaGFyU2V0ICgvaS9rL24pCi9Gb250RmlsZSA0MSAwIFIKPj4gZW5kb2Jq CjEwIDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRmly c3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhzIDQ4IDAgUgovQmFzZUZv bnQgNTQgMCBSCi9Gb250RGVzY3JpcHRvciA1NSAwIFIKPj4gZW5kb2JqCjQ4 IDAgb2JqClsgNjY0IDg4NSA4MjYgNzM3IDcwOCA3OTYgNzY3IDgyNiA3Njcg ODI2IDc2NyA2MjAgNTkwIDU5MCA4ODUgODg1IDI5NSAzMjUgNTMxIDUzMSA1 MzEgNTMxIDUzMSA3OTYgNDcyIDUzMSA3NjcgODI2IDUzMSA5NTkgMTA3NyA4 MjYgMjk1IDI5NSA1MzEgODg1IDUzMSA4ODUgODI2IDI5NSA0MTMgNDEzIDUz MSA4MjYgMjk1IDM1NCAyOTUgNTMxIDUzMSA1MzEgNTMxIDUzMSA1MzEgNTMx IDUzMSA1MzEgNTMxIDUzMSAyOTUgMjk1IDI5NSA4MjYgNTAyIDUwMiA4MjYg Nzk2IDc1MiA3NjcgODExIDcyMyA2OTMgODM0IDc5NiAzODMgNTQ1IDgyNSA2 NjQgOTczIDc5NiA4MjYgNzIzIDgyNiA3ODIgNTkwIDc2NyA3OTYgNzk2IDEw OTEgNzk2IDc5NiA2NDkgMjk1IDUzMSAyOTUgNTMxIDI5NSAyOTUgNTMxIDU5 MCA0NzIgNTkwIDQ3MiAzMjUgNTMxIDU5MCAyOTUgMzI1IDU2MSAyOTUgODg1 IDU5MCA1MzEgNTkwIDU2MSA0MTQgNDE5IDQxMyA1OTAgNTYxIDc2NyA1NjEg NTYxIDQ3MiA1MzEgMTA2MyA1MzEgNTMxIDUzMSBdCmVuZG9iago0OSAwIG9i aiA8PAovTGVuZ3RoIDUwIDAgUgovTGVuZ3RoMSA1MSAwIFIKL0xlbmd0aDIg NTIgMCBSCi9MZW5ndGgzIDUzIDAgUgo+PgpzdHJlYW0KJSFQUy1BZG9iZUZv bnQtMS4xOiBDTVI4IDEuMAolJUNyZWF0aW9uRGF0ZTogMTk5MSBBdWcgMjAg MTY6Mzk6NDAKJSBDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVt YXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjExIGRpY3Qg YmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEu MCkgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBB bWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNl cnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01SOCkgcmVhZG9ubHkg ZGVmCi9GYW1pbHlOYW1lIChDb21wdXRlciBNb2Rlcm4pIHJlYWRvbmx5IGRl ZgovV2VpZ2h0IChNZWRpdW0pIHJlYWRvbmx5IGRlZgovSXRhbGljQW5nbGUg MCBkZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYKZW5kIHJlYWRvbmx5IGRl ZgovRm9udE5hbWUgL1NFQkFBQStDTVI4IGRlZgovUGFpbnRUeXBlIDAgZGVm Ci9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAx IDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1 NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCA0OCAvemVy byBwdXQKZHVwIDQ5IC9vbmUgcHV0CmR1cCA1MSAvdGhyZWUgcHV0CmR1cCA2 MSAvZXF1YWwgcHV0CnJlYWRvbmx5IGRlZgovRm9udEJCb3h7LTM2IC0yNTAg MTA3MCA3NTB9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDAwNzkxIGRlZgpj dXJyZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK2dZvYzuEape2hql+ RaPQqgUqAUJnt5BOs8DTvQuD2JEBbKbKS3Eq3rJY+quaEw7mBeYfd/wbc4q8 fFHNRu+BcZCY1f7mdmDmmnq5G1jymk155XAi94PrD7u21PTsNQFP0t7LqZRZ pMWd8MbroVAoRFTnB9whAMFbdrTBm4Q2N1hGmmxVh4WyJjMhUhCYcamINIfd dxCUkgTdz4N+aocIuCvb8W+8dRL6owigk/5c9OnSQFsWnNU2XW7O1ddo1m1s aGGLjEgrNB+Mo46bubr8+q2cLz/QM7YmkJhu1D2ck2E2RbgjktXK4Rp8tJ1+ LoLc1IXLoXcs5CK7HXKDrWdbZUin6gBpqIPsHao+H57OdYbWzwoSjNVXx+XX qj6pfrrTlhnRv89KbWR2h0Ht6gpbDvu/NHzcvi4D11aWeha2E9sPxF+iozEu DEal/QRmqwl8WP/uxAYBuDleUnddCvzX24qzFzMxEFMeXESky0tazVcaGmCW CxXkUJSKXuoU3TMP6iCSZduOGh/IDc04YDI/0mwROwQaiMiKIWVYeGgKRGb6 EEA9JLuXFSpJuELBgOTSWMnUjyHQV3gtkGIxFoMLo5kCs8Xy8t0BQzsNcJnA fb3iaND/7VFpvNA9SLLwWK1i2GeMYm3Ho/NSFSyZupY++V+K0R24sNNRIQoX 5MLFWtietkFyk108IKOY8+7uwxVRlmp0OO8/7kIsbU4FM3Yg1azHtSvtmEv6 rTbvnSB0iwXQe+RBSmOXUSXScvrYP3bmEP/4NjAUvlJtWAhzxaQrcPqRHse4 aQXxOv5V6wJz9YKDFYeTuMwpa43h3M8SUP1Xyw4DXH7aOwCS7ZQNN6BUky7F Tgm5hPykq30uoYK88SY6okSwfsDqkvmvNLNMHES4Vq0QwRjwNWLmjB1n5KhB TpTTqgfa0SbXj+m2+5ori8KTp8S7lcmCtqOk4T8XzOnADOrsXFNl0GvprIH2 4RfPZBjkjFYX8wdQemptU4MOyKwW36RqOy3oMECAHDMAcR4hzCweYZB5yAss ygSWDmB526ppqGu3ORFrbW9zckH7fn134ofahyTEpHS6GfOvzuKmdJeu4iZw eDoLzN9KLBGL7E2GZbDy7icAltdFf0EiThfzTJLL/j+IZEa1r0fbqb1Tp+0f +kP9O1gH9m6VVdtI8nGV3VhJr08hctpiqcPfh1p8o1K7SkqlzI5LVINzZCyx vS6GeqGyTxKaC4+RX0FDqusRW23yw9Q2OUVFNP2RVN8Jog/97khd8zPNwdkZ pD4kl8ObZ9IeZAvORmEF19gasHDa/295yez+DFoJSRBA0zLgT4vYidRYWL6H BSLSlcg73D0nSepILypZ6oG/LJbHaDjphGqjkG6GzkTzy944p3puRAfCjfvB sNbzNOqugwotRJ3BExodkyTnpuMOsGXIrycSygAUkYKtUPgxt2TvtpsJpjrU qK+OIrBcgCA/L01Fpol5RV14Gg6a7nt/XNLoDjYnIHKHvr7PBVyY8HwzVST8 Ev2KUR9AsnIMH8HVEnJ9D6D9PGA2A9K8yUn2PMvpOxpF/Yy8/5nOP1WcQLOA OQ1DxWTBhJ4SVBuNhfYSwgMj93PKqn0GydGtPvUyiivS18gQVAXf7EkrPn4t pmqTvTtAikkInrADb+0ApHJ4nkgboqnAwTsMZhd8xxCEkUWOd4eYjpcboguS dHSu+9rk5676CRO1q++xWJuUU7KvKYm8UuMLSyLQnjG9T0ODXjgI5fjp1ths SMmPkMDFcpjRZOK9bGeI1lsLRChSiy13ubeUMW1MJEgzplQ3ZAt87nusETtN /K/0ioYFmpRlnoa3+KDB2B668VTCahKMzbrBD6MS/K2RtDfiLFiwDL24Zk++ GOtJbE7HH8BqRL2TRPTYRm6OsGM4Oz8ZdQOZ6j6UjPIBgsmgLq7L1hkqp5PI BgSFSVCkO2QOVSzad3l1nPXIXxzkQfct/DNFZ+5C9Bnev13YbxcxU+zDkM8Z 7Xf2VSIsVP0+bGaJrlQsvLNX4yh7IwEXNdiQ0ztO7CZeNvSiAW5TJ40g314o JhCPDpJ/klbGfMp8sOrY98GFLTwQ9A+DnuY3mak8hlW9hBImUYsOXNTRB8Pl axP2MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNsZWFydG9tYXJrCmVuZHN0 cmVhbQplbmRvYmoKNTAgMCBvYmoKMjkzMgplbmRvYmoKNTEgMCBvYmoKODEw CmVuZG9iago1MiAwIG9iagoxNTkwCmVuZG9iago1MyAwIG9iago1MzIKZW5k b2JqCjU0IDAgb2JqCi9TRUJBQUErQ01SOAplbmRvYmoKNTUgMCBvYmogPDwK L0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9u dE5hbWUgNTQgMCBSCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA3NgovWEhlaWdo dCA0MzEKL0ZvbnRCQm94IFsgLTM2IC0yNTAgMTA3MCA3NTAgXQovRmxhZ3Mg NAovQ2hhclNldCAoL3plcm8vb25lL3RocmVlL2VxdWFsKQovRm9udEZpbGUg NDkgMCBSCj4+IGVuZG9iago5IDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMQovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhz IDU2IDAgUgovQmFzZUZvbnQgNjIgMCBSCi9Gb250RGVzY3JpcHRvciA2MyAw IFIKPj4gZW5kb2JqCjU2IDAgb2JqClsgODI2IDI5NSA4MjYgNTMxIDgyNiA1 MzEgODI2IDgyNiA4MjYgODI2IDgyNiA4MjYgODI2IDEwNjMgNTMxIDUzMSA4 MjYgODI2IDgyNiA4MjYgODI2IDgyNiA4MjYgODI2IDgyNiA4MjYgODI2IDgy NiAxMDYzIDEwNjMgODI2IDgyNiAxMDYzIDEwNjMgNTMxIDUzMSAxMDYzIDEw NjMgMTA2MyA4MjYgMTA2MyAxMDYzIDY0OSA2NDkgMTA2MyAxMDYzIDEwNjMg ODI2IDI4OCAxMDYzIDcwOCA3MDggOTQ0IDk0NCAwIDAgNTkwIDU5MCA3MDgg NTMxIDc2NyA3NjcgODI2IDgyNiA2NDkgODQ5IDY5NSA1NjMgODIyIDU2MSA3 NTggNjMxIDkwNCA1ODUgNzIwIDgwNyA3MzEgMTI2NSA4NjkgODQyIDc0MyA4 NjggOTA3IDY0MyA1ODYgNjYzIDY1NiAxMDU1IDc1NiA3MDYgNzY0IDcwOCA3 MDggNzA4IDcwOCA3MDggNjQ5IDY0OSA0NzIgNDcyIDQ3MiA0NzIgNTMxIDUz MSA0MTMgNDEzIDI5NSA1MzEgNTMxIDY0OSA1MzEgMjk1IDg4NSA3OTYgODg1 IDQ0NCA3MDggNzA4IDgyNiA4MjYgNDcyIDQ3MiA0NzIgNjQ5IDgyNiA4MjYg ODI2IDgyNiBdCmVuZG9iago1NyAwIG9iaiA8PAovTGVuZ3RoIDU4IDAgUgov TGVuZ3RoMSA1OSAwIFIKL0xlbmd0aDIgNjAgMCBSCi9MZW5ndGgzIDYxIDAg Ugo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTVNZOCAxLjAKJSVD cmVhdGlvbkRhdGU6IDE5OTEgQXVnIDE1IDA3OjIyOjEwCiUgQ29weXJpZ2h0 IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwg UmlnaHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2luCi9Gb250SW5mbyA3IGRp Y3QgZHVwIGJlZ2luCi92ZXJzaW9uICgxLjApIHJlYWRvbmx5IGRlZgovTm90 aWNlIChDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2Fs IFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQpIHJlYWRvbmx5IGRlZgov RnVsbE5hbWUgKENNU1k4KSByZWFkb25seSBkZWYKL0ZhbWlseU5hbWUgKENv bXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9XZWlnaHQgKE1lZGl1bSkg cmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTQuMDM1IGRlZgovaXNGaXhl ZFBpdGNoIGZhbHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFtZSAv WEJBQUFBK0NNU1k4IGRlZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250VHlwZSAx IGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9u bHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBpbmRleCBl eGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCAwIC9taW51cyBwdXQKZHVwIDQ4 IC9wcmltZSBwdXQKcmVhZG9ubHkgZGVmCi9Gb250QkJveHstMzAgLTk1NSAx MTg1IDc3OX1yZWFkb25seSBkZWYKL1VuaXF1ZUlEIDUwMDA4MTggZGVmCmN1 cnJlbnRkaWN0IGVuZApjdXJyZW50ZmlsZSBlZXhlYwrZ1m9jO4Rql7aGqX5F o9CqBS8J+cit6dkHwFi4fptpZH1TNZ5RIWd0pOqh4rWOwxdr0RhKYzuVE3K0 GY1OjF70ohOstYqgpliQgDW/LthTF3mDipYN/isn6knDcVaYnIXiGzq/cuOa iSMs2fQjf8gMnmToQlqjvvfe1gsSKlKSKiIaN9moB90BFhd53efV/BshCYOe W1Lfuyp8G12OfoqgWxDqQ9ao7WGvWyPUmSDY952ralkGITTYSsAQAYemzR+A 9d3Z0iKsscIzJqdlamNcSiQczTLL/fg2Mga4qjbhBxR39UlhEeBVx0kQAq/y cuRuzEZCLwOA0JMoSHACJSP72hcWzE8uLMrV8XP8vm7duHStJVzV5cD4YhQ5 P8tfXCCcPCu1iG42/DzMIUg8OsGTSFpG6dIr1yAYlOTUWt2b8cxc9qUBC1ZU rAvg2pA9tWOxOEC6MBX3LlHjvIAVfj4FBWav9gtTEP2mZvGrL91AHc0KrZI2 m/qKTd8rihwcRV5vqCHUR4nHLI9WvslXj4ryZAKcnQcgtCHbkk/RSavf9H6j /U0QVLvCtrFpiRotBkRKYZMFYq8om+Oo7xG0ahndoK1ADpVYMlhALAdUf9K7 hcHqtcZyWOtBTQ+nhyDjZxbDKMch0quHwbQ6pPhUIoi/W7n4RKHbcz/hSoWt Gh3uMJTWosPe+DB7s3IQyASOLjwE0zaQaWweBfUGOPSMZR7tl6yym69hK9da peejK7XNFHnvg8SWg1Wgh48C8ZHsB924rKgPX+hQUnYLKnomoSkY2xlihSa7 SDyZ7IHYeyxZxHN2P5W2mBReEzJcIOMGW3bEZcRAdmr4hk2N7Z72juoEXZWQ G8iwW9QUYhrUOs5MSQ7yasOfJ1q1huK9DLfpKdj+iUuN4F9xjLFoUN9HfwOF 9dAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xlYXJ0b21hcmsKZW5kc3Ry ZWFtCmVuZG9iago1OCAwIG9iagoyMDA3CmVuZG9iago1OSAwIG9iago3ODUK ZW5kb2JqCjYwIDAgb2JqCjY5MAplbmRvYmoKNjEgMCBvYmoKNTMyCmVuZG9i ago2MiAwIG9iagovWEJBQUFBK0NNU1k4CmVuZG9iago2MyAwIG9iaiA8PAov QXNjZW50IDc1MAovQ2FwSGVpZ2h0IDY4MwovRGVzY2VudCAwCi9Gb250TmFt ZSA2MiAwIFIKL0l0YWxpY0FuZ2xlIC0xNAovU3RlbVYgODkKL1hIZWlnaHQg NDMxCi9Gb250QkJveCBbIC0zMCAtOTU1IDExODUgNzc5IF0KL0ZsYWdzIDQK L0NoYXJTZXQgKC9taW51cy9wcmltZSkKL0ZvbnRGaWxlIDU3IDAgUgo+PiBl bmRvYmoKOCAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEK L0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyA2NCAwIFIKL0Jh c2VGb250IDcwIDAgUgovRm9udERlc2NyaXB0b3IgNzEgMCBSCj4+IGVuZG9i ago2NCAwIG9iagpbIDYxMyA4MDAgNzUwIDY3NyA2NTAgNzI3IDcwMCA3NTAg NzAwIDc1MCA3MDAgNjAwIDU1MCA1NzUgODYzIDg3NSAzMDAgMzI1IDUwMCA1 MDAgNTAwIDUwMCA1MDAgODE1IDQ1MCA1MjUgNzAwIDcwMCA1MDAgODYzIDk2 MyA3NTAgMjUwIDMwMCA1MDAgODAwIDc1NSA4MDAgNzUwIDMwMCA0MDAgNDAw IDUwMCA3NTAgMzAwIDM1MCAzMDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDUwMCAzMDAgMzAwIDMwMCA3NTAgNTAwIDUwMCA3 NTAgNzI3IDY4OCA3MDAgNzM4IDY2MyA2MzggNzU3IDcyNyAzNzcgNTEzIDc1 MiA2MTMgODc3IDcyNyA3NTAgNjYzIDc1MCA3MTMgNTUwIDcwMCA3MjcgNzI3 IDk3NyA3MjcgNzI3IDYwMCAzMDAgNTAwIDMwMCA1MDAgMzAwIDMwMCA1MDAg NDUwIDQ1MCA1MDAgNDUwIDMwMCA0NTAgNTAwIDMwMCAzMDAgNDUwIDI1MCA4 MDAgNTUwIDUwMCA1MDAgNDUwIDQxMyA0MDAgMzI1IDUyNSA0NTAgNjUwIDQ1 MCA0NzUgNDAwIDUwMCAxMDAwIDUwMCA1MDAgNTAwIF0KZW5kb2JqCjY1IDAg b2JqIDw8Ci9MZW5ndGggNjYgMCBSCi9MZW5ndGgxIDY3IDAgUgovTGVuZ3Ro MiA2OCAwIFIKL0xlbmd0aDMgNjkgMCBSCj4+CnN0cmVhbQolIVBTLUFkb2Jl Rm9udC0xLjE6IENNVEkxMiAxLjAKJSVDcmVhdGlvbkRhdGU6IDE5OTEgQXVn IDE4IDIxOjA2OjUzCiUgQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1h dGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkLgoxMSBk aWN0IGJlZ2luCi9Gb250SW5mbyA3IGRpY3QgZHVwIGJlZ2luCi92ZXJzaW9u ICgxLjApIHJlYWRvbmx5IGRlZgovTm90aWNlIChDb3B5cmlnaHQgKEMpIDE5 OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMg UmVzZXJ2ZWQpIHJlYWRvbmx5IGRlZgovRnVsbE5hbWUgKENNVEkxMikgcmVh ZG9ubHkgZGVmCi9GYW1pbHlOYW1lIChDb21wdXRlciBNb2Rlcm4pIHJlYWRv bmx5IGRlZgovV2VpZ2h0IChNZWRpdW0pIHJlYWRvbmx5IGRlZgovSXRhbGlj QW5nbGUgLTE0LjA0IGRlZgovaXNGaXhlZFBpdGNoIGZhbHNlIGRlZgplbmQg cmVhZG9ubHkgZGVmCi9Gb250TmFtZSAvUVNBQ1dHK0NNVEkxMiBkZWYKL1Bh aW50VHlwZSAwIGRlZgovRm9udFR5cGUgMSBkZWYKL0ZvbnRNYXRyaXggWzAu MDAxIDAgMCAwLjAwMSAwIDBdIHJlYWRvbmx5IGRlZgovRW5jb2RpbmcgMjU2 IGFycmF5CjAgMSAyNTUgezEgaW5kZXggZXhjaCAvLm5vdGRlZiBwdXR9IGZv cgpkdXAgNDQgL2NvbW1hIHB1dApkdXAgNDkgL29uZSBwdXQKZHVwIDUxIC90 aHJlZSBwdXQKZHVwIDU3IC9uaW5lIHB1dApkdXAgNjUgL0EgcHV0CmR1cCA2 OCAvRCBwdXQKZHVwIDY5IC9FIHB1dApkdXAgNzEgL0cgcHV0CmR1cCA4MCAv UCBwdXQKZHVwIDk3IC9hIHB1dApkdXAgOTkgL2MgcHV0CmR1cCAxMDAgL2Qg cHV0CmR1cCAxMDEgL2UgcHV0CmR1cCAxMDMgL2cgcHV0CmR1cCAxMDQgL2gg cHV0CmR1cCAxMDUgL2kgcHV0CmR1cCAxMDggL2wgcHV0CmR1cCAxMDkgL20g cHV0CmR1cCAxMTAgL24gcHV0CmR1cCAxMTEgL28gcHV0CmR1cCAxMTIgL3Ag cHV0CmR1cCAxMTQgL3IgcHV0CmR1cCAxMTUgL3MgcHV0CmR1cCAxMTYgL3Qg cHV0CmR1cCAxMTcgL3UgcHV0CmR1cCAxMjEgL3kgcHV0CnJlYWRvbmx5IGRl ZgovRm9udEJCb3h7LTM2IC0yNTEgMTEwMyA3NTB9cmVhZG9ubHkgZGVmCi9V bmlxdWVJRCA1MDAwODI5IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVudGZp bGUgZWV4ZWMK2dZvYzuEape2hql+RaPQqgUpcxyZp4TMvoW0mTsu6947EtRy t89UZR7yEYURammrEJbtS60vZGY14Bm2QXzHe1MvhdgRxw0UKaGaUwfvY+tc XgLIn8bCD22diefZH+Rwtyvv2iP133a+Ba9M6TE3ohntigSp19b9835rf83g 2QuYZCPllgpdn7tMlWVW6N+Qy/rsR2+jb9mlyBdcmvUT/tkZwt3Sa9wNmTmL n00D1qjwW0evle8oqcVh29yYxHz1UlAD89vlvwey6D5mt/l93Xzg7rdaeL2S J781nQAratuKxXoz/tTvAhpwhbHiuTPeYC8P9xRn7NUBdErjOK8poCb302is byXMuILbe3NDVmGSvWh+E0kiWYKCMCfTtmcDOw23p+aApoK5gCPTnH+ugaXV uGegpmyKoNvIOxWWqE8ENqxqeQC3Z73M4AYKSBEAPHn9zHHXP38tCmZ16TrS Gla0zY73Xu096MChi+v3udG+clBIctVu2ycvHpf8cmy2aMhccTBZ2hn2wuDz 4ScQpZtvxGma6IPejIYVtykqwlzVcUts+xTvDvEesTAJvrpPNFpdPW2ZJqvC utfbEyhlHkN7+zxG2ntiIZZg/DaM89NwTa06tGHCj3EWZb9IS/YcBSCT0jHK ZWGOpGPWPkBuzoWNGApsBYmy/twyE3HCjnfel01lXfX/fUHtAf5xfZKKiF9v ps/k0sCAf45/k3kW4Jbt0aO6Z4ArH0pJEA51YTugNW2dy7rU2rPFnnCkcFj1 IWPRcw8O5NH4fDpK5yOiPP15hvxPvTmTR+n1lGNU4BPYYPxEav8LB0T12ifM d3yWrbOI0eg13cvhI/tRdnm5t+5aPd3NOSQVr1jOIupVt/RwMROMbyd5i0D3 4Y/dMVkSvpnzOt4P3VOKij5d5Yr2ilRzKuafGI8/fgRY2EggVkjL6CDCh63C OUUg8Du7l9uJP2oSFUsbf4Ym01zmtw+FJMsSjeh4IaDjLx6CX2xQrotL43+q MYO6TWeOiWzH5hzJ0CJvw4ucrgk50ZFJ2YeXm5aobraaEFgHq0JmOSkv9fvv 8IF/z9XlEdQsX1RoA0D77SHHR24ixUmPMpXvyPUVxWEv/2moy/Fz/pLYM2uW xDM/h+EugfXlp0xk9GUjWY9UWkmJeheyJ16RB/PzHN+kgUXs1lv/PTgjvc8Z xrA+x4CHZa9PGwmlSk8yGAUUOUabiojrw1NIjm+av2so+OcyufGhH9b7BPg8 ehFlaHrPjrQZTt/dBmidOzWdnmN9TpB43bc6Hn/0Dt4sSn21pxXktDaZ0TG4 5aId1YhU/mTmGVIJtBviY/RqJKeOfaQUFhCyAGUG3AEaffuQRm6kDtxg6QLg JpVug+Rl68hYL+NYlxaltF9uqqbt6hPMNNBDpsP4phhcm3pS3FtAKs1poqx0 M29N3P96IKvrU3CQXOtjpoV8rdO82fnXxHZjf0zwYzwFCLzc8ddEMWQxSzPe tWBQbnpoodmHtJSO2T1OyWiITFAZMzW6R62ffOdsLv0SpbxVzAsG9Gxycp1W Dw21iqUHB/ppgpMHRCgotkKxyi8jtqJG7Jxyg2eYXrVXEJvv9zr/umUo6CV1 SHynZCFnWv4vfKJlWNJa0eiKnCxAqteFI1VnErA0F7KGidUzc/qXEQTwGi5+ STO6kgIFVMAB0KZjSPl6aVG5TU9bF/ZrWIlt3c8dppMe4MzjG603J9UXE2C2 paQp/e2BaOVtGGK1lLUf/YN6jZ8hzTmEIUik4Vb5smAYEyFuhJ4unpLjD+ub iWPDO/OAJkFI2/NKy/OcS5cW2DQk6mdiFK+ZfUo5ncRNYMzev77z/NxpiHcO 6FH6WLbObCSRyCZsVQ12Hy1MXrOMsWGQ5WYlfxWR2cSEaB7ya92kgjng2tGc NmIUItUoYe0WolMOH2/KmpWYsd+xf9LBmnnaQWgzlIr1UcdjnCi3hN6w0LzG 0LtmAxarCIbu3sI+OD99t/BT3gZlAXEpzmMNjAseRTM+yutB8Bdtn7ttSO3i 3vXO96zeJEolZhpdLkK+v2N3vJ0SIcPHiM0JNrcOmr2hQCLT1ocJvLN2xtk+ 3zPPUsI/80s1HjjuOtvSjzap2rzC95FRU6K98Q4j3azBuKBNslyy7zroPpsO yPWBom+ZWJxYrmBsjSZu5YGOa7QNNNcaNGbUisT4rx6js/fw04Fu6Nd3bAgr Bxe9j4kuo6Nzp+S/O5FgVe6fwewT55u879mwRRU/UX/CXb4a2g9KS8uB5ByY WJ8u34eZmrx2r+75Pwr6n7OFYAtQSX89SAQxLucg07vvaaPlqHjnxD+7Zzlf gziAwV0OYxEm4WCFB9JzFawoJhYu+Gf0+lv752djzU/itM7rLlSnMHW0Acvj q2eSbTUmVMzdUHLwTAkCvZiKpWYBFAC3HFl1zmabeb84x0VoN3Cc1GPY6b4e uMuSOUsclCMagm9fVf5YZMM5wttl5vy7TLkKQf0+tMzny8hxT71R1kZMGP6I 3Pleke6loiel/gpX9yxAbKFjj9qvaksKH+5qSnxw4ohg0sP7YXWiGFb4zJns 7U4vHb7BmyRyVYfh9fmZiIK9zA++ZtuILrLyO/oiMCV8x2AeOH98fI2Hmk6d CJjzza2QjXo6CCIdiJKI7TFk+yOQ2CQzO9MiTkZ7NshseMOEVellfikovGdJ mX9etcq1C2yT2VTWymmSKcRmWns9/C485/MTXpVnoP69WUppoHUq98KSGTMw CJa9ymKLDDVhy+xPzgfLpVgWMCyUADGNfPpfwDqoDG0shToNdRZ/t7AA65QW Jj2v//aXwY9IaktV5T/FWis38T0BiPBc7O/D7OzReBPoB1CksbWzAWXzjNrX bktqyKAAyu+IfjIfzxCkZzu8n3uQhMB0QOb+Q6OvhqNSl4ka6hUk6Mu8V1vF r6ChLvTlaf8gt6iRPeSItur44M3HuKMm+EHe0LIu2zQnO39jP3nDgJ8aKqVR 1eUzezpLlhVsaKVfO/YgwN1HT0uqeR8DNbsUZjgOLMdBPRcih5QAtdLAUfAq KicVxbG+Kk6ZS9FGK4Kb4t31DhXO7E5YUt28IHS5Q3ykNbPQgyNaeAFkv4CQ k1HwiPoT2DFJ/qEaCWe/2dFnxeeS3T2ySyfl6AQDsEn/seFWNTo1RTeX45lx 1TQss8krCJC7Qvs9rzThBjlRSe/0J+FMmI0J8OBVTQe7UAEnUOoDTLfR5g13 L3LecmyUP0RO8NrSUywaBUmlUC1DFoD3nE6HLfPfWqB822yi/Vr4mgUdvC9m DtaKhJv3iEUH3DtvvveFvfP/OtBv273GErryj30X0tpjIWQVp4PhOI94SohH oTXzFih59iGeScL+8Lt2w7IuT+dR4XyStYWr44vDVZ9r57PU521Qf0oMFlJc xjQkjiQnfixilVMhCxllR19jpr7hjMJ3rt+iqoY9957PJ1UXFNCRR/oOuVqo B96dJHuwoZb5wmhuqp6Rlvxy4nnx8W1dT6fZvdS164cn4WEBHd6JR+H1MOV4 p3IOGBWa9fFwRKuhI67gblTp/LBC2nTAk7L8Ah40x/7szK+vcdppCr1cmV4s OFhShX/Z5qYbz3qdrPUAyd4DdAou+CabTiT0g38xmpiTDr2BWERbfOZ9eiMM JnDaw0viHjTQXl4pKSbSrdPLzfryMjEi1dws8TzMwMk95k4k3YofoM00jcUE /lSHuctDMLUW9F1R3TPOJ/cvmI1KvaCl9215WCkzAZw/tWbdyEdWIPNUrIiU dg8YHNTRT4SDFi2JfYOrmhjnxcQd+6ePck4/Yj6lBwn6ZyZq7eX0sdOmM4j9 mbZvZI0GmXcUUZSEbJw4W/EUsY/f8CyTJap4zYmy/uJjdIodYPgroPHTkuI/ /e85U2e+x3Qb5Dj7cm8FIKTMknh/cL9d73tNuWZWq2LIxx7vEYo4Pqgea8PQ hhzmC6w0KW9Z9e9CdOI4fwN72rjW0t9r0Umkf4OORMIiKUY/eroRUlkTCvby TdjJa7R3f/CbJQzWcomyIVtk1dqhyj0fRJAdtNsBKUJt+0scCHGcNi/mw2KX wUGKvsyfUJoiRvjRLoElkwj8m+WC6SSLyXJimQKi/Ev9JFy7YX7FWIYjp9qJ qXDwcREyyIL8TQJFFVmjjNC9hYe41i6W85PK3IPzTP2k0NxHXRlKeTmUapyr 4HUxlXhM/vOW24VG2RGjfxUEJyomwRqfvT5nzF+tYkxvKe/fUYTEY5mm4GAB 34CMhulmnrPvYy6MQzvJN8fSA1oxPPK6wm/jvUX9P8Sa0PaagVNlyIz3CahL PohSI4H3VlXoOjV67GIrwIG0VMWV4aToLd69f644GNdbcZBSs1gI5SY6aBuq huXgBMsOW5VrNSBKdKOdSsBaHlsdCbF91fwdvnFGmDhFXjP0wJ6lGsrWkAla a5GcV05DswWE6x9l2BDnXeD9Qa/sCi3fdGmddNLpdFASFf5CtSaZHb2lz+r6 IctkCjW0mizIVFw2/huzelST6c+J+sZjPyAzHzi4e5x0W+pErib7qwkKwNLu 04x7Yt1fbKS1X1nM8QDgHUGfu5H1jl2S//6n1MMGUYOqjV+zikLTc3hB3xLt qmfGkSvx417wAmx5GppANfRcBqsiYfUyeG5vsO8qgjwiXzmy3/DRP0ivUOxj xmVBXhMOkdkhAUFnhbBDKfeaNEoKEzc2tGUrhpcOE32LuAjKqcGG7I6Rk+PH NXcO8N5roA2Nnpf4opfnnZZFkdhfoZ/cQMU72CsPOG7n67X92HwptjeHAnDG G+X/1HNIYEBOGySUvcJaArchttFU1YhHn/JdEZX+4SRtW7pwgyvwNC1N+xEQ NNjsxXU9iQ//66d0yNPK+DUFMgYL9qIM7/Hj6sqfuBqPwhAEg9pArCpbAgU/ MEfg5QjLEPOm2EKej7/hzMGPMrwpjSqIx45o05GPyhgoKOFNAs5IGrlRPPag FSYcTjVwxQ4f2JWdmU3PWpeudy5J7U9TFGcCR08GiasC2cg4XNawQQw73Wad PnVRjN4jADUgsJEv+ZhRio+wrMaQewYciax8aZLSvsxq2vlyv7YHXuvxuKLX mm8JcA6cZVGZw4aOn4v2T/WC9nDjuYjFlm4oKBPwCKn4CCBShKyiEG/kELnS 7lvFVDz/BZSV5KeMyqDQEjZEg78eEab07eEyMqCmlobtUuXlQluvStY/trH3 WSg/tT2MNip+Ac6m2MhdKg4g1mDQ/qx9yicOI0MWVUgYjFXbMtaCYRi/aTlL 2C5K13v8/f+x4j4AyTPSlG/F/slhjLzyIcYu/NnK61P8A/9AnV045R6ENihJ iBlWNw2pYRk9uTqrHm0pIxXwpgUW9wv/+OUhWwtj4yL9cjI5qV9uZh9M/moG vp/DnXx6gx4Bj0f6xldER8GkQaA6fxxmpkHvmTjvF6/y+gzBYODCXDrPrI+2 y+9T+tYA4i2IFxklZcCMkvcPBQ9+SUAzC0eaXSlVezQJM+fU6OEYLzK4W8ta vK31UQ6S66k4A5UY4oYGvA8SnEAZ/7n5AGGOpi17VK8f89M6ahPQCaMhVs12 MUG7cThXDQSP0etKbjTWz39pSxvO43Vu+cQB/6JN9NP9qznmyCi3Yg85m0Ig Ee5hCuQZqA2BwY5UdsXD2ZT1VX7DzLwN+WQZ5mIb2Y2PIv8K1bj9zX2QUW7a JzCEdHc9ipdyrwbdg+WHZudUY8SM/ZS6s2Yf6dimiNDMr2AaCZzzoE/ofLj2 BgLcKoJAYfR7sjF6XqbBqLW2Fh05C2N0peD2vUkigTuLAwKYtGVsgoHwZj5M RT9N4Pi/09b584KyRWxYWDmfCK6Mv0HilaYTg8t2jjCTePBimAiXo2N1FkQW PmAXiV0r5fUS4kouW7D908b18pfTS5TlFf35owpfFBxVD1XB9SJ5G/snV5yP UKkaRDlm/4+ajtrD/s8vL69F02mq60pUKzJhFbG0UB/1WYt7kUdmWCP5dB0P vpi6CpAIf1u1Xn1rQNOpH7zgFfVUA/QdWMe0o4QhBkAftdtw3yo2O0nTbafW nNkWwU9sdUr3YTabEd2m58SvAzbnZGHPq0W8yA377zpfCg9PrXxPFOGKZEAG EyOEQD/7TQc+4XMAese4YYmdvMRmOJicWZFimNnvsQSiJbWDxUKGKLOj9kh6 K3knFR1j0YNc/CGfbPuJnwjj416tnopbWW9CbXkFW5dM5zLz+MU36ReMHURe BQQeLoQebeaBSDV/bE5iJQALKImdFmGUnMtx8h2I0nTDnhpXxsdHJ3FEcypO 1PP8i4eNnK7n+YtEHsgEHdaksw0Z+fhTV22qPki3Je6rsATRRvgfyTV9rkaV tu3HJZzofTkYcGV9voGYEfy+OOsJcig98MtYWgcmHIB3KI/ZlHS6fN5ic3UK HIR4TGc3RfpcrlAsyUmHs7Y0Hfcd91FPN7eGx9egaSaKut9taYko5AcddbbH 91IjGtxvq998o8rBEvDJsS/nVpNJWI/fLcMU/nGmamS2NgKvXneoVh/JG6n3 QBZqqRBdOuvVHmWm1X8z0UovNjE+2syutPwUn5LhxK2NY/XM2r1HZwRKyCH3 zKMcktmc81YN6rpSTz1n1ub3rO9bQ0qvJIDY0Z7XdA9VXP70e+BX14drEE3I N5Ifm/1OFloC3X4/Newj/WGu41+nOR9JLKZ0UXXrJtfD/SrhgfNPfUXpnJtP fyOFpdlAzl6GwBuB0h/sT3bGcAk4YTzvYJ4+TazTlZIeVlovYwhVNsc/SOHK 0QzTqHTiqcPcjRDkfijL3G/9La0Mxyj27IA55thDiIFSSuDVmwjXlSaUSrFt hkWYW7qdOxaCWCAp7t753fF/qNyh+EdAgC5IaSNFfhTeCTpoTQg2rgnn8SZy HlGdOO6whcBxJJa6DqM66lOELfgarJ7Q2fJ0mhmGgvFH9uN1qQDmUv5nd9aG pmjnAOqLkF9NrqzU0pTgafPZBgyHegkPbGvzy66HZS5gio5zEGJQxuhFNoGm 8SdJ+AewoCz185JvlScQXpd3KhUWDMKBMcKrx2mcqsNweke2Boqk83NWFnVT IKhyTLzUsTAx3sz54FPNa2m+nCon9zqk/mX/ZRpws30ktmumkZrkTAB2Z+4O pOjFezGr7cIeMj8JfgkwCBsPkx4+rqx+yo3w7NHz+RleEHFE0p9OgL+WDzYK GJX0z3DiC41tvWPtZrwYL6PfAKylM/THpRHYDkZGhq1M06GwvewqJ3RSb9eb 7BdCEGhgApJi8qQrukmdhvD4mOcGWqPFl/7eKXXomYYBk5ubduW3fZk7f5u3 CFSPBnAczZL+6+zTuDXSrJKfTOMZvGEYoz3Te03FsmAyvPFEtvuCY7P/koXj k+zmdn330VgraxJXL+U4nV8O8k7ddSaqztSIDRt0ARnx6H1NeyleVmpM5lwv +QlTaygjLSGcAZyeRSOKqKw8sgPtPRWIBMbZ3p5nTMoL2JcercYCttbF7wWR DiA+MNgCuuWwzjhJVt4Fioi4vXAWyrSKwy1HPiQtNjfQAqPJDvdi3HC9/LGH cKm1+8RUFbEIxbFRpg6LcuUcKVBGaCvT3IqISaabMB/nr59x7IKG+K8PN7+I w75Ht+GkSBfsjg+rOQw2lP8Xe2pafHL/acYTe3X+owwaUJ1aWF4jxm+WMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNsZWFydG9tYXJrCmVuZHN0cmVhbQpl bmRvYmoKNjYgMCBvYmoKNzQyNAplbmRvYmoKNjcgMCBvYmoKMTE0NAplbmRv YmoKNjggMCBvYmoKNTc0OAplbmRvYmoKNjkgMCBvYmoKNTMyCmVuZG9iago3 MCAwIG9iagovUVNBQ1dHK0NNVEkxMgplbmRvYmoKNzEgMCBvYmogPDwKL0Fz Y2VudCA2OTQKL0NhcEhlaWdodCA2ODMKL0Rlc2NlbnQgLTE5NAovRm9udE5h bWUgNzAgMCBSCi9JdGFsaWNBbmdsZSAtMTQKL1N0ZW1WIDYzCi9YSGVpZ2h0 IDQzMQovRm9udEJCb3ggWyAtMzYgLTI1MSAxMTAzIDc1MCBdCi9GbGFncyA0 Ci9DaGFyU2V0ICgvY29tbWEvb25lL3RocmVlL25pbmUvQS9EL0UvRy9QL2Ev Yy9kL2UvZy9oL2kvbC9tL24vby9wL3Ivcy90L3UveSkKL0ZvbnRGaWxlIDY1 IDAgUgo+PiBlbmRvYmoKNyAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlw ZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyA3 MiAwIFIKL0Jhc2VGb250IDc4IDAgUgovRm9udERlc2NyaXB0b3IgNzkgMCBS Cj4+IGVuZG9iago3MiAwIG9iagpbIDY3NiA5MzggODc1IDc4NyA3NTAgODgw IDgxMyA4NzUgODEzIDg3NSA4MTMgNjU2IDYyNSA2MjUgOTM4IDkzOCAzMTMg MzQ0IDU2MyA1NjMgNTYzIDU2MyA1NjMgODUwIDUwMCA1NzQgODEzIDg3NSA1 NjMgMTAxOSAxMTQ0IDg3NSAzMTMgMzQzIDU4MSA5MzggNTYzIDkzOCA4NzUg MzEzIDQzOCA0MzggNTYzIDg3NSAzMTMgMzc1IDMxMyA1NjMgNTYzIDU2MyA1 NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1NjMgNTYzIDMxMyAzMTMgMzQzIDg3 NSA1MzEgNTMxIDg3NSA4NTAgODAwIDgxMyA4NjIgNzM4IDcwNyA4ODQgODgw IDQxOSA1ODEgODgxIDY3NiAxMDY3IDg4MCA4NDUgNzY5IDg0NSA4MzkgNjI1 IDc4MiA4NjUgODUwIDExNjIgODUwIDg1MCA2ODggMzEzIDU4MSAzMTMgNTYz IDMxMyAzMTMgNTQ3IDYyNSA1MDAgNjI1IDUxMyAzNDQgNTYzIDYyNSAzMTMg MzQ0IDU5NCAzMTMgOTM4IDYyNSA1NjMgNjI1IDU5NCA0NTkgNDQ0IDQzOCA2 MjUgNTk0IDgxMyA1OTQgNTk0IDUwMCA1NjMgMTEyNSA1NjMgNTYzIDU2MyBd CmVuZG9iago3MyAwIG9iaiA8PAovTGVuZ3RoIDc0IDAgUgovTGVuZ3RoMSA3 NSAwIFIKL0xlbmd0aDIgNzYgMCBSCi9MZW5ndGgzIDc3IDAgUgo+PgpzdHJl YW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTUJYMTIgMS4wCiUlQ3JlYXRpb25E YXRlOiAxOTkxIEF1ZyAyMCAxNjozNDo1NAolIENvcHlyaWdodCAoQykgMTk5 NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBS ZXNlcnZlZC4KMTEgZGljdCBiZWdpbgovRm9udEluZm8gNyBkaWN0IGR1cCBi ZWdpbgovdmVyc2lvbiAoMS4wKSByZWFkb25seSBkZWYKL05vdGljZSAoQ29w eXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5 LiBBbGwgUmlnaHRzIFJlc2VydmVkKSByZWFkb25seSBkZWYKL0Z1bGxOYW1l IChDTUJYMTIpIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIg TW9kZXJuKSByZWFkb25seSBkZWYKL1dlaWdodCAoQm9sZCkgcmVhZG9ubHkg ZGVmCi9JdGFsaWNBbmdsZSAwIGRlZgovaXNGaXhlZFBpdGNoIGZhbHNlIGRl ZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFtZSAvRVhWVUFBK0NNQlgxMiBk ZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udFR5cGUgMSBkZWYKL0ZvbnRNYXRy aXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdIHJlYWRvbmx5IGRlZgovRW5jb2Rp bmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5kZXggZXhjaCAvLm5vdGRlZiBw dXR9IGZvcgpkdXAgMTIgL2ZpIHB1dApkdXAgNTggL2NvbG9uIHB1dApkdXAg NjUgL0EgcHV0CmR1cCA4MCAvUCBwdXQKZHVwIDk3IC9hIHB1dApkdXAgMTAw IC9kIHB1dApkdXAgMTAxIC9lIHB1dApkdXAgMTAzIC9nIHB1dApkdXAgMTA1 IC9pIHB1dApkdXAgMTEwIC9uIHB1dApkdXAgMTEyIC9wIHB1dApkdXAgMTE0 IC9yIHB1dApkdXAgMTIwIC94IHB1dApyZWFkb25seSBkZWYKL0ZvbnRCQm94 ey01MyAtMjUxIDExMzkgNzUwfXJlYWRvbmx5IGRlZgovVW5pcXVlSUQgNTAw MDc2OSBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnW b2M7hGqXtoapfkWj0KoFKgFCZ7eQTrPA070Lg9iRAWymyktxKt6yWPqrmhMO 5gXmH3f8G3OKvHxRzUbvgXGQmNX+5nZg5pp6uRtY8ppNeeVwIveD6w+7ttT0 7DUBT9Ley6mUWaTFnfDG66FQKERU5wfcIQDBW3a0wZuENjdYRppsVYeFsiYz IVIQmHGpiDSH3XcQlJIE3c+DfmqHCLgr2/FvvHUS+qMIoJP+XwNkzVZg90vu lnkN41r6kMz3ErGAXaiK43WgTZlZjq38YlvcH5wxW2zyjJvUJ/MsdFyZrr5w 2q7UnqRa+U8IGTSqR4lKNw1pirq9pCFVALGQryZ/z7fdorxoYFpO9h7Mo9Yc aEtH/7WIejvt4LTTDo66vyCYDCMxJhjrDq8omykk/0ozS4XZj9aFRf2ttH+Z HnOQsQ7oakalr4hmwBAiUCTV5YYtSd612OzLldlCg8UKNj1opJBxRFYQ8Dzj YAlFEYprwLOqRZMQTnJyYcaMSkf4Cdd+TPJ7NoH2tvOsSY5FNhv54B+vVSf1 48x5DTCEZ0s+JilvPgMyG1xVXSRYV4qJ5y0xZqPF10Czq7Enz0IMMW35V4c9 oEzw2yWnNXSk3i5PLV1OjgtDBlTPfzQaG9s+JnfBlHZOrVjFhfSe8QhD/gIP n9/ZAI1mDeULm9eiqHKZvDGeZteBEBu5VuMGQ6Gbk8iWfhrkcZ8wC/5YZvDW 2l7FXhcaJNO3B++jJdR/Rzdk6ZvIsRCNgVzyrK36bEZj6DCFXWc86Yq3j1+C n3+iJqtX8Hs+fU584w7Tt+sNMDXFFI2o2fo0SDQU/ajj3J5sR54+7poRoFR/ yQhfpGMa0ZzpNuBZjjGXIH+nu25Vz9Xvcq7BLZqWdSQceaNms83ST8+Dubs0 bo5BAHmS2LpJTnoAKzoX086Dq7XOgw/Qj/7qfRQ9zHweHnpgx3bZKwGZRHsu 9DtGAFeRTEVjNs7F5W8d6Cwezxb9CCBlJtj2jtu6gUjqf+AAlh3Q7c7XFaql Bb4lJmWHtSvaIG89lxLnzQC6J6gBYec5sNyuOxotz3NnfbZsM7RLP8tTgI4O RWhBcjuy+6F9NdmgvNj165W3FYGON18XS9+UWrTBiW4rgL21GZ/nC0vODnep JBtaiGTr8h521Kx8zWTJFS2qh7o4BsY7u8jssZoZ17JmMQWyDnaRatVIpT9A ndM/Vu1+WKUtrbQt3spmHiR18hkj9QrKmOLgA+dVr/4N2v8R4lfoYsbbnVKU c0HkZ6pBhD0thpchL0OCcgGJWgaicCccAbIh0WDvBCwEYoVljzsagey2BKn/ aILtDBKQRI3saB8X4qSl29yM6+wlfDFgD9Dvcpt15ZDPbvZWided6QK3/dHl 65/RtOBTFUA02eH+IgonA7TQd2GDtJrn4AsQCoTXou7TCZ63Z7lzBy9/BNlw Qtzuu9fw0uTEreRnb7zFKoErNN6cJb7ziMKkmwN09lSVm5Y56fD9T/omW0dK +LtYVJMyN2ipNcgJfvpq3ae+1IDOh3lSnc6cSOIMXcXHH4eTtmbzVjiLWoHP awveOAiJT9DOwSR3MqrnwAnGLKMfZAFp5QghB8t510DfO3WsZzArXviu7Stc y2l82i6IlhXKhyY1ewwVBpgvpBp6MDnNmJnPKz25pyiEg54XBmq5DUHEKHJ5 GgjPSWwHXt0jC7bFpLVG872mUdANC6ZT13btTf1DyJJMdyLZpinbwwbNQEL7 EExG+xGnsMshMabmHex5zbFf0qSZrFyDA65mh37Q/lrvOADvDXQjNHMa6SIL 2EX7jjls/QGiu/NBa7R70LIcL6XHFFtni42hz7sVQCr0dnC8foi3hWeKNvAE 4ry1XinNgPKjfKcA7RrLHxrXc848tJptRpl4Dtal5aPVASoeXai34hawzQDV 7DjafxeU/2dMGoRWzTXaNqtRblnck3Ch8pmPkbUVTDQGstm3IZTYHiZmjKq1 xHEXklwoRiQ7WSdPs8tDKoG4y9DdwplhK/nizXlZXhr4JuUlDnA/IRdpUk3S hBQwovbo7JPg51BSXRD5FPqoTRKz4i+iBEaWWbLR/hV59FoKbsGOyNNVM/qO mXEJVi6ERDD4W0auR/UDFprUyk5AzAt1Kx20z70ZRi5ZgXe31JOen7L2hzRs QfaVwmPJWJwgeL7VMLQNjGjVJx+YhHY0FBih5Lo2dC0VmMwlwIlEC8FvtxXo CrGMEHVlQA4G+U+pJXTokfNr/18veQvPYhDEtGbNJFvUm6JFauLAULpquhDp VZF6/cK/rP4emV3kF+qsRbTbXgj63G8WKLl8SqSR5BwlO+sMOu00NHf6ObDB boD98jz3XQfHTBhHxEiacxqX0O91Cby0mov5fyXaXgMNKnQ5oDdak49FQLrD rNwEbV8xZTe/q5w6Tjjqkf+4Tf0Fzo+0YkoXtTEt5ioRGOVMaTUIQ0xsVai2 seHMtvHoAEbtRC6yUszDNHRywVzWI1CAhzQ40we2xflaCaGGdrgT3QR/p005 R5ZayByVZS1SugeVs7e6T2p5Kq0NPItbKyb+65+TuqcPHYsSPFKDxsDT0+ui j+b4OsmWg7+CFtivcRi2FROMfH+KepnndbtI3w5nAL/uEGG/OPH2CS8JOr07 xeZHbE1G01GshLI6w3MBX09u5y++6kb7k/nDLM0PoYlI4nOzIcM0LGvUJApf TPlsX1J8NdYuI4J3VVEr/DntYtgoB7bKTAxID3ckYJXSOBUJmMcy7mZEK+sI R/bDdTFNXST7V7IyCl+t3CLFA5N1zsoXMXRmngMDEkMmlK0+isNDCBTS45U9 6WLhD373gUepS0OKIBHa5YZnSc6wzyRjvdmn7RGLfmmQd/KtV7ya+nkLEKoa LRAy0tLXEbv3KFjpzLvbZb3ofwSNb0LT2As/gWKtenTPYCGXg5hQ9gTlaU8K P3yFUwOaPt2OF5RQBOmQ/Y6WlT43h23SwSvGETgXWLyvTGFuGPIG2AW5ZVsr QSwB1lIcPSTZQEpf972MyfkstlsxvZ8WUTBgTXUO4mZ+BCyqof6lcI4SbyMy ZwiIE/6tkL2DjG1/MJHpN96cC1RMh2S+z1LrEAGio5vqkrJR3Q9S3OAQWzMJ kEtyJ0UfTbOJZPXZXPvjc8lehfjhzjuNm31mmL107bbcci1w21D7BBweIFjp B7T3nhbahg0+EwciaQlRcoIm1quiVreN/MmchLZyr4YqghKcBAQZt79hb9kR Ism6igXzD95HbuybnA+00GA2L71bEQ4A8Ybpnv1Ac75JtPXBafCOPFcOo5f/ bczuCvf6z36nALjNah71L1SIkp7rBjqWJEK1JruYPqt4ZtBmyQDTNYvMw0q4 jOM1OOS/rahGozXaUSzREltEfLOXj3ZQJsf2ZivVLvS7yiwXBbvSVZ3QRGuM 8FSvFk2RgZofrgBoEThCJP+b37CzevzEfOtigNZDazo6xpGwLTQ/qo5u0FMU YsfLXPiyXvw8Q0bVRZDBo4H1yuHJse7JbzcKy9Fd2QiIGeOm8YA0F7MLAAhC Xou5dQuf1xQGNTI2iOJJLZwSMAxYNpnvPckeXmDRqvfn0bWgKtcKvIZcqsVx c+6LS6GwMY0p0wJ/2Sok4SQLoJo14jNJMv6X4IYGQl0sb9//nJrZq8Ijc8nO ohZxCOJrnZqYzmGdj9zNNeY6eKg8otw02K6hkieGizBh+nK8DbDkESOYPM5J kAvCIfPA0oeXK7cS0sbBbfqgwVOfR1v5vwZmwlOhmlp4onB6CKE7yjlbZELk d3UUcleSjBoT0qJy9B3m1tYE7BXSMzG0ArxhzCU0GzQFhtTLAA0cW8B8YJHZ D4jS5BDk/UpJEzOWTlp/4WuFZuuXpTZX3y+1JMuK9/E+vyCziNDmvIRO6lly hxnwwVHGDiq/z2GP6S+Ug8ioGjpvgTomdOPziWts9W5aul3mTxdH+WoePnpG fVkLgHe2kxxY1FaGP3UN8CWqADAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMApj bGVhcnRvbWFyawplbmRzdHJlYW0KZW5kb2JqCjc0IDAgb2JqCjQ0NjMKZW5k b2JqCjc1IDAgb2JqCjk0MAplbmRvYmoKNzYgMCBvYmoKMjk5MQplbmRvYmoK NzcgMCBvYmoKNTMyCmVuZG9iago3OCAwIG9iagovRVhWVUFBK0NNQlgxMgpl bmRvYmoKNzkgMCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODYK L0Rlc2NlbnQgLTE5NAovRm9udE5hbWUgNzggMCBSCi9JdGFsaWNBbmdsZSAw Ci9TdGVtViAxMDkKL1hIZWlnaHQgNDQ0Ci9Gb250QkJveCBbIC01MyAtMjUx IDExMzkgNzUwIF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9maS9jb2xvbi9BL1Av YS9kL2UvZy9pL24vcC9yL3gpCi9Gb250RmlsZSA3MyAwIFIKPj4gZW5kb2Jq CjYgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9GaXJz dENoYXIgMAovTGFzdENoYXIgMTI3Ci9XaWR0aHMgODAgMCBSCi9CYXNlRm9u dCA4NiAwIFIKL0ZvbnREZXNjcmlwdG9yIDg3IDAgUgo+PiBlbmRvYmoKODAg MCBvYmoKWyA2MDcgODE2IDc0OCA2ODAgNzI5IDgxMSA3NjYgNTcxIDY1MyA1 OTggNzU4IDYyMyA1NTMgNTA4IDQzNCAzOTUgNDI4IDQ4MyA0NTYgMzQ2IDU2 NCA1NzEgNTg5IDQ4NCA0MjggNTU1IDUwNSA1NTcgNDI1IDUyOCA1ODAgNjEz IDYzNyA2MTAgNDU4IDU3NyA4MDkgNTA1IDM1NCA2NDEgOTc5IDk3OSA5Nzkg OTc5IDI3MiAyNzIgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0 OTAgNDkwIDQ5MCA0OTAgMjcyIDI3MiA3NjIgNDkwIDc2MiA0OTAgNTE3IDcz NCA3NDQgNzAxIDgxMyA3MjUgNjM0IDc3MiA4MTEgNDMyIDU0MSA4MzMgNjY2 IDk0NyA3ODQgNzQ4IDYzMSA3NzYgNzQ1IDYwMiA1NzQgNjY1IDU3MSA5MjQg ODEzIDU2OCA2NzAgMzgxIDM4MSAzODEgOTc5IDk3OSA0MTEgNTE0IDQxNiA0 MjEgNTA5IDQ1NCA0ODMgNDY5IDU2NCAzMzQgNDA1IDUwOSAyOTIgODU2IDU4 NCA0NzEgNDkxIDQzNCA0NDEgNDYxIDM1NCA1NTcgNDczIDcwMCA1NTYgNDc3 IDQ1NSAzMTIgMzc4IDYyMyA0OTAgMjcyIF0KZW5kb2JqCjgxIDAgb2JqIDw8 Ci9MZW5ndGggODIgMCBSCi9MZW5ndGgxIDgzIDAgUgovTGVuZ3RoMiA4NCAw IFIKL0xlbmd0aDMgODUgMCBSCj4+CnN0cmVhbQolIVBTLUFkb2JlRm9udC0x LjE6IENNTUkxMiAxLjEwMAolJUNyZWF0aW9uRGF0ZTogMTk5NiBKdWwgMjcg MDg6NTc6NTUKJSBDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVt YXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjExIGRpY3Qg YmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEu MTAwKSByZWFkb25seSBkZWYKL05vdGljZSAoQ29weXJpZ2h0IChDKSAxOTk3 IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJl c2VydmVkKSByZWFkb25seSBkZWYKL0Z1bGxOYW1lIChDTU1JMTIpIHJlYWRv bmx5IGRlZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIgTW9kZXJuKSByZWFkb25s eSBkZWYKL1dlaWdodCAoTWVkaXVtKSByZWFkb25seSBkZWYKL0l0YWxpY0Fu Z2xlIC0xNC4wNCBkZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYKZW5kIHJl YWRvbmx5IGRlZgovRm9udE5hbWUgL01ZREJBQStDTU1JMTIgZGVmCi9QYWlu dFR5cGUgMCBkZWYKL0ZvbnRUeXBlIDEgZGVmCi9Gb250TWF0cml4IFswLjAw MSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL0VuY29kaW5nIDI1NiBh cnJheQowIDEgMjU1IHsxIGluZGV4IGV4Y2ggLy5ub3RkZWYgcHV0fSBmb3IK ZHVwIDY3IC9DIHB1dApkdXAgNzEgL0cgcHV0CmR1cCA3MyAvSSBwdXQKZHVw IDc3IC9NIHB1dApkdXAgODIgL1IgcHV0CmR1cCAxMDcgL2sgcHV0CmR1cCAx MTAgL24gcHV0CmR1cCAxMjAgL3ggcHV0CnJlYWRvbmx5IGRlZgovRm9udEJC b3h7LTMwIC0yNTAgMTAyNiA3NTB9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1 MDg3Mzg2IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK 2dZvYzuEape2hql+RaPQqgUpcxyZp4TMvoW0mTsu6947EtRyt89UZR7yEYUR ammrEJbtS60vZGY14Bm2QXzHe1MvhdgRxw0UKaGaUwfvY+tcXgLIn8bCD22d iefZH+Rwtyvv2iP133a+Ba9M6TE3ohntigSp19b9835rf83g2QuYZCPllgpd n7tMlWVW6N+Qy/rsR2+jb9mlyBdcmvUT/tkZwt3Sa9wNmTmLn00D1qjwW0ev le8oqcVh29yYxHz1UlABHRnpNm62/RU9OhAMqmIS49XZOZBzf40ybTR7ftxD kcnfRAKFuPwVnQ6Y1CWPxXiS3MV/eQNEngeRT76eZzwVwhU8Bh61QfZsEefu d9XXfAsR4axVEB2pdsysq2mT7tFAb7t/8w6snpC5Cyr07HwnPKMvEaXBQm/2 QbSi+y9OaGNck9uDVzdWf6+EccvAUHjc1OQOJaL05a9GwjTPWSoc6POeG6Gy pZQ1VjfkdBZ+rU2X1RrwqJm0Q4fh/ZM6Mjr9prp0BTSlELRwXAoVZHr78+U6 gr8yDdlnU2Ob5JwveaGYiGPvl3uADJ21tCA5wj64aVNxP3MOA+oi/3uywdl9 M/13sb3MKmCxLPeAXPyQxbkUwPMKZz35WH+T5HzqWTLdGTBWDE8Nl1R7zYBd bYVEVbE6TXOCoi9WLXxVBB8P0pS9qhg0gg+JQmWmZ+XJfZX/FSUx75clj1Y3 RQKGXaHnwMX7fG+308Q/6zQxCVpZ+/b2HOxtbe4J9OsP1w13KosKSYTGEgKT 9rlHlEviMln262QwPWJzUxY7ZQX8imAAaB96OWi2y7SeBCCmkSWPXnsHtBcV eAP8vpufsfgP2MoKJ2l7XQQm5eENOWM8DNjpVZD0NmMErLTr3o+2KPHTPk/B gzGZc2IRyT5IykHSnvIjQdfNh9hpGDu8eVofWbTrkUmzRyCiCfkGMuVvz2cj IbTlf1xT4VI4qT9T0u6oVEfxQSft8BCU3PgKpTsljmHxEQnM3CXZOcAbOLKP 2a6m+p8oC9jD4DVFnKX3Peb4IMdXIjLrYt4n2iuKfesawrsqiAGiPyli0FUH h8JFNUq9Aw5oDYkJA0WMvi7NpaLmccEMrL9Y6fEdWhSdr/VVZ4oU7vP2VF66 AZwu4dC4YN993G8+LMjbZZyCLHloW2ePCiCVMlp6wW6YAFujb3KgjhA8/Y5p RB/hH1brdoLJKu3e9/HiNl8uxdUqzZbKkxikAJjPSxPjKQkcdgQr6bLt6jZs Rqlr3doUEU+nIgif0MYj+0mNuxNqxuNpgAogp2HFysKoXbdCm8JCon24/rp4 npSdoI3VbI0Xc0sFLEMitnIfl0YaSgFms64GcCdkx9q+vIM/GrqEKOe/UDLG 0zh+Emi4/o+Bi+1FgRwAsUbS6PeUwVRvY3O+hHZ9r5dZqrnRc1VDBkVqLwDr e9GZpsghdrlkJ043tFX7irDHg9XbXOenpB4X+qSNpTz+k4y8FDYJPl8htl2H KGyIsvTvuJ/FrY4bPd59OjhAfPzUXG3D2/Rsypvc77RvPM+STQ1mAFnAAO1+ Q06PfwAIGgyRHx7tsIBZ+KhaGrQYdEjpizxljZuiRdi73dz/25YOxTzE6+DU IdeGPG81lSfSrQ8TZGAKQwVkdt6aF6NxvHsUH8H2mZi0aH2lqAIeOEap4AZw NoBeIPAVhG28ssaQFh6Hc5uHvSOzVtDkT5nl7HlsQsqazSMz0G7sWbr0oBFl RqnZYsF8yinbdc+TZ+sVfIlj0RGHnaJHB0Flp5RKrt+V9IBTFgGGx304GKro tutwzrOvxc7oajk79z+zmJUtzOHwu6pRCpxZytOoyj2VrjbC1rp9oSVRXtzu BXRUPSamLTe6plQazGoxdZWjg0GckJgW3ezDXw/VnQzsxrWJ/HYG2nEmnWR1 lzO4tvN4aVta7ZO3QwVC8Iuj2clEalJgryuJeR6YT/K6Q8jqOxD2iD/mT+rn /WSnvSvYRNM9ZnlazF3LJWALxc33usFu5wEkr8yvmzKXDqN5YURwCt5yXr8U Ko2rbZTizVCDHMZq6jDqOe9YwvJRo6dS+/gMAJ2vEvAhjXy65pI3PMoUGdJJ mYlUW0xS7ylR4qawAoJNSKlB0igke+fOfnIGxPBEEqlwAd4pmN/0lc7Ykz6Y 9f92xBhNTGnzhLcsnzm9hbX1+pGGITzIii4JE/06pVDL3t1hlQ9VSFEqeGEf QMw9w8xRAtp3aFx9pVxeC58Bbo7w8M+bJPFFaba6kmqY/FyfaY40C+YjFMdV 3cRkCJd1cB1krR9x1sxv8FRpudrogIxN1G5lMhYu7KTcHB+YH163UP7VLYRW drQA0A7r4xZJxfPID/PLwqwQ4PkCn2gpyCYRxdyAWC1Piv74BmlVcBdtqBX1 iB3unabHJmMTQkumP4VCbZRDhNHAAxMPvRdXJ07MqpDd9QkmUVDkNtj0wOi4 Qa0YyFClLqCDZE56jyOl6UUIOqXEtdFTk794Mzjuy3PRxMSeRM9zwpEb/5GT sYh7mwFThUBQGJldJXIj7iw7br5OzpdSg0uhE8HA/m9aHGZU0x82fyM0VeHJ abTzgjKv/KItWMRHwwqDUdgrW6iQ44vA3Bz1w2SoDcOMGBbAMcTHMPKUbKRm gIsIMQOha9fFJizl58EbUaBg80HNezReDcF8bIB4R0/0O/lZU6yUPmITy84b cc763CjgXLXeAs6V5CG926N7nqWI6CI7yqrrAg3ncAOCcp4whpHcxptcoQ4W Jjd5dwBCdQxv7KxiAlLMYRUOfurFpuXZGGB+c6IAfatMsBvXh6KrFI7Pr4Fp Kn+7T35c2y/7CV5yCLmbrK9EngZOEGufsBJ5drZ13d9H8mRMWS97soVTCSz7 k1ocBYoxE5hQ2yKeWbnSlwN9CSwaXocTaUf6aDkQnQzYTJVxltNipReBzJkL DAk1sznDkPPvD8uK0KRMj/zhw7ZlrdvKj0GU3X/4JRp11tjuIYu/6v+7WGL9 inOssKfdjI911R1wbN0J4CrGt47dl46nlTnmUhAY0uMnAos+aPpT3fXGgVjw jZWa4Q5SepXVT83cIFG7t3Qcn3Dm8GHOCOVzNuhNDXQyHVi6IJ0w6/kLDLqf Hn3iWun2kCXEuj80OZuA9yed2OOcvjW4aUyEldDnSO6a3dv0mVYnkTRpASA0 Ok2ORzek79XiomwsDoiPBJEIUsaKxAPbBE7cvZl7+KqMK6Wr64e3IV4impYG 3TXEOIfRza3s1TavegYCyPw5SdoJY8pW9fHgnCH2ceM2KUIfS9o+jhnFjWKa Y5ByqofmQVBzOC/alDR1eHrDDRvrbgcLioc35lc++o4U7KyRhXIiTwihUWyP v++iZBsAuEQhju2GC+vCDT7Bf+cRHjwJapFFMhAJpqx7gF5DB0MRgFIy/FV2 vaiBFekYMTRjXRE64I2A7NQcVqlmx9pV+tPPWE2KQtbnVSYSIICBn6g0PP7c fZIaeuTJDr6LvTARBPrEdODLGOI/2+hBRPOQ6Akwxltby5I6EvaRSZs5ogWI oqr+/oKsgByYI3npt2SLM6GhCPJeAX/zZNQ863k3iP1nnSjCRQ1gE+4+bgWj nQ1bdvsfF+FvA9kXlnzToKCnxRPmOr/bFKd6YbPi8MyJyclaxq2tZoeo8rpU ihcADmYQUQeYZCdTbHK334PWEGn8WeyyaUmq1xSpUdpTKup7GfplJu8dFZU1 o0p47ZOeMjEfG9Epcy0hAdiTXk16TAXqQ7s10TYw24lUmvNEOqagJEGRa5p6 m9ObdQHupbLi1srsWf5ZgLg3YXTx6IFUKEz+OPwt/JL/DL1Lp18piCcmBjkq F151cKA1q2a8VZxy/QyvvLuVQnlDeHnu3IP4LRAeu++vP2bKrqw5HyZYPjTX MD4bLPoQ5pam32wY3EaMlg4CE/39LcINvkY5HEXCERn8Vfd37ZugXx2mDOgN Nnz9e8H0oQe3zYvIZEKx4V5+djIstQgirSNfQwgrwHXFvfN5pi0ewJCxHKbs 8G5RZBErLoQ69bcIPxkWVTFcklYxn8lM+HAf4ZI4bR+8zOPrP/jHKxGceOGb Ol9tyRbbyG/GJeWtgMiYhn7E7I6loYPWuW7e1UiVr/j0iZqnllWxEy1q5Z/R E3Hx4wAYl5j7gyD7Ca4L8t+ZtTvJzJwX3p0kwFED2DysXKah7SpLjeFerYGD 30CChTAPAYaeMd9XcvYMYSX9w85I3U5wi6EC9Ey8o1uuTcgFBdgFRg2qqXuE cTxPyEiQBqKHyYubeAHsFpYqi73UGo59CuPOgZ/UtyySCPnCod0NsqgCpRCJ RSECPyHcgZXAFKj09NBmYezCNOYBeirYX8j3na/6tmiJXPrSKYbasmN5N1FG Vtc4c/jkCsmq8w8F/l96RUF7F7prcxjorGSRzduEvZv+zoGa1bLOmHvR0T3g 3GprrCPop9Kfzaz7fCOpor6265aSBpurZ8sIU1Y9dAr2Et6WDCmSVB0s2FaJ BgsoUAc1IbnAzTj7ekSwA1zpkKhMSslUCVQsMf2URiINvYErY010Swa8nL9+ oWrIk4FleFRhQgpr2m1ipKzOD8U+QPK5qHSh59TU/VsaeVa7AusoMAWmP/4W orNBYk919FePmWRSuT7D5suU2QB2Fu0X0x1rzsTT6E9XZO8fb1tUrcpdDJ5W iNGLxRYtNqkiVBvB0oaOOPusx3vP2kh4qINfjR32fD2Alkt/Xz/4VW+NwAMx Ojh8memHBYbrAHMriGirpCoahuEvJc+08oiv5C6lCAX5eAUvaj4sJvzUf6Vw wWcQifaJuaaVywvyaYIK2F/ewzMXrs07+IFvfEN5RVEyrKmbBNwM8UAiDyFm bCuUwlvAbaxG2BFNl+WYjCuDt1D/WM3S6z3mzw2PagqTYa8l3Xl/jIzBM44V 3OoW9iLgyCyvwJZ2tN/Frw8SOrDaJmOJrxA2ikLBqVDHbkcj7BChmJA6oc5z t2bd+24rgROKOfimsG+J5iiRLlfhVRtVf9kL37kJQ3UEyT0KxHxX6Psdm7WI kAWgAAIWExEnBKy3Bfo5XrruGilARYMnpICrcMNQDKOOT75qe4HkeK0eXLmG Ys37s+AyF4n45D1ilG1yFEtuodUdpc7Be/JUg+2djjNEygGwOXfusAIwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xlYXJ0b21hcmsKZW5kc3RyZWFtCmVu ZG9iago4MiAwIG9iago1MjY5CmVuZG9iago4MyAwIG9iago4NzEKZW5kb2Jq Cjg0IDAgb2JqCjM4NjYKZW5kb2JqCjg1IDAgb2JqCjUzMgplbmRvYmoKODYg MCBvYmoKL01ZREJBQStDTU1JMTIKZW5kb2JqCjg3IDAgb2JqIDw8Ci9Bc2Nl bnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnROYW1l IDg2IDAgUgovSXRhbGljQW5nbGUgLTE0Ci9TdGVtViA2NQovWEhlaWdodCA0 MzEKL0ZvbnRCQm94IFsgLTMwIC0yNTAgMTAyNiA3NTAgXQovRmxhZ3MgNAov Q2hhclNldCAoL0MvRy9JL00vUi9rL24veCkKL0ZvbnRGaWxlIDgxIDAgUgo+ PiBlbmRvYmoKNSAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlw ZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyA4OCAwIFIK L0Jhc2VGb250IDk0IDAgUgovRm9udERlc2NyaXB0b3IgOTUgMCBSCj4+IGVu ZG9iago4OCAwIG9iagpbIDYxMiA4MTYgNzYyIDY4MCA2NTMgNzM0IDcwNyA3 NjIgNzA3IDc2MiA3MDcgNTcxIDU0NCA1NDQgODE2IDgxNiAyNzIgMjk5IDQ5 MCA0OTAgNDkwIDQ5MCA0OTAgNzM0IDQzNSA0OTAgNzA3IDc2MiA0OTAgODg0 IDk5MyA3NjIgMjcyIDI3MiA0OTAgODE2IDQ5MCA4MTYgNzYyIDI3MiAzODEg MzgxIDQ5MCA3NjIgMjcyIDMyNiAyNzIgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0 OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCAyNzIgMjcyIDI3MiA3NjIgNDYyIDQ2 MiA3NjIgNzM0IDY5MyA3MDcgNzQ4IDY2NiA2MzkgNzY4IDczNCAzNTMgNTAz IDc2MSA2MTIgODk3IDczNCA3NjIgNjY2IDc2MiA3MjEgNTQ0IDcwNyA3MzQg NzM0IDEwMDYgNzM0IDczNCA1OTggMjcyIDQ5MCAyNzIgNDkwIDI3MiAyNzIg NDkwIDU0NCA0MzUgNTQ0IDQzNSAyOTkgNDkwIDU0NCAyNzIgMjk5IDUxNyAy NzIgODE2IDU0NCA0OTAgNTQ0IDUxNyAzODEgMzg2IDM4MSA1NDQgNTE3IDcw NyA1MTcgNTE3IDQzNSA0OTAgOTc5IDQ5MCA0OTAgNDkwIF0KZW5kb2JqCjg5 IDAgb2JqIDw8Ci9MZW5ndGggOTAgMCBSCi9MZW5ndGgxIDkxIDAgUgovTGVu Z3RoMiA5MiAwIFIKL0xlbmd0aDMgOTMgMCBSCj4+CnN0cmVhbQolIVBTLUFk b2JlRm9udC0xLjE6IENNUjEyIDEuMAolJUNyZWF0aW9uRGF0ZTogMTk5MSBB dWcgMjAgMTY6Mzg6MDUKJSBDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4g TWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjEx IGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNp b24gKDEuMCkgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykg MTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0 cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01SMTIpIHJl YWRvbmx5IGRlZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIgTW9kZXJuKSByZWFk b25seSBkZWYKL1dlaWdodCAoTWVkaXVtKSByZWFkb25seSBkZWYKL0l0YWxp Y0FuZ2xlIDAgZGVmCi9pc0ZpeGVkUGl0Y2ggZmFsc2UgZGVmCmVuZCByZWFk b25seSBkZWYKL0ZvbnROYW1lIC9XV1VIQVArQ01SMTIgZGVmCi9QYWludFR5 cGUgMCBkZWYKL0ZvbnRUeXBlIDEgZGVmCi9Gb250TWF0cml4IFswLjAwMSAw IDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL0VuY29kaW5nIDI1NiBhcnJh eQowIDEgMjU1IHsxIGluZGV4IGV4Y2ggLy5ub3RkZWYgcHV0fSBmb3IKZHVw IDExIC9mZiBwdXQKZHVwIDEyIC9maSBwdXQKZHVwIDM5IC9xdW90ZXJpZ2h0 IHB1dApkdXAgNDAgL3BhcmVubGVmdCBwdXQKZHVwIDQxIC9wYXJlbnJpZ2h0 IHB1dApkdXAgNDMgL3BsdXMgcHV0CmR1cCA0NCAvY29tbWEgcHV0CmR1cCA0 NSAvaHlwaGVuIHB1dApkdXAgNDYgL3BlcmlvZCBwdXQKZHVwIDQ5IC9vbmUg cHV0CmR1cCA1MCAvdHdvIHB1dApkdXAgNTEgL3RocmVlIHB1dApkdXAgNjEg L2VxdWFsIHB1dApkdXAgNjUgL0EgcHV0CmR1cCA2NyAvQyBwdXQKZHVwIDcy IC9IIHB1dApkdXAgNzMgL0kgcHV0CmR1cCA3NiAvTCBwdXQKZHVwIDc3IC9N IHB1dApkdXAgODAgL1AgcHV0CmR1cCA4MiAvUiBwdXQKZHVwIDgzIC9TIHB1 dApkdXAgODQgL1QgcHV0CmR1cCA4NyAvVyBwdXQKZHVwIDk3IC9hIHB1dApk dXAgOTggL2IgcHV0CmR1cCA5OSAvYyBwdXQKZHVwIDEwMCAvZCBwdXQKZHVw IDEwMSAvZSBwdXQKZHVwIDEwMiAvZiBwdXQKZHVwIDEwMyAvZyBwdXQKZHVw IDEwNCAvaCBwdXQKZHVwIDEwNSAvaSBwdXQKZHVwIDEwOCAvbCBwdXQKZHVw IDEwOSAvbSBwdXQKZHVwIDExMCAvbiBwdXQKZHVwIDExMSAvbyBwdXQKZHVw IDExMiAvcCBwdXQKZHVwIDExNCAvciBwdXQKZHVwIDExNSAvcyBwdXQKZHVw IDExNiAvdCBwdXQKZHVwIDExNyAvdSBwdXQKZHVwIDExOCAvdiBwdXQKZHVw IDExOSAvdyBwdXQKZHVwIDEyMCAveCBwdXQKZHVwIDEyMSAveSBwdXQKZHVw IDEyMiAveiBwdXQKcmVhZG9ubHkgZGVmCi9Gb250QkJveHstMzQgLTI1MSA5 ODggNzUwfXJlYWRvbmx5IGRlZgovVW5pcXVlSUQgNTAwMDc5NCBkZWYKY3Vy cmVudGRpY3QgZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnWb2M7hGqXtoapfkWj 0KoFKgFCZ7eQTrPA070Lg9iRAWymyktxKt6yWPqrmhMO5gXmH3f8G3OKvHxR zUbvgXGQmNX+5nZg5pp6uRtY8ppNeeVwIveD6w+7ttT07DUBT9Ley6mUWaTF nfDG66FQKERU5wfcIQDBW3a0wZuENjdYRppsVYeFsiYzIVIQmHGpiDSH3XcQ lJIE3c+DfmqHCLgr2/FvvHUS+qMIoJP+XPTp0kBbFpzVNl1uztXXaNZtbGhh i4xIKzQfjKOOm7m6/PqtnC8/0DO2JpCYbtQ9nJNhNkW4I5LVyuEafLSdfi6C 3NSFy6BMdzIusuannXPcGU5ZwSCi2rub9y4s8lbdbrVO7LpYgQGr2TO1fOij oNFrKFHXSU9zCW31O9xmu/iWtYfflkMxfV9hDNkIj5hJEm8j3eAw97J33ZkF XIsRnK6cmRWKxOFQzfwsZu2S67TMCSqqB4zhYkehM1rTMtqpUNIDlac4TDP/ cuqjGluJdm5jX0XEwGitfuhnOY8DgbB8uU0p/wl9Wf+ZYdGVqUjj2Hwxgh6S laVtIYdbQZiPehahWHBQw8cbTkNVuzfyVdayN86W8lRn9w+hng+FeF/0kGiU nMx58viuV9X3m7nFz17tXZhXuZZ9m5bNz3PV1l/3Wvq7ZnNAGLriZFlyIMif 0XN5JnZKkwLQeLTrDikXjIeP1hAH7qLdsRmuiMV+z+9LceQUCjSVHdw1aKhM ySNxp4kCGhA6GjRwUP2m7PeQP2fSEx0MfEdKkFOGbpyI5l5pMrqHpzaG6rAB k4n4TRWYCcSYHnow7ZQushGwDb/1vMcg9OJ2wzObMbbqu7B4Qw5qCbs3fTBh ogseuYeWuGB+7LxplEXqqGbDjgBCCwR3UzrbE/w7OWwGWwl2na8IcQdvt/0N wijPPuEVRGxxWbA/Gbxrj9qRuvKK0wPib4he4jiHSxH+6ExHrzfocatahbBD GQ7oYLZEPEPifqEi8eSSQcoNO58SSVsJRNq1YqhdCEMSrIpft8Ta23DI0dA4 cLOOYUBsKBzupMLWBhXmEy+sLXdRE4N93y3tdon00NT1p7Y4zctQRP3iGXzo M42wwfWc8lUCCPkB4R2gZW1k9yVWmmddxquLenFS+OX98xOBSKeA8TnXOmGI EP54/udgU/SSaZvVzpbZGxGYxo5Kdqf/d/SaX9psZfwYX2U/TloADGkye48t Yx/F7qgpzDEfF2jPktq6hn5X0OAfrm87JeMoYMnsLL8RDiqa6folkcjKPhwn TgP8mJ5iUVUtKBJal435JpuRJUUYwyjW6RLPpBuM+z0xW4zN1nltNfszbq3k R9FNWTXfm6+XXIN8FUIuueTp7k1k/IR00TDBrky5yiey8agmJ2mH4UEdHrk2 p3I1L8N7HcoO5ZuDt3oXzyIV4ARLRnILazfxZUg334LDIkW5DRKojKauwWwS YnyygOxKWtVTFzyoHZGqUn575jXpjv58cdP1kj7MWGdfD3NSoQJfqFfLNfn9 rgyccjr0AUFoZA+T+ndRkNWUdoKX7/D1OUIFXmDr4MJxdFTgk+6rZ96h7JBN bxI0fMXrE5xv+wqJCJV3R4THxVQdsw4Swbql77bvtaHNEk1o9lfSbE+r518E f57X07NG2Mz1a9QEjKGxK44LKNbWdORoF11k9hx2HUYQz7REJdG/QZR8Zwsj 38A5awta54HvRwpU7IYMqFLvLJ7Ao4mI/O14S7uBEIbmgMRuktlvopefWC4A dV4AuEHWIKDSkrDULatM5H9i+fRwWGY/IPoN+XTIBEv0l+9maPR/tKbLYfSX DqnOF4UOVoqNiz4Xm2sT9Ox2phqsZOeSd9ktgbUEzyn70kNIWqMcnBwq6Ejl Lij5ZFO3pP6YiHAqiRXMYK1UxSXVIufalcIoGHfOX1hzF+fKSlNaRBAh9FTz R2pbO6QSdolHR25A+QjVx6MvHvfMq4PmvX4F5jRH7OZRzjEdHCIKZwflybHv UlUQ1Xzab9BDyHGqovvz4eJxjiOEzCN98Bm3hYtW2WojHZdedPN0oybCxJbZ StHTOQ8sWlLATa1X8m41/uUNu+/iNr9ODjTqPWA1qlsb6jd4CsvJE91ZsKam TwoAXAtss3Trt4RiJDZG1X0H3jNilIRUgFHBhRfkxU3nF5P4OSM+mXdQDbu5 16AH5QJ2U1Cg5dHOZIUdzOnACMrdpfaDNPyDMMBu6HwfvtFvNb+T5ih9fmKP b01sby+gfViTMGRHWqYqID5wu/Yfyp7SCj5qzqREtIVsvxIQ5NMBv3Otl7hS h8wP8yGDlzloN1Z/8aTw+8aDJLIBKF4Y9H+niPj4ik5vhmHcFCWO7gktuau5 c32RQ1XSiGDj02Ez+Tgw+LjMbNuc5FDLIBxN3expCqhFPP9upu2fc+v45Rp8 MjCqztV1b9PvyEZTiAuqrednaJlkuBrVyKEOudZ/Rf4eX4RkMNrLh5dIIdkp BvCeChGO0Ytx6u2MD5XtlStXaMlQ2eaAPiZjtFReWRf7t8ALQeJBvG29TSr4 JkqbW4p8X3Vy7BnMNPok8GH6IzL+REW13ZcTz+Z0iwNOmJAAEAgMfZVsyUZg Y/tw5VyWtwlgoGYfh1UeCyUwXEoLa+HFqLq95vvyhagVDqgJn0rWAT09QF0o W+XfYj6QZVgZPKFwt2CUtIyAqm14H/X6kvtZ+UNGtYsF6Fnd251UG1nvJM+K YtJ6T23YsRgJm0beKT7zqKm7iw30UVlnypEAYJYK2iuZioHN8c/KcBCoPBLD UL/1lrthdTSr3Jh0D5Jygqwp5eJmAFwOD7qnSw+O3C6etjMZ8fXe6iOuow6D f0ZxDCR9WBIghJk4k6LrsoYzPRcyxf5Tipz7QLGKKvmrqavx3xd/aOqaEVia djvhsBJx9X8OsasbFXiqKbIisf5Lk4VlrTBP4PmmbBGcBVjRqUpLrLBXV7uH W7MNHez4ZUZGGv7XwOAkUpyN9QDVb11s8o7Mx8o8klsVpxo5cbMgTasgbeVP neVT9ZQPjdy1wMWiowCWpLkF87P+P5CLU4YjTcbZmuwHIicM/C3e0uIxZuX1 3TN+Xl0R1Xv4w4yoTL2XgQmycZWlap244AK+Xjgw/VCB/UAkCd+76MJ51yh4 mcSM//OyqXiguQ9PFfQz6AQa0cPPBNt3nJq4yX0Gxnie5blw5Y7SFfTNCgco 2TeUOFCGWZliaLDMJhoQJ6PudWCCjK+rI2EPx3N2fmPiqUxcphkTrNNTGjPi WGpIZhELOc1EVa9BOAWxA1Vs0PMiisLGayynaXbC++PWIEguTjSspEvu7g8l R33ooBd8euwiFM+rejfodWuhLd+he+JC7qOge50XWKKKFR81HQaI7pS7EZFJ SgON9S8aCiwvFdDCNBifTsLceBf2HBDL/45Vet65c378I0Eo9XN5oqh8hS8q yfr25otLYylajS/dE39b3EKHBO58MXtoTgQKkTPBqt5+rnI39hhdkH+K8P44 RBft5qEDz0dZytuMZHjcmRnnMyUhpGRgxGWgTIXp+UjAkLU94mg5Q42e6Omc Uy7MGxMtlhnOsk4rXP2jEdV8ZjEqr9A5DNViufXwBhX3Cg/Y24rd896qO7NZ NglLn9IeYZUBhXAvk/kGMIYt9wMzZ/mU9RUFKAZJMVZHvyDCSEnrm7gSEMn3 I6E073kIZlRqmE+eJFbfBK72HFlYRFWQogelqvFPbj8lHuaWtiU1JKOXzpJt AqWsgHmNOruVc5/LFTvnxi6033PQOQ6EsncqiLj9CZVlLa9AXdtSZUsGwasE mzDA5OIJsoiw7Gl1U2KrK94Cum5ElYlQ9gbf0HzMTE/X4iAhCYt4YuhdTtss aVe0kK9fYEqW2zD3l0AMqplGDMjToCVbD2gYHg68m968YQ6xdudZBBIMfGSn 7R7FegOOyknLgglQNARnbqs71wjFq3gKWA74gY/XKNsvDidHba4+L/Vso9p1 R/xZRodECAzUzQ2Pl8O/8nlvms6I+0yWQnwbPlpgauOh36H0oP4aoyGuRtIC ihVBeuCs6acRvZhu9wPFjB6GyDHdfRL6yOJ9z33bqBR61DFSBx9J6CM7zgSM 0+u/3fKdMCQQdGptUHPwwEtH1koBRB6bG5VV7PuX0dkTvAB9rTXMqF//H6Y2 vKoTPqsqNCOztcYrzGhLuw3AGSoVrrX5785Tsv5Sb8aOohwVXTYlq6Pf3JSL dc0m72cBBycgxEjFkoYzitL0mjkR8rT2Wtw76QWKcO8OdmGmerRk7HXlv+IT 5KYhpLMq6heaNooWlBjt7yKT6NWyvdhPA5HNCQAZ2sWG9cC+rky2fU9VTwsW oaC5kPRRpegEuhFgPp39mn84Na/T3qLnFUpLb+zftFjitSZG3/2+P9U17IP7 qDzsRqzUZFLjVBzV/2OZHRFL9dAJUc9U0ZAnwt41F+9mSpaGwPbemQUDCkO7 clWa8uxicmN69If79kHiSvxXX4/bcmC2xO0kYrGFwBQeqCs65EeQdM4ueyTU CjDX5TAmYbVvfFkEppTcUn7AnDxkFNB6CaiGLBKyuJxLTqq5NjIi/2WKSGo3 mz9NfL+HOYJCMvCye2A/l3kbBL5FVu2hgYvLljZtSwspn0h4vwkVpYHD8nYN JM35oZKohleyv5Lon4hB65TxZA0uAmVWqtxCbKs/khkrIXvL2iKqE0QMY/JZ DJYIwEjPpE/M5TUaHP8OeqzHUSxki3HWoOfaF1szcF27TYES1uQIwfKg7mXA zYHGKtaP6zdU9wv5Rr6VldOgrpld9pjnStV/5hCJEui/R0aPGvk9Uo1ZzWMF 3cTzWf2CcVcaYK3TQxcJyDgACyJNCAz6lH1k45OVyWjUofpFKMm3MjqUHC24 2LOmWOHXFrPAzLN/g+LE3WlAyrGv6TP5TY+aT4MF39vH7L8QTggrVRYX6UGA 2/JDx4fY/xJvX7KHv5OSUogZmuxnLNCg91sN5Pb93wjodgjkmwfNwal0s7Pu le0sHGYS2vbhMqOCqC6AhfjMSnsHHcAurFC/SpY9nrZdjkTquTe20XVH3stX J9gHpLas1Xiclu6fFlRGGP4WMiAZa+kGMnMUL2fk/2vobGujPli6llwoZBKU r2W31Ok3KfIZvt5EPyfOHH8X99n/zUilNRuXmWVVFERBnYyGUWsnifqQcioz iyfkAH1PiopFhiyStu5yY2nHF9tnX//OetPZBm1ftWvyT9/2azrucDZ6+EEe cK7SWImZUcTfLVWbrVcEq1WqFyXPCPRPxFPRayLU8Fx/xCvAdmoDVNBBOHav VqRChYYBE4yit94L1D/VUr5+EOAFsDRwaByfmKRo9YsH/w74kWZeHCFfTS6K juTV+xJbfoWQ/+3L5sJYc5Hn2xeXcEJkR6csLVBbROmX+zvXmyHYG9NTEfGb JMLWl2GIBmUVhFSwrnyoGp2AsElgYbt15JhV3wijcuPW73x+eoXJM8/zXUCy r2IbPWkRVzKj2xgVEak6uVG1l5wfHK17jXEoUZw2auQKlNEvlYZ1XBpUmNoj MNZbNW6PC+Y2zf7szeoe996dGTrfpO0sBuGHstcwoBL044ny05QtTyVQFXpH QVZSrovjktFYLSBim9xlwAWMTpNOh7f0f+Yc4zSBKJCA4jYF6h2gfcwOgQzq TQR8gAQCyLliVcn5FpCbUTdjxlBmVNpojE/WsoBCVolIoaCw5SnPgfM1bVAb oDD/CfgKyIil8igUWiv+bXbN4t4n7uXQp67bI1ZWJ9/ulQ/e/7mF1+tIwFjG AHPNWkZ1mIuRSnCy607Tu0I2Jqn6m2rIe2g6863Dk7XKxPSdJ7PRYHQHzO41 nxwvXb5h51IoujN0xfcfDERTWa4/YbZfAr16jlunU1FHsFxRWHcKx6l4T2y1 +b5FKM2Xfr4CVJf2AUkhSMOKOOqGcq/4SE92RH89+BeSNXaGcoPUIJBna7BS zpK+zPntqebQz4q14mOtIBFKFG2u8YzJX045QWB7IczFHr8hR414Pkiw86r4 uNEEYoEVa2QZJ5PmfcQOmDvmU6h9ricclT9+19UbMVfBdIwP0mYCo/2qCGpJ CfmA0nToo741gsR0Z04KS51joKjQEGmbruB7jMXTmsw5kKAQy2oorNnlq818 q6OCFXiRs/YXpfYge22Nt7BIOdaM1ETiaObbYHlaO/JgzaqznJN6gPFq3vLf AReFuGDWoLhXgh6QlarHLuQ1IgXAOd5liwG7Pq4ZlCupgY4qkNFTrLDSbBpe OIyTdCW4LXsjMWO9NIeCDlaWVTdneHDITjaIMjyZmVJbgnaUn/9U88LfQiyd IzEQtyWChkGuC0mKvIzzObxOEh1b7lrzs9Ng683m80tGZ6pCN7YCKoNdYTOi pXYrhilOHLkjyosfSlIw7A8pZUFehOUrbBZUozRO2JUm5EAhZJjm3gvolTqd 1qWplWyUBd/rEJLt2A8u4BhNzC3S455YS4PNZSjaV4hTFyJqtfS8wxQGIgZM jDLKHU55+fiZjPsqhwxVlE/7xNZM0Qv03nITNZE54FX2NoQTcLX+T7DEbuuN ua0pPuLQ9lHmn/ljjh5F+5bbum0aOt6j15Z/5AaM54thAiviM3bibccsADue v3VBWqQkD39zpZ6uFHhtn5KlAzkFNUeLxtin+OjpsPLOAWg6Katky8yplEsM /2ALrLLONZIpXAqSHktDtAjOAR+1XI+zDFRMgg8YIeIiVBFgHLXRRYVu83ii rkmWKTvGVfRGzHKUajC+r6p9KJhZwYJkm2fqaWx/Pj6JVUZTeAHPiMT+Dpvw vfK0ZSjPEgcJTqvh1EQPIvZi4rYq1VW9AbesrLyyy0pTjuvw3e46VdgZmAX6 Wg7hOuh5kpn++cs4UQHF1x2tOODBjYhCXwkGPRpsjEX48O92zFPKox5C59IW UEZDu7IRpVnm5rfRDpGBeStrATO/iTNqaaR1l+/AZHsYls9mo/mfAVIwt7Wq Sot5z1LBXrvkiBCLyw24TQssIqIg8f6mjnxJE9Tn8cykrZn97StWW0u+2Em2 vdwv4D1HKVFVyM4dzpy6ZNxYu3NKNGQ4vJDsJXM4LonF8VpgNuTQjIon5WrL SOSjUrIswZNU2t1kwA2ji3l2wr5SsQCLVjRmfj4VLD0Ph8CLxOGEi2Av9joD gUV6PB/cjaJP2wFiCZOgrpV/fnXAOiPnvr/ZgXxyx32fhsjnKpOiEoQL+3ni +mjHUX9FkSzM/aeG3Vk8C7YATyUwWjzmUkza/svHfwTBzX2X/KUzpmcqk1Bq zjmdQgDLafufHKr76g5gnNmvHkBLtg9EJ4ViWqBdT+k7OUTi+4Gym1Tx2c+L hFX2ogp35OausIYGvQSIf/xJfCFHzsTtcbKr5zKzJAk8INyTJjFtD0XBLsao 4BM24z5X58cjJtKYBdkoQYFu4cuU5+wFykz31AKwpzgzpk4oFCs/wn2itR7p E1FV3BFwCHwTBSn2jBmQzSa2FLvxbgVTmLgk99Z6fATiMCE+b/4P16NR68oM neS9ng9w/V/VdpckoX4gp505SMEozWlVX8AxJoDmfRgL2ZMNJNBdDcxH04J8 cuiTx9AXI6AgDK4rKYnxMPraWF8S5y7cexBOsVvx2hUZYE67+sS9sNHU6Z08 ECStRhqpc9Vzjxzy8uB6CUF1vJ+pmoAvSjar7Y+42j1BUdZ3ig73cMJ9H6TZ LbZzwIhiMGw34s0MMHfrB/qSTrua5QF3f2iLGzOgKE6Vm1yvclHOzAJ6Mkm6 WIzhKcKUgbq+eCtc9PwwJJ1aYdq29agAj7moKU6TLLgJYwClm6mkngls7iQs PsuLzGmdNevch+rxVMOn7miomfG5gLNYaaPgMhYfpSx0C7gST7xNOEe/rALA +2T14T2BVqZ69GNLY0tL24p4IUkH+NSpUwm98D9XXC7DetGH24rgblI1orCj RM8xqLp2FH5MDeQ5rZMGoO26Nnf80fEwIxcfJzH0s21hnzlm8e4TTZ5QjC7Y Iz4zIL8NhXVu3nL865j7f0CFX/8+O3aK3kxI3o5ueeeM2TmP8U/e29oCbu4V SwQue99LqEqsQORhRNyZOiCjdToVicjwHRtGrNJoJTi2Gaa1uOlnEtngd160 MyT0It/9Xam5bq4WZRAgtfSwLpcx4keJuS9MwxQ2W2YmbwJjxUjh37X61ZKb Elc7FO9qJf6sUsPuU235tQXP5K8tsW3MOmPpsQroYzvn5XQI3GRqyiaUPm9h PNA3l5aBX9jhRgqYQEC+uwsXvHdHUYIoyRdw35SMOYxwSU105Pa+ZcAjfleQ bkgciLJS5PjFJ8YgyC1HePW4iMCcRyroAK39/6kEISNF/+blStpUhNteYJsv bNDKRd/d4cGx2SgzjCT6pxZI/rvSG7qAGUBsnkdle2JfSfhD8dKt68WTb21O dSKFWO97/OstIP8MmrqijNRIvJjlVIA3uxPLr19I5z41bv6wO2OXTgbcun/Y zW3ZmB5J3n36QOVm76xYXn06EfkhytF/Gvm0r1nJ/oOtskN+JcbRgRBaaSfx HetlJ6SEX8zcuM4zA+mTkDosqCVfhCaIFH6xYjQxBB9kMPysg65uO/NEfNS6 S8zy14iV174tPrQvEiphOPYDlXhe9XWs6CI091hgbjCn6VXhjr/62H9EZhQm GxSCnzSO/tcIZfoHqd8TLaeT3mogbrUFKcT1KUxoXxJoNJ8v0RzoKpLoox5d jZxTTHNKCBMI88E4sPJIr2nWUX5Jg3UvoaFL62slk0BHXLafFjtkjuSSTelQ KgCUfvAxufnIBgOjhFZudEhamgwGB7Ql9BPoCUhj3GZKg6JuIrQhkWxFgx4D fxr+CWMHuIfsXOeywoHQcWxBgo7cwYEhpEPnUfOoZJ0gV2D03/LcHmMY4P3c 0AVCW18LgeoC8eVBfnD/IAmtJBXz923amA3pne7AF9Ib/Teh0LExBA4ihvR7 XkTnsILI9npmdfGa7NP91AU7aCgqoH3yUFXOPshULei2RrjX1FwYoK6TaThE wWN93oINuk2uIfjg0lEZiH78lewCksDfzHNcHariblWn6/nzCvd652sAIJ3i UDMVjASIlPXtOojMoubO5eAbb6yDMFyUlYeedxpVYRO+dPUQMQ/ApXxGnpkr jooyDIhxucOkx0UH3NljlX3ad31FNoOex4uucClvyNd4DVVdv1d63g0QkQ08 Sxgn5Q8ZXRGCaM92NjGzmAccJtdUoSzQ2MvsxP8A2vsmBj3vUxmfmRmc7fHQ K9PNQE8m84iTc4OxK3zRkYsjh4S1Jyw6uLXEkVHrDnO/tCavMuNQe86948gQ Udq/yhrEFgQR0Kas2b+gzO1AbNz+tN0IwqfFon2Rjr+23q2g6LdQ8jPUnH2m eyBt4BsuImFA3agMqWSjESCq7W5lF2ED2L3KOkkopsdD8EpFsWpgWtQquMZu 5fXbGN4jkVR87iIktmtXFv2Ax8q3lA6MDWFpWbD+wba+3suuU+7b5Riiylqz 3ec/r/G02FL+fMLe1qaFt22h/CDhEi4nNLRZ4x+fpMIEQ6BSFUZcXGua1n1r sKwVbteTmBq2xUlO2gYLgFVS+sQqFr9JUnw9SMkMMtO9XkCZrifD57xJAhUj DIVO+cQ0LK/mSYl94xET+KMczT5pqGgbX/LSzNAOdoOfpZ/LM9PCe9rTuPNY +p4Go5Mlvx2zeQ8Or82jYqxONGDJ2q+w+b1TuTqjZBm4ad40RJ+axiQYyepj MDxTisnLKJ4Ca32/0Cq/L7LqWwo1uMZxsZn/ERkRm6cqQMq9hBO1jdKCt/E4 1ncWGy+QlPRhLUmi70E/1VSzCniKXHuO5F45pXmEtRrPbn72ezy3tUQNqZcj mOOm8WBkwAMHlC8pQkFZwmoyjlAeJ20pKCS/m9ESd8aVl/HD+Ffa6rmoMM8g 9WOzMSuEt80QyFBcrq6VhljWk13jg1CFZBRXedcbQdRH1W4IxKA5hlX4vpBJ l6nRpUWArAbYs3xDIyTBIvPnKMSWu+EkMaRllGE53venrF10Dl4M+YWs0xGU wGwja+58Xtw4h/yNp5KyAoC3BluifllMlCOqpso/DsSuNOYk7XWM4leaKWIJ qZVKsQRMPk0kP5n+EDfoibQUI9rJHLQx4/LvnGdmMMhMTOosUBC9+xe0rEhv MLILk8DW9tjlIWQPCnJrkRYuF31H66pkOlt75SlmcrgfEZQoyoWWiMXmjpQc SaHTWdBgz/scl0wNsa+wzMPMIVJkdFgexq4+MN25nwRhd1yr+ibT5ocOM1RY bONoMJQj7I3yz15wtJTla+0kD2QvfjyN7O0L9foNgJsA3eCrL33KmNYrKwPg J+KeywdtSSSsMutQ6n1hIHaDiAFO+ibvK75Nyt9f1Cpi+B8Iq7yqzKRIXfzG NTXLfysc37kiAlBkDQb7AXYg/V2Rx5aYckqxKLfBZ9vF15BCGo1l60LL97K8 lhn88yWHFe4KAjYBLUwEIm6DvSVw4bJe4JOU2eTbkRHebyQNsOlTEHuRY26j f7ZYKilWGyX8OeCcURenjQhsPbKhQY7+l4PMQJWPxi0c992OzfR2auZDO4FR Y/GKHV0oSbIzmgufeVvOt0uy7q120e3J7aAYnexgyFvhStzt4U2JWTX1EggW 4eMUi2fg496tPBzs7b1B27OEcWn7xC4lous5R3MzEPmLWy1AszYB7GFvuB1S 0Rk3uI/Qn7e/ceSoMzA5YGes+26159eSBYXunMgyGR9wu3RlP3C3ORzttn9p uyMtngh5qjylCOZy1xCFlWEswo9Ng7ns4AVuPqO1/+fAJVex9Zy325IhHpmy wiZ1m4DsZg7XejY4MwctL1W3LTkaI5JknH66Ol3DZIKj5da2X8S34mggv27G BP0bV6wxONC+o5URihiLbTtVdNUJW8mIEMRDfyqwnkTiecfsFXYA0t1mk2JY Zy6Y3qwR0NPiKiEyykxtfsraLS3PCXSVm0zglnIp8hZ68/HmTYPQBNvvVToK veDTdV4EVly0oUSeCNIXOXndpZeflWcwL4Ge/vonP/Q/JV4l7o3XXBpl4egq wmx5/4/81i+CmX7n/oGlNe9FApLXf0su7Wb7jGctBMdtpTivk7au6KN4Av9P N4NMYUBTJGQRMZrjVoA+qNTZk1r3lJpBY1GBDB0LPfASxgmB4wdLf9MP5EHq upYA7ne3rvHBL1vvMpKnzx2tIDu6zhZIh56G5yQwZzAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMApjbGVhcnRvbWFyawplbmRzdHJlYW0KZW5kb2JqCjkwIDAg b2JqCjEwNDI1CmVuZG9iago5MSAwIG9iagoxNDc4CmVuZG9iago5MiAwIG9i ago4NDE1CmVuZG9iago5MyAwIG9iago1MzIKZW5kb2JqCjk0IDAgb2JqCi9X V1VIQVArQ01SMTIKZW5kb2JqCjk1IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9D YXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIDk0IDAgUgov SXRhbGljQW5nbGUgMAovU3RlbVYgNjUKL1hIZWlnaHQgNDMxCi9Gb250QkJv eCBbIC0zNCAtMjUxIDk4OCA3NTAgXQovRmxhZ3MgNAovQ2hhclNldCAoL2Zm L2ZpL3F1b3RlcmlnaHQvcGFyZW5sZWZ0L3BhcmVucmlnaHQvcGx1cy9jb21t YS9oeXBoZW4vcGVyaW9kL29uZS90d28vdGhyZWUvZXF1YWwvQS9DL0gvSS9M L00vUC9SL1MvVC9XL2EvYi9jL2QvZS9mL2cvaC9pL2wvbS9uL28vcC9yL3Mv dC91L3Yvdy94L3kveikKL0ZvbnRGaWxlIDg5IDAgUgo+PiBlbmRvYmoKMTUg MCBvYmogPDwKL1R5cGUgL1BhZ2VzCi9Db3VudCAxCi9LaWRzIFsyIDAgUl0K Pj4gZW5kb2JqCjk2IDAgb2JqIDw8Ci9UeXBlIC9DYXRhbG9nCi9QYWdlcyAx NSAwIFIKPj4gZW5kb2JqCjk3IDAgb2JqIDw8Ci9DcmVhdG9yIChUZVgpCi9Q cm9kdWNlciAocGRmVGVYLTAuMTNkKQovQ3JlYXRpb25EYXRlIChEOjIwMDEx MjEyMjMyMzAwKQo+PiBlbmRvYmoKeHJlZgowIDk4CjAwMDAwMDAwMDAgNjU1 MzUgZiAKMDAwMDAwMjI3MiAwMDAwMCBuIAowMDAwMDAyMTU5IDAwMDAwIG4g CjAwMDAwMDAwMDkgMDAwMDAgbiAKMDAwMDAwMjEzOSAwMDAwMCBuIAowMDAw MDQ3MjE0IDAwMDAwIG4gCjAwMDAwNDA4NjEgMDAwMDAgbiAKMDAwMDAzNTI5 NSAwMDAwMCBuIAowMDAwMDI2NzM2IDAwMDAwIG4gCjAwMDAwMjM2NDIgMDAw MDAgbiAKMDAwMDAxOTYyMSAwMDAwMCBuIAowMDAwMDE1NTA3IDAwMDAwIG4g CjAwMDAwMTA3NTYgMDAwMDAgbiAKMDAwMDAwNzI2MiAwMDAwMCBuIAowMDAw MDAyNDQzIDAwMDAwIG4gCjAwMDAwNTg4NTcgMDAwMDAgbiAKMDAwMDAwMjU3 NSAwMDAwMCBuIAowMDAwMDAzMTA4IDAwMDAwIG4gCjAwMDAwMDY5NTAgMDAw MDAgbiAKMDAwMDAwNjk3MSAwMDAwMCBuIAowMDAwMDA2OTkxIDAwMDAwIG4g CjAwMDAwMDcwMTIgMDAwMDAgbiAKMDAwMDAwNzAzMiAwMDAwMCBuIAowMDAw MDA3MDYzIDAwMDAwIG4gCjAwMDAwMDczOTQgMDAwMDAgbiAKMDAwMDAwNzkz MSAwMDAwMCBuIAowMDAwMDEwNDUzIDAwMDAwIG4gCjAwMDAwMTA0NzQgMDAw MDAgbiAKMDAwMDAxMDQ5NCAwMDAwMCBuIAowMDAwMDEwNTE1IDAwMDAwIG4g CjAwMDAwMTA1MzUgMDAwMDAgbiAKMDAwMDAxMDU2NCAwMDAwMCBuIAowMDAw MDEwODg4IDAwMDAwIG4gCjAwMDAwMTE0NTEgMDAwMDAgbiAKMDAwMDAxNTA2 MiAwMDAwMCBuIAowMDAwMDE1MDgzIDAwMDAwIG4gCjAwMDAwMTUxMDQgMDAw MDAgbiAKMDAwMDAxNTEyNSAwMDAwMCBuIAowMDAwMDE1MTQ1IDAwMDAwIG4g CjAwMDAwMTUxNzYgMDAwMDAgbiAKMDAwMDAxNTYzOSAwMDAwMCBuIAowMDAw MDE2MTc5IDAwMDAwIG4gCjAwMDAwMTkzMTMgMDAwMDAgbiAKMDAwMDAxOTMz NCAwMDAwMCBuIAowMDAwMDE5MzU0IDAwMDAwIG4gCjAwMDAwMTkzNzUgMDAw MDAgbiAKMDAwMDAxOTM5NSAwMDAwMCBuIAowMDAwMDE5NDI1IDAwMDAwIG4g CjAwMDAwMTk3NTMgMDAwMDAgbiAKMDAwMDAyMDI4OCAwMDAwMCBuIAowMDAw MDIzMzIyIDAwMDAwIG4gCjAwMDAwMjMzNDMgMDAwMDAgbiAKMDAwMDAyMzM2 MyAwMDAwMCBuIAowMDAwMDIzMzg0IDAwMDAwIG4gCjAwMDAwMjM0MDQgMDAw MDAgbiAKMDAwMDAyMzQzMyAwMDAwMCBuIAowMDAwMDIzNzczIDAwMDAwIG4g CjAwMDAwMjQzMTcgMDAwMDAgbiAKMDAwMDAyNjQyNiAwMDAwMCBuIAowMDAw MDI2NDQ3IDAwMDAwIG4gCjAwMDAwMjY0NjcgMDAwMDAgbiAKMDAwMDAyNjQ4 NyAwMDAwMCBuIAowMDAwMDI2NTA3IDAwMDAwIG4gCjAwMDAwMjY1MzcgMDAw MDAgbiAKMDAwMDAyNjg2NyAwMDAwMCBuIAowMDAwMDI3NDAwIDAwMDAwIG4g CjAwMDAwMzQ5MjYgMDAwMDAgbiAKMDAwMDAzNDk0NyAwMDAwMCBuIAowMDAw MDM0OTY4IDAwMDAwIG4gCjAwMDAwMzQ5ODkgMDAwMDAgbiAKMDAwMDAzNTAw OSAwMDAwMCBuIAowMDAwMDM1MDQwIDAwMDAwIG4gCjAwMDAwMzU0MjYgMDAw MDAgbiAKMDAwMDAzNTk2MyAwMDAwMCBuIAowMDAwMDQwNTI4IDAwMDAwIG4g CjAwMDAwNDA1NDkgMDAwMDAgbiAKMDAwMDA0MDU2OSAwMDAwMCBuIAowMDAw MDQwNTkwIDAwMDAwIG4gCjAwMDAwNDA2MTAgMDAwMDAgbiAKMDAwMDA0MDY0 MSAwMDAwMCBuIAowMDAwMDQwOTkyIDAwMDAwIG4gCjAwMDAwNDE1MjQgMDAw MDAgbiAKMDAwMDA0Njg5NSAwMDAwMCBuIAowMDAwMDQ2OTE2IDAwMDAwIG4g CjAwMDAwNDY5MzYgMDAwMDAgbiAKMDAwMDA0Njk1NyAwMDAwMCBuIAowMDAw MDQ2OTc3IDAwMDAwIG4gCjAwMDAwNDcwMDggMDAwMDAgbiAKMDAwMDA0NzM0 NSAwMDAwMCBuIAowMDAwMDQ3ODc4IDAwMDAwIG4gCjAwMDAwNTg0MDUgMDAw MDAgbiAKMDAwMDA1ODQyNyAwMDAwMCBuIAowMDAwMDU4NDQ4IDAwMDAwIG4g CjAwMDAwNTg0NjkgMDAwMDAgbiAKMDAwMDA1ODQ4OSAwMDAwMCBuIAowMDAw MDU4NTE5IDAwMDAwIG4gCjAwMDAwNTg5MTUgMDAwMDAgbiAKMDAwMDA1ODk2 NiAwMDAwMCBuIAp0cmFpbGVyCjw8Ci9TaXplIDk4Ci9Sb290IDk2IDAgUgov SW5mbyA5NyAwIFIKPj4Kc3RhcnR4cmVmCjU5MDYxCiUlRU9GCg== --0-1361544525-1008220676=:29700-- From owner-ips@ece.cmu.edu Thu Dec 13 01:58:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04747 for ; Thu, 13 Dec 2001 01:58:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBD65kO21566 for ips-outgoing; Thu, 13 Dec 2001 01:05:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBD65hZ21559 for ; Thu, 13 Dec 2001 01:05:43 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id EDEB4324B; Wed, 12 Dec 2001 23:05:42 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id B1E7D2AC; Wed, 12 Dec 2001 23:05:42 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 12 Dec 2001 23:05:42 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 23:05:42 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF763@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'ltuikov@yahoo.com'" , "'Paul Koning'" , "CAVANNA,VICENTE V (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" Subject: assumed CRC circuit performs simultaneous mult and division Date: Wed, 12 Dec 2001 23:05:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1839C.315F23A0" Sender: owner-ips@ece.cmu.edu 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_01C1839C.315F23A0 Content-Type: text/plain; charset="iso-8859-1" Regarding my earlier memo "effect of initializing CRC reg to 1's depends on implementation?", here are more details and a proposed fix. This little detail has generated a _lot_ of discussion among Luben Tuikov, Paul Koning and myself and in fact we have not all quite agreed yet on the severity of hte problem and how to fix it. Where I see the iSCSI spec deficient is in not making explicit that the assumed circuit performs _simultaneous_ multiplication by x^32 of the message, M(x), and division by G(x). When the spec says that the message M(x) is multiplied by x^32 and divided by G(x), if the spec said that the division must occur simultaneously with the multiplication by x^32, as it does in the attached circuit, then the spec would be correct. In other words, with that assumption the spec is correct in saying that initializing the CRC register to 1's is equivalent (produces same remainder and quotient) to complementing the first 32 bits of the message. If the assumed circuit is the divide-only circuit that I also am attaching, then initializing the CRC register to 1's, as the spec requires, will _not_ result in the correct remainder specified by iSCSI in its examples since initializing _that_ circuit to 1's implements a different division than what the iSCSI examples assume. On the other hand the receiver will still compute the same magic constant that the iSCSi spec specifies since the magic constant is not dependent on the actual message or its remainder but rather on the fact that there were no errors. This is what Luben observed and what he and Paul and I have been discussing (and still are) for a while. This is why I am claiming that the iSCSI spec should be fixed by either: 1. making it explicit that the assumed circuit performs simultaneous multiplication by x^32 and division by G(x) such as the attached circuit OR 2. saying that hte most significant 32 bits of the message should be complemented - rather than saying that the CRC register be initialized to 1s, since the effect of the last statement is implementation dependent, whereas the effect of the first statement is independent of the implementation. Vince <> ------_=_NextPart_000_01C1839C.315F23A0 Content-Type: application/octet-stream; name="Scan_Fro.pdf" Content-Disposition: attachment; filename="Scan_Fro.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJSDi48/TCjEgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL01lZGlhQm94IFswIDAgNjEy IDc5Ml0NL0Nyb3BCb3ggWzAgMCA2MTIgNzkyXQ0vUGFyZW50IDIgMCBSDSAvUm90YXRlIDAgL1Jl c291cmNlcyA8PA0vUHJvY1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0NL1hPYmpl Y3QgPDwNL09iajMgMyAwIFIgICA+Pg0gPj4NL0NvbnRlbnRzIFsgNCAwIFIgIF0NPj4NZW5kb2Jq DTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmozIC9X aWR0aCAyNTUwIC9IZWlnaHQgMzMwMCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEg IHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4 RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/ luKKMs5Sv/6+8S1Frj5ZD1B7ruGvYVvlqGvbu6xblkq4cQ3JsakMEQRmJDtQFLZAIt1gM5Nsk7lu qAXTorrWWYCBSl8LZ3TtVBOpkqd2lZZMNKHLcsBpJRW6lcS8rqSYahFDpYRAjEugtP3UrgRkfQgk 6IP4R0SqOuNQQQkELCIaFj4IFBXKH1arSgnCENwgkWOFghCVKsyCldFdQGaEEw6IUNCKX9DWix4X hBI6kVLTSWnQQ0E8IEI/vaogQP24QKtJcr1eEQg5zlOU9AvS+13SYifVN0F6DI6Lpa1lDghCh6C6 K4jI4Zl52W76EJBdLtC+EJ2aojojt8ILvVYJ5miOCZkLBnUi6NrSS6S4KdoQTI4KHMhsDCmEhegk FevzvECEaDOwXUg+gQWSYL0l9fUELMltdkpDNNYEEuGjpJ9JaIKIKHP0mc61ogxwJQRAiKpJPX5Z AQiT4QpewiKOToEzjkIXILr5SomnevhYyDYOao6UWOVsrdrQsIiDRMmQSQ5Pca79eOiGpcbKRFOj eCKcb6hBCEyPhFDhBA9JIiiS/R3687hHqTcgvMEK+9g/WgqFCESnXrTW6BquVWylAwCCZpodBiIh sl6H3QQUFdlQtKoYXshgcperreSUFyOKO23pvrVBAlCw/VNBPQka59naq9cIijlDggsqwr711+oV Iixh/Vr4M7K35UJOg2avjggURHeGw07bRMeoQSC4JtA9LbCTwyDRsDB9Jp/0CIg4QilhhpKg+r+l O0Kudwa0So1ojoJcMMEyHkqO9s77W9PQQusPwXS5CjddVdWH4J0SokC5bgQZoTyKh6/CeVfp3CT2 4a3puyBA5xCr/UMPyJgitheW4qCg7tJphb9VyIDupBsmLCBf6osdqksSEIWlpLQb8Fq0+W5UGgiS I6I5prr+dcpPRG/BBqoJhEQYdQYbrCcqEw2lTMDdXZBqm9/wkw1I2lNTMZHQJ3YS5bhYYBBMSIMo g/8L+E10t09VTyOgqSXqDaqlfWG0tJUlVtwuUBq0xC5bkgcEL0CfRC2/1CaoLVdQmmMNNtW1pbVA m1WyUBl1a9JJA3QSImevXDaeiJVUIJrT010nwtKqba0giXq7DeiK6V9LIWGhQw+tJJ1Cq3INLvDC 4cJ2gh0C+tV1+Qj9V3C6WE6Ft0lVvSytAwgfartvSrCaX4NohO9YQQS/TC6C6CIo4nfqCIUemml0 m6tpJPT9ZNAoYNKsJJOqVtsF6VW0R6dKq2/VXpLiNZFHpNq6qjj+rJdO4SWr0sOwd9JIL8JuasuE rVbaCD6WEFa+iMeqr6Ix+lhLXC8UmMLI66CWt627IYGvhK/pEh1Yn1bhB90v00lf6deF6HpYQXSq 1SkI003hpLvnZPSfDIMJOkgq6VJux1QfbSXSpL7VLCIj9UlrSUJU7hU1XdBEdKhTVb66YZTvXCpL eEF3Wmt0EF60F/pYS9LeRB+lpdJohHXgusYKgrChvtJtEx2LD+ILC1QXb25Hjq3QS0tL/S0EvSqi zkUHpwgWieHVpBdNHVBI+k2qMwdhJfxWrYN+lglbgl94QJhkdLdQt+kv9YSfSrx1Q/HCrpk4ZxaT il0ruFhJhg3XCSCXYStg0m9i6rSTSS1+6tpLGtVoKQfTxC/LhlnEusKt+rCTZ0RhkCL0sEvS4e6h +6gqH6v6VJb12hpQ+FSxIbB9+wvr2nCCZCDlW974WCXhBcPTQTCSJsnW6CCfS0/7CXpe0wk68z69 eqhJr5UXZzCTEXV1pYILsJYYPboHSH4IKq19CtAqMdKvVUw0EoqyCgcKGLp0woWC5EDp8JMQtOIV kcM/ggtgyOiOknSBpZb6JNUktJfr+tBPpVV1R9aCGH1BLeCWagtWpSIIIMIjQnxC7CBZG0xEnrTo VoOIhP4V9qIWFyPfvVMNLTqQxp7DCYS0tlAYYTpKCCIQQjpaSYW2cDFArIZSEw3raCVdfqFFcetV VwlSBFDoNIFVMEPYSozAgWPSEQQXwXFWEmQzfsNqsOF+FPL+qphK3TVBhmE1pBBONC41BmAYzYbP MAhS8EnZY9kOKWE0QYjDvEILYQVOXWFH6/P1ZEdUrYmiZQ4ToER0MJ/DFYQJ4glBJawZMpsJQQQf BgiOlwYRHBDQKVwwwU3/wqx2yOgtBrgxEVCHVVpRTCaiQoF8eFnVBAgeoy6WyhwYSBkEKFGhId6/ TVfEGeCY0GFGO9wUhoHKkci7ghRJX4YLKARqoy6SsMJMmOUW+tK366DUUwg4aphC7CkMDghDPvzD mFv4Mocw0wgRlgIrGYVbCWO7C0nXa8WhEYQpMFiIjxWIpHAQy0RHNsGhQUMhnqTZLiawmNW6FrYW w2kQrcNY2iEX5ggoMhljhMMkBjwwSX47VUGCkbevxBA6cMVITltBket93BkLImE2GccFjwhOyODB RXj9CoaaoRXQIYNMKqrfEdcIFDIKFZAuoq1jtN5kIB5bigcNO0Pj0gogyCAfb0WP0oMkKQwl48Fj Qv+EFH+gt99EO+9XhAltdYS4/hBJfVEVCr637oJV/QVd9BLybAaXS7ST0gliNa5aFv+goXtrTG7w u0KpGRJ1rHapUqW31rS6/bS+t6S9/0vpe/ul7SsLSi2FxVrUMLwwrUf//ICDC8TNR////LLnyyDu JNw0Yy6IhEdJy0iUzMG0RrEgWOWO8goHEXRCjnMFwUOiyhSoIREoiODceJTn+/+/nHaxfgtb7OP4 /6/yCfyVCdtP8Nff0SgP6Qb/T+yGat906rlnM7bBHHheV9YxlkIRcUjg1FxkfI+XifIaNo2vQsJe JGbmZTiOIiJEgRJ4U5Wyq6FZEw0UQ2G/mHIYg9RxxEg0j0GEJHBMcqCrPhW6eW6zmQw1S1KvINA5 TlcUbJDedzPkY5Q4kUcREREREhRyY54IQqurCpCG3iIhnER0aIzRhE6KdHYPNikdGRNnXBCIiIiI iQ2Dmc4Nt8JNMaERERIMDkLhhyhyMrMOQg4iQbjleV54NqVBQZhyK5dkWCgZ/ESB4NQ5xzDkNA5V mHESHd2kDBNQ8REQZEoIRIKBxERIYcRHEREgeBu5ks45hzuQwORIJDjbSG2QVBzuYd5aCB4LTnHO OUOfxERIHgoHIMDljluQQcg0uCERERE4B4K7aSyGmMWinAzBWoREnReNwmSgQjgfMfIZiZIyLZHA zAuiS6wXaaygi9xJhG0XjNFwPBXMBkAykdBREl0RwII5NYjxERIjMIwjaJw0y4IQNGMuDYYRdEeI 6I6Loj5xkdkdlxCOBgxm0IiPSXERE1BliIiIiIiIiIkNCP9TLVH0NIP4j/9P6olAfrS/vQbrqla/ Vv/v10r70rf9J+qpaWumv6j16/tZZalqxx99f/68suv9IZXtf4avll1VD8a+UK1kCy4MniO8ItUy LyDaORcLHM5Djq7ZHQZsK8lBQ5blCSFbYiIiNIO7p1LM5G9qSHk3SehEYQd+U2GRHtyBY3K6yimK gYSdeIIGuvCf+4dKncswIgibh3S8E86IwExraDUXrpQ6Da1dPb1/tv9NN9LeRsyuWot1XB3X/2g9 167SmRZewwevj3e4X01rTfreFqdeEr18NKt7v95xwTnaVlzgl7t/YjnZIiODpJf3XLOp6hCzi//+ LhU9Un/6hPSq/v5Zhc8EQT/X9v+HwXep2ru+qO67lkSJPhBLWgT7pVCe1VwgQQS0oJ/+SMLybBcO mkfD2uC9LZ13TQfJsWiKqCYL0jsPCBNP6q6kGiPkcJwTSVIfzuYEJ6uEsGYbKodEpwz1JsLAxU49 K/BHHIOBotwdfpaDKuy4e0+CSS9J9Hbgw2ED1/ZEB1RoOPUoDLtBBQq0ulCBZXFY2jGE+lBK4MXE dQuybGAIqtb6CIUcFZhG2V6kXqI5QyPhdSDD4JUDBi2shodcEFBC8KlwkpBouCoQehFaGpqd0awz 66BrIkJEMeuEQXZ/ayx1qEQjoULJBBMIqAgTnfqnqSALxVomOG6SpLwQWl/UENF0CFIQhET+t0l9 bB36IVHSBdd/UMK74TusggbLDhv1hBHNquFpdekyCoPCIWQISCiLi9clIGOzML0rC9wX/rCJYiOR gQj4gihwkCI+kJOk9LIogQX2xC6HoETY0el/wYiGEKEIKISBDcJMiPBCEuG8Iodflm47+P2QilBA sqL/l6hIJrD0hX1C6+lIYLUkSoMFAQlmlYSa0hGlw+q9L6+2QzlGCJSGgIGRrI4iCVQ+Fp/iE9vC /XTIFxKEgqDKsF/CUiQtBMjc9F2Fq9Jb9eyGWBUEFCgoVVhDpQRHQ2pjcE6vyHNlhr94YeEjVKiE HdVhOsJCPSUV+0DVtL6O0Bs6VEIORR0ggbCIOO9aXQXHSCfw0/p87EB7SthBQ0MEDqwiOqwsNsJb Trd7/9TtWLQQWkOloh4EIKKhJEY+QfYJXS2Q4QPp6nTwkuG/UILhBYJAgXSSCtMgRsmUHCC+Ek3s tzN3TrhXwfhKmuXDOlYzjwoS7uK6DCDvwrJzKHcJb1+1CSULCrBB6SBJLg7gn4VB+kj1ZEbg+4X3 4QVJaaSGKBQgqYcG0rQMocFUPluUajhnbpKqlf+lC3ao9qCQJUGDbBLcQwWndBwnH7Cf1pBJJVZC jEE8oDScigMBsEtoaD9tBfuiEH+u0v844IjrCBMER8EFg8Qsjoe6tpL9ggvdaUFpXERYhREhoHCa B0rV/aSWsMJdWUrQXgunsscKCSEHDC6+w1X2GCT6wwnpJa2EOCoHYVYLeGktUxC8Ow0vBcEnIGDs JhCGcc21rlXglsN0lrCTtWDBSMuwRBd8cME5AhuS8ECid/ikqphMO2wYMui7I4I6xCg5BgfZGBTg oYK6EGginWw510hwwqS4iIUbBQTuwZODkdWDKNnpiPDtIMzCA0wX4aahW6hiCFsaoah4oTtQFe3B hcFULph3+2hGs7oFDsLDVMg3HCeu8NgnbHDJp0DBbKHCElyutoOEvio4sh4/9Ex8ImxgMusXyExd 16QYYYImyQNT2sT1a/WxOwXPJAyky3UluOwyXCf0g52lBnRBV0BWg+uGEv4SbRBqwpc4jFhDhhmA b/0g2dqiRDWXQRpGOxIED+ulZ2LtUQ2xyhyl4k6JcMsuehX9IOgwRT2IkLZ5KsQyGgcLw7/S3EWK sjoigcawyDccL+guGGQQgOhFvJYC4/pJ3hmoGuF49VSphhsiMjsjxHDP/vsJC7DERPAx6/0FZrCA 3/v0m2ww/8dKG2yVAhIX78ILBsloUf36Tbgw38eEru16qk5dBwYa/dBWL25Ci+kkHsG8JfuvDegv 8K2w3oL9NPvoKu47bela8mwsZHRsFDfqRvr+TYbBtI63baVJa5NhGbAnI4pfBFP9VXupNkZHA8FT 1CSXVwQ/Ck7/6cg2EfIzLo2KRx+kl/RDMEnebBTNoqAQ3F0YzwIRxFtfXohnU/DQkHcRERHaCrNh COdWpHtOQIi7Ebf8SGGgD1ZWwSpVFIZAZQ+1WpDTaC+2J2ULyFYyGeZUHHPZTnsscbaXyBuOU0Gv j6cjgxaQaRyvKIIx/VnBeJEZVQq+r06EraI6MIxiIkSEYathB9rW1e0xERlj2KjzQGZte1Tv7+Rg MsVfVvSetSJg0v19qErsLFr/uOHhOH7X0vLwrSP/p7SHquqXdcN/Vd7wq6j3S2QpuCLSdEx3vCap JKretv0tIN/K/ho0kurF6pKvba0/SbSfr6SpPluSq6SQSaoPrRcfQWvggQ6sjxlUj8eyOiPEP6ST 60FSQhkci8YyPmES6JKZHRcM5HBmLjKEuEqSFR1EREWXBcSPEdEdEql0IiRjlLwlCCunrEhx2EUO OQg5WEQcm7BCJA4HEhJLektUrow4iIiIiIgwloJ1fxILcOYoK4iQdyhyKOXtOazxUJdL0Q2Dn87k DwbMKHIZg5xzDluRuVYkM8Hc/CIiJCufyUFDkoIYcococ5BMcR0Ev7zQhEjERwOCOBAiIiIkuEI4 ZIF8JbT1boT2VYMEePoTWjYZMoILq+hQiIiDSQSx7GDIZAMo6wgrrCK5KCkdQPDVI6D0Eqsm4xaL cJEcysRHBcp8jgwR0OmECv7QiIiI0EjUGPHSSQIF9tQkfDRd2qQp+VyERxqEQ0lz3j0gmRFl9JBS DBX6yGWuIH7kM66R/ZBFxJFuIXaIjK4nWPgggQlcCwqJDlDk4IKVyOuIjCDCEToj2bGYxHhxERHr f10/jyziSLIBriSyBMtArcIMm5QJd1BFDvqmhkQiXSfLOJrW00HxwSvhGER16JukDQX10hEm4KvQ QQXybkvX0kl8ydXj2gRB4HenVXYJAn1XTuIIJEV93rXJudQqpAiOqWr2IQJxxqk0ugltevlmaOFv f9sKgvo7F9KER87Jx5EdGP61+diaREroQZHkRR8WvJsDBcLC9QQ6CEM7Qgggtkcu3DUEvztIBGW5 aGwEEIaX615bi16VAuRTNoEQ0PRFcRFdbotxISvVEGB5myP4UECUyBUdoDNBNmctyk87Wa+kCaX4 JDEYIY5JUagLkdozluKEbOy0V9hlj2ECKHD/0ChlEbRHwibhEdWdBwYQQoRKdKEFmQqPiZmwkOvw RDjnHBMQbhMRI0jp6DVhIiDxVFoYQP0KhdaSEYhBMIXYTtEIOYc49AgUdRT6haS1hUgRGgy9NkSb G4rN5g6JEaknXUqEvTggRFgy4SmoZA/VBjVkdYTsiNckCJ3oIhjoV/VBMLChEEBkJuKa2hBkdRFw ZSL0H/SUQl+ggYKlCDBEx+FTqIeCa1nwYU3EdV0C6hfzQdytAjrIg3HM4QTBFjjdZId8jHIMF3Bp +p2BovyP2hJNzWtBL69Yj2iEEnFKiHtQgfiHYQelpnasEQQdO6UEklukw7QSaLHKFaVQnhEdPhh5 w4dkPuwiCDndhENANRe8mwo4S6ryHKaWmQdpWlca7DiCh99QhwQNJa4Wgtfog3GvUJVkUcodKgtQ uDJjtENl0S447pOtJsIikQt6LcWyNaSpJKl7IZROkqSdQUQohJUFxPhioKhvtWIToIpzpGH9MLrS Wvl0w/XCVUgRHXxSUod0CpMPBcMK4WqUli/r0EqXxYfS5rCpWo0p9JKJ4SHSV4TwkoIJJKoaVbSp arS9tvCSQLxVKXYpOHiqDaqu0kqLHinXsJbWkq+dgwUUoK2ZhogoWg3dpLbwXS4ShJWPtpLQ1hez tJEcH3CUdXVtK6XuFqFaSSVJe0sMIJUqdEDQnhNQSaluU5lDrQLVkO/Cx7XQSCC5b+2EqFLTqxlP TjrEfhQs7RpLSgqIZx2qVJAoJJb8MNLrRFf4h+pBRG20oTXatS7ufDOgnVpcEkF/9BJILS699kCP w2HoKFWEqcImOghsJB1ThIFCXhrhtXSUEvdaZDOPRBxwSsMl96ceiMCYoU1h1aWkgSSw1q0h9Jr1 4XjyC+HsFVwoXYUGlSYK1Hswi4Neo9sJJYQXqdowtwoMeLEW6Hhk4YrYSTFJREguOFv24VEbsJWe t8p8JUwu+92Qg6WEwmCD8JpJbtpJFJBFD9Lr4ZIBhWC6cO4xCqpDQnTXBIL6sVmjQimwlrtsj4t1 jVMF8p1UKCggqSIMICX9ZdEcJ6C1+wRQ4hfsodBxGQIHC1DKHCEMEsgg6YKvtRGFwS0kuIljgusZ McOwih0I0IYLQUkOUOEKC37pwohRtOxTVYsqChw8QYIj9CGsRGqT90tU0kd1sjhxaxFkIGmUOU4Q sJqhVh+9qnGkVhTlbW3BgoiIjXD6aC2ChYiOGQYHjUMu6p0tY1HUQ9om4cFbCqwZh1XaUNwS0wko oQwukG0RQlhDbsL0w2FQ4MEGTb9hJsmyRFzKMuiOjUgwvDO6HdNjiIhBCfyOGYLWI8JNqVCMAq01 0mGpsD2wl4SDBnYEokFNyN7C+k9sg2jcfhW02QwtL9BqyJKT3Fek3DJMWv8JrCIELnqTdUVdBDog YXu4/phyDSOeSVX48SCSC/+UPQP/7f9e279f8l4eSsLt8W7I6ZI7wg8s9NK7bFhGHlOiOiOD/3/Y TYicCdb9SbLBEcMozPxYdokDwyPcmxSjgLKbYb/Y7RNvzbM0byO0IvDdZ8tqmTY1AguB4aTbeQ5h rad47D8MINKg/V7vBFjinQXRA8OO217CQa/yBxxRMi3burCsK38g2pZCv120EGHjdkrO5D7V9vbQ SdcRM1vq2kt1G7bOqKgEI++lft/I4dEKOW4kLBrO5VZygqu2kiUfW8REREZHiOGWRwzCOCYYr+93 ETDiI6S84yOt/G/0hJpkT3b30k5DCZA/pECR7x6IGBzJmvu2QfQqDuYc8FVFQUOVhQ5nINY9OuLI 4KC77uybxERERERKtFSReI5kc+uIkRMAlqtOdhoREdBtcHd33HTDBZDArq/jybsbNQKV069XyXDW q6f0+Ol1pbfdV3Tf/S1fvr6Tf+lX/aS06Tde9ev9UurV7XXS+gdJJdQvBrpai8EGTdWBGlr0ybkA 0YStK6ZNgoyOy4yOGqkl1yvMGgmwkyOB4bqlVfJtQDwzaCVtfK4IZjMRpF8uyPmYLl0bjGR0bA8G 5gUJBLHJvV0GZCSI5EcQjowGCEDIBTSoEn06IKrlywziIiQUOQyAanJDlASChL4eJF4gw5Q5Y5IQ VZ1UiDiJDIBgcykkEEEuniIizCPAYBCQyAONkJQS8IOyNxEg1uXqQPBsGEoLHKcjcgkFUKHIfZhU EF6dqIkNXjcWMIMSSwgkEE/JwHdENEFjkMgFC61SNQZ+1h+EJnmA2GIjgeGsYQSokA3XoMGWkNvF CT4kYiNhtDCoIJ9IkDQZdcRBkFDkm9SBIzAvlYDRhs3oehFI2ggyOBjJUGlUHp6Q0ILIECqrFw7V ILNYFFBu7TSINK5xIa45I3GQyh0TZRyxyY4cNQUhlL6kFQcqCnM5S6Cl09/BiDlcYKTcTUg3UipC ZBrBouhoHMljFQ5kWd2fQhhcCIaHKNzO90G6lepBFDxDMzpT/BlDsbGR0LtePDjQrv/p+3luJLfh JTIK0Hvf9P/+nf9eq/nYrdoLDKbk+7giPql9dPvotxtWP9fQSvdq/6v9/6f/yMXvV9+x2rW+unp9 GQju+3/6h/11mRHpWdlOv+W/0/tMN/6da9bI0ocP99/9NhSNL3//35LR6ZEI2NB3fVf39NhpAhD3 XT3/baqGwSTu33v+/SbYSW4f8hSI7rO9ApHWtrhO0CkSdFj2/uCENNwhD/dJMjW2CokRVw/pQih3 2EyOFf12wiNQE3u3e7CG+ELMprNr7CcMJ/h//fUij0iOiOCjUiSCInbY/W9yLslWaruFvQIoDOU6 JggQiD9NW0DhU3SV5L5PhELZwNheq6cES6I4iYQMIOyR8QnRIciGQSfpg3oNC70/r0EhfTXykVJO Eg3Vb1pmBVBbX7df6pp+n10w2F6pWd2GnfgvLWFE6X1WneqfCsKDdVpBWyZBtJ+FNXUaIECjpL1Q LbXV0m01WKsrIKy3qSB9Ov/RETkGCwgo46fppVoJwv1YLIVyhyh9+vLWSWkSm+vhBBsqDjlTQ+Fv 9wg/SaQghF21C32SETo2ERNAgRH2Na0lER/C9aTYJ9dyCq626ChPoHqwRSGCCjr9KEnT69aTohMa mxVhdNPcVXkMDn4pxhhFWMEIxXS1CkV7WwnS9cK4hppnIxGyDaVbqE9MRHBAhJuVdpL6UjY68EQ7 +lSwobjkFxxEPkNdwqpvT/BIocofgij/9EslOjgPvglf+qC+K5DMcpOtuQwOU9e1SEQQjX6VEMUk YIVrhJrpYQUJPSQbkHPH7xpPhrQXpaUIYgu8jhnVUq1QIG+EsF+3WEQ8eWsKsjhp8Fr/oF8QTfhJ UgQV0iGW5gPI66VtoER0oSfiGQy7SyQ4JLCrqiBA0+t66IYJhtqSsiDmHCHHq3odBdy1gsNg7jem 6VSEHOKp4T+k4ShXCoREP+9R9S1iREci80kukkuiMcIdUF3SQUJU7OW/VtukFfFx2grYTulYQ+wv hbFIKxSS99JJvTV2FwiK/9L4K/0FCfX4MjhGoXvyQWnaWYWtL8EljTKHChB2tvY6oN7ThnkE7W0r XrtaYJ/SSFqq/qk9eEKsEUORI2CsV9wyOtofqIJxr3qE33tGdSFgw4p2GYB96piQiChkV4TCST92 km/xEJiPYhaS8Q/xDBCvtC1/agkHW12Qaf2zurI+lq1BP9oGUOg9UKVlDI42FXiKXQMoc4rhkc/w QsFhgvYcUyChQvCXiLTEhHNIR7Kc4EWOFChVTFBoVbCXoJj+IkSEI+2GRiKwiDB+66Fg/sqThNQi BdZblGCT8hnHBexEaHuKTsN+mCSsEumF8GiLrYZbmATwyMcF7LcJG0Owcm/aEbTiKtiihwVDTLM4 yYlaDiN8s43kYDWaA+v9M8B76euhbq1+vBhe5Bscg1m9dIV7ISChyRgocg7r/wQiIta10F9fryBJ V7qo1X90l1v/v9Im639ryb0WVyzV17rfpDX9u6r37fhSbmWF/TeIS6pZBBG7cm4EFv+ED2+or2mr eGv68aCr6uzDwaf8knsY19JXr/kSAgjitv9Io3IQG3r5G+gg7NAKHHWZpbC1dfQYTj0+n2lV767S fRBqHIKDYQv2lXIKEyDXbp+RBySZAn21DIr8GEP7SH/4bS8P/SSsdbaXlmK1vY+hrsLv7///VtL/ unvSbadb6avp/U7Et1f46I3fXWmHV90mh/1fybpLVv4J0k39dW/YTum/XpN/vV/+gr+F6f691/VJ rul4/d0uqXX//pYa+ko/d39fr1OL1xfpStgx3zWiTBp/iZozBsqlRLoIJrsJMjgeL6LewPBi9AiB 4QcpMpW0iBYmiFFkFccpNA+QzwbCk0UtszMJnaZRj6v9S2o1/6Tvqu9/+k8uqpCPveV3X07oseut 7qWuJ668tYoMIOtL3f3dwmt9Q3eEpQ/trhwQgi65Nxv78EUPTunZqSRDWkkhke0ocnGiLUGQtfZH AjabaIcGEEQQpa5kqIIQRhFIdVTCahNMlxdTIXRHZdBNiwle3tL7rIxRCBOIkMyooeS662tWFQb1 mR0XwihxEicSHDLpCxI+Rxeraa2ZsjxHpQ7tVUEIiQgdhmAzkYkOqsXVBCOJUUGShAihx2ZGuCIO OVazwZy4OCFnU/yE+kuC8scp3xWRs0MRcoDMCKH3pJoOsg46CaVUOROdIhEsIusMjHOOQowa/QTa wgnWl4QnHXpkw0hplHQcL0mnSRId16agjj3STUqBIViCRvBEY5Nyn3MiP90oQZQZFtWmmoQL6tUw n0GFd3Sd1SrXGWDHGxBVwiOgoUiih2CKHSoER0hC4t1fVaVEIcJPTVMUQLiKEILCExTVkx/W+upI eiDqyhxBHJpJDWD0iOgVIEdxYQ+1pesIIUzDhRItBD5DA7kWIZQ7wgo1QQKkvST9dXiiE1Rx2oVo IJxDIZRGPiP/pL6QapiFF01cIHJoGzSQ6/MPCu/wVEQGcwiOyPGxFgnUKGvCr69JpO6HOpEcGm3C WgmzuwfUxhFO3vSWq68QoTpQlqgb00wlCr9oLbI6J51bRTkG4atfU7IE0Pr16XFlwlhTpMaQfqkm 330RGdbp9wk8dqZoEU4RHTCQQ2gtQUPogw5HAlD63XaSVeYkIxgq6WkyS78hxwToJkHjeviqasIR QZDA4KQXKUXS+CdhXoUIIMpzOCu/XTTTIV0DKctwhgg/C8ERR+FWCDCEReyFf7YQwUQQwQoIRpJC NIIoddCoYNf0ggyY6BkCB0LBVUhsHwycE2Uq00+V1a7oRhJTbolhPG0O/UX0mgwhOq1atEY4TUIj pvuNJNM44XXC2IQqLT1jDJERGqhOgoZUS/EUFwv/9ikGcc9VrH6ViNhhXC5Zk0XRVhJd1NaNxtJM ijlbVlTY8s4rFOiOBI+VwRYhAi+kCKdhnQVswFezwHrUaERFxGqqXBmI5LbC/sSDS5Av3ocySL6I PZQ5XlUO5RyhyhyiG9af5FHBDkeEIEIl7xOZHUFf3VqEIiIiIivfa7r9WEtf6eK7+tNXX9U6Vf29 f/YV9/pgiP/+sRrax/q+rVtfT+l7kTr/69V7+/v3S1XP7X/010rvohA/+7votxZdfvSEugX6Uw4d +1+0zA63/q3eW4uF7gih4cN1VXTCGvtLXOQRN/eLCvppU65Z1L5NxvqwQXYLj79eIXRQ8J7aC2u0 u6T10121hAwX0+KFlDrLh/7CEdEC8GTIhwlvxIo5aZP/xEhUzHpPJjkCRMGfZXS1poSBWmFhVH5H Yd1daNQK1dYeVYad6W3HrSJRW79fVL4fetQ3/9+vpf69h/9JvvXX/1f6X198JP7SBFRxXWKginv2 dwraX4+/HDCy2CRfHHv9X7d//X0l32YClrX64sflSDWJuZomwKt5LopwV0yUIeEQXcUTcn4+JBmN yhploheja7T0yDK5bnc7kx4kdHFSr0RRzuQyxzgUR8tzGTF9pxGlxte0PpoHkJV30TH2kvF/7PKr 46TwxXvX9fLMBEtXSudjdx96rC/S2U3H6ddcVwpAz/WRtVaSftdPqFeuvbtU7ZaxWuly3S/4SCr6 6r6tctWMfSrXhN8E+le2tfpuqQ1+9oF9U18H6+k16Q9fSX6phbiF/fCISOpkWEUo79K6C+gTBEPs EX10FVIIKEyOklkNG8wkl5Tg4UIQ7K7rBA1thBLoEnfeS4NP67BBHeupVpM8yC7IEDkWRWsE/pVQ SIhLrYJ2SgGs7r/CINDgiPkqFS6CWwVMqIE5HCtEJxxxqCa9SBeo4p/VUFvVBA0sITgJ+thENhdh PJeOxyuklYRBIS2EkhpBZCfSRq761pV6S4QWnQJV1XYYWEyI/kXuE1ULWFm6IWuEquEglwSwmnVA yj8g8LppekLkEPXCCS1QXRjIfWFTvGrVEPD0gvewk6rC30lxUgw5HRH9QpUdL4Qr1NY0uKglhdBf UF5QgRUZPZTXu+6YL0gTW6YIhiuugqXQVY6fqqW+m11QTS9ggtUqX1VResKFT11QWqSaXUEtER/C r0FbpXohHrVdNQl6tBVMitIhMguEl69Kkl60sIiDv/zCqtIKgqiiR4IgxHS9JWvrT9BfSS9qKS1/ dKggXhL/vpardKgk9X8iapdJYL1wvSr6XXVdCtL6+qS+l9aBegur9aql4SpKv9Kl1wuklIuuK1// Wumgl+lVUkqyY+vSkI0FwvvI1vSXWtKgq0tUtLVKU4S2+k4XWeXB5SFB/rXWvr+klTSiPSpVrrC2 w8EtdA1WvQS2F69LX7ilwutdvBV3IiI6ta6ivLo4F/SCX19JRuFhLYeEtbOgSGlkQtKFxFelr19a WqitvBJqkQo4QbC0IXqj21+qBfZEt+qtwVU3YSrYphglharCX9UEq2wt6S9gqpuz4EX8VVcER0qT S96XkegwgvpBcaaDxSVUGtlD/GKa9rS0NkGB03bSQXQmkG4XsKUOh2klhQXhrQXsSD6ekukyVLCa WCaGtrD+KFVUL5lphVtgmKhbTTjUKEDBV01sFdelcXgtQyIOCIkIsEkO0gQ0DIEKN8JS39MKsgaE M0hRD4eCYQYLpCEkF4YTCHEfUYJoemgh8MIMocm3E8Lxe6XgwQikL96hNY9JXeq8NP1EaoVrdGVe 1S8RFf5ka9IpnVEYiuMWPLOCopcWhaQiPyziYZpFAQshIhroY//SX/hsMsYUOQ1xyY6qCKfQnQHI +O+PEaG3rrv9f+vV+/0vt/WyUL+mla1P979L/3/Va///+vS3rP319M1arf8L9X8L11bbBBX9/X1r 2gv/ugt/+v+ttKv3xCf+TcGuh8s1K9DtB9/75aA8f0PVdcb99f9Kg/un/kna/Vuv0w7rpN9/bctR WvpN1/UOmWjpf03pj/fvrXw6WrXDLQUsjrvjk3CbDLQJgnWvbLQBBn/+RSYa/F1waBPlnn16YaXj /iTcnr71UV2/2yGLnR9dbREDgg9eqk3OyPwS9P0YfLHsWdrPBa/tLSwbuFra+r2wdRBJfkdQaT+t hb7iFXr6QU16pElDOlrVrQ/sjaOBpE35Jek+CuRNeI9fvyuJKnC/irSSJsYRK1aQpJBP0Gn1EacI LJMP5A8ZuTxZXJLpcl0C8MgtQC0l9OjWGi5Zy1kcNQjkPWqw1IYKOIicSdN9Q8+GVUs6UjRG0R0b RohcIJ6+jYZRHXLOpoRERHXVbQgh5XDxwgv2V2uOEFriTlBdwXS3RBQbV+ElKAh3irMhtKGQYNi9 Fma+CUWSvQaWgdQW08IgjyuCq0wmU6Xh1OOSNgJJOwQSnVHYriCKdPw+87wUR64QTppmQ4Nbau0d iqasrSBd+gklzslSWmIUbTtLhWIWq3BdkYqWHEFa0FpkIN+QLksLDWjITEKR/SBAtSnBwpFLRBgz cjfaRJrbBFO6qkCCtI6hoDkZhPZD7ignYevKHYQtheibhQEYUJ9hMgazVdd1eLYWCI68Im5YDelX 01M/T119ttBMIfQS0k9Qna9dcNUjo0mwghtVIEPVV+1T/XCDS07JdIodoFWoXShExyOfwut/Sp+r nUOVeNhLjBXoij0oQf0QsPT/SSkoB0oQdAg9sECqGRo6XCUGtJL81rq/CT6raauEFx9KqofQTeqe vStMGtJ4TBWIXLM1Z2VLiuq+F6QT910g9a4VWuE/pRXVJ0P69LvM9I4CF3p1W1Hrp4r2u9VSB9dB XqrWk3qlWr9fpKE9BLCXog/FD0ES5V1uF7dVVe30rqF0ndBC6hB/90qqtfrwkqcaFegQdIFBdV18 io/r6VOCtQTxV0FvoLp+kuRB1gq+lQVKrhcIEwiKO6mRhMFj5Luq6SQMuiOH+lVarrUoBQEg3vFP wt1pbEfelQSaguglng0GCV+L+dRKpPrfVKwkGFW0rRgFDoK/8MFf66VuKhkcGBa4SoSGc9Jv9xC0 lpWnuoggwXhKtJ/21TVK0GC6poelgtJul3RJfrrBhesFhFDoEFCdK7u2GFXoLEX4ULQpJkMCGEE/ EHkMb/Cr3hMInWzjEyEUabqWYnYlOLjqMUGT3roEpIcLSb4TGmqSFUygFxHSfptD/IQcKglcOFGn pitJ4X/YVJPpL1hKk3utrYIlStJ+klpBoevVX0GRdukF9BVqOv0F/VVuFuqSC/Bel76GtKkhthrS T6Q4Wq+ktbwkgvWF2vQSx+kl7OxtBJbeEISVeF9wwX8UtYX5XS1WyzLyOiODBHiyesUuWdUR8Ncp F6XLOWgVkgL4SuhQ11xSuiDSOW4IjpKsgxBQ5Q0Q0DoVuzEhEcrqC3iP/wl/S64QX6S/oLXpfsGC 9Y7/WVt/yWQIPt9hf6V9fXv7///7KivvFJ6XqtvJFaT1+gl/s1a+WcaV/C/f+wveP9Lbr+rw/7YQ Vg//VQ3f20Fh67erv/YhUv96X/Qr16XvtBK7+F66Dr/wstJLX0w1j+THDS/rY1S8N++E3f02/9N9 9W/9P19+9bf1V6r093Xf/jRaNV/sfVP9pb45aC366Z2tr1k3F1pmTqFX7UhaT7/4pdcVTIysrjgv 6yyJa+6QZTrXoNdOwUSXX6TtYaqJBb9prsPRE9J70DBFDvroIj0kXgn3JkGx5nWVC0EkCp6si4Kl LqPCCQKn4h/fhIJAt7gpN/X0jCaRN3yyDaaS/XSEECQTfLcbxgq160kkm+2DKHIMo5BfPv+kEQil fiJ4MEcIKk3Ayp670kFTfEcINbXVcIJL6RN1AL6/6SCpv4T/6DpIIW9BoIw+ulULoJ9ihIQevu7S SWW62uiIOVP1aS+k2OkEOUi9etJK6YQShP2vfSe1BJN19a4S+q+tqsJJSE+oQQSBfXKytnkFaTb+ G5x5DlSjQZV+qRCNBJ/Sxwn660d0S5IyODpX3aBtV9fsijhvnwb02RBt8JevSRrinWqYQYLms8E0 nC9JLVdV4d1QJhVBB4Xhgk9/SX0UP/UFTC4J6pOEvmRlJBaC6R2YRHBdb8E1SdMjKpAjFthBfC1q vndYZv+U4aFSdOyrNZF1VNhBXTCWqped0DV3woQSoJOwq40ul6MiQXWl9L+loJaquqthBPwgkjok lXUL6VBJUFpqv0xC7ggkhC0EooIgXHL5fqlVOiCPDVrq0vCWqSQI49EM7x+1pEPaWFoiUeFdagn4 IEoKkiIOiTGRxUQXiKX1oJUguk9IkPvVV4IitTRKULSwS5ESP1VAlQVKk/v1QT6mQoEwkMUkF0Ek +rwkioSSTpVhLv0/mQ0EwiCPqgiY7qF+klSmuBCCqKvS4fp/RNqJEktaHtHRAvq6hUIVE6prS20k giLb+OCWZ8KkKSH7SWgsLGlsJqw/CTfyuSLBBa1og70gTTcL0CsJKlwk8g56pP1K4KCRC4VJIhOu iI6fS0Nr1s+DqxeEmHw4IOFQwsjnCVTUkFrFXgycOqSoJb6CbWEUPkWwcLONgohlyCQTcQqtLUgQ 8fpYhbdBJusVYMhTBNpKAsIoeMkPSYQXBK4bW1/STCcNaBN/gz4gVqIqmJ3DwRBB9AihwvhSLRbl Od0lCzspBcj+kw/YYYYYSQVRCFirhhCnqqhdkMVA8JMLEdIPVpsjoNgrChQqeQkLL+08iosGCTB0 rXoLXgxDDISYTBbCrYhX7CaYSxTbQSkUcEuk/TYigylYQwnqKEcXrFKUPGug1VphDTC4K4W1ZSkE hDBdoIfgwqrYKnWnVIfpLgwTQZY5VSax2E+CVuPwYLERYINbkd+gqtLlvgZxMhTI8cSTbI/HYJK6 7Bl2xEWrFqGCWnVVDY2yQ5x8QttLStuDCiW6a2/034RxzjiVtwVQaX3xiJW/SsgRuiqEmHjW/+3B k95aS/0OwkrpNtJAwl+5NxCLIlIcUv4iqXsun0uw87GLUmxotXjQQQ7g+ku2RwewS7FKguGuC4ao eGC9CTcQl6ZMgerdkgNhIRcMr+bA8syMKpb2okGe6j2Ubi4LrYyDORfyCg5DKqS6kHJnEveQmx30 2CpLluYTC+5biMe/lvdf909dKqdv/t8kj6vr19bv9bXakW10iyAq3/n1WWmDLH7umvyED+7+1wyG LRZQa/+vhilr//bKHT1btfSoWUPHfuaZr9bNpxqH9VTSTi1LTFkRxdV7a6FuNf3VL+Zn+3+wlpY3 /0l1gl66/3bS20FyGB122K9Kihj0mthhV/1xC/uW5ATphfUGY3J2ENcNjtfUt0X/W8L9/T/Tff9d P+9IlGupXEhLTVv+uCKdJNjXK5gHxdLXhArtK+4QXW98Jegm6qECtQrfdEWFvX9DUjehT94kMsch sNgXa1Bi6eoRQ8rqwPDVr4uVxUDwMJPwih0W+oFyPEgv8XIxNU+WlT61Q69+u/SWv7Gu//7Sqibh SLcTXp/wn1XOxxcmRp5NwNX8paBcJrle0NdSsAQKle5JR/kEDMCBAnXd3IqGqoXcrqZ3SykBWJuC aCO3QVBcOFfIwDgECzaJUi6UUfvp3WjMD8RERoUq4dccm5WkFr19EFIco9BkeyaMv/wr8g2BJNwP I8l0EU4fWV9dr7INylE3UKMEUZxHb1ZTIp+yDjlMhyoK/6WdrOo/JuWIREf8LXoSyVr+1+o/0mu6 /17TCLT9/2lnYxVFPvKdVWpkB/LMT6e+N1SYW6d//65Q7Bf/VUloYUK/f/+ybrIPf9el1rv/69Iw /CZdf6pWlDuSpEfyvgaP+vdfHlccMqtKtLpRrZklA1rv/WmW7VoEECHr66prJ12Cg+dwP+obhC/6 V4JX/WibQ/8Ihp05MQJ1d1VhXj8gQOeCMPkuFC/rx78MiafNQLhZAjdMg8iPS7sarVIiQZmiBiT/ uRC8l+7wsIgYaeiDRsz3LM1atplH4T+gqIcbD0+oVbTfwm/aByKKdI7USXCZblSXTHwXyIWiC94V ZQRHWg+4US6C6a6+ahkDLRDjgvZAwOSHBZ8MQRHSfdRVtfCfgoIPSF6ZDPCDBAkOgYMnxKCtgbut LrWFI3+CYIPglhkrRwYiOg8R66S6+ClIHIuE9V67F9BkJYT7wu0/CkIDAT9U1Stv01wvXd1rRDDw mE/CkORCj+qYP0/REHf2ly6RCD1cILCYT8FiCBD62/v0E/xXtJs32hBUFC6SILvj/h+iIgof8L+W oDSdsU91VqQ2E/RBOv1wfEEINrpP1FEIP6sHqk7XiFbT2oYfQf0v6W6V8K+wiDDvr/wyDA2vSpL+ lxTdQtK0QengiOuF+w7r1q+6XX1pMQV+NJEtW6hv+i61f4S6b4TUiuQcYvq4Ie1DfVa9f0urSq6G F8LkrJ7v4PWv5Gpf5ZgeR9Jsq079L19aishYsO/x7rroaCxpja6r6WtjJfD9KuG176a/98F8L3c+ kiXH/4br+qS07Va99d4S36S6Gv3oLKE+1cOva/cFX3WDyYX+klcJ7jsHS9d7Hf0lqJEtNe6SEb1s giRU77B7IMDhYXcz1p6pf6e9SGgcpP8eQYgyXDCewXeGEqUeumkrXsQ0la2LwynLmpCD3GGlXr+k 99p/23EaiuN0sF/StNYeqD/VV1XZwO5BV4StENNbVY7u7W0H4qx5XNOChDjgyKOE92whaDW0O0ug QZ1RdiiBEFOVxGOdcCYiL4aGQ0CumvIqLwnGyHTxeqBlWmQwOnYTtOVYZ9ptyKDRA17iJlNCIYQ1 lOi4N/DthWEHsFiLBZQGb7scJuLwtEDGxo8hWrvUr4hBhZwMuvb6YjELt/hZDN2V6/hQiGVtZKkY fcsgNGbcJHYHhEFDcnvlkrDOoSUIhoHBahNk3qBrNM0BocEFCLJUgiBDcUTJTUpNyAPDPwhFEMNy ilacIgeGB1wjJJzDlXvBPhAq2EIj1F1VXhPfdELZUEDdDaDMuYKZiz7DWEJV5HRtkcOSOhEyFUPT h9CIiPeVC7IY5TD8m9qsKZWuGNfyKrx+7/hb/hpLxPodsbg1/Y9IGn8SOizma7lvqJ9/7EehIoh/ 6T68euSUEybgt709fWStrwvun0P9IIhx9/6kWuTdZXzsVzIGPphH/Um6f/r+niIWooP7Xe/kUu0/ 4fT2PHnZaof7+hfIcEE21lrj+2Hdhdrqt9pbWPDIEG6jhBbeWsSLyBg3rtrrY9B9pX129sIL+4fi lvqGtpr7QadhXrTkQ3MXarLMFUTf1cG/F8Rq+nf7tayb1rt6DYX3b5GO2nGrek2Pq9IPzIlW+kw6 pO2+/G70m06Rb8GjSvJulLlczYW0E3p7Q134PXpPr2TdUrfBFnMdcoC9eTcWVFesi3Brvvr692nX fhP+2vf+/TVv+rfTVfmRUv+/jrtivt/YJVNFv+u8fHMgLvbnYmpQ+39GH6bZks+tYvv0vN6eu0W4 /F9rqv9v/td+u9r/aVU7XQWtblT79acof//q4VV2uNP6W47/4Xp/pam13f430gRT9dxTfX+3+sLX dJ+yuaIqq/+djhNc2pMeHta8f1FFZRHDQL4+PqVhHZSs6oew1yFg0elWQ14jiW4RUUOoM3rkURHB t/8T6Lr8bYYispAJP1xEoX9Q1IeDj1uvH8twP4NRG3W/rjwZCG4ggeMcq0XVf/rDmtFcyUgtOfRQ 7OBgjryp+dmF1luWriMgqQcDjEeleE/y3KENOS47kKOdVk3MBp/pw18Ssr4iIk3CBrnUaqvD/9ZZ BsFRWP8+v1u5ZCYMoJkbS+2OuPaCqEztQDlOumEfXX8EQ2vppndYZ1XaHztQ8qa2MhqhwqnYYKF8 g8hSGsqhEmEohS/IZbglRCXULdZ0SIg5hQjU6kKChdghK4WryGiicJNqCKHS5qREg4gjDiwn0UME wqiOpEEespwXQ801UpAIYtMpEc6IusEGFXo49lGKDS1C61ZBg3TTwREpHCYVc+WLHaS8IhnxJfhb ITUISGI4VKsED0ugiOvkEQvVIKsXaqmqCUIM76/FDtIhBwv+0QIeuFrCpSE2oFhO/W4QQ1/ohjKy EfHGlCyYMJ162klS0qCIc6uE6dkdJIK01K4w/11CC96wvp0Q8KQzvFatNSrS364JL9dBUiT0tEWm E9uoUE0xv6SJpylUIJV+ktMw6ptXha3IYh2vC8LxSCrpcKsTxL0DoLW0gddTpfr6C+vQXFLta/hB 1RCjpwn9esL2q0tmF6JvWFq3Taxap/rWgWtL1vrXWvJDunVcL/SpIEQXH+vgsarVBYWmfGw69dP9 fmw2Wra1BmwYhk6r9EIP1CmAjdOF9f/xVeElimNbrCVEGqwQhX3S63/4XUU9wdL2Esa0QynCYa9S N0q1LOULy6uHX19/4Sh+RwzKevSD6IQfDj91IXZqF7QaZDY9hdcV8SVkHoE31JAafQVwucw18Nhf QtU1T8LaSZEDTdKuULS/gpHS6WQfBZxdVbT1a70GasJ/pRVL4IQW77iGCsVaDCsMJhNRCxoWE9L1 FfLXGIjojpBDj53iYTwgyKcIjok0R0I1UINNulXXwvFXhoR2hjEYTsIXpfq+GImHVK5BpqE01sIp SI6VpLs6fmQqvKicdYiItQmhQjFc1uKQT/Udui+LQkNa2C1//V3YW4ShnMEqrGo7TQna0iuLIaBK IqFX8RMIRDnaeCVNJfLWM1iGlBBNVTmQsqjg1HQYVd/IxBgqYTC7/iKCaFpoy0u9UGF2I1GgwTC+ W/JhCPwQNkLLsOEQwOUmnMOeR8IoeEJGmyOO+4Tfsi4v0Qyb+JZoLtexGr/93bq3fLSmqtidraJu Lr5aQmjv0FHsMRHuQEVKrlMJedledUdEN23OxiER6ZbE4rKEewybpMmyoi3MIR4dSNIi+JF8miH3 EgiuW9SNozRA1Q3K62BeQZoZkGhERGuTe1FjyuZhoKhDWi3gFx5XNVDLciWLjJmCeSbTWsSjI4Fx natbiTonceh/forrS/f5N9FCKHp+sf9br5NlRVWQeCjcTkLF7rsQeRTCDxGoMHpmwY9FvYPVhLLT DXBvjwlsGHaIaB+N3SkODluJorlnVtuET1iZJX3D1S1jCX0E776pLrtfBerlu4Z+OukCC/raVePa siOrpA179y38SyOk5Bgf1DoQ1hf7bSkhz0/0wuPk3VVbbun8e3DSS8sif7bNAate2WrRV1YoaxE8 v7W4/31/tVlkEu+4a3JuLLLcW/q3VdZV1QlpjYiq3LfATv7qVzMM+nqtwgu9atSGDcCrrU7q8Mij gtEbg1JuqLSimI9W1nRFQkYf3dIN2NjXV1V7JvNdfXSb8lO2VylJa3fbxcQqXlurvav3Y9FcQgg6 pJBrJuBLU7rXpBbsV/dj4rU7DRkltFjoMLt6XW4mSyJ0P3/I387rQTY+2/0h4hOvf9Lpzb7+61bV PyG3b+vb7pivr5HFe0+uuu/r9Ha19Um18KUhumfCBMINLnZdV/phBk8QZHZY+IoJrfp9dM1YTsIg iQj2PzvmRwaCOiOiPEaUH7Gve1tA4aDQMFJCWIQjiiDEkLu/k3OrRDj2k20wmUgUKLws7C0g18N3 Ut1hbwm4hpqdewg15DK0pyMdmof4YUm+hoMjQNFiMQvu7VQlyGgRijwgRBNls+MuqsPQi6pZCYkZ 3JXiwoQVvZq6EJnaQ0Ivxu9aQ7dA72gWdl7CDoJnYPQh8P01wttQwpCdpBfhaTK1EuMjg2lYHbLe ARxrrvGm7QXerkvohPqC5VAe0W8x9JJbdUFkIOUPr9aiCzqFUKwgg6iGQUxyC5uCrU66vuXDyXpI gYv4XhBSgCNIGQzXBBB1LOVxHzghHRHRHy6N7ObpVJKKI6fQ+EgiYAj9Vo8HCDLyQSBkNCXtCIiI iIk3U+sJNt/pUE/1djQtJAiMFT2OkFd1qyPoEkEyXP1CIkIgxNJdBNEDGR0iCdv691uI6gh7paD0 lSQTkYBdEIHhLVFv3tBWkFX0lQaUJEQ/pQqCDw2tBBV9QnrC+gtPQSCNYqUF4SGpb6rVAvu4V1rx WnyQ5DhoOq+ldlNOKQ19SKOUKV165L+kNfVPXHq624Q39VWkvULr6XlvX6pW/TekiI/q0gXrT4fV dtUvWyXS/JWFX+EK1SVfkrIxyga8PWq3NWm5UJth0GRBiXqv6WmH0Ir27r1tPyIheHikix/XWl/D SVLw9fWGEvJCI4vD6XX2C/XYfhK+WbPO0KKOJbVkLFcEIRI3Ydqgr60F0miQ+r8mAet40vaxT2bB 62+KX+T3NYJrqH4MlwY5b3rgjjx1CvUQSYKw26S9e8JhL2+DNERwL8tzUDGNOxTrUbdwl6/UERuG EvfYiQwP4SGq2E0wt7SX/8JMV4fhVcIKiHu06UE4bbCKHQX/dwgvSfZBo/tEFDTHi9NK1T2hH19W CCa99kFA4XVkRp6RaDCcjphbsGaIjou1Oir7asJNeu414dNAwktggwlYiIx+sYoNeQ9cGQdP4bpo RFhA0awxINL9q7aYL1WhWt7CImhEKyBccEyDvEYcOEQYnSgl9oPYqd8DcONew2h/I4YS+3WduBhk F9VVSDGy4LeIXVtvGiTZH2ErthhYtNdWDzsTUhncIRDC4QaHhDXK4Ii8ckH2d8MSXQa6fYT3K4mC vuRfESrXi1sE171cRzIDPEeGSHuJAkOPSEzzaI+XDQWarWNdsRE0BLoqqOwf9RE7DWNZ2Kpb+OPc bILkHmpEy+q7YiP//9DS37qudumv918tw3uK8rrTBB4rwVOiyqir9vr1vureERR/a0uvbCX9vitt rhqtdNi1v7LNJFXYRHnxDC6643ityAkBrbRH0stsuhrT+TdOGC+R0YVmSwtXhLBCIkK1BKUtDuNe QUhztA5TVm1FJISFNyQqTzuvqGuQPBHIQ2WimuCZXSwuidChz2W4stxsxJ1y3NX5HRdCINn0RwJx E75baqxN5dCYaKmihDwzIndShCIidUR8uGYR8buEhxE0RQQlqV8yM0otYoIsoUi3T4xdLCKHYjWs aLTCl63G4/UshUteV9UO3x6Jslf/1ZUl+qIKkHfb4vqnaeJZ1T06//otMEJ7+6Y/kY+062SFSkhr fq4WZg/a8NYW6fZ1xTBQ3e9BobmV/JsLqr0ybGqc7E8LVJ+tMsuIOFW/dqlSYdV4rpKNj16DfaWv t1RDLHd4S72kiD2qLINaVV1faCKHVFkjX11eqCFrzX+tVq0mFSYXXOzNaVN3ShMIvuo6Qr34pIRU Eq9Kt4YJsm4EgS/WH3HUF1MjMvr1qEElSDI/SX2uggvQjrXVCEFkUXa0/0EuW9EshlarRbhS1wgs VqQanK7fI6Kyn8IiFGtiSH8RFUHdUuGUOPb+ljieDV6+TYa0F4ZDjngne+iQ/GvkYhFR10r0Flco 18iB/V8txVHYKtSQggfWE/dXiCBcPzKjkLsc4VIXrhaVK7iMPEJhM1CKRszGEQLjlKOkn+tZBBaR I1qD0IiwnWFIGO3/bILjCDQMphAkGpIdAl4UIH9JolCaZDPoQ1SJBcqJZFCA6CcEFXUL/Edg5Da6 EwmqTDVYIKUiIhHQ6pEOPXRb1FtYZBR9BErECoiulYeE2CCapgtqgTrst0B/UGDwgiUghH1S6lu9 QZDYTIPFUgg6wgsL0GdhqtybqgbGQ1BwSCBDWEKSng+mS4dL9PoJYLyutmpBUiTdLfZNyUCAyDdy tUfQRBceq1g2qlIQQJNVCfpfaUJiVYWmqJulAuSDFIKCCvpJJvXQKv1UJL75FeE8cH0rCBJLVYbV ER+gvUIjx+l9cJN65ZIF0lQLBFDkb/SfSekFqkk/EKoX6e4PDapYQSoa2lvpWqX1Xwuuq7fYeklQ Whr7xXpUkqCv+RWTOq7ylIjgYfS5E106SvX0nqr8IEUPQXX27IGMjouCr66W99dAjj6S10u2h/6V bILjiP4XBK/gukPdVpJN9V3tdYomy0tKlS6sqqBFDwVfpJUlW22EvX9Vg0tegl4jRGAutPpfST2w v7FatNhc0VAq1JDgm8hhguYWlXCqhXYYKj3+knoehUjgRhcbRDjhWlW9BKqeGKlyQdWskqeTHIKo 5G5GOW4RHRoihJKTqOwS3iFha1oKklbTEE3aaoQ5kC7TKc45Q5Q5Ic/EbmsIMocKUOCDojHKZDX3 oMF7hQwSr4ZmC/W2vWlDlbQiLjbiDKGkJN1hILbWPeExVfH05BphbB5Ts7Mk0XVA0RNCIiIk3Alh KxkNg7e24KutVSUQaqHjMIQy9UI4qkwW/bCqr26psYTD4jQhBUwtkNDpsqE7ILiAmt5AuPVLq70W n6CWyMifbC7BKwwmhzfsF1WwnrSQSxsEg1wyQK53yYVAgQqwvq2CauJN0tqCCqKDIs7EI3uIYUW7 BMNWE2Ia4T0ErCHggRQ4eGEqsK98yFHwpNzRYJdbshBzZGnGqFxK2umOThjYXCiNrafGpb+1koCp hYYQelqvt0TdZ4gsaadqg4tXtKoLwyKMTTi87JEtnYNUMIcQ4sIPGsYRbkswWVgHEe3CQQYLBhWy utDtqhxJuXVUHYidiF/C4/dfH791+Fkh/2o7Jutvp+d+HI+E/T0CEGR1ZbkL/oSZsoj7cJSDUbCP VjZDTNql+mDVbhoMi8HWdja0GE2SAz1j2E2dQXBr7J7VsjA492nBh0WRVVRbB/q22v8N/dtstJYW PMo8N/aJIhbbGtiV/e2Ta9aq26f5Ecg+9LYUslfRZANXQkNm58KOvkGyCjK2nX4k1m9ND4ZCwfCj SRAnFr92Q2cyNgX0FCaJZOjI4Lgk3WtsTgIiCgppfDZJiyJ5wTCt71JpTYWuwgh0CqrhKhLJX2/R MdPX3oREyTqviOrstkoXfH/7rbdfXsNS1kjLIsIyAleIRNzNFn5Jk2CsiaEyVh6TnZGR2JZQ0NvY T7R3AZybCAI0x14aJQynDKJsQDX2TYtQoIjrhhIUCINg5TOnndaFL4M44J0IM1IjsshYnC0EENsR YRNr4i7a8codBkM0cpyjYgMJmEIMJNAqGDJORufEIxBisLjKNhMgQOTmVZVhbBXEEUOQg5TlDQRH ShriwgoiRQMseuW9SrJpY1O1r8dItwJd7vsl/KvJtCI64sHVqkZBeFCoXOwVN5NF5brSxW/jSaD9 aTXMi1EdJ30/Eyoa66Gl74RH8IH9aaVX6HBPS1V6ZXWjur4frWwuuvhB9dqNHHpkML1V6f+lzYZ+ Ha9eliqBBJVohKAiOvouv8Qv4QjXbNX4eFb6S6EjDruC8rCbr4Mj69KH5Fu9LO1CI6whDzsmqvJ2 /hp9EUPOxDSwg9U/mgJrabpBEKuJTvUS9DH+HvfUm4WsFo7IBcrYzi/rhuHt33QTwRDA4QRBHKEv zsUveQc2nIa/8KoUVHRBqHVR7bYPsp5tv0lMosIKtkMocFr6dkM5sPtbXTwiHuUiPkQiztApfwgo WyELyFuveyDduZ8JU25gX0EoTBQQanfhlEu0EiKWQ1nWW7t4bW1s2mceoVigkCrYXCoNAn6UEwWv 2D7pYQYdj0CSVMJ6hBoFakhdBU0vZHXvhJVwukEgqqVYMKCScK8fCa/Y+a1fx4SK+vSMPCUWqDpb QJNzqtQmvWG05m+3VIJV1QSVQVMg9NSTaSf6hUkjt7hg8R8EFxBfSFSMdhVoEDRDB4XVEh2orSrh byGH4bUJY1oJCR5REuFwTRC1K4pK+tNTtWRdm0pLpMhohGR1divS0FoQq0tVtLWEk3+FzsYGqEqC hCRt+V90oSXCStBa0mglX39VU7DDaQZrSSYJkDXDCOyEsQkoVMJKklXTSDStJN60iCRXVNcIME6h zsdC9afCq0uQg5U0knCWqpv4p6OzgrfWq8t/GgzeCKfwRHXsFTFaQwWqS+r+gtV/1W4xBl0O9CyC D3kxeloI+tURccJWq/69JVpdfEO6eE+lCpaH6DrolZxPTfULSkGHNgXrUiTa0iutSfy9ATXrWgtJ W1XH31r0QdR0u8kMII7mut6wTC6opHWtecSV0tUr/WqIUwltKrgkEa0CIsifyY7poafyEHwq1XSe lvr9hdILr+wuEGRaBB9dvCivYWFSpBaGnSCw6Vb6rpQut2KCQbYT3e/feag6r66t5rAiQXg+FDOF rpaha9cguroNVr7+pN9ZShQwWqToKkl4WItcFva9JQdfdBXhaXhrttJxZCuutQS98EQw/8JZTqyO jiYWgqS9dhrD04fwwWuPEKj6SSwvXZHzAZ+FWC4QXEGIpSPeqX6290l/3ok73qhqsEkkuIra48Jv +vrsNK46fsP3Lr2C34YX+t+sF+6+1qHrILv9q37/sJKqj0uCpglp0uoaha9Q+iQ4aCD+tvqP2qFr SS32CdhYIEwuQff1W0rJCbSoNoFf23tbrYTjIaInF/CwyKNL1YVl1IEbhhd6oQw/bhV9bre8iQm1 hPraxdhYUYbINaqwn2ln02krdf97r8WE1FL0GFidVCwl8MIhx12qgk/uEv3/v4sFXQsgieLCiER0 1yGELS0ohB/dK7R2V9P+R1ftVtFa9hUMJpiq2+g6X1VtzKEprHddD9i9CLgwWGmqf0kg9q2ldIQh ZwCGGF9/rEYQvTXHCINN221CqmhyHHW/tNVCKomEwh6ojDXhqvaaY+ncXeFYMguOVs1VNUkEuOu4 MINW4aWEK0IsL1CHWktFDsMEGCoRyy0xQQtBqqVhVX6K5KEI6DBeWRIsJAwQhhaQa3q3BCOvRNga UGcc45e6aSF66vuI6iIu8EwnS62fRtZZBNCrTVY9/UECXJunzWhSaFhBhda0IrI4WhUMEGYyX15T hRiZF9RE7HaX9CGS6OIvk6N4TFEIPHvVWQ0IibQxcL61shgSoLv5M/gzyI6NowCql+6TwxERpdfu EDIH8AksyUk9xsWCI6ErmqJteTY1XiwRHXZCGy0EKeKWI+yNIGQ14Kc7nX08L4ZDCgGTYCDKI6ER oa+W9GyGdytbKHO5G5pzi9vQQYYixERHH7YTIUGqTYEQ/0w5XtD10way1DVFJ/0RR2VgG4lmgShw /9Nk0RHQuHe6ldVvES0xPF7+qtiL/XstQr3/0+Qvvve4jfv9v1q2w//lkLE3+9zu0LbkbX6WHevf ohZSK2RoHpXteQzu5xx1XSuNiurdJBsGUPG+qRFMGh6sUEgQMGF30TFGymytqrCFMR7p7hZamnoM xJHj9rhrhq9UU9bwimBNdK/Ra4sh+Phf6kS/RAgvFB8IH4dHfJ+GW0lrHgw1vYce21XDXse32+92 6sP2WmTXbHTB8LybJwX4UtoaVUluCIVtFTrC+33YZNlMMwstqqlcTMNk20yHnAVR7hBt2eQQs9k2 rS1QbbYQkFMcWLW5BfYo4jG0GQz7G3k2Tormq4MNuQ0nOgqfHQMho2kDkC5UxqGQUb1DkEWfDIZV RZK2Rdj+DINHN4L7KHGHSybELs0ImQV7Gm2fBoHKWYIqPcoAvp/DPoE2Sxp/DOnBcP6UMdb4OHe+ +JHWnb1QfssevYPxrpvc9sL8HMhtfq+scp9wt3eSNyjcUvClcq2RDcUeEr7lcbBDcDBkeI4ytGbR Hjz747hCQg5uEWVQGn/6EjH/aXWMPdpN1K4oBwDLHXeGUPhyuCIjg2iSB9pFzHqJpkcMsXB0Le4n gYIXFIX4W4hMIPu04IodKE9tURX+7XtQuWh0Tc1WN5PA9uFC8fpN4YpLG/Xog3HKpqure0MFd/7Z BHClDr+k/Ig4QiPW+8NC9yuFKt+1LISo7CLgnf9uI0UPXS9eNf73ZaxdV329PLcIhqutaeP29eTd /QIunrTVvh1Eqdf+71SMZmyOZSC/ut+9wQhgr9aTfX0MOktU3ltKq0opX6YSuyzVXZUljbQVrX34 28ME3+kjD3HTZ1DNvo7Vrp7/kmHYYSSt0hDd1bDynFYqEn7TbYtVX+7bcbSf7bYYWk19tx6HLKsr tt/9WG29Y9tvp7t2tLww3en7beKlk1XYbe2PDB3rUMG9maNaIEjaBFPI6u22TYrWR8JEdAgTKHKm ZysPAQsEhHwweKERZdF0R/EREMEIsOrILjlewQiIiL4MScFQruDEV927lvMC7KH0w0IZNzuXGpb6 h2hE6IwCuXocXEjUR2R0JXIWhER6Y1LWKloswHE3IQ5Q7CY4wuUPLMDDx166StpVQRaQH+Ce9DTS 8FarY/8gNEKpW1/LOIZaiohtCFWpS0o3FardKnRZRP/2ksrpFThP/x7jwfiWgW7aVIb1tlmVukF6 k3Wcs2ipqK5Q6C9ulpIIbpf2GC0N/UgIGlx9sswujmXjY6RZmuRwaybjauWcsyTRgG0S3hVCIjlD lDlDjMhCHoRESDI5Q5x0NUQJ00cGCI+DIbc5dF0SFiy0FiKzBlDmsw5Y5Y5Mowo4iIiK9b/XSuHv oKksPIUXvCd0vCKH3WYeELMEWh++ELQgxyh+nwh1LvLHWd/CaWQg50yC0Fx4gh76wsapLOxVO+3F 9KUO+pL6Q3XFIHrogiHfJRq9He4L+NM6sIJaLV9d0wsI/V/tJkV0hjf4UELX7oaJsrX8LrXDpBxv codhBMqGTYzVGH7GLjY+stU1RN9f7X13rLJCx9vajqrybBa97eL1u8b9+6knfStJO7KH6CCDev0f F7EofqnWP27rpP/oN/1fu9NdbSab9b9roU/Yv39/S/O/eKd8Kv3692t//MhWyn1LVU0eVUumGWaq IftWIUR45SwILSU13I7I+YzyJMGosonjnHcRERjY0qTXqpZyuI4HBHzQridEXRgZHIjjL5HQvcmy ViIiIiNXLcWXEb/+v/rf8tQC7jRh+K1u9d3tUim1a2PLbKFxrugsP3v6/KHWMtMn7G1y0zHy0yIa dcb+lf/BEfoVv/7vqih5bYUsY7LMEgpHi20/os6WinRsGksgWvlnCwPZZCpD7CDH0mWcxvuQPDd+ N0QN08YWRIKchmAUt/VZiZyqNyzlCof3+Eo9uu3rXa+t+6/f/kEHVVTNa79kgrJul1XljzMSkrSu 6BZNwaHeOEFY/VBVXSQS/pL+Eq/9NdzroJU76DSvqtpfrYZr0gvfDYQoE+92kEOtB0iOIYDYTYWX 2whTjvbRMcJ67aCQQZIcq0UtfbSZac56lqmS+xiLiP2EsPtde/6f9fap9Xlu/6TffVv/TfpUm7/t vvSb/8Pow60m10vTDctQdWN1DePWm8sxLVdQ35NP9BvEb6t3Wqf3q01dcbr6Xvb+va4XXaX4t/O+ 0HVSZZHBR6KoiOGp8lYMnziMZoyOB6vSEMuB4XvGTcQjtC2NluUYjqQPEHvbDIFfFeVaHk2M0DIa bnFlSEtyUiOiOi5kdi1sRERHKHWL/16/loF1BxrXW+WyqdW7vctkZjUeU648tcp6KH9DGGqOO7FW ymEtVLbFV1XuI8tgDWh3q3UtUD6hLpFmrC4jf1MiauP9K+6fv9b1/e9a0UPuWcziPmdyzrQK2yzq oE/LOFAWZh4RAgdFmja9AiCKyqEblWiuk+haIggqkRBJxuECEXHUFduC6Y+rtlnA3f3rfcs89/Q7 7b/p/q+38rQPvC5h+S0l+6D7Gqcn3uo9FD09v9I2cm6dXxSUaudNe6wzUkl7dhUFlphSv2qS3VJ6 X6tsNQko29ukEcL0raxom/OPdvSrLUJOG1bVBVv3bqEkowVY4L4fDsnXb/Q1V3D0v8XJtV17+H7x +nwva+5Y976t3T0n4a1b4Xq8shj3ST/e1vG17fC1T99LevT/0n/qN//6Xb663/0stBCtbWPoX+v+ t///X71lukzstXvob+P3hVJSihL0QowrioPcECQh9kGAKYBr5kppkMyxdPY7Qzdyn0SA2iPmtF1H LcCZHRHhIhkdkdk6ERgjvLcIGgRESbFasaY3uq+yAwT6u+UOi3glHFhB/CbNZ/V0xGtb7T/5Z1j9 pAtqRL9Xgi+6jTx/sLr/8V6r9VKYE+ih/jHp+q1SrnZlnZJheop121S+VweFXLVBFXWD7vayC4z+ 0ob/sJX1e+6GFbCTv7SBxynUNIqwl9BCW0FLc47QSmSFrY6Hu0N9hfa/W0qvrxTqn8tQH3CIjsap P1uHSbhUmymUtZQ+my6MlcRwg41uzsbZCwb1QTGmSwNPr2EQZAGKj0HtEDgBgLYQVtkbAgj5Hzga mt2wiC4Mg1gMFem7smM2Bgt3AitO6DEnDYR0V1gFQsoNeg4bhkqDYVwQCdf9zDhgwyuUAWFkAkOo QabE8i4IQQGCuNhlnsuiOiOIRwXE7UK3i2J4IVIEK6sMwREQzuxqwjsXziL5cMbDKoFK6cMshoQ/ E7DA+hkkFK4YKBNqibgq2W6fLojgeEBhtyDC0EOyuNspwPDbDtyTmNAVIrmAcjmRwPBSDYbghvSE W7f+220u6IHgXHKHI3MOUi231nHogeCKYbt/jK4MiODKR2RzlxcN6+JDb2rd/lrDa6JjD7VG7d/U Rbv8dO7eRY+923pmpdFDsN7+Ti+K27btfu75KaCq3fDMgoZHD8F6duzJApDyOGl/28KdlQHg1q5s 1rup2MA8CdbCd/sGzuYHgz1FfulJoB4UwCgk2lC++VUFyCAsF0dM2hVKuvaINA5A+srCtiTSr+6E gSDlOfZJSru3cgeGJGs0kly1H7+yEHIK8hGyGIfDFcL2GFIlkOgqQHbBI2GfH7pA0It2EJBx3/0r 7CI7IEDw9/8JdoKQfHdZx+6VOxoFFXj7SGw1BP3/6HSpPpdNd167DC/urpi/paVffpPJu/r+k2v9 LW/pa3Td/esK3XpUug/f/Sb7/6TD4VKktf5XSES6LhDgLkoiPmaJ369N+jIKyERcDwzkdGtF8wDa q1FfsyKQPBYI8R0XA89d7uQVGeQMOXythkgiVUGqyDA0JBxyY4kQ5hyDp1SpfkGscRESGyK1jdCJ A8Dccqi0qy0jGWWqhkMkMWUEPBgQg0DmcocpBblTpJQdD5DIBXGE9ipQ5SVSWschxyxysIahBAhz 6lDghEQaoIL6JCZHsSO5DYvdJKF7EQyHXOkglV8fC1XLpJIECq6j6ULuqQIIaoodVglePUIIrgm+ 0qCCT9KEgQLvdUCCvyh+oQSB+KSSCCZDgpTg4b0ggmUOQXExcJJJAgQsgYr70ggTFFcs7qp5Akyh wQ1UiqCCI6QgiPieBlI5+ooQgQlunDUGqSRgMFuJxcM96QghHpBBV0F6UtsEXVENADdaQUguA0Yd mSVAoKLjJDnAaTcRr715AZauNS2BiqPtcswN7CD4J9bSdP/pfW6uwqtetNbZTWLDMgLiP9/WpAWH UOOrZbCmoRQ6EsuqxZZgd3QY9Pp9PrlD+hr4V+sjTQScdtWN+Pr//DwpZlauP3oyKz7fEtuauN6V MsxFwg4PZZBtQVPh16p9cdTj/HRQ9BRuvBWkFWqwrhqpZJobY/W/C/W/fW/71/9b//3rf/+ih3Gv CwctIJQVss1aV2hqN/63/2QFBpaZS7plpDePS4/RZhQiOuI/+yh+P196/lkIv3aqN6lsLfofb5Zo uuWbZlx3sIX8J37yOqrF2ruv7kK5V+lI0K7KfC6xcKF8Scfpahss2weqpGO9Q7aqhd8sxUm+2sg4 9aRZAXBYJOjtZVMSuN4JSRDbG9pMEqRbaX+wkIeh7aCIkgRT29WkQIEvdhAiY4SRZqWtWEUOkKDj dtCmvhuEgvsMEmFVW6RIcIbhiCaGtDtrk3JzXd+K6vt8swGwfe31b/fSb4RQ9sv2ib/oUx7Ju4wr 8mxmHQT8my2C4V+TZVBQl7CpB9AmvybFYaUJrk2Fw16G4LC5NgIMsjghhkntVJsoDNQTQJpVBJIQ ih3C5NqwzUEEMdBAgggXYIhlkJeEQL1hLybcDcjpIJcEQzjghQSIccoBhlluaBoFJBCTYERe0gkk ETYEBOCCSQRlPJGXRgIamR8vnZkCEczqGXwgSSR2tBsNoECiJBdxEhLLmU5SmUOVBQ5oOgmOIZHR dGAai1wJcIFSR26MZSIui7I7I7CERoQYQkvKDI7BJghDkY4kFA4iLGoQSoIqiLhlEMMgOXQQiIiI q4QVUUkYZcMgNBHDJItoqXQKkinyOGQGvIHhB49AkqIYHgrkcFYjhkkRzI6Low+EtBlwPAokY5Rz YRHKDKHIo5OCMchByrI7OOQ0nILjkDwccIREeECpCQPxypkxyDccnZW3QiIs+hBuOXxUHGGHIaMO OW53KcococjHOOSTIpoJKQ26ihYkOVImUqnw6aGYQVyGmAxSVBUibkM4DEq0vDIQBr4QKqHqq2oX 1QVJeF/S0vr9L/Wl//WvXrr/+rluaouiOBBHRdEcJ/MojQzYaZVgeGeup2tZHA8z2R0RwPDL6ud6 mRzJMMgFO+pLxHDB/KgMwvEcMgCz9moNQwz6CESGQGkO68hhxESGQDcchtj2Qg/XGGQynM5eIMqw gynS+QyAyxyrM5PUqCxyGcaKHKHMOCI6QIRERafshkFQpZO54BCIiIhL6IZY5BQ53KcgYDOOROKc uRbvwSKcpyjBBBwQiI9PZCOSHQiJFsV/CER9de3Hv2vDb8N1lsCq32ymcLDd0O+/vbC52tI4iOra 2dlaLo8QIQZHRHr+d6ozRHR8EI6iIg7a532R0R9TCCZfBCIdt3JKiPF4uFwhBEcCi/ZrR5EdGpGw PBqt+eiOGQO3uhIHgy6PD7kDw2oKLlRKaOt/IHhswoTKohu9sgswZzbHVveQVNk8NvDZcnWHht7t vbd220+rex9tMNXDu9btvt3fu2+w9h8MO2+GG4N9u78HYYeW1r2HbD+w7DDI/jDDbi+w0SHYdIty Sgw3bt4Vh24fGGD7DfYN2wdZZQMGLYb8MhnIbDfgyBexhrhix7vLKVhtrZQ65kUoWQaY/d3ItxJu GCgfmWIm6qBGsQYJWo4/ev9/W/q5TZUv1H2///f7w/othT9D7dL/ZaldJuC+NPt3uiul91H1f/b9 9+9ROyTvde6f+WUvf9+54MF1ybgUdp7UjgXctUf4TsnDTTHZExQmpwGyrkDBFrvZDwTT0vphNVgk iup/dNdlDkGiSmx9pmvC6EgoktbeiDEbCmfyHHJrjrtwQbuQru8MufLZCL6BcUt2K4+KbYVLVLth dfv+v/X9dL95agoV6utV8L6dKq652aNXXX90PrpYX//Sv19Xrav+l4Wv+6g03C/648+Cf+6j3/16 W/pwn9r2v+9B37v7Cf4vIg6gny3K/vEIMmKLLcU+4yI3t4/oY/f/+39S0gRe79Dorx1bRCjlOUpP xEht/0iDPG8d1KaFLbjcLaDxl3widEdEcNhgGmECERE6RHRsJZWxwUmxKhGP//yAspry01JDH//I C5ooy1Sa8SbU//H8tMGtx///LNLrxlnFV4yFfjIDAVePLYKeJEKP/lpjPUf//////////////+AC ACANZW5kc3RyZWFtIA1lbmRvYmoNNSAwIG9iag0yNTAyNg1lbmRvYmoNNCAwIG9iag08PCAvTGVu Z3RoIDYgMCBSID4+DXN0cmVhbQ1xIDYxMi4wMCAwIDAgNzkyLjAwIDAuMDAgMC4wMCBjbSAgMSBn IC9PYmozIERvIFENZW5kc3RyZWFtDQ1lbmRvYmoNNiAwIG9iag00OA1lbmRvYmoNNyAwIG9iag08 PA0vVHlwZSAvUGFnZQ0vTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQ0vQ3JvcEJveCBbMCAwIDYxMiA3 OTJdDS9QYXJlbnQgMiAwIFINIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8DS9Qcm9jU2V0IFsvUERG IC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQ0vWE9iamVjdCA8PA0vT2JqOCA4IDAgUiAgID4+DSA+ Pg0vQ29udGVudHMgWyA5IDAgUiAgXQ0+Pg1lbmRvYmoNOCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajggL1dpZHRoIDI1NTAgL0hlaWdodCAzMzAwIC9D b2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCAx IC9MZW5ndGggMTAgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAv SyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/yAoW8f8sAirH8sqOJaaRWU1iB8shR08O uy1Ei431avu8P4lmKXGTYmFk2LgxJtWDeC1JtaLMNEWdKUm0waU0xohoHko07hEMTCUyPwzuncEC CCCa6k2/egkSTnUHH9abDhAkCI6wkOwuhhELoEIp45XE/oJBQS3eVyVwQQiqqq0CrvboLpJI7HRk C76WlxHpV19Ba+0WSeW5U9ekdg14QKGCdJbXrQoLqqobTwpSqvog9lbLhcIJAg6Xlcui4Zl6RXGj V9LoX9BEM4WCI6CLHe6wT9QQNBDF4V5XDIjhpZDRdEc1oJoi7H1rjTPARqCoI7mPBr534ajC1CTe QRcvwiBccjidjikcNKtIIJ8g3XInefMOagQZSJS5E4HDMilEcHwiCQVeryGUvP8IWhFCJh1ZkBsj hs0EJOi7V7B/isSGwcIyW5I7CtDKvMIjSMCpIEIwrsGdjYVdSqvkM0cEJ0ylIwt7CmtGFaDBC9BB J4YYQb5UZ2ke+TSI6PojpGggR5QFJhEIi6wv5FwbkdEcghHZLhs0kmUO5brQZgKQ8lRqtptLhCyP hYwZVENj3+togx2CjCWECSeTaA2BB2RQK/pq2a1klEI6DCCwQ9FJCIgytlV1kTQQgRTlDkQcoIQX XykksmxwwShEnqoT/O/17TwgQJiI9t2RjhqqBChEmkC6Sbk20BCkDChEGHWvuoW3TpCFvdJv6CQQ RBJYVvkgquDDBA9EHo8KvenkIL+EC7h3dumggiKBhAiLsd1Tw6eiFD6IUe+p0iTtEb8EHSkJWlC2 GoXXphIESyTaVeGwtwg6hBA/4XVLwTtQTKQegVqw3910kC7tBQng3IJD0EOEF/phOkvC6ppkYirt JPT8EGsmP1QWmQnqpNO7oikdKkCq/VbQT9qmEwna0ixwT7aDVeukFSraUKvsNBP1pKu6YXS9aVJN yPJ2mlTbSokOG2k3ZHXCztCRHdh9JEU17oIP10vpKtUuERHKH6p2NhVW7BvCq6p8SQ5kiVLhWget JhJ+kuqoLfdEY8Lpfsw/UFV0nhPV+gvS4kKMVKqTynB+sNeG6Xq0r9OvVaoIR6SIceuFSUg9LD3J D4TD/ZDMI/1phhrXaCu4SC6VBBL+lhXQVLrI3l0EC9tXQSf3QQIFaSvSwyDT//1Yeva/oJaXT/SW iIP9XXXELrapp/tpoUmmG9Kw3StKlpN+SppNq+6C/pL+k4S00FrtJaC1SC1S1YdoJNJaS5KURwMK 2uqpAw9IE+iOgv1CWkqXevhBU+vJjmHWlhLfXSTdIl/0EtB7rE9EcCO16pJvcigegxaCUtxrvQSj r39LSvVJUhlDkQdXWEC4WEvVaUjq8JdJulkGhPBnbqtVD5ApQVQbCCf6hBPpJL6VpV1vQn8VXqpd ljhcjHKf0q3b/raSTiSgEYPVUkr1IpZrjCBOk08ZbleE8Eq0lfddBLGqWNBKO8R0/wV6oJKgq3bS ztxGDI6+lw3QULlAat2k9NsIodHAYX1XWsJdU/EJEH06hAus6AvqkUBdLSelT4hr4QSWva+GIXtC IqulfitBZhYSWuoaKHxaRQvPIwGdOrCoQlVvO0iSfBg/VKE+ggrrVLtAv0/4rGvTqFjaCceIkEfV xVVXpr7IMGNYVf+5Bov/g0Frhe2FUHl1C9KoSdJLucWnX3dxTaYZQ7W6QS/QTeQyp7DCI6eZWJBo k5BuJrsL9QvRFHXuwles+ksL/UJUva0Tdiw/wlXqiT7a1UUqDYYVgvwv9Vsf103X7IKMDHaqF0/W FbBv0KUL6XZGDfS6DhhIMhCzBwzAaDiv2qzxdpVUGglTSQUPVprhe1pMMhYTSgsL6C2xVr+wyECs FvEgkNL6QVVOLJ2q2HCoJUGQTRNck5GYVWawmQjqwSbIeYwfb6CXQL7qEGtMMg3DTZCFStYX9rx7 KeM1TSTkfa0iISsm5Q4UIdiCpPCWawlNnMIJkEfDD6oFgvgk22rYQdXBiFZ1BOmFG/VV7In+h4sb SGhEaopDF0wtkhBadJJiILX0gS7S79PqdlCBhQZmC9bBUvtbjFDtNRwXik4IodYIdeTCBBNJtaCw QLwl38i2+6YZQ4Jir2C36FqnZQLBlDhY18GCFUCQsegiXBcEk4hYJbhLYNJsIEGQcSXxahbQZhi/ HaERGFtcVYIER06gggZGLXpiF2EF3+HWGYdJgwQYLUfw1bBUI9YUfMA4ggqWF4IK2D9LqLBZ9E8R 4leXGwqprocMh5K9zjhMSC+xdRCJlmwx7BdggqYew0EGljiYRHDiJFgX3rGgyh7BHYGsMgQNkCNl oTCwkrLfBbDBBZGtkNiddMocJLR8M7IQb0OogypDVeqFkTcCccigXVkIKuIWCTIF9LpCHrIo7F2m 8RrYUh5AwUSxJeDMUpqioFYdQ8UoQ2h8XZEFwQzjgvodgkyMCshm+HDaWVy0Noe8GU4UEI7+wsEQ mwsNXGFBBdOIr/hgsoDkdB61yGq3p66jcMoThBCHwcugtEGtvr9OtoaPAgahWNZDNbiFjjQqCIeR +5HaU7W9kFBuaZY/iCI6MhDsMZjS2di2yDDJf+EIi6Cgqpmo6j0gYYSI6t/fyFXTwo8rWR8jmul5 kXDidwoIj/KoiODFL9BcRtoXvt4QQ8Eyj1esJc0gmmr+oWnYTT9/CV880QzueKvj4S+EHCEN/3SI WPtNev1CVeL9LXwl32Q7ta69EJT7nHWuu+gS1xq0vuqC9uQ8P/68IKqpPSaWt3oKu17gl/1S3S9i np2tL/e1qvpL4XQJe9ul/4rXSahIKtPBWquKV6I6fpwr9f1WFDBKtUuNaCY/r/sFT+lX0SHKA0Oq V2txYTuvp9haVcYWGC7Xiok3KV9dy3KMfW6hB1pVe2n4a7JZwtKO2E+0uwePXBu8Ldh52Yd127dt KodxsLysTdxW5Fs7ljka4G7a8REg45Y5WwMw5UH2VOQzufDjmbBmvEQzBnZqKXBoI+bTcREiudsE oVqJBysqBEWTp4g66BkaQIOJF3zDIMrYCl2DI5EcZ8Dw0yPNsgcNgECid2GSEL5dAnDGVylEDZHA 8GouyOB4NyOiPmM2E2RdHETMDwhiEnA8GUOQIG8txMGQuQkSy4HhrWRMCIZDUHK3pbIsDEtywMF8 joTsCy4HsNkrBIiIlIGYRwfDDlkIR5kYbYNxHwYO22DD2THbB21cMH3bDB3HDB7bDIEANq3DfsMO +GHuww+53AYvYP8GGR13DFmQF7TD38Nv7e7uw3+G26dhsf3fRTuWQtXY3/bLatR9xrJjsgSIWmy3 AkTPPFeMRbLcY0Q24KV67cRJQVV/oResqu2iFAst1Ve26CKoGZHkx43ndojouf87mncR67jf/29f e27XreU76/iq6Xtf+3/1cH6S52T3uu+v//d1LUJVr03yWH3VD3yUBfrpD3jrW2HyuVxe+HojHD8S IupBUgTpBvogXHOuLSH5A0lmpQm1oQZHRHZjVutTuiOZoyPGEalgmkHaxESBDkoIlnHKGiUrt2Kk lyOi4E6keLvv7oRERIZxz7VEOEiCIjgeVISDA5Q58Io5tkuGCOPC1ZeFDiRqpUEcGHKHKc8HMaTC ERSERIsEeyi4XCXoTMMgZLhDDI4NhHI2iOjaqkCIsghEgocpycFjlbt12RwtkEy6qRUMkNi0FEIR ESQ5FwjLLrFKVYZvIWZ4M5HMjhkBqKoIESkMwxmIhokI1IvmwPBYI8Y99hNHBmwbeIidMjhkBmUs hgcocrghERESfL5HRHBcjguXA8G5HGbRHUOGkwlQh8SUAeBPoIk0IiIiInRI7iIjdIGC/mQwD8zR HRcGjBBCIk6LojghfMAeDtqPIFaYGUZKMj5JoRBlYUPoJCIiGcc+W0tkNROtiIiJQLQJCJEI2Cqx XIZqYC1S0EJCAYaUh5tXS0EW5WdYjqkgQX/SwgluvSQQWn1VQQLT+kkCCpEof9IrAMWk2ulUIL3+ ggih0ECpJv+4QSpN9UiGkEQoCH2/hLSCSpX6UclYaNJ0q0kRcNlJN/SSBBEkWtf0gSHSH0VxZILB Av+KpEIjAGC9kdNVK4G1SUp0CEE8Ya8bSR8NYcVq8SGkbAX4ggS9ot1YKf3RBWNirlMCy8g2mwLx sMMg0mxL7luYiOZHyOrS4iI/5DjkDw6ZnUfYVwz8fyY5CnKOfihyIOqDERERENGatY+u/H//8swQ y1ik+g4fQa9O/YTupaikr+RTLU4Oid+WSicEy1DVAge+/oIQ6cgXxUNFctSfr2hUINfvVyMcqgfS fDCzItSQnQJ61ZTdRTMuoQPQ/LOpIe09tUrjhb7+up11TDfXLMBpTtaCwVsKUOm/5NgQggbnaqDC S0LbVLybFQdNTsL0zi1XYa1wW9DVKvdteTYTDOuEQwO763w/wkuiEP1XTda4IhnNhvwkrpfsL8my sCKUIEElr93+CBVaR9EdBBekdkzpvruEQXNi0JUExCvwTv3+kgtIMrRKkC19/RBDYLSO+hus71QJ X+vgh9JfOzoEILe+toEgsJX0EJCgf/vBHsf1U7sNHf/oeFfR2OBBxfX9cLM61CILlPVc71PaRN8r hf0iFdEIjAhHoZdEcibOvcp1p/CDaS9cIIUIiIkM4QpcTIzlbWa4JZO16Ic2S/qvyMbZDCmQWiOI YwmOuvhPoGtrvqgqI+EjIsSEw7TI+E79LYRH0yDy4t4a9OvwmwWKiLU1/WglGDKTPBFBCHW10oqt SVhrEcwRDwgjweMrKhNVsF5EBy6CDU6g35bmiTT/9skoy6FBChiJRJJvREBjCVQYoT41KAy4bCci jlDtf7ShtCCISSmEOnqQwUauyhw2Ca14WCE4LelXshgtQIJBIhL3pLhJMYMQbRCPRDOOUOqluLrg g6//IZymkSsHIegSCwXriqCB8LkMDofSYQQv/T0yBcSoESoM4IhygpzrMq0kJ8CNchSCXJODtUgi CU7hwtL11DIZZiiRZCBkDBFTSXSyVAXsOGH0siEBe0tqyH/eDDwprQVBlQgqBWFDTpMmPIoiOGXu ynfrQR25K7aVSI3EbpKs7qBd0kwoVDtUg6hJggQlHQQrxt0lgqpsNJQZ26ipD9fOy4dUlRDOPRCw wSSwtNqIiEC0w3FJY3bVIfvCV0dkxcIocK5CDxQIHTSTWR7U4QVeHpe90vjrWDfFKgg1CDohRzQC I/pBaVWElhul6hhpBKlwvg/WgtAgqQcIIaVVcIKccmOend4hX4o6pL7W07wkEkER0rmGYDwW6SSI 3oh9hVKx3wWnuHQYVvwX+qWh1Q0EEgghUJBaYPCCF1L7YLSe3hmwSuGiFH79oIJIJekhHCpchn2U Ql+hW/DbEJewQX/Wv01R7I6oEgRQ4SUPCWxuEE3dOtWGCXWq0CSrVUoqCQQp2Gdl+IXC0rqmwVUy HcJ7ylpJ1BKk0wyxzhECBNEgNASpkDG62wl2mQQG7omO6pKKvbgwSWgvWI2EszDUcgaI4Z4aT0wm m6atsEOwV1sNfBKk3YhRCoTgLwwl7Cab0kwwwQgwX7DCRGXhEMDtQlaUhmwE0GgxStMhBpPtIOJ2 Wx/DBXeGRZp6UJbG2QMEqhIILBeGU5Qon6TYISS4sRwQ5voCq8MVGxCh3DKgCITQetoRVB6SbRDN XViQ0G5ByaSbYTyBFFIMDpsERMchs0PtCDCsXD1SDohpjlDnXIDEdwa632DMIuC5fs7cHEWC1buE mzsWaEaIKhcqDm43wZQ5DjSYKmuIoWzvER0GUOba3r1WgwyBxhUiQgyna1iLsFQYVMJhiIjX7S25 B3IbQ+RhBFq+KhgsMhoHCDfkCqqEE9hs+yOGk5vNojA1PD44aEH1JdFwxqt2xPg1YiDIZUXcawyh wT9CUFwkLDYYMoc7mHBwZEwY6oPiNt8466TsMREzAhhEsPERyNNfoeEmzWEIsGECH2GFSxqk2eRH TYN77DBL+gmxw2GD9WKtK6uCBC5BQj3/0gQUMQ2GGtdftLLp29PBp/VNi3e+GVBCDglXoJyOnBhu uM453CC1/puwbWsRER6vXt5VP/8LbDeQov+o+6pe9cmwkIbyOEI8X3w24S6/k2V5cGxW70C/9k2D GEJBlgoDb+l/8m1APAubwX9BX76JtwHgpfkbX/+Q1Qyh+6ppJewuiGWJfVJLXHogir7IcXRHDKSJ 2FXoNeT3UUOQ2DvsuBwR4kxSBNda8eInAphPcRIYHEhnvaVfcf2I7pXOL2L5CtNtLVEF2gr9aTkF 4KOUOUOfChysIUffXIGGgb99Nk1QSDSOU5ODD2wkrUg1NCvdfskuYRHRjLoj5HMRE/m8jkeyOiPE fI4J9miTkFdoPr7eIiIiIiIiInBG0s2E5AoHOyma+Trb5Y9jYuoka4Ec2J+4+/sLszAsS/XpJP3l OCkR0CBD4a/sLeqJjI4aoilRBDcs/iu1iZo4yPkfI8c+n+wtqQQiIiIj3pVSUNzA5aFhLK4lJr0L 2vD6H6WnSxVel7/qlhJ062qutaJDtdqzQ1SSXDfhqlINzcT6Wk2ONKGR2R0bRHSVBJ6b+hEHEGXM g0UtHDI+bRF7VL2/TGgZHDEmOctBKRwMEcUjg2kcjCXS1+oIocRBEcGC7MIuIR8ujAUjm8RESNzw YcpeaUJKkH7TUREREREREh5GWknp/aIGLKcjHEhkAtSWOglX+yxyGE4OkglpML6VEUA8MGEZsjhl EcDwyyORHyYzYz0YRHzGR8LhJ8V8UTNEdFwblwQj4iJFgPDkeI6I4KZfIeQaIqwRQ+klS7FCIiJ2 WgeBcjgeEI7I+Qwy8IJ/LSFForlYZAZhcNRQlq48rgoZALVBK67CB1CC9dFdZRgy+XDSOoHgb4QS 18REjIuZCwPDmh0EuuHETt8kw0KoIJx8kOhFUgQI2tqPQU2gQSr9IKkZgw7d/TiCI6HXpBCEO/VA vJvWvSINQ4V3k2El0qFsjrEenIZS5cSZJ7yDDlLmCDAU/siQCFEGS/og8joSOo+yhwjWiPDpn0/E QghBlDhDQlcjLteIiOmyY53NniyvBCJRGEXy4GCPmLiIiIiP/ICoa5ahaviP5Zgfwg9J9d5NyztK TcoHvBb0Fp0pLrtE3GwYTIyvCLczQW/iW5J4IIveWVZ94hBL63EEQwO1SW+TdKUJggQ70+TYGy6E s4oCWRx3mT6fQkJsuU3qLN9QrN/aZbqVRf3iFCBY9ekGUyk9MKgXCqnof6Xqv9zsulQXdqFXhm+k tX118Q/UL1OyhVrpRhFuLtBdZ2KaIqddejstUIKqXghqv8Wi3Gwwl9HYEBG6lcWXzsuxCKHf6hEH H0SxKdq8+jf/UXrXOwYZ6NGR9yKsS3hIhjehG4v/QVLrhBRQjI0MIKLCDI4i/wRx2v4IguMDgiPl vAbCPHeYRQ5Haa+oQ69JEOTLHIZbniJkqI7QBikIlONRrUhhynS16CQoIIjoJkTz6PeU+RJGsFBH IIocp2yhyhyhwX8JD/55AjjkY4TGwkIuyGJBpAwkkIj4L5bikQOVAk0usYoWUOkERIMrT0CFCRXS QqdrXrWibC/CrSWgkIYKEC2E02RB2mGhzsFMjr9pYJoJUv4QYJUzoFKSI69g1nygiOhwhb+0l5Hp /WmWORwCo6YSCDIwPgnBgytKIkygKERZsyFj9pUulVelQilDkMsdIMIjH+opWOczDQLBB9sJKdpE tBVXzyYd1yLUFCUIsceqd5HsE02Ekg634qkl94yHKXSYQIRCx6IceiKO6iRgQiyMNWyQiO0+2Euq CVJLnlIZxOlraWgg8K+QbqCx2EGSaVUINP6VPSWr5HQyBcCS1RLyIUegmqeEGuD7TV8EH8MMJK1V Ktewf2gSaIo45CjpNBL3sscONg01dNP3VD0qriw+kqWKkraq6pYeGmcYQfWE5Fcoeby64dJhCEqS 6h3S4LVLEJcLxIccNQgodkP+ztQiOEQIQ4QklylpMJClr2D6gqmoE9AqSwXBlOU45BvAgiOk+1sI h+oSC4ROnUNwksLedqAb7hKiGC9R6ZyiqET4YptEfHHdJ9ILBA0ovtpVSfnYoF8EmzMNEFBQqBAq TBnd1UIbX0ITYIhXMO16tpQtER/g3pBJClukHa0PRHRHQQSV4Tp9EUOkndil0usP2R0CvIdQ06Gs HiI1YenyJq0CJdql6Swl0ofiKWTGtINp2kqDeCSdvS1MOR57VYSq299kC8L64S6XuteEtUFddutK 61XZDP+26hJavhtQXqqSRh0NpVtImMjmqCz+vW8Et3wmFnaEsgg6UK4VKFoJQvHtPJ8IU4SS/O0Y KlIYzC2Qgw3OoTC0wqsij2gVCQR2tXQSCXVpNQQfYQTaTvkYgih7bWbQMpyhzjhcgxBhytGuNVCa RMcJJTQCEl9JJUEkiY/3GnhLVeDKAYqCsRER4u2ChdkYEaDUVBlwb02talOFBLp+ESd2lhBYX4RH YRMdbC929rwRQ6oOxwk6p6BUl/pBtYVgl1TsQ0Kx+nx20MNaW2tYSCQQVb7ph1UQo/iC+mrcZFwF woTBYUUnChLw10g3X0wqYXWGUOEGqjrYVMaqfwUElx0FtJYKhVkUcKtRZxy3DcaqoUINcREFX4Qb JsYUK4TtM8T0I4g4YNMGFUKQ0Jwn5DKdfsJMMZB67VCIi2LRHsIijnHBEdeDCYJLgoSr1bJsrRHM 0pCF01WhI5qOd0IpSFUqUhnoq+EEwY4nEdER0fzXl8juSUYTCUMZXUzTegZZKEsFC30oc7MKhiIi LhYYQvKHUECTCENDCQKQtZaf2wk3ak+bRHAoDWOMm8REQ0ExVq60HhkCRtREUcQtJMUwg1CVfWmI yCs5EHNBUFXBAhrDjQ030E1ZJishmFsYWGh4P0DWiDr6kex44YXDMfobQMj0FWVWSYg/BNoQf4wl 47IaWFSJfi/sISUlKuwvKfB/hhe2/6HXyKO/vbt0fDXX7Qt5HQZZ2+lXYsjvOgN8liLr9k3Hy6OG R/hBMjsj5Jh8lAY/k2BAOHbEQ33/JtmXI6xHRHRHA8Nwnhvr+W5oDBgDwa3b5PCq5VqvG23qOK3W wb2/6ht8kWeLLPRZXtVkD7Q7vT4cNe8byCqWFDlOVm/ynBF/7LwzkOOdz7ghIuFMgLWGETgVtrxE GCERfbHcJBhcVx22+0E+//2wlelu/IaLogRkfptJdvu8RIxyNxIVyrPZ3K2HdJO2tXcREWEMjoj5 gOR8vEdGeXRdEdEfLswttKSHdLbd2IiIiIiIiIMjiF7YpJ//xEdb7X9Wus4MftpukuiHTJ/2QcYU OUOSc2ntLkGEzm3sm7EREiYy+XCkcUvkfI4KTcdyChzphK1XcREREiRkdEcInVIQZHBuc+7VNCJ4 9riIZHVfsdBhpOIe9a0TdhgqJAFhNypX//GzWCmXQ/10ncGCH3/t5EkYR9EdFqpL1rq3iIiv1rrx 316t+Gkq6T9A+v/lcUQQNdLSb4p1hevhNUq1rhMm5iSwlpfCk3LojguqXsL5N6Bm66QvCZNhcGdJ Ba+ybeB4ZlJaXRAklURRyK5WEQTIaHKc7lDnHPBY5uLHIxzjmguynKHShL7yBRBTkEOU59iRQ4iJ BjynERERERERERIHgXhJBeFkUybrCsRESMgrCHBRIG44kMgFiioEraxHIxxEgwKCQyA2OT4oTQSC WOWYFqHZDIEHO5Q5A8CccgeGpZxzrUJBL71IZ8ERINsEM45KyhyGYrJUIcci+VBG5LD7UBYQLx8I 65HDIBgREM7kLI0SQJP7UTMZBooZHBQRwWS6EUkgRQ6XJvosUIiJwFQj4oKohfZaphaBkDFlt6oQ RqDY+gY3EUFkgG/hPVBJBLaDsJJIEccLeSHcNZjCEQTqgocrlg0KQLKkjMGFZQ4fqslQaVDD9Ig0 rokCBVSBh1DBIhlr1shgV93GQUWUvqJA4HBJGoUj9SbjakMfEwjikNscpyhyhzuUOVxRuXxfEGdc XINcFHi4iR0JIWXT8SuWsjhRERFITyDZ2po7JUVxVcRoQ4iV6I4hKtXw0IiTYFd9syWUWUIk69WM hG9Xuq/+H8dP/D+nLcocH18W++of6luNLb/RkFoaBlD/nYr2mdgsot/hrpu//06+9zP136p/wS/9 V1393vpP6/7hfv/VLHTp9PluKdkZ/+9fH6JD/6X+7f6376pJTINdB3r97p+ZCNBr9e1T1VX/v+9b f/6rT4Z2Up0//70toP/lSnv7uiCHZAtNt+5LUEGgs71Ca/hNtMk7YfqwgohwednQIP23VNtSX5GK O+mqFtaEGEUOK+gocKCENP//oRv6dhBBbe9af/6bYSTv/hb0SPUu+kyNdhBSE7wf20vQIjAQp4pB ndWRwMa6thKTDomPB//qkVYuEGhD8iSRCQ1hhAq0m7fuktV6YIHkNaaBaDYYWrV/1kw0vWlCYW74 p0DDFb7V+y1iaWIIjp+vu9ST0kg2iC5ml9t2/D8SULpL1/XhYRHbgvwreRYyOitekRRk61BOL/kW czBhLtPrphh/aSfIiNAwbyB6e2DwrBEVCtaVIIQg5DZM6daaq4SDaCS1W1TTVV8gxZnlwYDBEmKC OOSdaWqSlSRmxtwvWobqr0rBDCd2nqIioJAiOD0vXSY9a16CcJrWrZSwbVvC/ZZhkdi1+kveE9K9 sF9CsrIKq+F26UUR1X9KRdfgvWk6aqgrCq3hTVcMKgiFHBD9aSI4kDRHGuoL/uCIccP9whIg5X78 kD0WsKRHDS4rSX0CJw5rIjhh60QR31SC0RRwg3mx9cgqQhdtIKuxlDkMscK5EULXSoSgC5H/zwL+ lqqdxDC0S+6VbaQST0IModDwWqr0o94S/WEtA8aDNhsb6vsKvE4i4yPEf69a1RDQOCW4p1pdQQV6 HyGuOE9NxrxDCEegthdLkFxLwX9JBQgr4TaIZjnThben/cJuulSIQp00+kEsJBBA3VPIOeKTw5B3 QT/kQlC6+skWeQxrf6BUC6RBrGrCX20w69NsoGLa2ERX/wvo2vpLJwxhh1JOQIF8lX1eFhEO7+me Cpp+3aWr8EK8KlCTXVHROOgm20lCT/YYIt02QwcwcMoCWkva7BP1sUlstz2eAWK/vCiE13QibQhR wthglDeu/heKoJAg4iIpNfb139tjRQ7iv+DI66YL6YUJvCt7d0gv7UJthf8SKgoYmhW9IWktVyOl qFethBrqqrYh4/UFTVPsRwqf7QYIOwnFcpzDX8JhNj/tJXvBlDZQ4VMJLhk4WvxBkJsaC+2lpv2I zjll4YJ0mGb0gyGwcE1udp4V6DsKFfxERqoiiIBcR7FLVWqe9QjouEDCS0noNDCuuKjCHwt4ZIcL fZZ1UDBUH7C20vEYKGX7lnA2eA93sFSYS+E3Ijnka0pHA8JidUSjMRhK2Eqp2LusViIjwy3FQROx i/Xh/2CI/5BByhzDlhCGWb60mQjcmFpBvsjCyoKn9sIhjYS7BEf6CEafaZIddBhD6+rLcDWHO1Tv 1q0LiPdehX961X//+l/+l/69f69dE3mtavlSWyp1XuSwLf110D2fmlV1T31Wrrw9KvoiP29Sbpen +CJ12pNxtBJ69pDsYQof/kT+iyGqC/I2qyoDUDyh0nVdPJzycDhxp1+f/W09gorSoMKmXDtQ3H36 CY9P7vadL9UthpO2iBgcpz2fihyFNk+uk2k/Ig5GOUbLKa72EpCDpQaERa6vhnHKx7X9tBCP/36r Dj1bXca7f/biq7pNL12vu366w1vXv/hN736+tPrfbvfRJw/qTcmtJx+EHaTfoFpXvp9N/XSb/erf /pv66T/C6V9/p6qlr3f9rr6QaX1qL9Lqv+n0tp9VtVV8VvW9a8tARf7H1yFTIR9SDzcR0XRGBo9N k6wgguJgNQtBRVhIIUIjI4No9qzeYRHBn9FvM4iKuIISB7HLZhgppD4RA8kyCcgyDlJodJkMsctN J7JuNKQRNC1CO/9VLONoswH8fltWr9r/6r07/6V6epHUyqWoe9tKIxv1e0THRXf5NwPLM6JKdX9M twJIO4wnpMQ2miT+qdhOEq3UN9v9dNJa6boiD+odUg2aDSBzQ/C/0QQuEKkcyWSqZLSCBEfLrqmF oIWE3aiIh+m00rSIMRNMIpw+raaqn1RkFIwkIIvEm/T3VmkR0mg/MhZkdAqcYS6sa4JkcpT4PUjM MRHJDkG+pQ/1Ik6SVKhKemShBDzKcXDPK4M2kLIhF0XRdekg3ToWCXJxWrInhCRBy9CbwQJlXFUI P7CdUWOF1SWGkgmdkwYI6BJhZ8PGEEU4EHX6XhKg16+RIUjhVIRLYjhlOIhIw+DvTTrikq2oK/pk xkdIFiGRYIQcIECBDTr+ly6BXqqO90gmEyEEhY0KBAha+l6VIUKiiTQThJNqoT8EEeUSFHKdJ+r/ +Q9ohAXpZQ6ChU9FOk0Rf0v7S65nqIRB5ukI05BQIxSoKKvVfXoU0kCr8N4QWECJjhL3Rh4S01RO 8IEVAJB0iC48IhHhh4SLoLCOaO7Xpf++GCqJMcK+ngmythsLrCCQtXQwtX8Jbri0S6I4UIQzYhgI qBWEmUOgxpxSl0EIVQ6W4S90oZIRHQKxHuk9Rh30IvhWu6qyQ70QzjiIVB6pUE53CI4JpL3vwk7Z Hy8F9iwinIKEU0qhY3qbQIpyMelX8JaERSYJHWDGgg/XandAvaFsb8OrEJJtvOZHQIFJjkGMQ6Wk 2H0I0rjrTBaERhiQjgpBBwmHSqoPyDQPhV4QaqQrnHlIiOSCxSQXn0Rwj6IMQShkcC6BemELBMRI NxqIpEdBhdUhklvZCz2bDkdF21e0EDLHCcZE3gS5gQuOgXhQ4KRXQug/pCIZBeAoSVIRqrwmEIir ZCl+qaFVkNg+ygEWEwWw0/GGmccKthOhVCOEGvLOL5Bo8iPkciXC4Mw5WoVJVyMcpwmmw66CmgM8 w7ERrhXEY0/vMAecVVQWwsNvWJBadS4inCdJMiERx9ZDKHOOeh4KHKHIJ7rSDO4JWsYJbUhNFTZe QRHSsoc7lUKuQitNRFsMLHrJAaERxSEIIjofLor15Iz6zXnEoZC7G9ehEXHoRccRdn2UIiEYRH4X pehDKK44iI/6x3vb/qWcGtV2u409foyJyXV/Ttf9U7Hy39P3rO6qK/1Ff//Xx7d2/2FTciU36/+s yG19fSH+f/7V2n/v5ED0tL032t/D6WzP6kx3/Qp7SDetXVdvpa5VhXbX+TcbTnpFvr8tylJZQ7Qe mEuH9CXS41WwgvC9ClcLuEqYrEtytAih9U+0utCK67pOwqrS7aVMF1/YoRsjhwYV135BRB0yOq9V EiJhb+nuQ2xzpgKDf/EjTBWq6ZHXIE7lJgUetRM0pIBkr7DGiXDa6SSuRQDGvk35LFvVW1GwRHVV UPofhJv9b/+1DfutW+0l1ft+vrWFD/nH6VfoMLx/i6/FWvt/8GF6x9/1fX27XsJupZxJLWh0/yDd M63mEQQNbWJEgUuCFU5A8M6ZJuyB6HMORUyBpFlUIliZBkcuyuCCZcZPk3NO4jJWUOUOU5AgWiTc nFIkz6MlarQiIpY2KRXTot9VevxG6h30xuLWtOF+hSst1tFvyvomPTT+lw1r7wa/S0HXLSHXXqVF x+4dJ2tKml/7pJe9ciSa+vVpilnY33LcDWl9OE+JZgndKvrChB6peqZE1cL60rpAg+F9LLcyT6CT qF/FP1XrahBesLuEQj+guvwugn4hb6Ce6CX/vvhBVpGQIiPaTSv0ukEhZSmvDwfpdhIyLA4RCbBP pDVBJYQQUF/q6C8EEqIZ9lK9TsW/pYQR3VKEGvudjYtaXMwYIiKjVSrWad+RzLpI7UAR0FVBVsJ6 aZgUls5HMySkqESW8neoZdUlwiCRVQsjvyFtrkoUSCiRS8hAzVKWCtepCy0YQVXgkgga0CIaI4ew Qs7q2sjA0si6I6I5kcFjlkA5pOIWuEoQ8IdfU5YJkE1Iwy4Hg9xFOC10vhZUL1x5BogEeQIhYM4i qqZTDGFwgkiOuggS3SnXT0QUDGdETowGQJdMEFSpIEo6wukFhMl16BHMxm0hEQXzI1QRBxldKukl op+SH4TCZF5SOjGRwIPhkilx1REyEKsIiD+CrVBfjJjlwUOaD7EBhVOgLYbl8joJ9EjztbQXS+F9 ILs0y6TxEROwwXCoSGSBwMXQWEJBH4S+l+lofoIRIZIFYkr+EC8JdJa6Xi/ILZjkGILcJLoJJEEp 0tap+l/kMkFo5CasLSS19BL30kkkq8hkhOIMOSsqCVQQTS3pFRSLrwl+sP/XkMgNQcgoHKc4ZC0j pJoK9aaC4qq69LquQPBpHIMsGsEZo2j5sEMKqhKiKOuKSwXWnd0tJKtSB4KDk05ICiNBaXWRR8VV U64Wc+HkCr+kvkGcMupfFJL0ENBdJa4WtsHv0l6ShkDgRf60l+C9Y9KF7yoFh/peDKcgYHIJa19U ER1VJa9V6itg6CWvBrWIZFmIX1VViFukq6S8KqD4JLuS9ar0/S/SVJLJv9JBW4KmoeC62dREGlVV XDC+lQQXqDKHBJdJAsap7LovpNUiFcodBsKt1C8zCf66VCP0l6EN2KlwI9iKbCTQKsJKNV0kF+cX sJLwgeIhL1GqX57qtVSrxrSSJj+iJl0/tV1CwQX9YS6U2gRTvhL8Y4KuEDTTXCtLJCv0kvsSk0n4 Sgvaa6ZAhQELSVIbCHp8IJLMJsKPVIX6hUk01XVBpetJ8KwZDRzBBXWttlDhSDBjhgg0KVVBVtUl ocREJ7peNMKspEDC4UIH8UK9kM3X5hYLBlDhHYtDiNDCIovhNVCviGEos+wopUC1HahDQYJ9C0Ii l4dBUDIYJ4braSGSJAgZcFAbhSzigZyIRGmJXIWL4OI/CGdAbj+N7jSaV/0L+oYpfk0FOQU3LZSs rcyisrUo3La7cSnRHZHB8Ts1QiJ2Jo7xGUIgiWtYiOR0IiPV+khHHX+//f+tL//3+te8PXJQsSud X06Gukfu/dX9U/9dftevX3//npV6XZ1v/6fSl1+wS//2Er8btul117S+9egquq7r121iFv0qafS9 0N33p/StD/X3r/v1p/e6+iMd/6b9qrfp6Yf1Sfr9/8N/0m/0r/6f9//p/xj/y0Zerh+Tdd1ocm5d Q/1cHrtW/+RSb/6bD364NFoF1q8m8/TaLQJhfXriWgCDP09tU17UHrgvW9GHyx5ZStJ3cpQO9Oli FqgZHRGw07X8m4a/EXFe4RGbFyDETqvtWl2drCkOeUC9ybwv8m+rtEXWvZA8hyjf2k+kHTlp99kG c31FKl+KhdlnCkR2cIwzkGm9U8JesRCKrPQo3FahTidV+IQQkdGGJtCsYnZSjtOiPdBBTX4iIvQn kVhCGypKGQJLj0tIRFOhzI1RrQQRHz6MJzWjy/S9CISERxHbYSusJZJsjxHuWaWIySlSuukkCEd1 HCBP0nmsNlIswNjYS/h5IAx08Euu0jMMv+EtMJXmwzOuFtJtYgqp4Ig49SgTwzZQK6ThBVFkrRVp JRf0uEFnSOxZHa0rTCZGJKg3IFxym6WtRBen9psoStvCHpVprglp2lmQ3JMgwbX1C1VTMNJtb9A+ QQ2nwgQLUlwj8LtuuwRTplDkzYPom6qC6pAgwmRVchlqdXXwhiPom6kGfCnUNmRiBPRAgc63W0tM rSC9hE3LAMa2yh9hMjS2EOiN3DrtBhKo1SgmlpprhlDlOC6dtSr+QVAYheQzj8KumqeZrEfS78qW czxHEp2URIyOZHA8GXULiQzuQ0oKJEQ/CdoPpv77KRmwPMjg5cFBiOZwUuRHCGAyAUEczmR4jj5Z mp3nERwPBQXI99eYSrepzQhmeEQIHKmkjrlwMw2jC4ViIiJC2ZDHCD9fIIj+XRHJCIiIhkYgphEd EcDQEqEybi4ZAKCOGCOjCLhQiHeNp2ptFRlwwRwNgZpHV+IiIjI6Na82zGbRHAlfU9sYoJCIiQJQ MNx08UQyQL8bhd0mIkFsCgchkA0Dmcg8HHIYHIIOQ+pXlDkx3SYUgV2VxJyiDQYcgaASDhI8Hwhk IcvAQiInBUEIidER0RwPDbvLNwUgqTCI6FoREkI8BpkfI+bQiJGIuZ4GgwzAhhGEXzZl0bzaLoxi LFCJJ5HA8McWSg8Fp9Dia0RyI4ZIaRHBrI+R0fGXRHyOB4cREXkMrVCIiIiItCZo4jgLVWEPWoiU 4YI4ZAKpJx4i6I5CLBCJmRsFyODSeNwoShCJDyODLx2ugZHMocgeHHIH45Q5Y5RZpoJ8sdHQCHVE F/0S5tCdAQwGeqj5B1CyEOQUxwgZxyRyIQT33SpYqtuCc+kgThCD3vsL0ahlxkcFAi2cBO/cFYUL oIE2KQJ499zqJ055Moc7kIOo6dJBKq1fC6ChP/DNA+qiIhrr9Kgk0k8U9AmYS0vsjgR1rT/S4LTB aVJAop8swY3uK6Wuv0sEEGq2EuZhnI5IivuC8Nrqva7QqKGugrRhEcG7YSb6bTtVV1QYUJagmccL aWIgg6V9RDsgvvrwSiGChvwhHwkEuE31DQYWlVAyknphdLBYL9RHGsfqF0CCgrpu9UuLoEwlBLhN IJusJoajDCagiOggmCUK3wgh0hWEISZCE6Cf0rXDKAwGWB0m+lXyI6FUm/BfxC0vwt1DWgm+P8FQ S/6Vahv/hhJoKvVJAyJt1TdfoVSq+69da1pBdx6VJ/rX/SqmvhJVHuEv3pKlrBUoX0qflmCFhJR2 WYOGacRZf87GgxXLOCIjgb+gvhCGSAg6CCV0PDI5CetYZUhdeQzYMOU54WP5blWcqIMOFYS8IRBk J8shav+ONL/0F72kuuKXfXqklfdKtX38Jf0vlLWl8rI9L5K2E9BV9VSvpK6MOqf3p2t3wa+sz8f4 pL71/kjun+nhV/dJf3OmR109/CH2tfS7/67b/sJXDX9pYf+6CUG++6Tu9Xj3/bCa/10uR1XaFK/w gte3C3zKi00q691/04Xx7a7KH6JDhhq6HpONf4f62/Wgn9rsNb2od/03+t/Xv9Vf9b+/Hqtf19Fu nVBrre18cf63V61/7qpaC3/p1/O1tZQ/9PH6r2oPUyNf53AYLIsO8iNfBkUBVtbT/Gdk0npQ8r8v pFvNEGlOy6J0mSH2mVxwx2hETsQjUk8do6ojERC7c4kD7BCKQ0IiPeIKRpH/hFWQPN1zPW1CiJCl xBkNKyoPMpyz5MevjSIQczoJ8sw1QiIrt/6I9KfHS6/hJEoadUnrVdJSKChPuErWvQQQQVO0HJuk Er38JBBAt1EEHvS0uEECCRJ3wT1v2khCChfRQ8p1/roJBJN3CE47GtL7wiEUk30yPHjX/VIILDdQ kNFQv9aVJJegsS90/XSCSbuggoX069JAhepZphIKuvXdJBN8UlfWtVwk/pwRh6/W6SV8JIER+M6X R2IUX+gv1Tcp4XUcrK6SVvSioIFqn+mVfTel3hKI69FOFCV+qpN9c0WuiK7zX6akVyJojpaSKi6p KIUKR0XReJ0bBXKqgv1YQcaqQiq774QMEIiI2UQlIz1wQYK5TqiHkcHSTfpBTQQIbKp16CphaOou Zg3SbIT65ToIRkLBpu9SEBcKlYQebDKqwT7hCKJYGpt+RgaMJYT12wV6lrAuXDIDUC7qFBJVeyMi kSqk2ldwQ116QWgsJqE9awSe5XChCOlBEDA5McqF/qoS7BU6kIGlbCC4UrlgLohkAQOdyPCrCRY4 IEpVFTqkklCVVXGkmwgvyKOQRpFJA8Noc8FWcchXIu8Ehxyq+nWEQ45Q6SSdEEHg0v+gXqzwQgTR TkDwai70QhP61QtaWgTap6SsQm7sMzFCcSCyOUghiEETH1BLuuECTQSWgT0q+1XDBsMJMgbnKoqQ 9BLrWwSQSpQkH0SH3pMK6YYM+QKiBA5IcpyC+QlC0Ka/WklIgNCT0aL19ektMNkQ4KRcCiIWgj3V SGB6gvhLwkagUVFD6Tt9BX3EVCBFDuqS0lMJELY6OqW3VOgsF16XdKvoMIGxYTCvFgog4JJK0RR/ YS1BahV4SpvpNdgwhFBUoZWhBjAk+kn4+LDS62E04fhEUd/BprL1DIrnHDYQT8Evr5Q+qrBJ4eoS DfwyGa0hUFEcIEInfgiCD3ZxwlqvEnPoLgglZBefCCb9Fu8RwYYVMQhivWrhtcgw99pJsuDGx0Er +IZscFSBU3cbtJQYarIx2krEE7ekG/psMMFRFya4hZdJNNQW2Cw2EklhpUEw1qkHGELC2vdhcE9m gWDVJhYfCV/q+E6BRjBNBn0wZHDDdJUp2VBgutBBh+1DbCYKgwWNDxVtBJgsR0E3Wlb4XCaq2mxC Upywa0nSvViItbtU6iin7SCa+uyhyFVoU4VlaQQQj3T/psT6Pqt9NL0EGq3uIvgyPiCDpwk/Qrqy 6sWxYpQQS216sXvYYJK4pbvsqYcjnFdpdsjpWmU4gqX/F0qSIu7BPaC7ZgO4hhVTDXseNKw6000Z TdSBGz9gwRN9E0Nulot9Qgik1Wx2El8yqJekKXLOCrS2W+Gmd3mFhK45xGMuGgqEXDHVYaERFnad EdUl4oRLIoRX0RA0VhJggrSIHn0REdfXQQXkC45UHHIZmq0FbkMKChy+KCUgYVFDotxFIm344y3s 7gr+rhqvaZ5a66cftrap9Le3f6XakktL/6fW/39tXkWS9e/TrT/fZuXq9v/9V/XXLOULh6/X/7+1 1isL+Z5rlS9KH/tdQRB6S0wfwrr66Hgg17aXYS/ZxyEmrxWqCI6QrFiqtdhRlj8Pet1/RQ5Q65bo E7QSs1kQdYjXGnSoQwQ4P+PrLTFRblui4UJeCpWrCHUd7hrfVql9fTr2VxTI/et/BC31/gvp6XBL 0Ru69IFek3XwS+n/oF4XH4JWCKfV+0QoXHSbXyGwcqZRyoOOccrOk36DEREREgyGwXS/g3G3XK4m B4ZcLy0iFyulAf12PLfQUjZK2l6qn+tV1vr/9UH60OPa0Ev9/119Yfrr/6wX+TMPXySho0uStEcM 22+RsG0m4J1zssWQgKXbwghz6MAzVqgrSGNtUEMgsDlDlDsiSpYyConQk35EeIsjnfkMoVQwhQRb 6KqCOxdMgQCIIITCEe4k26Em4ojHa8RLIMSikEEdpTzjvQRHQi0XsZa4aEREeP5ZlfoE+F2npd/S 6Xr1eFVLtFrBfsRtV9yzNXwXheE6qW0qr0W5YkH4QhvUId5bli7BDx/LUELQlcWW0+1xvyzEDqvy 0kLpj0uWcta6eFy3NcUthMiOuCDOg/pugvds6aT9wxvfW393/vvV/wrLUu00/elT7uWQYC4crp1T fJvqDWUgF7T/ghtp1tQiB4aGQp5bltdh0CIHgw9Vvsg/5BB1k3J/3wyDA9AgZArdIMuofkNfDFQi MRIzYyOCWwhO3VkK7UTsDPO8zCtPQiIoKh3zsNHdojb0HoQ+DUzxVxoRuu4dQYS736oPT5b1Cark KWUi3T74/uriklf9p185/3sL6vukvoi32C7+3jrtXcFx/TI9/TdOVySr3tLvhbxK5jW30W4i2ut3 s7q19ZWA/DtLWnfT1qV0vL+Fwn/qt19XQtyVHfeurpZ2LK7O0pL1O0muq/1brthB/9XWHtIiwcda T3r+nSa96rBFP4RHQj//+nfa/EOKpKJuwtnSqtV1SSC107faC/oNf6/w/6Yf2v6+ZjSa9LX/ZFdu yJvbvC6fpuvaWkv1Ctl/Xj179M7W4oS+sLp17wmJGOc3ESRJO1rhO/QiHkTL/1/jEH2C2GtEQf/h OHoP61/6D7CC/30RB3rkubDVOtUksJl77+lbWF/brRCDtB/aa152B+hIh+g+2lT8LdLvQWmQRBkN upW6lKvKH3yGXG2D9qqeEm9J6jVMS5MocpwXapAg0sJpMPjqyO1toJ/S721S0yUBgRBmc0HI5poi u6UJ+g9h69hi+EF+q63wtMg8EGIi6mxGvSCeoTVg3fvsVd6C+F/2p8MpcE6b1906ZCVwe7e1+l6v 1psMEcd8Wt4STqk5DRsmHcuhCxNfVu2FVa9pN9a8f6tpGgObSQRAjb05DK2DD8cLph/voKzcxV9e xINx37qhQIQ81BlqoQMG/UE++mNa4Tp+tEY9kCEfjrSQPRBx2a0gzshsP6X3relF9rSXwV6dUnSe gmwTTCb/YXbeg2tILTevigXyC90tBwrQhOCaaYf6C69OFSBkcMrbquqrRBJtYXBPtptpt/p9vkbt q0KrTr61diCSRBOChO1+ER6f1qW/Bn0g2P09VuEl4LCCgpwNSoIIOT9JcORNTud1T/hSn7lcyMF0 mHwnvpbrqmCBJBXiDBCNYVxEQl3qEQ8IIiLmqoXq9QRT26XyE8ydLtBhGEEFV9UrJjlD6hf6WF7u gm02Qai7q/2Lqumhrt9BJiO6X8VrqSHXt1Io6vb1S6X2wSq296bX30CUE7dFAdQk+zCO9pPt1W0G QmQkt2qS/S91gn9+m7HVp1qgwl8RtaynV8JUtIJfWEvvpP97G0oME0v/i/pWlpXSX/+rrVr8mD6W 5DxdSGrqlrSX4Vft8K96QuNC1C20CyQE1b2gkuoJNXWt9vhdbtU97bJnYRN5mgiBDo0bel/QST6V qu/vvh+FVWLhJCI0m6oEus8iODvoLDIIvn/6+1i04by4VhbahhJepHDP9cmuHu/Q6sIMLGtimEwb eJ8F14r666p7+HFzutuHphQ287IReLhsYfC9pf2+O4i9W0yhwTHxEF8LIjpql+6+ItQQyC4E9hJL CwuPf7fcWmF1XUg4FIYv+3+mhEPcKuRBOC+3r/F2mccJrHBbWH1pcNBoQynKHC7sJVTe/1aERFph 4QXd9u/LIa5N1uHiE9MHa63y3ohYXSw+2tLYjCHet1fQQJ26ZXQmGpNw9LpAkg99ivBRLc6CQcPc Q1GVkNmgQtaBrJYGnpDsGCoiYKpZXxCCMhnUYZ0zgFClfEvzaMlmOyFEY6IQelcUELigv4yB5DlX LMoggn+iBRB0Q0XSpKt5LCGVZRREsoxOR8ytGarGudcj40IiIlchIF3cREUrMq4yhfLIZppxHuKX XS+Gq+WcXQ18a7j1/zsFWWgmq8p4/0imBK4xv8thaVLxGuWusL4nYLrUthbQmQGquWuSoRWrO3IK ZFhVSC1D0d38KoiI8tck7v1qpZoGvCG8OtezJbXxK4tmEV1VctcaRdZCZSLEj49CDURoalriAXzI bV8EFlTQj2EwiOh7IyYzvTqEeAUIk0N6FlK3xX0WqWdDy3w87qx2CZHi+IleHcIRl5rSFjtMs2f2 RX16JxBrgwi0ifXFb4+/XYfb/31dW+3b9Bv2Wk69+7LNE0NWxMjVaBFOxuV1sC5NyeWpahW1O+S2 yuqIGpGOQjkxyQ5ISYk07idAwSpRERIMYVVWdlKy3DxK5SoiGW5QjiLIJXGhHK5KhEqEdzRBo7W9 bqkInVCImXqy/d8RxysozXkY5XHenQiTe1eEImrNERwaSyVvsYWhE8ZHAhTslR2lf2yuS7iUZhk2 7CKHaapVfx37/6SriPfqTcpV7bXu6cayDm5R7W0kuyGc3EuTaeutqWU16hh+K77d3BlWDp5Id60o XiaB8qSI7ybTTXf6dQ3ZFMEINMSU6uvT929MwDDX+q4WraWE8Xvd/u/Fa/6pd9fatV778hYK8L7T b6Xr4hBDddJevXhINdb9UqluOGfQS5bjSvSf64SLcqVYT9akh9vrpK7oFaF+PS+jjtrqy4YulKla +tjLeworHS6dOmdqSyuJ9aB/9JZMernQx9dv1f/9J5OJaX8iK/bVD001VP9w7pdLfpaCyEb09uGs gvH1QSlWjz9PTta2gwlIg5U+WSF60JcISx/4QaDMiyru2sEPk3MwnVWCYJ+p3qE1TMhYWoO31rRN 1oGiinVAmn9ndAxp2ZDQIfReI6LyUJ6DSftSRLeFJdBfUjSI5kdhLTKRGOyBR26KwDBcNhqXfk3a 16X5E1gnYJ+mCEQ1jQkpCTTIGgTBCygfXdiunBFD1STJNEcM6qFIwGNVCeEDJcegZL4QZHYIMq1h Uta0Gvir8ENbwXRCvCdyGi4TTIV2mR44gQiHBmoVW6/4+CKHII5TrIarBV1XS1RC2UOkFKHqmRtB PQyPspzj0wQNMJ1wuGq4kQOoTXVdQuuCCI6hIVCHVNO5F+kgYYNQnIMRXqEt9YRGD/wSVQiC49Vh cIUlrXwtBtDT9LCkSaUOW7hjBqER1oKqtdQvIX9YXRBxzAQTOtqwTVVdJAgoVNAiOqwn6K5mGd1b elVUlCIKHXcI2tap0rUL/d3twr1hDIpyx1hV2EQYNwLYwlWv0QwhBBIUKrpaIXuEkECKfqq1giGc dNohXUgg9gsR0KvCVOGkF6XglkMsIqkEHx6QToIKh1TtN8zSFLCEIKmugXlc0ZHVXwl9KkFohoHK MBJyJelQScQqX9fiQ4whxzDnHpQgmtqlUR06SX1VhBKRHCGEkmtcIL6TpJL2FcRPGlBfqF/3rSpa CWEDSfHT4JpJLWumpHAuGukO20lvojcPoIiD11ugVRJgGEuqQ22lr10PTS7vXdpX4SS2qrC0EUOu 6XTSpBSTqr5BuOlWkm4eteg3VBL0wqByEjQQpfuGCeFkM4hOhIg/LhrIIKq7etqqbtQlfpOx0RsC /wqsoDLqpKzuUQX/CvEgXtKFrYYdL7avtAk/GgsEcciDlcVMpwlkNA9eDCIUd0uqkcULDRQ6rkMu lQlVAindvIEQvq32eQQXtUyBcfUQYQUkOK9utEFA4suDHSERFRH6BJUC8kOkm25DO58LHKH/Lej0 n4YIQu4XWMREg3fVdbCaDdBKpDYITaBVlw0LVAobdiIil4IOt+Kh01TXUKj2R0GCdq6hO0rUMjsj 5wIRw+gVRXYaqnSe2CxT9e1sLYLkIPFhWlwTIEa+kCQii4ZWyI9dIFDBJNt0/TqutWhJcLwoUUQ9 usNMIjoNlawk3HpNe8ggR29JdPHp/GmQaalCI6H6kTVDaYSprSBUkEp0DYdPD7CWq1wXsKwwQyMd C3WS6DBB6SpkNSF/1ZtGAzSOEhvs0IPe62qtrDKHIg5NSFPqJVoMoeoIJggZY5DPqE3FbURFyCPM 0rEhlOCWqIr5Y6wwTWLiDOlBO1iPpBkQcwsVNV0sFIZbhRmwYZBQdfq98m6xtPiwrHM0FjBoRHfp BPWoZGOU5xbdJ8cRpJhMLI5CFoaVhUwoKEyKPxEX//4ihDBYSXSsFQajqUOp2hXTf5MvcqYwWmE2 wVEVRHQNMocEGqjj1rv3IUlHCV2CoRoWtljljhPVBP4i6TVUg4WwQYIqAcGMauGG/7VMJ21XEGEL XQafuGCaggwrfDJNyew0tWhaDKkXa41h/jCHcPbDH4ZEHMuYapaaJvqdkrRsZ5ZaRaiOhZx1Uo2K 1BoIREXiIax5b+NtybjaLJND8axOy1EhFcDQvd2hESuSpMy0WsRxqHOzJVDZZygORwyy8R8jg49Q RTIVFM013Eflvqi0yb62ZKqeu9jdpnkqb23aXt/UMa23/+mWkFJf38tzUDFVcJCtQgi1Cv9oF1qQ nlNIaKkMrRh+I9Y2y0zCI667Yj/bLTGIqa+2Gy0yEIpVScRG7DLT1XYMtP/OxT2VxNkdFwzkcF6E qFXCERBiR0IlWsINspuQU0iSGVxeI6LhqsrYsU1UmImsG4SCCHlvwVRuNe6pHYsq930vj87LrtlV Q3oTsHctyH1UrrLBBuPCaY9b6r9Ebstii9ePtW++5a5qt9WPr9ZH/t1/W/fvSVytfs93j26Slpiv 31r6EVqQpesm4gKR8wibmSxtA6ghEgg5RuFSW10wYWVx0hIg5bJrXlua9cSHZO/HFEHHILA5RuS+ ZGnZbjwWXSDKcSY5CG5QnuHfzeIgyhyhyrF9RCQsJMSOi6MK1BFOUOVD1mU96oREjoRERKERwbS3 EkR0t30sRJAKCOiPhBCJHRHyNo7To33RKEZUzaIsorTnfEFEREREaxEECESbcuKTj5QhEyDXf9lN bXT/H/f+v9dZbha734QfT/S/+t3Kkv1LKFL5BB+qrSVP/zskXe7XCCwQP6tbm0TxdIKwgv6uCERk eO1hVoP3ep4NQOg0FhfUjHumCBCEHqvskaWUBYkGnZoGkVzCpLfsLBSbi4NgQemqWqsVCRNxrI4b ZOapXdXvOsmCk3VgrhNP6Spu2nGTdODaR0R0YNbStZFlTXwmTegMgi4TOxZJ5OH3S06epN4BkI61 TRFHOPzgEKvr0smywCwKraCENKRwb5NnzY9KZAi8NpJSDJmkRR/COjjsIRVRtfTRDaI6TtpZCxSC MJ6pad1TkMtJVBeobBBqCXnFW7bSkF3IQfSRQunIPaoSUAQFXx/6wVVIZxyhuOlohN89NQiDXviL smSSS3ULa/aUKsm7ofSwgbakCRHwqCRDMUHCwwTaK88jojx96DS9OkwmsECH0tOsqwcJBJEC6sNB gnoREiDlLDh1XukEwRhYpaWt0S4KFQSIaAIGEztAEAih0heUWRRGBmER1XuNhCt9Ja0kddNEE+kg RMBns7zCXkXFzXG9QQOyry5IRY6ppFGNqkkiLfVBpoiEBJQlQYISCCUjeCYVD02Yc9ljhBXbIzJP veNeuEPqNBBUFP8KQLUIhgVIO5QMUdiZ6DdMREGEEIwo76tesL8g49JH0OXCF1CawiNBmAinRFsr AMGOk1VIIIj/y3KBdp+PqOOFQLWoQk5pAkHEiFIZMDjkQVunCRQ5AwONdD/UJJqqVIwl+lGRigZ8 HNwJgg1RIo66ETuCyntukktdboIVCrgoQVWlkmGAqdIhIarQSFcnP9v101VJqukix6Cg0CyDDQtr CD6eiGi0mqf/1VFjnHCWklRnQTVhAgTTSEEoKC9QrQ1QIugWlCddBrRDVUrsrdeER1WlYXYLpKF6 1VPfIPw0E0F/2v9CLSJwRB4qEKpGfUuhRhVbIMIKcLBVZD+UOF/IYykgQWrT+vjVaqZqWOCyGDqF 9RQSUg40ekTwRUQzvVBCKq3CMJ3VJaC316Vd7ERwgXBfhKkQ2CuEqCwr19DqgQLqF1ck7wRT61Vh mpHAheI4MYQUPVBKweqwvfXp+CBUkP0k/pa1SDJwhHBo0m+wklD6CSCwUNdOl6hKuq9uPVeyDuy4 Zmkw9hpcHSQWCVJ+tK9QqX3V/9eI8ECGGqDIMa2sJJEVwtpbS4XoVrbLfQXr0q9WtO+wlV9BKElo Fv9JfUgvekCa/6pdSDQPNpUCYdMhjkoPqC0NJU2kqXpE7XfZXMkE9Ida74TIaB4+3xVHYsGfSC3w uyBH/00ElQLuCanZFuaLqk/YJkHHBcU+wlOy0P4SvgrTS1pdKFddVCYIPx/ourNT2QIDBDwvgkjt TGlRHBv8gg3bJcJX5tVQS69VIjwgy3WF18KOLwZxyMuWH32sN8aDWTFDXbCC1poEEPIF4YQXC+mg m1GvSH6ER+6DST8g3fD6QRH7kOOTcFrS2tUEFwkvr3/1VcEjukwyBBdfWUGRwukRsh2I3Wo+Qzzk cWoXtJJ7x2FVDpJB6IoHztIarC0E2C5SBH9LS6jprvVbfik/rWyhyoKJqEC0gsEmyOD/tphRqpBA 1TXVP7Uj/TXqFoRFUgS2lMDirIwMbCdatphNffX4/YJKsJVWdECSyHIp9keBBbVqHoaEVq2lt/CY XSFOkiGHFbUUGosILaiglwv9JBbKzEcGCOMWQsklqh26oYTyGBwsMgu4LaQV/itIt1NSC9QixxSq K6DUQsND1DpdPWLFdVCqg7BUdvl1Q9NbaSDa9cErTtYi+/VhbTk2q7hMIMFwiBiQumgwq+Y1eF0w QnZX1CBoMLaEU7QYIaB5A4HIxzDoaEdrBkOTsL2NCW6qpblDmsw5hyChxM4sjoj5HRciOyPl0fWI 4Mswce1V0hERoOz2U5xzDlYVWEIjCGhI6Gy3VFihUpwr+IiIiIjRhCJZBNHZWky6OiJCOIrgSJ0P 4r4IRE7AkLWIiVwiEuhOxiOiOizyI6f+IqIiIjiNFYQvCtKGEJkaog0troGhFrZb+iyUXi1SQYJr /bJupoLpD0GKe9t1/trmRqupXS+11W5XWBLhUP0+v0twv6vXVV2l73jXWSH/3jfSq6nfl3/O4DZ9 WkkQyzYaOzkmr2R0FZBoNlYf9iKgwvXDCDBkdZNyQ6XhpkWYtQl92CbJAEYQL+yLsuzqC+wX1O1l ME5GAlDS8RYYN11fBuv02GybTX9w2Kr9ulq23+yulPDZaimutJtvpd4ZgEtu+txBvw6WkiGvse2W ko7WvIKy3ybXDpd4PcLFJVgyWAu4TddSGjgyKBssLBV0StkgG4JPj7w2RAOEsKusNkIERDYVOmqf h5a3SG+2gmF0WUoVVcKLoIdegVUWRUU7KlfwQwSca2xH967d69rZNxJ+6qRWcLd106vSr4YS/sfB 6aOzmkiGxnF22CO7DP0R/g0SkiGiOGXoVUMKIy0rVNaFomyjI4hH01rhgibVmRwbkfI6vDIIOC2G QMGwEIiDWibluCQ8tzJG0dEEQVRhZuSVESbJPTKiJxE205AkHJjvwT4iJ2qpNCL9eMZEJdLlvUpA iCvK88SOhJss5AlQIp5NyTQV4ciiyFzwy+MIuhSK0i3oky3JOu3RKwyxiIkMPxVNL+VXLkYaGbxU rkSrTQZS/EaiQknJtwPrWuHBEdaDQaQXWm2sa4Qa6VaK62fq3CL+uQ1rtb3pkD0OhSpIf0p0QVbT kCccEJdoJdKvnMjgvwWGQ45TkY5DjoQTS116ghCoK0IjLGVRG3Gl/eKUHuqTpa6uwWl9KQLOw9Ja +sFt6qFBO6OxGq6+/60gg9U6/uiUB2v6prS66wuaAm/6Ij0/JQKpGJL6+/trStraRG0RwwoU7QlZ Q63vhu8i0df00Co1hofCGQLVNPMi1BC/rh5BDZG0+sLqlVIagtAn62tth7af0kqsZrzMG6qQJEca 0of9/DX9VSpVTCaqCEGjjpQv+m9kG7c0t3+l1UYVU69f924byRf1SC66wkCQIIdJfS/hvzWiOm7/ SwappEKOlCipMDIWsJf+HYa2wgovfWK5DjqqSTVPCZKQ9EbiOoedpwMKS5dukePoQu82dJLJRhaB EdK0FSJdZIwnIMdKQEKRJ7GE+GDwyvCu1TZx8Q8x1whHoYWktpXYIOgmE0RjhYbWFvEX0nLmOkq1 S7BKqIg6kEuNKFh4XKqq1OxIGkLDsUlpIUl/WlQZB3CrS0RDtUk0GRySsoGXRIDQk3g0iMd1dt1T wl9brJ+hWwkqJaa00MK5cFNV5LRQnu0d0VWlSkdBL6NFp9DCiFrXpoi3UJBJK38L8MK9tJYiF8IS Okr9eoWlyI9AiQGxequjutfS6LfgjduqSWqj3pJUqS6hAg8IpwYWKp09JJLqJ28cxq0F0h1nOH3C rsnDr1qQYIkgktx3XvEGR/4SCSqoqQX2QlKdF/hJYLWgm6DVSDKOUCX9UshBaldZkL2Okqaq9soo 0ER+uwVVSpKEgkhq/0sEQXbq37T/oeHyE4U1VXH0r6VSCoSb/SUIOFTvagi66p1Q1ZUwrSPJKKbS WpE8ijknKHKsEgn8wkkqRAw3Gay3f0LId+l1SXUh8Kthar+Qg5huIiI7rrhLRFO++2CKjTCgg0tN cJxqGEEIcJKr6SIylL8ekqBAt13H4KEpNyfTOOgfapgsZAiBC61CwvvIRVoKkOt4fUWE/QjCUNII bkHHVJIJcL69GrI5Kqqlvtr2sWE7UFsEwh/oNnUGFS3UIdOgqQWq2FqOJ3VKwhZQ5acFSpOgzeEQ 4+0sJZoGKSCSsg3bk+1b7UcjY2gYLqFoRVWRFuC5wCKwlojblf7er4iLCWlfQZIFpSPFwxkcNFRV V62/6rYJ6wxWhFRCev37aokO7oUhqlQSClDoJCgku19/l11VME1XvTXd730mPrapWFQ0goVN17/e hxZBgNrwggmEsM2v+/eTdWmCDqwVVCHDEiNyeVwWo1Cv9P4gyQhUlCRDOOF3cIQzCI4MQ6LdLWvi IVkEA1BQhoN+IthhRum9hPQYSBbCoofTFU+mJA0YxGswxxgwXe7iMijhR8GEGv6YIEOFwZB9iCFN uu6aCba8j2BBcJ3a2F8VxUsgL7Q+8dRCd6fqUPqkuL296Sr9velOC91p5h1mBvbUmVxxD9Vapl0T oujaPI9nEbRdBP4aT9lOVkWUDEfxb2IsRIeYBr/IU2F0DIGHMOKvhhkCTQYiu2yGFANqQPoBOVyl VLfxshnrYgwQ42gTBjJsrBXI7I6+mDTKHINEHDj1QZCwahDKchBzjlNYtCtojHYMI7DQiIkhDUrq qw5WsjhxEsk1oJ04iN0lvd7ZaYhf8de+ER/3x/dK0nhu9TuFCVVw/a5CjkYDUvb9EF8DLc0RZQNf WoxHd0FDZZiktNpBIikDV9ikECYML/MKhkCh20KY0CI6aXFhq7jWnu9QYW2tL0t1ahV+leq18jR+ gQPiiC7WNTtJKwgx8k79Hwpahj+DZafIJ1sN66dof20t7H7/b/fVv7DWrZaY67ti3SYMtJL/RHQL TDsodgovQsK52MWgkDCBEI0kvRCNYchhpLPCkM7SVXtg6lcUYbBvYQbDLWDHaQbZHx8G4k2BWfyO MjoshSVIMgvsSDJsRERkfI4aZQk9gyDGwN5oBwKfBg27MAei8vZDRtWHEdcMgX2GHokP0GDI6IZp sgqQVmrps44kb3kDA5xuvxncYakEHKUvfzwNYPIiWVDSa7ZQGULLHCF+9BlBhKP/Z6wn0qyh7DHv TKXW28pQ/aTpDZLF/rbK6zkf0DT9eo26e/S2g32n//7+lqFDOble3ybCX0t3Lr+wv5JCuVytRbos eUH1qkVMH5XFzZFNxTCbC49YTISqVxoNhHwyFHOOSNxEdLXpU9oSFwRZVQzLKfIhLe2pqapBMgna QNQnrH5N0tMUE81HhK4Kxu+len6rQSuDlcpBlB+0kLBEJRX8IFeHK6kDYdjguvMOsEQIvkM62Cmv cr6IKV1sMsW7Q8IHQfXQQqaq8ZbmqI4pfKnkD+6dEQc44/rBFD6Tb4iKZVi7aRqCoEJwF79sIeFb 2mEH3RhukH7VTUELireQfpVw6EPQQNP1oEw6RDOIlOE7ojd9qnQP2tFAoYPg7IYL/hBvvCpVulhB UqJDg7CD+k3uq691ggT1gzjg9fre2qIj/t0sIkEa0JoI4RCc79Pt0k6r2uCBW6t6BBu9/cUl0F26 iEmlsO0n+l7IbByqfT9aRN35BjVLhSuFL29oYLVWuqW123S6gn+7II4UK9JbS1f/SvX/oiDghhfJ vt9L/eKyuo791qHEawl7aVO/apb76/u9L2Oo8NhaobSurunthK6r6TBKvrfr7YSy/tbWwZmD0tNB euvDCCf9thMJiEgvpOlvexCj6Z3g0LTVdTCJ0RMVv9Pa2E0IjIKNAl1QnAwv1yTtw1i0GEwmt5tI gop/tLVkWtBwwQrfEIYb11bcGCxMow5GwnurS6pvFoYKHWwwTfSpN9CG9OdA0r6fvaBu9kIDtpah L2E/cHhql7bYv2w3OOK9Jh4ftuIaptBPje7caw/CthsMLSu9u46t1dtvS+kw2+mvt2qQYV3DDd8a 8Nvq+3a78MG319v2uoZBK24r2/+wbduWkSK4YZHzCI7I4njUtxwIFhZdEdF8j5tF8g0aIvm3cOGO I1EIIQzwU54KgodBBCgi6EEHUOCEjHEGIiJtCIyh2VzJHadVDUREQxEtFfDg0mNS30DDey3UJ6iH 4ZOCnKHOPtUIiUZHRHA4Juaqm0IlOGYYRjW4nZriPcUq1yzAeNwvC1Kqizqwnwt0l3roUqoK3C6C 17SrJJoQ0wqjbLWWvCfY+mWZo+mW2W+lG2tQl+6XrpeiyKX2vg38eih/Q/lmDFmV/CePC9036j1n ZUuoulVK9VCXYXBrj//SLXB9sswrQw5ZgwM2FLMQDZyzlYQjojouCxwQiL8gzDmfDhkFdz1lL8U2 itBFnF2eMjgoI+GVx6HTIVDxNaERvaipaizfx0l0/td/Kmqow+iCjWxqn/sFvuiCDk0yK+E0If1s 5+kbKJjhDXFqJMcscpMlCrsQQwb1QUF0v9Xq0pTv6Qp/UN30QRH5KNXLKFr51gW8a6YIJJf2FaaM ir9poEiEHR8HT7t0GCFa9aQtDf1qu2gg/tlDwk3a3UlBb4rr132utu96tMtzX+/Xu3X1eNe0u2m3 +HdpUTh1T0ofp8Nt/Sdfq2/6f7pB7qu123SrosdK4a8W7CG72L9/S/1+/b/t/S6t1fLNFe/vfxq/ VOH8mYL+GcRhEsBReIkFESbT6xQ3cjoyn+hqpZyvI4LRcKJZTNQ4nREfI4aYNDUROZtG0ew1xERG vLWNVdaj+W2GuN62qW71v/yAkJrj/T+t/2vC3//vX35AUJVMliUYJcEF0C4QLpdL0sX5TKWq9x9q n/rf8ySfpY5ZgOMByOLyzqQOfBV5ZwQDy8PSd5Bn50yyGSkGXyiNxRGcgYGtSzlHNvFfrLWEKV+X jjF1/8LXe/r+v2vyCP9IOvpmqv9lA/8zwSr74RH+uOEC/pILvpUnfSSrWl5ZRip50kksfcNK/1DS /4bNVCC9dtCgT/thIERRxw3toQnpbaLHCf7hKCZDj/toKEwVdWOYYc+ntCP9hd/9f/T699vRY76W k3eZ+k3WL8N9rSh39W+vTff2/6Tf9IMP/tvXSYa3SSDb19v+kH//10g1d/Hrp1df9wr/T/FfX1O8 BCOu5VQ1CzUpXolCMArjC5wZuI4Hj/Bx3LKIQxXEl0vG+GQPDcc/FOuWcLDXcQcmxYi39cs5IjZl 0R4uxoRK4UuIiIiJbgahRvD0v+WuB/+P9S11hcb8ppUVSzVlfEfa+6lmpS4/W9W/W9b+t66/p/w5 bCqq5KVstcyQjq7j7+E9f3ruzjquWnUsXzIkpx0WdKDLHoWWdVBTtNlnCgK44LaCIPUeCnIZxwuE QhQXRbRHUVWVqd3SQIRGEW6l3QJteKj72WcCnvd6vpt/27v7/X7/TlbBLdgvoghp1tB8PpsnmFVR y0wJQ08t7rCegvG+P/IellshS+g0lWRVB9s6aWMftVWih+2qC8Xvqv2GgkEZ/Dq3qYFurtqhSLdU lvQSWWoYUN4bqFVj9jQLqF3kWr69lDlCF29oRr7tj5Q/8tdUVDu7H999PqTY1XLH+h1b/pN9v366 V/9v+k30cfpd2Olevdd/SdrWkGvpKKdFD/e7aWW2ar1WnvrJstKr3WvWh0kFrxG9/+F+/01yzBTr 9yvC/aj+V1BjpSJKgwryHHKsqsFZHRhF0Yy+YBcdsSY5QGIiQ2JkFaLcmRvYi+W4MNl12eaumJIy OGkR4wjUVFD8TWhEb2NS3j7hEUjwnUKEwytMPY9VqD3lctVfHyLDrwg6+n6ta719CvbWoWu6+lWq X/2V1RBLuE6rquWyOi3C1yuDwmlqNK1g8belILjNbShv7Svh9b4I4+Gk7UewkDjXSKsJqHCGD2lK +qCs7ir7X6vTC3tV1tCvXafREH6QV5Q7Vs7C1XSbHVJNlqoVC6b7hcj49BMWdjTKmDH9MEQLgNh0 EHslQatQrbaIK8hIpN69dkSDQRw1B9O2EQX1IaYDBbpttSERcMwshpUqdtMQysB1fe4YlAbK9NPZ Kg2XVoQ3PzbK5KGaR+rY2JDCEtRHDBXCgZRpluLIxng0m2GJ4KVygCykW7oiAPEYZKUDDK42DSRw 0sw8rgSLxLgeDaR0GGIYZXVhlkIjeRwfGhIQct2HBsr6ZcMwjoz8TgW0hGw24kCAyiClHOPTBw3I MLKxaIHgyjtt0QpoTTKk0iB4O5WFTKJ3Yc2/VQiB+aO3+qIo5Q5hyGdzjncw591lw3bS+GVL2235 TAWoOLbv4wRT37/He9r222+u9w/yh7eHyL93d7wg6pNv9/7e7NBF9vDwdcm60tvpmS03DySENbbC nYXlxTYbDoDXwT98HOwZngPBt9P+mdnA8GdXNn38qoLkzA8FcjgYXC9W9ENg5wyoLORjkDwQcjQV BDBgElH/tCIiJDVsibAklCyvP/yB4ZWyWlWVaq+2yB4g5pD0oVCNfZHZBUkEmmkv9uEyRgqQ1s6C GZ/r0sbhhIEL7+oV2wmC/d6rsIjcSGHf11DKHC7CCkGIvddaEXY4KHaUP6WwoKK679tC/erXr/9a Ya6rr7XeunTHLVL9u9JU8YRQ9LSbRK3dCv6/vVJaTf1+1b9lfRFDIPPI+jYjqvQbq0ZFpFOi4NRH ZHBWItEQl60vyC4qQwYITdiIiQUqinPBDQOTHIQhaWlfRBqwlAkNmFIOOcCERESBEa9W+xEREhjx qlFN9DpaeoaWq7yGQBuOVBBQTO5EHJhm1VLT3kkhDZZkEG45zkD2nI9pCGWOTHK8pyY5GPVJXqoi IkIi6I+eRdkcM0TsLQiIiaBYVY/ERETMGBBpUq+ZJ8ubnRJBBQ+ojjQX+kqCq8odVQWvHqCVUVyh W1oIJJbrShBVj0kgSp6+EEwvqoSHvSQIF9UggRXJO/SQIJe+kEF87WVpYQSD4gnhIIFBtw9UCTId TD0qRdBAmQwUh/CDLoKY5DKByzrS6ojhiEQT0DFFkdD0gkxBC0MLSQJAwV1Qgi3JgrFzpUgi3Eg0 x6SCLcFAgs6WvpCPSRDOmy0qQ2sKQwA2sOMhQGlweYcocFK5FiI47/117dfel+WYHXCDqWZ4e2vT r6v1v9XrwrtQrXgtD4NwRT4pVt1v/CMPLMD8ad04bQcJLlO07rX0u69XkaaEK1w+UPHHeuUPv5kl yx73ryzi6yh0OO8J2ibma48sxF0HdPp9ffWvXugvXroKsK3VYWhImuP9Yf13fVd//W/7W////WHh K/3S99+t/6//+9faqWdTUONeWQhFcVVRH3LQCdX4//3r/epahO2n///eupZBdFuBxvIT7eEJIZ+I J3XTztTXrg/uiC47sbp/15C/v8jQtvwn/k3ooQIKqqIgv8s3EF74Idesx/4uu5ZinXfUt1GdrECs hbfw0k2W63hUCCKi/xGwgpMN/vBIeukw6D7cr0XYQREgt8Qih6YQRGgTuLKHtoIgVBJce2ow7yud YbPiVmQF8duEljyuQtwsL49oJhJfDEJE16srkLaYIjr9tCLx3u/26+n927lmCEEe3wRT3b4phW/g k3yuhbVmFxcJMX8K19Jv6X8K91Sf9Neknb9D+qqwu6/heh6lmqqPB/lmmBC4aZEzMAhHfyzQ2eAo IgNouiIyOBBHP5ZnmXZHUSB4bjiIiQ0aHH8s8RgUwiPEcHLgpginEgeCyOPIvlDkGHIKGVIVoccr CEHERESB6IKc+GHEeIiQK3KGEGDcuQz0EREREeIkNg5OZDO5IuQUDk2/lFynKs45Y5hxILaL8REh hzDiQMLqaPgtgbkfJQDSXRjOuXA8MyxEgeIOVBOzL0KyRwWwJxIIC5HQiJODcjmdcjhrYiJFJkCI KkGaBGUswSEkjLoRM0XDMsocgrjlDncgoHJDlDgy6JANpuO1QDMKIiIkujlE8yOIbjAhHQiaBgRZ BpHERIYcgw5wMw53Ks2HwpwhGIiIhkgZBQQU5BrsocREREREhkY5DA5OCBA5FHLshkAofERNRCZg 0FCI+R8zBbBZNmYRjI+YQiIiZhmHmR0R0Xi6MMuB4y6GIiIlQjALYZhdCIiJ2oxERETQQj5HZUIx FwgxNSNmYDJDBPn88jcIoqCk0rETMNQujAORwPBnI6I4pHyPCIiIyyEjNhyPmEJqRyI5EdEcy4cj sjxHDUI4KoZThCMRERERERFlYQYdkcG5HRgxGJqzpHViMRH//+WcDUcs6ko//+V0tFkAlEm4VDLP SMZHRHRsyOrloS0KiKKAYBCIk3UlE1KZGeN4////+TZH/u1H+ZE1H/lMk694////LUE1LQI/Yx/l Nl+CdAqCwo/5aoTk3JO41H/KaJrcf/8tCdR8swDOP/5aZZ+P//y1S68SbT//om4vxH//8gKqqj/L NCLnZfjUf////////////////////4AIAIANZW5kc3RyZWFtIA1lbmRvYmoNMTAgMCBvYmoNMjU1 ODcNZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAxMSAwIFIgPj4Nc3RyZWFtDXEgNjEyLjAwIDAg MCA3OTIuMDAgMC4wMCAwLjAwIGNtICAxIGcgL09iajggRG8gUQ1lbmRzdHJlYW0NDWVuZG9iag0x MSAwIG9iag00OA1lbmRvYmoNMiAwIG9iag08PA0vVHlwZSAvUGFnZXMNL0tpZHMgWyAxIDAgUiA3 IDAgUl0NL0NvdW50IDINPj4NZW5kb2JqDTEyIDAgb2JqDTw8DS9UeXBlIC9DYXRhbG9nIA0vUGFn ZXMgMiAwIFIgDT4+DWVuZG9iag0xMyAwIG9iag08PCAvQ3JlYXRvciAoSFAgOTEwMEMgRGlnaXRh bCBTZW5kZXIpDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMTEyMDcxNTAzNTEpDS9BdXRob3IgKCkNL1By b2R1Y2VyICgpDS9UaXRsZSAoKQ0vU3ViamVjdCAoU2NhbiBGcm9tIERpZ2l0YWxTZW5kZXIpDT4+ DQ1lbmRvYmoNeHJlZg0wIDE0IA0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDAwMTYgMDAwMDAg biANMDAwMDA1MTgzMSAwMDAwMCBuIA0wMDAwMDAwMjI5IDAwMDAwIG4gDTAwMDAwMjU1MjEgMDAw MDAgbiANMDAwMDAyNTUwMCAwMDAwMCBuIA0wMDAwMDI1NjIzIDAwMDAwIG4gDTAwMDAwMjU2NDEg MDAwMDAgbiANMDAwMDAyNTg1NCAwMDAwMCBuIA0wMDAwMDUxNzA5IDAwMDAwIG4gDTAwMDAwNTE2 ODcgMDAwMDAgbiANMDAwMDA1MTgxMiAwMDAwMCBuIA0wMDAwMDUxODk1IDAwMDAwIG4gDTAwMDAw NTE5NDcgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSAxNAovUm9vdCAxMiAwIFINL0luZm8gMTMg MCBSDT4+DXN0YXJ0eHJlZg01MjEwNw0lJUVPRg0= ------_=_NextPart_000_01C1839C.315F23A0-- From owner-ips@ece.cmu.edu Thu Dec 13 12:38:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24903 for ; Thu, 13 Dec 2001 12:38:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDGoUh13361 for ips-outgoing; Thu, 13 Dec 2001 11:50:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDGoRZ13353 for ; Thu, 13 Dec 2001 11:50:27 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA112638; Thu, 13 Dec 2001 17:50:20 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBDGojr149858; Thu, 13 Dec 2001 17:50:45 +0100 To: ips@ece.cmu.edu Cc: Sanjay Goyal Subject: RE: Re: iSCSI Marker questions MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Thu, 13 Dec 2001 18:50:39 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/12/2001 18:50:43, Serialize complete at 13/12/2001 18:50:43 Content-Type: multipart/alternative; boundary="=_alternative 005BDDACC2256B21_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005BDDACC2256B21_= Content-Type: text/plain; charset="US-ASCII" Sanjay, I understand the login issue and will send a text that takes care of this soon to the list. Dean's assumptions where wrong anyhow and assume the same knowledge of login space. The new text will say that the first marker appearing after login will be placed AS IF markers where in from time 0 so that the markers can be placed without knowing anything about the login length. Julo Sanjay Goyal 13-12-01 17:19 To: Julian Satran/Haifa/IBM@IBMIL cc: Sanjay Goyal Subject: RE: Re: iSCSI Marker questions Hi I would agree to the way Dean had thought of where would the first marker be. Assuming marker position is independent of Login phase, marker interval being 4k and login phase being 11k long. the logic, to find where the next marker would be, would be either multiple additions until it crosses 11k OR division of 11k by 4k. It still has to keep track of the FFP TcpSeqNo and start TcpSeqNo to know the Login phase length. I think the simpler way is to start marker after Login phase completes and the next marker is at FFP TcpSeqNo + marker interval which is what Dean stated. In this case you just need to add marker interval to the FFP TcpSeqNo to get the next marker position. Please let me know of your views, Regards Sanjay Goyal -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 11, 2001 7:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questionsLink Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. --=_alternative 005BDDACC2256B21_= Content-Type: text/html; charset="US-ASCII"
Sanjay,

I understand the login issue and will send a text that takes care of this soon to the list.
Dean's assumptions where wrong anyhow and assume the same knowledge of login space.
The new text will say that the first marker appearing after login will be placed AS IF markers where in from time 0 so that
the markers can be placed without knowing anything about the login length.

Julo


Sanjay Goyal <sanjay_goyal@ivivity.com>

13-12-01 17:19

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        Sanjay Goyal <sanjay_goyal@ivivity.com>
        Subject:        RE: Re: iSCSI Marker questions



Hi
 I would agree to the way Dean had thought of where would the first marker be.
 Assuming marker position is independent of Login phase, marker interval being 4k and login phase being 11k long.
 the logic, to find where the next marker would be,  would be either multiple additions until it crosses 11k OR division of 11k by 4k.
 It still has to keep track of the FFP TcpSeqNo and start TcpSeqNo to know the Login phase length.
 
 I think the simpler way is to start marker after Login phase completes and the next marker is at FFP TcpSeqNo + marker interval which is what Dean stated. In this case you just need to add marker interval to the FFP TcpSeqNo to get the next marker position.
 
Please let me know of your views,
 
Regards
Sanjay Goyal
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 11, 2001 7:54 PM
To: ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker questions

----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


       To:        IPS List
       cc:        
       Subject:        Re: iSCSI Marker questionsLink



Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 

> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).



> Thanks,
> Dean Scoville
> QLogic Corp.

--=_alternative 005BDDACC2256B21_=-- From owner-ips@ece.cmu.edu Thu Dec 13 12:43:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25090 for ; Thu, 13 Dec 2001 12:43:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDGeFh12482 for ips-outgoing; Thu, 13 Dec 2001 11:40:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBDGe9Z12471 for ; Thu, 13 Dec 2001 11:40:10 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBDGe2x05179; Thu, 13 Dec 2001 11:40:02 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBDGe1Q12541; Thu, 13 Dec 2001 11:40:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15384.55777.108657.692182@pkoning.dev.equallogic.com> Date: Thu, 13 Dec 2001 11:40:01 -0500 (EST) From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: Re: effect of initializing CRC reg to 1's depends on implementation? References: <01A7DAF31F93D511AEE300D0B706ED920CF757@axcs13.cos.agilent.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "vince" == vince cavanna writes: vince> In working with Luben Tuikov to document the math behind the vince> CRC I discovered something that surprised me. I intend to vince> study this further but hope someone can save me work by vince> pointing out that I am wrong (or right) and offering some vince> proof. vince> Consider two ways to implement the iSCSI CRC with a serial vince> divider (see PDF file): vince> 1. divide the message directly using a serial circuit that, vince> when its stages are initialized to zeroes, simultaneously vince> multiplies by x^32 and divides by G(x). vince> 2. pre-multiply message by x^32 and then divide the results by vince> G(x) using a serial circuit that, when its stages are vince> initialized to zeroes performs a division by G(x). vince> The two circuits, of course, produce the same results when vince> they are initialized to 0's. vince> In the approach in (1) initializing the register to 1's vince> appears equivalent (produces the same quotient; same vince> remainder) to initializing the register to 0's and vince> complementing the most significant 32 bits of the message vince> prior to processing. vince> In the approach of (2) such an equivalence does not appear vince> true! vince> This means to me that it is meaningless to specify that the vince> CRC must be initialized to 1's unless we refer to a specific vince> implementation which we did not do in the iSCSI spec! What is vince> troublesome is that I have seen claims in the literature (and vince> in one textbook on data communications) that initializing the vince> CRc to 1's is equivalent to complementing the most significant vince> n bits of the dividend for both implementations. I have also vince> seen the same claim with no reference to an implementation vince> (e.g. iSCSI) which would imply that the implementation does vince> not matter. I must be sounding like a broken record at this point, but I believe the answer is to use the Ethernet spec as an example. The Ethernet spec has the mathematical definition of the CRC in the body of the spec. In other words, it talks about complementing the message, multiplying by x^32. dividing by G(x), and so forth. That definition is unambiguous. In addition, the Ethernet spec gives an EXAMPLE implementation in appendix C. That is not normative; it merely shows one way to translate the math into gates. In that example implementation -- and NOT in the mathematical definition in the normative part -- it is meaningful to talk about initializing the shift register to all 1's. I would recommend using the same descriptive approach in the iSCSI spec. It may be possible simply to copy the description as it appears there (with suitable alteration to the placement of the LFSR taps, of course, for the sample implementation); I see no copyright claims on the document that prevent doing so. paul From owner-ips@ece.cmu.edu Thu Dec 13 15:18:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28534 for ; Thu, 13 Dec 2001 15:18:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDJYSt26970 for ips-outgoing; Thu, 13 Dec 2001 14:34:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from glatton.xo.com ([207.155.248.78]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDJYNZ26952 for ; Thu, 13 Dec 2001 14:34:24 -0500 (EST) Received: from rooster ([66.89.96.162]) by glatton.xo.com id OAA19588; Thu, 13 Dec 2001 14:34:15 -0500 (EST) [ConcentricHost SMTP Relay 1.14] From: "Dave Francheski" To: Subject: iSCSI Text Request Date: Thu, 13 Dec 2001 11:23:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C183C8.909890A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C183C8.909890A0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Before full feature phase is entered, is it valid for an initiator to send a Text Request PDU for parameter negotiation purposes? In other words, are only Login Request PDUs and Login Response PDUs allowed during the login phase? I believe iSCSI draft 9 only permits Login Request/Response PDUs during the login phase, but we've noticed that some initiators violate this restriction. Regards, David Francheski Seven Systems Technologies 575 Menlo Drive Suite 2 Rocklin CA 916-577-1281 davef@seven-systems.com ------=_NextPart_000_001A_01C183C8.909890A0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Before=20 full feature phase is entered, is it valid for an initiator to send=20 a
Text=20 Request PDU for parameter negotiation = purposes?  =20 In other words,
are=20 only Login Request PDUs and Login Response PDUs allowed during=20
the login = phase?
 
I=20 believe iSCSI draft 9 only permits Login Request/Response=20 PDUs
during=20 the login phase, but we've noticed that some initiators=20 violate
this=20 restriction.
 
Regards,
 
David = Francheski    
Seven = Systems=20 Technologies
575 Menlo = Drive Suite=20 2
Rocklin=20 CA
916-577-1281
davef@seven-systems.com
 
 
       =
------=_NextPart_000_001A_01C183C8.909890A0-- From owner-ips@ece.cmu.edu Thu Dec 13 16:46:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29877 for ; Thu, 13 Dec 2001 16:46:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDLLvs06532 for ips-outgoing; Thu, 13 Dec 2001 16:21:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDLLpZ06513 for ; Thu, 13 Dec 2001 16:21:55 -0500 (EST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 91B09600C46; Thu, 13 Dec 2001 16:21:40 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id 557434000AD; Thu, 13 Dec 2001 16:21:40 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 16:21:40 -0500 Message-ID: <499DC368E25AD411B3F100902740AD650AFC7D1F@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: ips@ece.cmu.edu Cc: "'Stuart Cheshire'" Subject: COBS Paper URL Date: Thu, 13 Dec 2001 16:21:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Here is the URL for a COBS (Consistent Overhead Byte Stuffing) paper. The technique can also be applied at the word level. http://www.stuartcheshire.org/papers/COBSforToN.pdf http://ieeexplore.ieee.org/iel5/90/16693/00769765.pdf?isNumber=16693 Jim From owner-ips@ece.cmu.edu Thu Dec 13 16:51:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00010 for ; Thu, 13 Dec 2001 16:51:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDKjK103146 for ips-outgoing; Thu, 13 Dec 2001 15:45:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from trinc.com (ipx.ipcircuit.com [64.170.220.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDKj0Z03102 for ; Thu, 13 Dec 2001 15:45:12 -0500 (EST) Received: from neelagiri (adsl-64-170-220-15.qpackets.com [64.170.220.15] (may be forged)) by trinc.com (8.9.1b+Sun/8.9.1) with SMTP id MAA16577 for ; Thu, 13 Dec 2001 12:44:50 -0800 (PST) Message-Id: <3.0.6.32.20011213124241.00938600@qpackets.com> X-Sender: pratima@qpackets.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 13 Dec 2001 12:42:41 -0800 To: ips@ece.cmu.edu From: pratima Subject: Few basic doubts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi all, I am just a beginner in iSCSI. I have gone through draft-ietf-ips-iscsi-09.txt. I have few basic doubts. I am very thankful if some one clarrifies those. I am listing them. 1) Data segment length in the BHS is not including the padding bytes how to reach the end of PDU. is it only padded to the nearest integer multiple of 4? Can we assume like pad can be maximum of 3? @3.2.1.5 2) Digests are not included in data or header length fields How do we know Digest is present or not? @3.2.3 During Login Negotiation PDU where Digest is negotiated What will be the digest? 3) In ISCSI Command format both W and F setting to 0 is an error. Read command(R=1) but further reads can follow is not valid? @ 3.3.1 4) If the Initiator Sent less than FirstBurstSize( negotiated maximum amount of unsolicated Data the target will accept) Why it is an error? Sending Maximum than allowed can be an error but sending lesser than allowed how it can be an error? @ 3.3.5 5) Residual overflow error why it has kept target can read more and give only what the initiator is requesting. @ 3.4.1 Pratima From owner-ips@ece.cmu.edu Thu Dec 13 16:53:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00053 for ; Thu, 13 Dec 2001 16:53:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDLf5M08212 for ips-outgoing; Thu, 13 Dec 2001 16:41:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDEw7Z04608 for ; Thu, 13 Dec 2001 09:58:07 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.00) id A09014D00100; Thu, 13 Dec 2001 08:52:00 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A1DC9120130; Thu, 13 Dec 2001 08:57:32 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: error checking Date: Thu, 13 Dec 2001 06:42:13 -0500 Message-ID: <001e01c18211$88487770$0102a8c0@eddydesktop> 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Does SCSI require error checking for protocol errors? The reason I'm asking is because I don't think the initiator should be checking to see if the target is in full compliance with the spec. (and visa versa). If the initiator/target does not need to deal with an item (such as the I bit on responses), then it should not have to check for its existence. I think the initiator/target should only have to check for correctness based on their implementation (e.g., where incorrectness would lead to ambiguities, trashing of data, causing a system crash, etc). If SCSI does not require this type of checking, can we make a statement in the spec? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Thu Dec 13 17:53:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00955 for ; Thu, 13 Dec 2001 17:53:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBDLeui08189 for ips-outgoing; Thu, 13 Dec 2001 16:40:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBDEw0Z04595 for ; Thu, 13 Dec 2001 09:58:00 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.00) id A08514C80100; Thu, 13 Dec 2001 08:51:52 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A1CF83C00F0; Thu, 13 Dec 2001 08:57:19 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: Checking the I bit Date: Thu, 13 Dec 2001 06:26:18 -0500 Message-ID: <001901c18211$7dc8a180$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C181E7.94F29980" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C181E7.94F29980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Is it necessary for the initiator to check the I bit in every response? If an initiator does not need it, then I don't want to take the extra time to check it. I think this is consistent with the thinking of all attendees of the UNH Plug Fest because the report from UNH IOL was that "all companies failed that test". I would like to propose adding some wording to 3.2.1.1 similar to "It is not necessary to check this bit for 1 if the implementation in the initiator does not need its use". Eddy_Quicksall@iVivity.com ------=_NextPart_000_001A_01C181E7.94F29980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Is it = necessary for=20 the initiator to check the I bit in every response?
 
If an = initiator does=20 not need it, then I don't want to take the extra time to check it. I = think this=20 is consistent with the thinking of all attendees of the UNH Plug Fest = because=20 the report from UNH IOL was that "all companies failed that=20 test".
 
I = would like to=20 propose adding some wording to 3.2.1.1 similar to "It is not necessary = to check=20 this bit for 1 if the implementation in the initiator does not need its=20 use".
 
 
------=_NextPart_000_001A_01C181E7.94F29980-- From owner-ips@ece.cmu.edu Thu Dec 13 21:20:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04188 for ; Thu, 13 Dec 2001 21:20:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE1WbB24375 for ips-outgoing; Thu, 13 Dec 2001 20:32:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from parmenion.hosting.pacbell.net (parmenion.hosting.pacbell.net [216.100.98.31]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE1WYZ24369 for ; Thu, 13 Dec 2001 20:32:35 -0500 (EST) Received: from TEDTHINKPAD (adsl-63-196-6-251.dsl.snfc21.pacbell.net [63.196.6.251]) by parmenion.hosting.pacbell.net id UAA28237; Thu, 13 Dec 2001 20:32:22 -0500 (EST) [ConcentricHost SMTP Relay 1.14] From: "Ted Kuo" To: "ips@ece. cmu. edu \(E-mail\)" Subject: ESP tunnel mode or transport mode MUST be implemented? Date: Thu, 13 Dec 2001 17:34:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C183FC.72605E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <001901c18211$7dc8a180$0102a8c0@eddydesktop> Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C183FC.72605E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit While I am reading iscsi drafts, I found the following potential conflict between drafts. In Section 2.3 of the latest securing iscsi, ifcp, fcip draft (06), it states compliant iscsi implementation "MUST support ESP transport mode" while in Section 10.3.1 of the latest iSCSI draft (09), it states ESP tunnel mode must be implemented. I am new to the list and would appreciate a private email if this issue has been resovled in the list already. Thanks, Ted ------=_NextPart_000_000E_01C183FC.72605E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
While=20 I am reading iscsi drafts, I found the following potential=20 conflict
between drafts.
 
In=20 Section  2.3 of the latest securing iscsi, ifcp, fcip draft = (06), it=20 states
compliant iscsi implementation "MUST support = ESP=20 transport mode" while
in Section 10.3.1 of the = latest iSCSI=20 draft (09), it states ESP tunnel mode
must=20 be implemented.
 
I am=20 new to the list and would appreciate a private email if this issue has=20
been=20 resovled in the list already.
 
Thanks,
Ted  
------=_NextPart_000_000E_01C183FC.72605E40-- From owner-ips@ece.cmu.edu Thu Dec 13 23:47:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08694 for ; Thu, 13 Dec 2001 23:47:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE3kw902634 for ips-outgoing; Thu, 13 Dec 2001 22:46:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE3ktZ02629 for ; Thu, 13 Dec 2001 22:46:55 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id E1834775; Thu, 13 Dec 2001 20:46:53 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id F070653F; Thu, 13 Dec 2001 20:46:50 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 20:46:15 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF76E@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'ltuikov@yahoo.com'" , "'Paul Koning'" , "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" , "'Julian Satran'" Subject: found the constant for divide-only circuit! Date: Thu, 13 Dec 2001 20:46:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18451.E095B6D0" Sender: owner-ips@ece.cmu.edu 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_01C18451.E095B6D0 Content-Type: text/plain; charset="iso-8859-1" Luben and I found the constant polynomial, C1(x), that makes the following two operations eqivalent for a divide-only implementation (attached) of CRC32c: 1. CRC register initialized to zeroes and C1(x) added (XORed) to the most significant bits of the message. 2.CRC initialized to ones and nothing added to the message. At the end I summarize my recommendation to Julian for fixing the iSCSI spec. C1(x) turned out to be the same as the magic constant specified in the iSCSI spec!! As some of us have explained before, the magic constant is equal to L(x)x^32 modulo G(x) with L(x) being the 32 bit all 1's poly and G(x) the CRc poly. For the simultaneous multiply and divide circuit we already knew that the constant, C2(x), is just L(x). We now know the equivalences for both implementations: 1. For the divide-only circuit, initializing the register to all 1s and applying an all zeroes message is equivalent (produces the same results) as initializing the register to all zeroes and applying the C1(x) input message above. We can also say that C1(x) is what you would add (not append) to the most significant 32 bits of your message and apply to the divide-only circuit which has been initialized to zeroes. You would get the same results as if you initialized the circuit to ones and applied the raw message. 2. For the simultaneous multiply and divide circuit we already knew that initializing the register to 1s and applying an all zeroes message is equivalent to initializing the register to zeroes and applying the C2(x) input message. So C2(x) is what you would add (not append) to the most significant 32 bits of your message and apply to the multiply-divide circuit which has been initialized to zeroes. You would get the same results as if you initialized the circuit to ones and applied the raw message. For those interested here is one way to find the constant C1(x): Initialize the divide-only circuit to 1's and apply an all-zeroes message. Look at the state after the 32nd clock and record that value, which I called C1(x). We now want to find what 32-bit input message would produce the same result when the circuit is initialized to 0's. I reasoned that, until the 33rd clock, the order of the input poly is less than that of the CRC polynomial and thus the current remainder must be equal to the input message itself. Thus if I let the input be C1(x), after 32 clocks I would end up with C1(x) in the CRC register which was indeed the case. Luben had a different development (see upcoming internet draft) that is more rigorous and shows why C1(x) happens to be equal to the magic constant. There are several ways we can fix the iSCSi spec: 1. making it explicit that the assumed implementation performs simultaneous multiplication by x^32 and division by G(x) by showing an implementation such as the attached circuit OR 2. saying that the CRC must be initialized to ones and not saying that this is equivalent to adding 1s to the most significant 32 bits of the message (because the statement would be only true for one implementation). 3. saying that the CRc must be initialized to ones and explaining that, for the multiply-divide implementation, this is equivalent to adding 1s to the most significant 32 bits, and, for the divide-only implementation, this is equivalent to adding the magic constant to the most significant 32 bits. Option one is the simplest, and the one I recommend. In fact, for options 2 and 3 we may (need to think about this some more) need to fix the examples. Vince <> > -----Original Message----- > From: CAVANNA,VICENTE V (A-Roseville,ex1) > Sent: Wednesday, December 12, 2001 10:06 PM > To: 'ips@ece.cmu.edu' > Cc: 'ltuikov@yahoo.com'; 'Paul Koning'; CAVANNA,VICENTE V > (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1); THALER,PAT > (A-Roseville,ex1) > Subject: assumed CRC circuit performs simultaneous mult and division > > Regarding my earlier memo "effect of initializing CRC reg to 1's depends > on implementation?", here are more details and a proposed fix. This little > detail has generated a _lot_ of discussion among Luben Tuikov, Paul Koning > and myself and in fact we have not all quite agreed yet on the severity of > hte problem and how to fix it. > > Where I see the iSCSI spec deficient is in not making explicit that the > assumed circuit performs _simultaneous_ multiplication by x^32 of the > message, M(x), and division by G(x). When the spec says that the message > M(x) is multiplied by x^32 and divided by G(x), if the spec said that the > division must occur simultaneously with the multiplication by x^32, as it > does in the attached circuit, then the spec would be correct. In other > words, with that assumption the spec is correct in saying that > initializing the CRC register to 1's is equivalent (produces same > remainder and quotient) to complementing the first 32 bits of the message. > > If the assumed circuit is the divide-only circuit that I also am > attaching, then initializing the CRC register to 1's, as the spec > requires, will _not_ result in the correct remainder specified by iSCSI in > its examples since initializing _that_ circuit to 1's implements a > different division than what the iSCSI examples assume. > On the other hand the receiver will still compute the same magic constant > that the iSCSi spec specifies since the magic constant is not dependent on > the actual message or its remainder but rather on the fact that there were > no errors. This is what Luben observed and what he and Paul and I have > been discussing (and still are) for a while. > > This is why I am claiming that the iSCSI spec should be fixed by either: > > 1. making it explicit that the assumed circuit performs simultaneous > multiplication by x^32 and division by G(x) such as the attached circuit > OR > > 2. saying that hte most significant 32 bits of the message should be > complemented - rather than saying that the CRC register be initialized to > 1s, since the effect of the last statement is implementation dependent, > whereas the effect of the first statement is independent of the > implementation. > > Vince > > << File: Scan_Fro.pdf >> > ------_=_NextPart_000_01C18451.E095B6D0 Content-Type: application/octet-stream; name="Scan_Fro.pdf" Content-Disposition: attachment; filename="Scan_Fro.pdf" Content-Description: BothCircuits.pdf Content-Transfer-Encoding: base64 JVBERi0xLjIKJSDi48/TCjEgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL01lZGlhQm94IFswIDAgNjEy IDc5Ml0NL0Nyb3BCb3ggWzAgMCA2MTIgNzkyXQ0vUGFyZW50IDIgMCBSDSAvUm90YXRlIDAgL1Jl c291cmNlcyA8PA0vUHJvY1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0NL1hPYmpl Y3QgPDwNL09iajMgMyAwIFIgICA+Pg0gPj4NL0NvbnRlbnRzIFsgNCAwIFIgIF0NPj4NZW5kb2Jq DTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmozIC9X aWR0aCAyNTUwIC9IZWlnaHQgMzMwMCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEg IHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4 RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/ luKKMs5Sv/6+8S1Frj5ZD1B7ruGvYVvlqGvbu6xblkq4cQ3JsakMEQRmJDtQFLZAIt1gM5Nsk7lu qAXTorrWWYCBSl8LZ3TtVBOpkqd2lZZMNKHLcsBpJRW6lcS8rqSYahFDpYRAjEugtP3UrgRkfQgk 6IP4R0SqOuNQQQkELCIaFj4IFBXKH1arSgnCENwgkWOFghCVKsyCldFdQGaEEw6IUNCKX9DWix4X hBI6kVLTSWnQQ0E8IEI/vaogQP24QKtJcr1eEQg5zlOU9AvS+13SYifVN0F6DI6Lpa1lDghCh6C6 K4jI4Zl52W76EJBdLtC+EJ2aojojt8ILvVYJ5miOCZkLBnUi6NrSS6S4KdoQTI4KHMhsDCmEhegk FevzvECEaDOwXUg+gQWSYL0l9fUELMltdkpDNNYEEuGjpJ9JaIKIKHP0mc61ogxwJQRAiKpJPX5Z AQiT4QpewiKOToEzjkIXILr5SomnevhYyDYOao6UWOVsrdrQsIiDRMmQSQ5Pca79eOiGpcbKRFOj eCKcb6hBCEyPhFDhBA9JIiiS/R3687hHqTcgvMEK+9g/WgqFCESnXrTW6BquVWylAwCCZpodBiIh sl6H3QQUFdlQtKoYXshgcperreSUFyOKO23pvrVBAlCw/VNBPQka59naq9cIijlDggsqwr711+oV Iixh/Vr4M7K35UJOg2avjggURHeGw07bRMeoQSC4JtA9LbCTwyDRsDB9Jp/0CIg4QilhhpKg+r+l O0Kudwa0So1ojoJcMMEyHkqO9s77W9PQQusPwXS5CjddVdWH4J0SokC5bgQZoTyKh6/CeVfp3CT2 4a3puyBA5xCr/UMPyJgitheW4qCg7tJphb9VyIDupBsmLCBf6osdqksSEIWlpLQb8Fq0+W5UGgiS I6I5prr+dcpPRG/BBqoJhEQYdQYbrCcqEw2lTMDdXZBqm9/wkw1I2lNTMZHQJ3YS5bhYYBBMSIMo g/8L+E10t09VTyOgqSXqDaqlfWG0tJUlVtwuUBq0xC5bkgcEL0CfRC2/1CaoLVdQmmMNNtW1pbVA m1WyUBl1a9JJA3QSImevXDaeiJVUIJrT010nwtKqba0giXq7DeiK6V9LIWGhQw+tJJ1Cq3INLvDC 4cJ2gh0C+tV1+Qj9V3C6WE6Ft0lVvSytAwgfartvSrCaX4NohO9YQQS/TC6C6CIo4nfqCIUemml0 m6tpJPT9ZNAoYNKsJJOqVtsF6VW0R6dKq2/VXpLiNZFHpNq6qjj+rJdO4SWr0sOwd9JIL8JuasuE rVbaCD6WEFa+iMeqr6Ix+lhLXC8UmMLI66CWt627IYGvhK/pEh1Yn1bhB90v00lf6deF6HpYQXSq 1SkI003hpLvnZPSfDIMJOkgq6VJux1QfbSXSpL7VLCIj9UlrSUJU7hU1XdBEdKhTVb66YZTvXCpL eEF3Wmt0EF60F/pYS9LeRB+lpdJohHXgusYKgrChvtJtEx2LD+ILC1QXb25Hjq3QS0tL/S0EvSqi zkUHpwgWieHVpBdNHVBI+k2qMwdhJfxWrYN+lglbgl94QJhkdLdQt+kv9YSfSrx1Q/HCrpk4ZxaT il0ruFhJhg3XCSCXYStg0m9i6rSTSS1+6tpLGtVoKQfTxC/LhlnEusKt+rCTZ0RhkCL0sEvS4e6h +6gqH6v6VJb12hpQ+FSxIbB9+wvr2nCCZCDlW974WCXhBcPTQTCSJsnW6CCfS0/7CXpe0wk68z69 eqhJr5UXZzCTEXV1pYILsJYYPboHSH4IKq19CtAqMdKvVUw0EoqyCgcKGLp0woWC5EDp8JMQtOIV kcM/ggtgyOiOknSBpZb6JNUktJfr+tBPpVV1R9aCGH1BLeCWagtWpSIIIMIjQnxC7CBZG0xEnrTo VoOIhP4V9qIWFyPfvVMNLTqQxp7DCYS0tlAYYTpKCCIQQjpaSYW2cDFArIZSEw3raCVdfqFFcetV VwlSBFDoNIFVMEPYSozAgWPSEQQXwXFWEmQzfsNqsOF+FPL+qphK3TVBhmE1pBBONC41BmAYzYbP MAhS8EnZY9kOKWE0QYjDvEILYQVOXWFH6/P1ZEdUrYmiZQ4ToER0MJ/DFYQJ4glBJawZMpsJQQQf BgiOlwYRHBDQKVwwwU3/wqx2yOgtBrgxEVCHVVpRTCaiQoF8eFnVBAgeoy6WyhwYSBkEKFGhId6/ TVfEGeCY0GFGO9wUhoHKkci7ghRJX4YLKARqoy6SsMJMmOUW+tK366DUUwg4aphC7CkMDghDPvzD mFv4Mocw0wgRlgIrGYVbCWO7C0nXa8WhEYQpMFiIjxWIpHAQy0RHNsGhQUMhnqTZLiawmNW6FrYW w2kQrcNY2iEX5ggoMhljhMMkBjwwSX47VUGCkbevxBA6cMVITltBket93BkLImE2GccFjwhOyODB RXj9CoaaoRXQIYNMKqrfEdcIFDIKFZAuoq1jtN5kIB5bigcNO0Pj0gogyCAfb0WP0oMkKQwl48Fj Qv+EFH+gt99EO+9XhAltdYS4/hBJfVEVCr637oJV/QVd9BLybAaXS7ST0gliNa5aFv+goXtrTG7w u0KpGRJ1rHapUqW31rS6/bS+t6S9/0vpe/ul7SsLSi2FxVrUMLwwrUf//ICDC8TNR////LLnyyDu JNw0Yy6IhEdJy0iUzMG0RrEgWOWO8goHEXRCjnMFwUOiyhSoIREoiODceJTn+/+/nHaxfgtb7OP4 /6/yCfyVCdtP8Nff0SgP6Qb/T+yGat906rlnM7bBHHheV9YxlkIRcUjg1FxkfI+XifIaNo2vQsJe JGbmZTiOIiJEgRJ4U5Wyq6FZEw0UQ2G/mHIYg9RxxEg0j0GEJHBMcqCrPhW6eW6zmQw1S1KvINA5 TlcUbJDedzPkY5Q4kUcREREREhRyY54IQqurCpCG3iIhnER0aIzRhE6KdHYPNikdGRNnXBCIiIiI iQ2Dmc4Nt8JNMaERERIMDkLhhyhyMrMOQg4iQbjleV54NqVBQZhyK5dkWCgZ/ESB4NQ5xzDkNA5V mHESHd2kDBNQ8REQZEoIRIKBxERIYcRHEREgeBu5ks45hzuQwORIJDjbSG2QVBzuYd5aCB4LTnHO OUOfxERIHgoHIMDljluQQcg0uCERERE4B4K7aSyGmMWinAzBWoREnReNwmSgQjgfMfIZiZIyLZHA zAuiS6wXaaygi9xJhG0XjNFwPBXMBkAykdBREl0RwII5NYjxERIjMIwjaJw0y4IQNGMuDYYRdEeI 6I6Loj5xkdkdlxCOBgxm0IiPSXERE1BliIiIiIiIiIkNCP9TLVH0NIP4j/9P6olAfrS/vQbrqla/ Vv/v10r70rf9J+qpaWumv6j16/tZZalqxx99f/68suv9IZXtf4avll1VD8a+UK1kCy4MniO8ItUy LyDaORcLHM5Djq7ZHQZsK8lBQ5blCSFbYiIiNIO7p1LM5G9qSHk3SehEYQd+U2GRHtyBY3K6yimK gYSdeIIGuvCf+4dKncswIgibh3S8E86IwExraDUXrpQ6Da1dPb1/tv9NN9LeRsyuWot1XB3X/2g9 167SmRZewwevj3e4X01rTfreFqdeEr18NKt7v95xwTnaVlzgl7t/YjnZIiODpJf3XLOp6hCzi//+ LhU9Un/6hPSq/v5Zhc8EQT/X9v+HwXep2ru+qO67lkSJPhBLWgT7pVCe1VwgQQS0oJ/+SMLybBcO mkfD2uC9LZ13TQfJsWiKqCYL0jsPCBNP6q6kGiPkcJwTSVIfzuYEJ6uEsGYbKodEpwz1JsLAxU49 K/BHHIOBotwdfpaDKuy4e0+CSS9J9Hbgw2ED1/ZEB1RoOPUoDLtBBQq0ulCBZXFY2jGE+lBK4MXE dQuybGAIqtb6CIUcFZhG2V6kXqI5QyPhdSDD4JUDBi2shodcEFBC8KlwkpBouCoQehFaGpqd0awz 66BrIkJEMeuEQXZ/ayx1qEQjoULJBBMIqAgTnfqnqSALxVomOG6SpLwQWl/UENF0CFIQhET+t0l9 bB36IVHSBdd/UMK74TusggbLDhv1hBHNquFpdekyCoPCIWQISCiLi9clIGOzML0rC9wX/rCJYiOR gQj4gihwkCI+kJOk9LIogQX2xC6HoETY0el/wYiGEKEIKISBDcJMiPBCEuG8Iodflm47+P2QilBA sqL/l6hIJrD0hX1C6+lIYLUkSoMFAQlmlYSa0hGlw+q9L6+2QzlGCJSGgIGRrI4iCVQ+Fp/iE9vC /XTIFxKEgqDKsF/CUiQtBMjc9F2Fq9Jb9eyGWBUEFCgoVVhDpQRHQ2pjcE6vyHNlhr94YeEjVKiE HdVhOsJCPSUV+0DVtL6O0Bs6VEIORR0ggbCIOO9aXQXHSCfw0/p87EB7SthBQ0MEDqwiOqwsNsJb Trd7/9TtWLQQWkOloh4EIKKhJEY+QfYJXS2Q4QPp6nTwkuG/UILhBYJAgXSSCtMgRsmUHCC+Ek3s tzN3TrhXwfhKmuXDOlYzjwoS7uK6DCDvwrJzKHcJb1+1CSULCrBB6SBJLg7gn4VB+kj1ZEbg+4X3 4QVJaaSGKBQgqYcG0rQMocFUPluUajhnbpKqlf+lC3ao9qCQJUGDbBLcQwWndBwnH7Cf1pBJJVZC jEE8oDScigMBsEtoaD9tBfuiEH+u0v844IjrCBMER8EFg8Qsjoe6tpL9ggvdaUFpXERYhREhoHCa B0rV/aSWsMJdWUrQXgunsscKCSEHDC6+w1X2GCT6wwnpJa2EOCoHYVYLeGktUxC8Ow0vBcEnIGDs JhCGcc21rlXglsN0lrCTtWDBSMuwRBd8cME5AhuS8ECid/ikqphMO2wYMui7I4I6xCg5BgfZGBTg oYK6EGginWw510hwwqS4iIUbBQTuwZODkdWDKNnpiPDtIMzCA0wX4aahW6hiCFsaoah4oTtQFe3B hcFULph3+2hGs7oFDsLDVMg3HCeu8NgnbHDJp0DBbKHCElyutoOEvio4sh4/9Ex8ImxgMusXyExd 16QYYYImyQNT2sT1a/WxOwXPJAyky3UluOwyXCf0g52lBnRBV0BWg+uGEv4SbRBqwpc4jFhDhhmA b/0g2dqiRDWXQRpGOxIED+ulZ2LtUQ2xyhyl4k6JcMsuehX9IOgwRT2IkLZ5KsQyGgcLw7/S3EWK sjoigcawyDccL+guGGQQgOhFvJYC4/pJ3hmoGuF49VSphhsiMjsjxHDP/vsJC7DERPAx6/0FZrCA 3/v0m2ww/8dKG2yVAhIX78ILBsloUf36Tbgw38eEru16qk5dBwYa/dBWL25Ci+kkHsG8JfuvDegv 8K2w3oL9NPvoKu47bela8mwsZHRsFDfqRvr+TYbBtI63baVJa5NhGbAnI4pfBFP9VXupNkZHA8FT 1CSXVwQ/Ck7/6cg2EfIzLo2KRx+kl/RDMEnebBTNoqAQ3F0YzwIRxFtfXohnU/DQkHcRERHaCrNh COdWpHtOQIi7Ebf8SGGgD1ZWwSpVFIZAZQ+1WpDTaC+2J2ULyFYyGeZUHHPZTnsscbaXyBuOU0Gv j6cjgxaQaRyvKIIx/VnBeJEZVQq+r06EraI6MIxiIkSEYathB9rW1e0xERlj2KjzQGZte1Tv7+Rg MsVfVvSetSJg0v19qErsLFr/uOHhOH7X0vLwrSP/p7SHquqXdcN/Vd7wq6j3S2QpuCLSdEx3vCap JKretv0tIN/K/ho0kurF6pKvba0/SbSfr6SpPluSq6SQSaoPrRcfQWvggQ6sjxlUj8eyOiPEP6ST 60FSQhkci8YyPmES6JKZHRcM5HBmLjKEuEqSFR1EREWXBcSPEdEdEql0IiRjlLwlCCunrEhx2EUO OQg5WEQcm7BCJA4HEhJLektUrow4iIiIiIgwloJ1fxILcOYoK4iQdyhyKOXtOazxUJdL0Q2Dn87k DwbMKHIZg5xzDluRuVYkM8Hc/CIiJCufyUFDkoIYcococ5BMcR0Ev7zQhEjERwOCOBAiIiIkuEI4 ZIF8JbT1boT2VYMEePoTWjYZMoILq+hQiIiDSQSx7GDIZAMo6wgrrCK5KCkdQPDVI6D0Eqsm4xaL cJEcysRHBcp8jgwR0OmECv7QiIiI0EjUGPHSSQIF9tQkfDRd2qQp+VyERxqEQ0lz3j0gmRFl9JBS DBX6yGWuIH7kM66R/ZBFxJFuIXaIjK4nWPgggQlcCwqJDlDk4IKVyOuIjCDCEToj2bGYxHhxERHr f10/jyziSLIBriSyBMtArcIMm5QJd1BFDvqmhkQiXSfLOJrW00HxwSvhGER16JukDQX10hEm4KvQ QQXybkvX0kl8ydXj2gRB4HenVXYJAn1XTuIIJEV93rXJudQqpAiOqWr2IQJxxqk0ugltevlmaOFv f9sKgvo7F9KER87Jx5EdGP61+diaREroQZHkRR8WvJsDBcLC9QQ6CEM7Qgggtkcu3DUEvztIBGW5 aGwEEIaX615bi16VAuRTNoEQ0PRFcRFdbotxISvVEGB5myP4UECUyBUdoDNBNmctyk87Wa+kCaX4 JDEYIY5JUagLkdozluKEbOy0V9hlj2ECKHD/0ChlEbRHwibhEdWdBwYQQoRKdKEFmQqPiZmwkOvw RDjnHBMQbhMRI0jp6DVhIiDxVFoYQP0KhdaSEYhBMIXYTtEIOYc49AgUdRT6haS1hUgRGgy9NkSb G4rN5g6JEaknXUqEvTggRFgy4SmoZA/VBjVkdYTsiNckCJ3oIhjoV/VBMLChEEBkJuKa2hBkdRFw ZSL0H/SUQl+ggYKlCDBEx+FTqIeCa1nwYU3EdV0C6hfzQdytAjrIg3HM4QTBFjjdZId8jHIMF3Bp +p2BovyP2hJNzWtBL69Yj2iEEnFKiHtQgfiHYQelpnasEQQdO6UEklukw7QSaLHKFaVQnhEdPhh5 w4dkPuwiCDndhENANRe8mwo4S6ryHKaWmQdpWlca7DiCh99QhwQNJa4Wgtfog3GvUJVkUcodKgtQ uDJjtENl0S447pOtJsIikQt6LcWyNaSpJKl7IZROkqSdQUQohJUFxPhioKhvtWIToIpzpGH9MLrS Wvl0w/XCVUgRHXxSUod0CpMPBcMK4WqUli/r0EqXxYfS5rCpWo0p9JKJ4SHSV4TwkoIJJKoaVbSp arS9tvCSQLxVKXYpOHiqDaqu0kqLHinXsJbWkq+dgwUUoK2ZhogoWg3dpLbwXS4ShJWPtpLQ1hez tJEcH3CUdXVtK6XuFqFaSSVJe0sMIJUqdEDQnhNQSaluU5lDrQLVkO/Cx7XQSCC5b+2EqFLTqxlP TjrEfhQs7RpLSgqIZx2qVJAoJJb8MNLrRFf4h+pBRG20oTXatS7ufDOgnVpcEkF/9BJILS699kCP w2HoKFWEqcImOghsJB1ThIFCXhrhtXSUEvdaZDOPRBxwSsMl96ceiMCYoU1h1aWkgSSw1q0h9Jr1 4XjyC+HsFVwoXYUGlSYK1Hswi4Neo9sJJYQXqdowtwoMeLEW6Hhk4YrYSTFJREguOFv24VEbsJWe t8p8JUwu+92Qg6WEwmCD8JpJbtpJFJBFD9Lr4ZIBhWC6cO4xCqpDQnTXBIL6sVmjQimwlrtsj4t1 jVMF8p1UKCggqSIMICX9ZdEcJ6C1+wRQ4hfsodBxGQIHC1DKHCEMEsgg6YKvtRGFwS0kuIljgusZ McOwih0I0IYLQUkOUOEKC37pwohRtOxTVYsqChw8QYIj9CGsRGqT90tU0kd1sjhxaxFkIGmUOU4Q sJqhVh+9qnGkVhTlbW3BgoiIjXD6aC2ChYiOGQYHjUMu6p0tY1HUQ9om4cFbCqwZh1XaUNwS0wko oQwukG0RQlhDbsL0w2FQ4MEGTb9hJsmyRFzKMuiOjUgwvDO6HdNjiIhBCfyOGYLWI8JNqVCMAq01 0mGpsD2wl4SDBnYEokFNyN7C+k9sg2jcfhW02QwtL9BqyJKT3Fek3DJMWv8JrCIELnqTdUVdBDog YXu4/phyDSOeSVX48SCSC/+UPQP/7f9e279f8l4eSsLt8W7I6ZI7wg8s9NK7bFhGHlOiOiOD/3/Y TYicCdb9SbLBEcMozPxYdokDwyPcmxSjgLKbYb/Y7RNvzbM0byO0IvDdZ8tqmTY1AguB4aTbeQ5h rad47D8MINKg/V7vBFjinQXRA8OO217CQa/yBxxRMi3burCsK38g2pZCv120EGHjdkrO5D7V9vbQ SdcRM1vq2kt1G7bOqKgEI++lft/I4dEKOW4kLBrO5VZygqu2kiUfW8REREZHiOGWRwzCOCYYr+93 ETDiI6S84yOt/G/0hJpkT3b30k5DCZA/pECR7x6IGBzJmvu2QfQqDuYc8FVFQUOVhQ5nINY9OuLI 4KC77uybxERERERKtFSReI5kc+uIkRMAlqtOdhoREdBtcHd33HTDBZDArq/jybsbNQKV069XyXDW q6f0+Ol1pbfdV3Tf/S1fvr6Tf+lX/aS06Tde9ev9UurV7XXS+gdJJdQvBrpai8EGTdWBGlr0ybkA 0YStK6ZNgoyOy4yOGqkl1yvMGgmwkyOB4bqlVfJtQDwzaCVtfK4IZjMRpF8uyPmYLl0bjGR0bA8G 5gUJBLHJvV0GZCSI5EcQjowGCEDIBTSoEn06IKrlywziIiQUOQyAanJDlASChL4eJF4gw5Q5Y5IQ VZ1UiDiJDIBgcykkEEEuniIizCPAYBCQyAONkJQS8IOyNxEg1uXqQPBsGEoLHKcjcgkFUKHIfZhU EF6dqIkNXjcWMIMSSwgkEE/JwHdENEFjkMgFC61SNQZ+1h+EJnmA2GIjgeGsYQSokA3XoMGWkNvF CT4kYiNhtDCoIJ9IkDQZdcRBkFDkm9SBIzAvlYDRhs3oehFI2ggyOBjJUGlUHp6Q0ILIECqrFw7V ILNYFFBu7TSINK5xIa45I3GQyh0TZRyxyY4cNQUhlL6kFQcqCnM5S6Cl09/BiDlcYKTcTUg3UipC ZBrBouhoHMljFQ5kWd2fQhhcCIaHKNzO90G6lepBFDxDMzpT/BlDsbGR0LtePDjQrv/p+3luJLfh JTIK0Hvf9P/+nf9eq/nYrdoLDKbk+7giPql9dPvotxtWP9fQSvdq/6v9/6f/yMXvV9+x2rW+unp9 GQju+3/6h/11mRHpWdlOv+W/0/tMN/6da9bI0ocP99/9NhSNL3//35LR6ZEI2NB3fVf39NhpAhD3 XT3/baqGwSTu33v+/SbYSW4f8hSI7rO9ApHWtrhO0CkSdFj2/uCENNwhD/dJMjW2CokRVw/pQih3 2EyOFf12wiNQE3u3e7CG+ELMprNr7CcMJ/h//fUij0iOiOCjUiSCInbY/W9yLslWaruFvQIoDOU6 JggQiD9NW0DhU3SV5L5PhELZwNheq6cES6I4iYQMIOyR8QnRIciGQSfpg3oNC70/r0EhfTXykVJO Eg3Vb1pmBVBbX7df6pp+n10w2F6pWd2GnfgvLWFE6X1WneqfCsKDdVpBWyZBtJ+FNXUaIECjpL1Q LbXV0m01WKsrIKy3qSB9Ov/RETkGCwgo46fppVoJwv1YLIVyhyh9+vLWSWkSm+vhBBsqDjlTQ+Fv 9wg/SaQghF21C32SETo2ERNAgRH2Na0lER/C9aTYJ9dyCq626ChPoHqwRSGCCjr9KEnT69aTohMa mxVhdNPcVXkMDn4pxhhFWMEIxXS1CkV7WwnS9cK4hppnIxGyDaVbqE9MRHBAhJuVdpL6UjY68EQ7 +lSwobjkFxxEPkNdwqpvT/BIocofgij/9EslOjgPvglf+qC+K5DMcpOtuQwOU9e1SEQQjX6VEMUk YIVrhJrpYQUJPSQbkHPH7xpPhrQXpaUIYgu8jhnVUq1QIG+EsF+3WEQ8eWsKsjhp8Fr/oF8QTfhJ UgQV0iGW5gPI66VtoER0oSfiGQy7SyQ4JLCrqiBA0+t66IYJhtqSsiDmHCHHq3odBdy1gsNg7jem 6VSEHOKp4T+k4ShXCoREP+9R9S1iREci80kukkuiMcIdUF3SQUJU7OW/VtukFfFx2grYTulYQ+wv hbFIKxSS99JJvTV2FwiK/9L4K/0FCfX4MjhGoXvyQWnaWYWtL8EljTKHChB2tvY6oN7ThnkE7W0r XrtaYJ/SSFqq/qk9eEKsEUORI2CsV9wyOtofqIJxr3qE33tGdSFgw4p2GYB96piQiChkV4TCST92 km/xEJiPYhaS8Q/xDBCvtC1/agkHW12Qaf2zurI+lq1BP9oGUOg9UKVlDI42FXiKXQMoc4rhkc/w QsFhgvYcUyChQvCXiLTEhHNIR7Kc4EWOFChVTFBoVbCXoJj+IkSEI+2GRiKwiDB+66Fg/sqThNQi BdZblGCT8hnHBexEaHuKTsN+mCSsEumF8GiLrYZbmATwyMcF7LcJG0Owcm/aEbTiKtiihwVDTLM4 yYlaDiN8s43kYDWaA+v9M8B76euhbq1+vBhe5Bscg1m9dIV7ISChyRgocg7r/wQiIta10F9fryBJ V7qo1X90l1v/v9Im639ryb0WVyzV17rfpDX9u6r37fhSbmWF/TeIS6pZBBG7cm4EFv+ED2+or2mr eGv68aCr6uzDwaf8knsY19JXr/kSAgjitv9Io3IQG3r5G+gg7NAKHHWZpbC1dfQYTj0+n2lV767S fRBqHIKDYQv2lXIKEyDXbp+RBySZAn21DIr8GEP7SH/4bS8P/SSsdbaXlmK1vY+hrsLv7///VtL/ unvSbadb6avp/U7Et1f46I3fXWmHV90mh/1fybpLVv4J0k39dW/YTum/XpN/vV/+gr+F6f691/VJ rul4/d0uqXX//pYa+ko/d39fr1OL1xfpStgx3zWiTBp/iZozBsqlRLoIJrsJMjgeL6LewPBi9AiB 4QcpMpW0iBYmiFFkFccpNA+QzwbCk0UtszMJnaZRj6v9S2o1/6Tvqu9/+k8uqpCPveV3X07oseut 7qWuJ668tYoMIOtL3f3dwmt9Q3eEpQ/trhwQgi65Nxv78EUPTunZqSRDWkkhke0ocnGiLUGQtfZH AjabaIcGEEQQpa5kqIIQRhFIdVTCahNMlxdTIXRHZdBNiwle3tL7rIxRCBOIkMyooeS662tWFQb1 mR0XwihxEicSHDLpCxI+Rxeraa2ZsjxHpQ7tVUEIiQgdhmAzkYkOqsXVBCOJUUGShAihx2ZGuCIO OVazwZy4OCFnU/yE+kuC8scp3xWRs0MRcoDMCKH3pJoOsg46CaVUOROdIhEsIusMjHOOQowa/QTa wgnWl4QnHXpkw0hplHQcL0mnSRId16agjj3STUqBIViCRvBEY5Nyn3MiP90oQZQZFtWmmoQL6tUw n0GFd3Sd1SrXGWDHGxBVwiOgoUiih2CKHSoER0hC4t1fVaVEIcJPTVMUQLiKEILCExTVkx/W+upI eiDqyhxBHJpJDWD0iOgVIEdxYQ+1pesIIUzDhRItBD5DA7kWIZQ7wgo1QQKkvST9dXiiE1Rx2oVo IJxDIZRGPiP/pL6QapiFF01cIHJoGzSQ6/MPCu/wVEQGcwiOyPGxFgnUKGvCr69JpO6HOpEcGm3C WgmzuwfUxhFO3vSWq68QoTpQlqgb00wlCr9oLbI6J51bRTkG4atfU7IE0Pr16XFlwlhTpMaQfqkm 330RGdbp9wk8dqZoEU4RHTCQQ2gtQUPogw5HAlD63XaSVeYkIxgq6WkyS78hxwToJkHjeviqasIR QZDA4KQXKUXS+CdhXoUIIMpzOCu/XTTTIV0DKctwhgg/C8ERR+FWCDCEReyFf7YQwUQQwQoIRpJC NIIoddCoYNf0ggyY6BkCB0LBVUhsHwycE2Uq00+V1a7oRhJTbolhPG0O/UX0mgwhOq1atEY4TUIj pvuNJNM44XXC2IQqLT1jDJERGqhOgoZUS/EUFwv/9ikGcc9VrH6ViNhhXC5Zk0XRVhJd1NaNxtJM ijlbVlTY8s4rFOiOBI+VwRYhAi+kCKdhnQVswFezwHrUaERFxGqqXBmI5LbC/sSDS5Av3ocySL6I PZQ5XlUO5RyhyhyiG9af5FHBDkeEIEIl7xOZHUFf3VqEIiIiIivfa7r9WEtf6eK7+tNXX9U6Vf29 f/YV9/pgiP/+sRrax/q+rVtfT+l7kTr/69V7+/v3S1XP7X/010rvohA/+7votxZdfvSEugX6Uw4d +1+0zA63/q3eW4uF7gih4cN1VXTCGvtLXOQRN/eLCvppU65Z1L5NxvqwQXYLj79eIXRQ8J7aC2u0 u6T10121hAwX0+KFlDrLh/7CEdEC8GTIhwlvxIo5aZP/xEhUzHpPJjkCRMGfZXS1poSBWmFhVH5H Yd1daNQK1dYeVYad6W3HrSJRW79fVL4fetQ3/9+vpf69h/9JvvXX/1f6X198JP7SBFRxXWKginv2 dwraX4+/HDCy2CRfHHv9X7d//X0l32YClrX64sflSDWJuZomwKt5LopwV0yUIeEQXcUTcn4+JBmN yhploheja7T0yDK5bnc7kx4kdHFSr0RRzuQyxzgUR8tzGTF9pxGlxte0PpoHkJV30TH2kvF/7PKr 46TwxXvX9fLMBEtXSudjdx96rC/S2U3H6ddcVwpAz/WRtVaSftdPqFeuvbtU7ZaxWuly3S/4SCr6 6r6tctWMfSrXhN8E+le2tfpuqQ1+9oF9U18H6+k16Q9fSX6phbiF/fCISOpkWEUo79K6C+gTBEPs EX10FVIIKEyOklkNG8wkl5Tg4UIQ7K7rBA1thBLoEnfeS4NP67BBHeupVpM8yC7IEDkWRWsE/pVQ SIhLrYJ2SgGs7r/CINDgiPkqFS6CWwVMqIE5HCtEJxxxqCa9SBeo4p/VUFvVBA0sITgJ+thENhdh PJeOxyuklYRBIS2EkhpBZCfSRq761pV6S4QWnQJV1XYYWEyI/kXuE1ULWFm6IWuEquEglwSwmnVA yj8g8LppekLkEPXCCS1QXRjIfWFTvGrVEPD0gvewk6rC30lxUgw5HRH9QpUdL4Qr1NY0uKglhdBf UF5QgRUZPZTXu+6YL0gTW6YIhiuugqXQVY6fqqW+m11QTS9ggtUqX1VResKFT11QWqSaXUEtER/C r0FbpXohHrVdNQl6tBVMitIhMguEl69Kkl60sIiDv/zCqtIKgqiiR4IgxHS9JWvrT9BfSS9qKS1/ dKggXhL/vpardKgk9X8iapdJYL1wvSr6XXVdCtL6+qS+l9aBegur9aql4SpKv9Kl1wuklIuuK1// Wumgl+lVUkqyY+vSkI0FwvvI1vSXWtKgq0tUtLVKU4S2+k4XWeXB5SFB/rXWvr+klTSiPSpVrrC2 w8EtdA1WvQS2F69LX7ilwutdvBV3IiI6ta6ivLo4F/SCX19JRuFhLYeEtbOgSGlkQtKFxFelr19a WqitvBJqkQo4QbC0IXqj21+qBfZEt+qtwVU3YSrYphglharCX9UEq2wt6S9gqpuz4EX8VVcER0qT S96XkegwgvpBcaaDxSVUGtlD/GKa9rS0NkGB03bSQXQmkG4XsKUOh2klhQXhrQXsSD6ekukyVLCa WCaGtrD+KFVUL5lphVtgmKhbTTjUKEDBV01sFdelcXgtQyIOCIkIsEkO0gQ0DIEKN8JS39MKsgaE M0hRD4eCYQYLpCEkF4YTCHEfUYJoemgh8MIMocm3E8Lxe6XgwQikL96hNY9JXeq8NP1EaoVrdGVe 1S8RFf5ka9IpnVEYiuMWPLOCopcWhaQiPyziYZpFAQshIhroY//SX/hsMsYUOQ1xyY6qCKfQnQHI +O+PEaG3rrv9f+vV+/0vt/WyUL+mla1P979L/3/Va///+vS3rP319M1arf8L9X8L11bbBBX9/X1r 2gv/ugt/+v+ttKv3xCf+TcGuh8s1K9DtB9/75aA8f0PVdcb99f9Kg/un/kna/Vuv0w7rpN9/bctR WvpN1/UOmWjpf03pj/fvrXw6WrXDLQUsjrvjk3CbDLQJgnWvbLQBBn/+RSYa/F1waBPlnn16YaXj /iTcnr71UV2/2yGLnR9dbREDgg9eqk3OyPwS9P0YfLHsWdrPBa/tLSwbuFra+r2wdRBJfkdQaT+t hb7iFXr6QU16pElDOlrVrQ/sjaOBpE35Jek+CuRNeI9fvyuJKnC/irSSJsYRK1aQpJBP0Gn1EacI LJMP5A8ZuTxZXJLpcl0C8MgtQC0l9OjWGi5Zy1kcNQjkPWqw1IYKOIicSdN9Q8+GVUs6UjRG0R0b RohcIJ6+jYZRHXLOpoRERHXVbQgh5XDxwgv2V2uOEFriTlBdwXS3RBQbV+ElKAh3irMhtKGQYNi9 Fma+CUWSvQaWgdQW08IgjyuCq0wmU6Xh1OOSNgJJOwQSnVHYriCKdPw+87wUR64QTppmQ4Nbau0d iqasrSBd+gklzslSWmIUbTtLhWIWq3BdkYqWHEFa0FpkIN+QLksLDWjITEKR/SBAtSnBwpFLRBgz cjfaRJrbBFO6qkCCtI6hoDkZhPZD7ignYevKHYQtheibhQEYUJ9hMgazVdd1eLYWCI68Im5YDelX 01M/T119ttBMIfQS0k9Qna9dcNUjo0mwghtVIEPVV+1T/XCDS07JdIodoFWoXShExyOfwut/Sp+r nUOVeNhLjBXoij0oQf0QsPT/SSkoB0oQdAg9sECqGRo6XCUGtJL81rq/CT6raauEFx9KqofQTeqe vStMGtJ4TBWIXLM1Z2VLiuq+F6QT910g9a4VWuE/pRXVJ0P69LvM9I4CF3p1W1Hrp4r2u9VSB9dB XqrWk3qlWr9fpKE9BLCXog/FD0ES5V1uF7dVVe30rqF0ndBC6hB/90qqtfrwkqcaFegQdIFBdV18 io/r6VOCtQTxV0FvoLp+kuRB1gq+lQVKrhcIEwiKO6mRhMFj5Luq6SQMuiOH+lVarrUoBQEg3vFP wt1pbEfelQSaguglng0GCV+L+dRKpPrfVKwkGFW0rRgFDoK/8MFf66VuKhkcGBa4SoSGc9Jv9xC0 lpWnuoggwXhKtJ/21TVK0GC6poelgtJul3RJfrrBhesFhFDoEFCdK7u2GFXoLEX4ULQpJkMCGEE/ EHkMb/Cr3hMInWzjEyEUabqWYnYlOLjqMUGT3roEpIcLSb4TGmqSFUygFxHSfptD/IQcKglcOFGn pitJ4X/YVJPpL1hKk3utrYIlStJ+klpBoevVX0GRdukF9BVqOv0F/VVuFuqSC/Bel76GtKkhthrS T6Q4Wq+ktbwkgvWF2vQSx+kl7OxtBJbeEISVeF9wwX8UtYX5XS1WyzLyOiODBHiyesUuWdUR8Ncp F6XLOWgVkgL4SuhQ11xSuiDSOW4IjpKsgxBQ5Q0Q0DoVuzEhEcrqC3iP/wl/S64QX6S/oLXpfsGC 9Y7/WVt/yWQIPt9hf6V9fXv7///7KivvFJ6XqtvJFaT1+gl/s1a+WcaV/C/f+wveP9Lbr+rw/7YQ Vg//VQ3f20Fh67erv/YhUv96X/Qr16XvtBK7+F66Dr/wstJLX0w1j+THDS/rY1S8N++E3f02/9N9 9W/9P19+9bf1V6r093Xf/jRaNV/sfVP9pb45aC366Z2tr1k3F1pmTqFX7UhaT7/4pdcVTIysrjgv 6yyJa+6QZTrXoNdOwUSXX6TtYaqJBb9prsPRE9J70DBFDvroIj0kXgn3JkGx5nWVC0EkCp6si4Kl LqPCCQKn4h/fhIJAt7gpN/X0jCaRN3yyDaaS/XSEECQTfLcbxgq160kkm+2DKHIMo5BfPv+kEQil fiJ4MEcIKk3Ayp670kFTfEcINbXVcIJL6RN1AL6/6SCpv4T/6DpIIW9BoIw+ulULoJ9ihIQevu7S SWW62uiIOVP1aS+k2OkEOUi9etJK6YQShP2vfSe1BJN19a4S+q+tqsJJSE+oQQSBfXKytnkFaTb+ G5x5DlSjQZV+qRCNBJ/Sxwn660d0S5IyODpX3aBtV9fsijhvnwb02RBt8JevSRrinWqYQYLms8E0 nC9JLVdV4d1QJhVBB4Xhgk9/SX0UP/UFTC4J6pOEvmRlJBaC6R2YRHBdb8E1SdMjKpAjFthBfC1q vndYZv+U4aFSdOyrNZF1VNhBXTCWqped0DV3woQSoJOwq40ul6MiQXWl9L+loJaquqthBPwgkjok lXUL6VBJUFpqv0xC7ggkhC0EooIgXHL5fqlVOiCPDVrq0vCWqSQI49EM7x+1pEPaWFoiUeFdagn4 IEoKkiIOiTGRxUQXiKX1oJUguk9IkPvVV4IitTRKULSwS5ESP1VAlQVKk/v1QT6mQoEwkMUkF0Ek +rwkioSSTpVhLv0/mQ0EwiCPqgiY7qF+klSmuBCCqKvS4fp/RNqJEktaHtHRAvq6hUIVE6prS20k giLb+OCWZ8KkKSH7SWgsLGlsJqw/CTfyuSLBBa1og70gTTcL0CsJKlwk8g56pP1K4KCRC4VJIhOu iI6fS0Nr1s+DqxeEmHw4IOFQwsjnCVTUkFrFXgycOqSoJb6CbWEUPkWwcLONgohlyCQTcQqtLUgQ 8fpYhbdBJusVYMhTBNpKAsIoeMkPSYQXBK4bW1/STCcNaBN/gz4gVqIqmJ3DwRBB9AihwvhSLRbl Od0lCzspBcj+kw/YYYYYSQVRCFirhhCnqqhdkMVA8JMLEdIPVpsjoNgrChQqeQkLL+08iosGCTB0 rXoLXgxDDISYTBbCrYhX7CaYSxTbQSkUcEuk/TYigylYQwnqKEcXrFKUPGug1VphDTC4K4W1ZSkE hDBdoIfgwqrYKnWnVIfpLgwTQZY5VSax2E+CVuPwYLERYINbkd+gqtLlvgZxMhTI8cSTbI/HYJK6 7Bl2xEWrFqGCWnVVDY2yQ5x8QttLStuDCiW6a2/034RxzjiVtwVQaX3xiJW/SsgRuiqEmHjW/+3B k95aS/0OwkrpNtJAwl+5NxCLIlIcUv4iqXsun0uw87GLUmxotXjQQQ7g+ku2RwewS7FKguGuC4ao eGC9CTcQl6ZMgerdkgNhIRcMr+bA8syMKpb2okGe6j2Ubi4LrYyDORfyCg5DKqS6kHJnEveQmx30 2CpLluYTC+5biMe/lvdf909dKqdv/t8kj6vr19bv9bXakW10iyAq3/n1WWmDLH7umvyED+7+1wyG LRZQa/+vhilr//bKHT1btfSoWUPHfuaZr9bNpxqH9VTSTi1LTFkRxdV7a6FuNf3VL+Zn+3+wlpY3 /0l1gl66/3bS20FyGB122K9Kihj0mthhV/1xC/uW5ATphfUGY3J2ENcNjtfUt0X/W8L9/T/Tff9d P+9IlGupXEhLTVv+uCKdJNjXK5gHxdLXhArtK+4QXW98Jegm6qECtQrfdEWFvX9DUjehT94kMsch sNgXa1Bi6eoRQ8rqwPDVr4uVxUDwMJPwih0W+oFyPEgv8XIxNU+WlT61Q69+u/SWv7Gu//7Sqibh SLcTXp/wn1XOxxcmRp5NwNX8paBcJrle0NdSsAQKle5JR/kEDMCBAnXd3IqGqoXcrqZ3SykBWJuC aCO3QVBcOFfIwDgECzaJUi6UUfvp3WjMD8RERoUq4dccm5WkFr19EFIco9BkeyaMv/wr8g2BJNwP I8l0EU4fWV9dr7INylE3UKMEUZxHb1ZTIp+yDjlMhyoK/6WdrOo/JuWIREf8LXoSyVr+1+o/0mu6 /17TCLT9/2lnYxVFPvKdVWpkB/LMT6e+N1SYW6d//65Q7Bf/VUloYUK/f/+ybrIPf9el1rv/69Iw /CZdf6pWlDuSpEfyvgaP+vdfHlccMqtKtLpRrZklA1rv/WmW7VoEECHr66prJ12Cg+dwP+obhC/6 V4JX/WibQ/8Ihp05MQJ1d1VhXj8gQOeCMPkuFC/rx78MiafNQLhZAjdMg8iPS7sarVIiQZmiBiT/ uRC8l+7wsIgYaeiDRsz3LM1atplH4T+gqIcbD0+oVbTfwm/aByKKdI7USXCZblSXTHwXyIWiC94V ZQRHWg+4US6C6a6+ahkDLRDjgvZAwOSHBZ8MQRHSfdRVtfCfgoIPSF6ZDPCDBAkOgYMnxKCtgbut LrWFI3+CYIPglhkrRwYiOg8R66S6+ClIHIuE9V67F9BkJYT7wu0/CkIDAT9U1Stv01wvXd1rRDDw mE/CkORCj+qYP0/REHf2ly6RCD1cILCYT8FiCBD62/v0E/xXtJs32hBUFC6SILvj/h+iIgof8L+W oDSdsU91VqQ2E/RBOv1wfEEINrpP1FEIP6sHqk7XiFbT2oYfQf0v6W6V8K+wiDDvr/wyDA2vSpL+ lxTdQtK0QengiOuF+w7r1q+6XX1pMQV+NJEtW6hv+i61f4S6b4TUiuQcYvq4Ie1DfVa9f0urSq6G F8LkrJ7v4PWv5Gpf5ZgeR9Jsq079L19aishYsO/x7rroaCxpja6r6WtjJfD9KuG176a/98F8L3c+ kiXH/4br+qS07Va99d4S36S6Gv3oLKE+1cOva/cFX3WDyYX+klcJ7jsHS9d7Hf0lqJEtNe6SEb1s giRU77B7IMDhYXcz1p6pf6e9SGgcpP8eQYgyXDCewXeGEqUeumkrXsQ0la2LwynLmpCD3GGlXr+k 99p/23EaiuN0sF/StNYeqD/VV1XZwO5BV4StENNbVY7u7W0H4qx5XNOChDjgyKOE92whaDW0O0ug QZ1RdiiBEFOVxGOdcCYiL4aGQ0CumvIqLwnGyHTxeqBlWmQwOnYTtOVYZ9ptyKDRA17iJlNCIYQ1 lOi4N/DthWEHsFiLBZQGb7scJuLwtEDGxo8hWrvUr4hBhZwMuvb6YjELt/hZDN2V6/hQiGVtZKkY fcsgNGbcJHYHhEFDcnvlkrDOoSUIhoHBahNk3qBrNM0BocEFCLJUgiBDcUTJTUpNyAPDPwhFEMNy ilacIgeGB1wjJJzDlXvBPhAq2EIj1F1VXhPfdELZUEDdDaDMuYKZiz7DWEJV5HRtkcOSOhEyFUPT h9CIiPeVC7IY5TD8m9qsKZWuGNfyKrx+7/hb/hpLxPodsbg1/Y9IGn8SOizma7lvqJ9/7EehIoh/ 6T68euSUEybgt709fWStrwvun0P9IIhx9/6kWuTdZXzsVzIGPphH/Um6f/r+niIWooP7Xe/kUu0/ 4fT2PHnZaof7+hfIcEE21lrj+2Hdhdrqt9pbWPDIEG6jhBbeWsSLyBg3rtrrY9B9pX129sIL+4fi lvqGtpr7QadhXrTkQ3MXarLMFUTf1cG/F8Rq+nf7tayb1rt6DYX3b5GO2nGrek2Pq9IPzIlW+kw6 pO2+/G70m06Rb8GjSvJulLlczYW0E3p7Q134PXpPr2TdUrfBFnMdcoC9eTcWVFesi3Brvvr692nX fhP+2vf+/TVv+rfTVfmRUv+/jrtivt/YJVNFv+u8fHMgLvbnYmpQ+39GH6bZks+tYvv0vN6eu0W4 /F9rqv9v/td+u9r/aVU7XQWtblT79acof//q4VV2uNP6W47/4Xp/pam13f430gRT9dxTfX+3+sLX dJ+yuaIqq/+djhNc2pMeHta8f1FFZRHDQL4+PqVhHZSs6oew1yFg0elWQ14jiW4RUUOoM3rkURHB t/8T6Lr8bYYispAJP1xEoX9Q1IeDj1uvH8twP4NRG3W/rjwZCG4ggeMcq0XVf/rDmtFcyUgtOfRQ 7OBgjryp+dmF1luWriMgqQcDjEeleE/y3KENOS47kKOdVk3MBp/pw18Ssr4iIk3CBrnUaqvD/9ZZ BsFRWP8+v1u5ZCYMoJkbS+2OuPaCqEztQDlOumEfXX8EQ2vppndYZ1XaHztQ8qa2MhqhwqnYYKF8 g8hSGsqhEmEohS/IZbglRCXULdZ0SIg5hQjU6kKChdghK4WryGiicJNqCKHS5qREg4gjDiwn0UME wqiOpEEespwXQ801UpAIYtMpEc6IusEGFXo49lGKDS1C61ZBg3TTwREpHCYVc+WLHaS8IhnxJfhb ITUISGI4VKsED0ugiOvkEQvVIKsXaqmqCUIM76/FDtIhBwv+0QIeuFrCpSE2oFhO/W4QQ1/ohjKy EfHGlCyYMJ162klS0qCIc6uE6dkdJIK01K4w/11CC96wvp0Q8KQzvFatNSrS364JL9dBUiT0tEWm E9uoUE0xv6SJpylUIJV+ktMw6ptXha3IYh2vC8LxSCrpcKsTxL0DoLW0gddTpfr6C+vQXFLta/hB 1RCjpwn9esL2q0tmF6JvWFq3Taxap/rWgWtL1vrXWvJDunVcL/SpIEQXH+vgsarVBYWmfGw69dP9 fmw2Wra1BmwYhk6r9EIP1CmAjdOF9f/xVeElimNbrCVEGqwQhX3S63/4XUU9wdL2Esa0QynCYa9S N0q1LOULy6uHX19/4Sh+RwzKevSD6IQfDj91IXZqF7QaZDY9hdcV8SVkHoE31JAafQVwucw18Nhf QtU1T8LaSZEDTdKuULS/gpHS6WQfBZxdVbT1a70GasJ/pRVL4IQW77iGCsVaDCsMJhNRCxoWE9L1 FfLXGIjojpBDj53iYTwgyKcIjok0R0I1UINNulXXwvFXhoR2hjEYTsIXpfq+GImHVK5BpqE01sIp SI6VpLs6fmQqvKicdYiItQmhQjFc1uKQT/Udui+LQkNa2C1//V3YW4ShnMEqrGo7TQna0iuLIaBK IqFX8RMIRDnaeCVNJfLWM1iGlBBNVTmQsqjg1HQYVd/IxBgqYTC7/iKCaFpoy0u9UGF2I1GgwTC+ W/JhCPwQNkLLsOEQwOUmnMOeR8IoeEJGmyOO+4Tfsi4v0Qyb+JZoLtexGr/93bq3fLSmqtidraJu Lr5aQmjv0FHsMRHuQEVKrlMJedledUdEN23OxiER6ZbE4rKEewybpMmyoi3MIR4dSNIi+JF8miH3 EgiuW9SNozRA1Q3K62BeQZoZkGhERGuTe1FjyuZhoKhDWi3gFx5XNVDLciWLjJmCeSbTWsSjI4Fx natbiTonceh/forrS/f5N9FCKHp+sf9br5NlRVWQeCjcTkLF7rsQeRTCDxGoMHpmwY9FvYPVhLLT DXBvjwlsGHaIaB+N3SkODluJorlnVtuET1iZJX3D1S1jCX0E776pLrtfBerlu4Z+OukCC/raVePa siOrpA179y38SyOk5Bgf1DoQ1hf7bSkhz0/0wuPk3VVbbun8e3DSS8sif7bNAate2WrRV1YoaxE8 v7W4/31/tVlkEu+4a3JuLLLcW/q3VdZV1QlpjYiq3LfATv7qVzMM+nqtwgu9atSGDcCrrU7q8Mij gtEbg1JuqLSimI9W1nRFQkYf3dIN2NjXV1V7JvNdfXSb8lO2VylJa3fbxcQqXlurvav3Y9FcQgg6 pJBrJuBLU7rXpBbsV/dj4rU7DRkltFjoMLt6XW4mSyJ0P3/I387rQTY+2/0h4hOvf9Lpzb7+61bV PyG3b+vb7pivr5HFe0+uuu/r9Ha19Um18KUhumfCBMINLnZdV/phBk8QZHZY+IoJrfp9dM1YTsIg iQj2PzvmRwaCOiOiPEaUH7Gve1tA4aDQMFJCWIQjiiDEkLu/k3OrRDj2k20wmUgUKLws7C0g18N3 Ut1hbwm4hpqdewg15DK0pyMdmof4YUm+hoMjQNFiMQvu7VQlyGgRijwgRBNls+MuqsPQi6pZCYkZ 3JXiwoQVvZq6EJnaQ0Ivxu9aQ7dA72gWdl7CDoJnYPQh8P01wttQwpCdpBfhaTK1EuMjg2lYHbLe ARxrrvGm7QXerkvohPqC5VAe0W8x9JJbdUFkIOUPr9aiCzqFUKwgg6iGQUxyC5uCrU66vuXDyXpI gYv4XhBSgCNIGQzXBBB1LOVxHzghHRHRHy6N7ObpVJKKI6fQ+EgiYAj9Vo8HCDLyQSBkNCXtCIiI iIk3U+sJNt/pUE/1djQtJAiMFT2OkFd1qyPoEkEyXP1CIkIgxNJdBNEDGR0iCdv691uI6gh7paD0 lSQTkYBdEIHhLVFv3tBWkFX0lQaUJEQ/pQqCDw2tBBV9QnrC+gtPQSCNYqUF4SGpb6rVAvu4V1rx WnyQ5DhoOq+ldlNOKQ19SKOUKV165L+kNfVPXHq624Q39VWkvULr6XlvX6pW/TekiI/q0gXrT4fV dtUvWyXS/JWFX+EK1SVfkrIxyga8PWq3NWm5UJth0GRBiXqv6WmH0Ir27r1tPyIheHikix/XWl/D SVLw9fWGEvJCI4vD6XX2C/XYfhK+WbPO0KKOJbVkLFcEIRI3Ydqgr60F0miQ+r8mAet40vaxT2bB 62+KX+T3NYJrqH4MlwY5b3rgjjx1CvUQSYKw26S9e8JhL2+DNERwL8tzUDGNOxTrUbdwl6/UERuG EvfYiQwP4SGq2E0wt7SX/8JMV4fhVcIKiHu06UE4bbCKHQX/dwgvSfZBo/tEFDTHi9NK1T2hH19W CCa99kFA4XVkRp6RaDCcjphbsGaIjou1Oir7asJNeu414dNAwktggwlYiIx+sYoNeQ9cGQdP4bpo RFhA0awxINL9q7aYL1WhWt7CImhEKyBccEyDvEYcOEQYnSgl9oPYqd8DcONew2h/I4YS+3WduBhk F9VVSDGy4LeIXVtvGiTZH2ErthhYtNdWDzsTUhncIRDC4QaHhDXK4Ii8ckH2d8MSXQa6fYT3K4mC vuRfESrXi1sE171cRzIDPEeGSHuJAkOPSEzzaI+XDQWarWNdsRE0BLoqqOwf9RE7DWNZ2Kpb+OPc bILkHmpEy+q7YiP//9DS37qudumv918tw3uK8rrTBB4rwVOiyqir9vr1vureERR/a0uvbCX9vitt rhqtdNi1v7LNJFXYRHnxDC6643ityAkBrbRH0stsuhrT+TdOGC+R0YVmSwtXhLBCIkK1BKUtDuNe QUhztA5TVm1FJISFNyQqTzuvqGuQPBHIQ2WimuCZXSwuidChz2W4stxsxJ1y3NX5HRdCINn0RwJx E75baqxN5dCYaKmihDwzIndShCIidUR8uGYR8buEhxE0RQQlqV8yM0otYoIsoUi3T4xdLCKHYjWs aLTCl63G4/UshUteV9UO3x6Jslf/1ZUl+qIKkHfb4vqnaeJZ1T06//otMEJ7+6Y/kY+062SFSkhr fq4WZg/a8NYW6fZ1xTBQ3e9BobmV/JsLqr0ybGqc7E8LVJ+tMsuIOFW/dqlSYdV4rpKNj16DfaWv t1RDLHd4S72kiD2qLINaVV1faCKHVFkjX11eqCFrzX+tVq0mFSYXXOzNaVN3ShMIvuo6Qr34pIRU Eq9Kt4YJsm4EgS/WH3HUF1MjMvr1qEElSDI/SX2uggvQjrXVCEFkUXa0/0EuW9EshlarRbhS1wgs VqQanK7fI6Kyn8IiFGtiSH8RFUHdUuGUOPb+ljieDV6+TYa0F4ZDjngne+iQ/GvkYhFR10r0Flco 18iB/V8txVHYKtSQggfWE/dXiCBcPzKjkLsc4VIXrhaVK7iMPEJhM1CKRszGEQLjlKOkn+tZBBaR I1qD0IiwnWFIGO3/bILjCDQMphAkGpIdAl4UIH9JolCaZDPoQ1SJBcqJZFCA6CcEFXUL/Edg5Da6 EwmqTDVYIKUiIhHQ6pEOPXRb1FtYZBR9BErECoiulYeE2CCapgtqgTrst0B/UGDwgiUghH1S6lu9 QZDYTIPFUgg6wgsL0GdhqtybqgbGQ1BwSCBDWEKSng+mS4dL9PoJYLyutmpBUiTdLfZNyUCAyDdy tUfQRBceq1g2qlIQQJNVCfpfaUJiVYWmqJulAuSDFIKCCvpJJvXQKv1UJL75FeE8cH0rCBJLVYbV ER+gvUIjx+l9cJN65ZIF0lQLBFDkb/SfSekFqkk/EKoX6e4PDapYQSoa2lvpWqX1Xwuuq7fYeklQ Whr7xXpUkqCv+RWTOq7ylIjgYfS5E106SvX0nqr8IEUPQXX27IGMjouCr66W99dAjj6S10u2h/6V bILjiP4XBK/gukPdVpJN9V3tdYomy0tKlS6sqqBFDwVfpJUlW22EvX9Vg0tegl4jRGAutPpfST2w v7FatNhc0VAq1JDgm8hhguYWlXCqhXYYKj3+knoehUjgRhcbRDjhWlW9BKqeGKlyQdWskqeTHIKo 5G5GOW4RHRoihJKTqOwS3iFha1oKklbTEE3aaoQ5kC7TKc45Q5Q5Ic/EbmsIMocKUOCDojHKZDX3 oMF7hQwSr4ZmC/W2vWlDlbQiLjbiDKGkJN1hILbWPeExVfH05BphbB5Ts7Mk0XVA0RNCIiIk3Alh KxkNg7e24KutVSUQaqHjMIQy9UI4qkwW/bCqr26psYTD4jQhBUwtkNDpsqE7ILiAmt5AuPVLq70W n6CWyMifbC7BKwwmhzfsF1WwnrSQSxsEg1wyQK53yYVAgQqwvq2CauJN0tqCCqKDIs7EI3uIYUW7 BMNWE2Ia4T0ErCHggRQ4eGEqsK98yFHwpNzRYJdbshBzZGnGqFxK2umOThjYXCiNrafGpb+1koCp hYYQelqvt0TdZ4gsaadqg4tXtKoLwyKMTTi87JEtnYNUMIcQ4sIPGsYRbkswWVgHEe3CQQYLBhWy utDtqhxJuXVUHYidiF/C4/dfH791+Fkh/2o7Jutvp+d+HI+E/T0CEGR1ZbkL/oSZsoj7cJSDUbCP VjZDTNql+mDVbhoMi8HWdja0GE2SAz1j2E2dQXBr7J7VsjA492nBh0WRVVRbB/q22v8N/dtstJYW PMo8N/aJIhbbGtiV/e2Ta9aq26f5Ecg+9LYUslfRZANXQkNm58KOvkGyCjK2nX4k1m9ND4ZCwfCj SRAnFr92Q2cyNgX0FCaJZOjI4Lgk3WtsTgIiCgppfDZJiyJ5wTCt71JpTYWuwgh0CqrhKhLJX2/R MdPX3oREyTqviOrstkoXfH/7rbdfXsNS1kjLIsIyAleIRNzNFn5Jk2CsiaEyVh6TnZGR2JZQ0NvY T7R3AZybCAI0x14aJQynDKJsQDX2TYtQoIjrhhIUCINg5TOnndaFL4M44J0IM1IjsshYnC0EENsR YRNr4i7a8codBkM0cpyjYgMJmEIMJNAqGDJORufEIxBisLjKNhMgQOTmVZVhbBXEEUOQg5TlDQRH ShriwgoiRQMseuW9SrJpY1O1r8dItwJd7vsl/KvJtCI64sHVqkZBeFCoXOwVN5NF5brSxW/jSaD9 aTXMi1EdJ30/Eyoa66Gl74RH8IH9aaVX6HBPS1V6ZXWjur4frWwuuvhB9dqNHHpkML1V6f+lzYZ+ Ha9eliqBBJVohKAiOvouv8Qv4QjXbNX4eFb6S6EjDruC8rCbr4Mj69KH5Fu9LO1CI6whDzsmqvJ2 /hp9EUPOxDSwg9U/mgJrabpBEKuJTvUS9DH+HvfUm4WsFo7IBcrYzi/rhuHt33QTwRDA4QRBHKEv zsUveQc2nIa/8KoUVHRBqHVR7bYPsp5tv0lMosIKtkMocFr6dkM5sPtbXTwiHuUiPkQiztApfwgo WyELyFuveyDduZ8JU25gX0EoTBQQanfhlEu0EiKWQ1nWW7t4bW1s2mceoVigkCrYXCoNAn6UEwWv 2D7pYQYdj0CSVMJ6hBoFakhdBU0vZHXvhJVwukEgqqVYMKCScK8fCa/Y+a1fx4SK+vSMPCUWqDpb QJNzqtQmvWG05m+3VIJV1QSVQVMg9NSTaSf6hUkjt7hg8R8EFxBfSFSMdhVoEDRDB4XVEh2orSrh byGH4bUJY1oJCR5REuFwTRC1K4pK+tNTtWRdm0pLpMhohGR1divS0FoQq0tVtLWEk3+FzsYGqEqC hCRt+V90oSXCStBa0mglX39VU7DDaQZrSSYJkDXDCOyEsQkoVMJKklXTSDStJN60iCRXVNcIME6h zsdC9afCq0uQg5U0knCWqpv4p6OzgrfWq8t/GgzeCKfwRHXsFTFaQwWqS+r+gtV/1W4xBl0O9CyC D3kxeloI+tURccJWq/69JVpdfEO6eE+lCpaH6DrolZxPTfULSkGHNgXrUiTa0iutSfy9ATXrWgtJ W1XH31r0QdR0u8kMII7mut6wTC6opHWtecSV0tUr/WqIUwltKrgkEa0CIsifyY7poafyEHwq1XSe lvr9hdILr+wuEGRaBB9dvCivYWFSpBaGnSCw6Vb6rpQut2KCQbYT3e/feag6r66t5rAiQXg+FDOF rpaha9cguroNVr7+pN9ZShQwWqToKkl4WItcFva9JQdfdBXhaXhrttJxZCuutQS98EQw/8JZTqyO jiYWgqS9dhrD04fwwWuPEKj6SSwvXZHzAZ+FWC4QXEGIpSPeqX6290l/3ok73qhqsEkkuIra48Jv +vrsNK46fsP3Lr2C34YX+t+sF+6+1qHrILv9q37/sJKqj0uCpglp0uoaha9Q+iQ4aCD+tvqP2qFr SS32CdhYIEwuQff1W0rJCbSoNoFf23tbrYTjIaInF/CwyKNL1YVl1IEbhhd6oQw/bhV9bre8iQm1 hPraxdhYUYbINaqwn2ln02krdf97r8WE1FL0GFidVCwl8MIhx12qgk/uEv3/v4sFXQsgieLCiER0 1yGELS0ohB/dK7R2V9P+R1ftVtFa9hUMJpiq2+g6X1VtzKEprHddD9i9CLgwWGmqf0kg9q2ldIQh ZwCGGF9/rEYQvTXHCINN221CqmhyHHW/tNVCKomEwh6ojDXhqvaaY+ncXeFYMguOVs1VNUkEuOu4 MINW4aWEK0IsL1CHWktFDsMEGCoRyy0xQQtBqqVhVX6K5KEI6DBeWRIsJAwQhhaQa3q3BCOvRNga UGcc45e6aSF66vuI6iIu8EwnS62fRtZZBNCrTVY9/UECXJunzWhSaFhBhda0IrI4WhUMEGYyX15T hRiZF9RE7HaX9CGS6OIvk6N4TFEIPHvVWQ0IibQxcL61shgSoLv5M/gzyI6NowCql+6TwxERpdfu EDIH8AksyUk9xsWCI6ErmqJteTY1XiwRHXZCGy0EKeKWI+yNIGQ14Kc7nX08L4ZDCgGTYCDKI6ER oa+W9GyGdytbKHO5G5pzi9vQQYYixERHH7YTIUGqTYEQ/0w5XtD10way1DVFJ/0RR2VgG4lmgShw /9Nk0RHQuHe6ldVvES0xPF7+qtiL/XstQr3/0+Qvvve4jfv9v1q2w//lkLE3+9zu0LbkbX6WHevf ohZSK2RoHpXteQzu5xx1XSuNiurdJBsGUPG+qRFMGh6sUEgQMGF30TFGymytqrCFMR7p7hZamnoM xJHj9rhrhq9UU9bwimBNdK/Ra4sh+Phf6kS/RAgvFB8IH4dHfJ+GW0lrHgw1vYce21XDXse32+92 6sP2WmTXbHTB8LybJwX4UtoaVUluCIVtFTrC+33YZNlMMwstqqlcTMNk20yHnAVR7hBt2eQQs9k2 rS1QbbYQkFMcWLW5BfYo4jG0GQz7G3k2Tormq4MNuQ0nOgqfHQMho2kDkC5UxqGQUb1DkEWfDIZV RZK2Rdj+DINHN4L7KHGHSybELs0ImQV7Gm2fBoHKWYIqPcoAvp/DPoE2Sxp/DOnBcP6UMdb4OHe+ +JHWnb1QfssevYPxrpvc9sL8HMhtfq+scp9wt3eSNyjcUvClcq2RDcUeEr7lcbBDcDBkeI4ytGbR Hjz747hCQg5uEWVQGn/6EjH/aXWMPdpN1K4oBwDLHXeGUPhyuCIjg2iSB9pFzHqJpkcMsXB0Le4n gYIXFIX4W4hMIPu04IodKE9tURX+7XtQuWh0Tc1WN5PA9uFC8fpN4YpLG/Xog3HKpqure0MFd/7Z BHClDr+k/Ig4QiPW+8NC9yuFKt+1LISo7CLgnf9uI0UPXS9eNf73ZaxdV329PLcIhqutaeP29eTd /QIunrTVvh1Eqdf+71SMZmyOZSC/ut+9wQhgr9aTfX0MOktU3ltKq0opX6YSuyzVXZUljbQVrX34 28ME3+kjD3HTZ1DNvo7Vrp7/kmHYYSSt0hDd1bDynFYqEn7TbYtVX+7bcbSf7bYYWk19tx6HLKsr tt/9WG29Y9tvp7t2tLww3en7beKlk1XYbe2PDB3rUMG9maNaIEjaBFPI6u22TYrWR8JEdAgTKHKm ZysPAQsEhHwweKERZdF0R/EREMEIsOrILjlewQiIiL4MScFQruDEV927lvMC7KH0w0IZNzuXGpb6 h2hE6IwCuXocXEjUR2R0JXIWhER6Y1LWKloswHE3IQ5Q7CY4wuUPLMDDx166StpVQRaQH+Ce9DTS 8FarY/8gNEKpW1/LOIZaiohtCFWpS0o3FardKnRZRP/2ksrpFThP/x7jwfiWgW7aVIb1tlmVukF6 k3Wcs2ipqK5Q6C9ulpIIbpf2GC0N/UgIGlx9sswujmXjY6RZmuRwaybjauWcsyTRgG0S3hVCIjlD lDlDjMhCHoRESDI5Q5x0NUQJ00cGCI+DIbc5dF0SFiy0FiKzBlDmsw5Y5Y5Mowo4iIiK9b/XSuHv oKksPIUXvCd0vCKH3WYeELMEWh++ELQgxyh+nwh1LvLHWd/CaWQg50yC0Fx4gh76wsapLOxVO+3F 9KUO+pL6Q3XFIHrogiHfJRq9He4L+NM6sIJaLV9d0wsI/V/tJkV0hjf4UELX7oaJsrX8LrXDpBxv codhBMqGTYzVGH7GLjY+stU1RN9f7X13rLJCx9vajqrybBa97eL1u8b9+6knfStJO7KH6CCDev0f F7EofqnWP27rpP/oN/1fu9NdbSab9b9roU/Yv39/S/O/eKd8Kv3692t//MhWyn1LVU0eVUumGWaq IftWIUR45SwILSU13I7I+YzyJMGosonjnHcRERjY0qTXqpZyuI4HBHzQridEXRgZHIjjL5HQvcmy ViIiIiNXLcWXEb/+v/rf8tQC7jRh+K1u9d3tUim1a2PLbKFxrugsP3v6/KHWMtMn7G1y0zHy0yIa dcb+lf/BEfoVv/7vqih5bYUsY7LMEgpHi20/os6WinRsGksgWvlnCwPZZCpD7CDH0mWcxvuQPDd+ N0QN08YWRIKchmAUt/VZiZyqNyzlCof3+Eo9uu3rXa+t+6/f/kEHVVTNa79kgrJul1XljzMSkrSu 6BZNwaHeOEFY/VBVXSQS/pL+Eq/9NdzroJU76DSvqtpfrYZr0gvfDYQoE+92kEOtB0iOIYDYTYWX 2whTjvbRMcJ67aCQQZIcq0UtfbSZac56lqmS+xiLiP2EsPtde/6f9fap9Xlu/6TffVv/TfpUm7/t vvSb/8Pow60m10vTDctQdWN1DePWm8sxLVdQ35NP9BvEb6t3Wqf3q01dcbr6Xvb+va4XXaX4t/O+ 0HVSZZHBR6KoiOGp8lYMnziMZoyOB6vSEMuB4XvGTcQjtC2NluUYjqQPEHvbDIFfFeVaHk2M0DIa bnFlSEtyUiOiOi5kdi1sRERHKHWL/16/loF1BxrXW+WyqdW7vctkZjUeU648tcp6KH9DGGqOO7FW ymEtVLbFV1XuI8tgDWh3q3UtUD6hLpFmrC4jf1MiauP9K+6fv9b1/e9a0UPuWcziPmdyzrQK2yzq oE/LOFAWZh4RAgdFmja9AiCKyqEblWiuk+haIggqkRBJxuECEXHUFduC6Y+rtlnA3f3rfcs89/Q7 7b/p/q+38rQPvC5h+S0l+6D7Gqcn3uo9FD09v9I2cm6dXxSUaudNe6wzUkl7dhUFlphSv2qS3VJ6 X6tsNQko29ukEcL0raxom/OPdvSrLUJOG1bVBVv3bqEkowVY4L4fDsnXb/Q1V3D0v8XJtV17+H7x +nwva+5Y976t3T0n4a1b4Xq8shj3ST/e1vG17fC1T99LevT/0n/qN//6Xb663/0stBCtbWPoX+v+ t///X71lukzstXvob+P3hVJSihL0QowrioPcECQh9kGAKYBr5kppkMyxdPY7Qzdyn0SA2iPmtF1H LcCZHRHhIhkdkdk6ERgjvLcIGgRESbFasaY3uq+yAwT6u+UOi3glHFhB/CbNZ/V0xGtb7T/5Z1j9 pAtqRL9Xgi+6jTx/sLr/8V6r9VKYE+ih/jHp+q1SrnZlnZJheop121S+VweFXLVBFXWD7vayC4z+ 0ob/sJX1e+6GFbCTv7SBxynUNIqwl9BCW0FLc47QSmSFrY6Hu0N9hfa/W0qvrxTqn8tQH3CIjsap P1uHSbhUmymUtZQ+my6MlcRwg41uzsbZCwb1QTGmSwNPr2EQZAGKj0HtEDgBgLYQVtkbAgj5Hzga mt2wiC4Mg1gMFem7smM2Bgt3AitO6DEnDYR0V1gFQsoNeg4bhkqDYVwQCdf9zDhgwyuUAWFkAkOo QabE8i4IQQGCuNhlnsuiOiOIRwXE7UK3i2J4IVIEK6sMwREQzuxqwjsXziL5cMbDKoFK6cMshoQ/ E7DA+hkkFK4YKBNqibgq2W6fLojgeEBhtyDC0EOyuNspwPDbDtyTmNAVIrmAcjmRwPBSDYbghvSE W7f+220u6IHgXHKHI3MOUi231nHogeCKYbt/jK4MiODKR2RzlxcN6+JDb2rd/lrDa6JjD7VG7d/U Rbv8dO7eRY+923pmpdFDsN7+Ti+K27btfu75KaCq3fDMgoZHD8F6duzJApDyOGl/28KdlQHg1q5s 1rup2MA8CdbCd/sGzuYHgz1FfulJoB4UwCgk2lC++VUFyCAsF0dM2hVKuvaINA5A+srCtiTSr+6E gSDlOfZJSru3cgeGJGs0kly1H7+yEHIK8hGyGIfDFcL2GFIlkOgqQHbBI2GfH7pA0It2EJBx3/0r 7CI7IEDw9/8JdoKQfHdZx+6VOxoFFXj7SGw1BP3/6HSpPpdNd167DC/urpi/paVffpPJu/r+k2v9 LW/pa3Td/esK3XpUug/f/Sb7/6TD4VKktf5XSES6LhDgLkoiPmaJ369N+jIKyERcDwzkdGtF8wDa q1FfsyKQPBYI8R0XA89d7uQVGeQMOXythkgiVUGqyDA0JBxyY4kQ5hyDp1SpfkGscRESGyK1jdCJ A8Dccqi0qy0jGWWqhkMkMWUEPBgQg0DmcocpBblTpJQdD5DIBXGE9ipQ5SVSWschxyxysIahBAhz 6lDghEQaoIL6JCZHsSO5DYvdJKF7EQyHXOkglV8fC1XLpJIECq6j6ULuqQIIaoodVglePUIIrgm+ 0qCCT9KEgQLvdUCCvyh+oQSB+KSSCCZDgpTg4b0ggmUOQXExcJJJAgQsgYr70ggTFFcs7qp5Akyh wQ1UiqCCI6QgiPieBlI5+ooQgQlunDUGqSRgMFuJxcM96QghHpBBV0F6UtsEXVENADdaQUguA0Yd mSVAoKLjJDnAaTcRr715AZauNS2BiqPtcswN7CD4J9bSdP/pfW6uwqtetNbZTWLDMgLiP9/WpAWH UOOrZbCmoRQ6EsuqxZZgd3QY9Pp9PrlD+hr4V+sjTQScdtWN+Pr//DwpZlauP3oyKz7fEtuauN6V MsxFwg4PZZBtQVPh16p9cdTj/HRQ9BRuvBWkFWqwrhqpZJobY/W/C/W/fW/71/9b//3rf/+ih3Gv CwctIJQVss1aV2hqN/63/2QFBpaZS7plpDePS4/RZhQiOuI/+yh+P196/lkIv3aqN6lsLfofb5Zo uuWbZlx3sIX8J37yOqrF2ruv7kK5V+lI0K7KfC6xcKF8Scfpahss2weqpGO9Q7aqhd8sxUm+2sg4 9aRZAXBYJOjtZVMSuN4JSRDbG9pMEqRbaX+wkIeh7aCIkgRT29WkQIEvdhAiY4SRZqWtWEUOkKDj dtCmvhuEgvsMEmFVW6RIcIbhiCaGtDtrk3JzXd+K6vt8swGwfe31b/fSb4RQ9sv2ib/oUx7Ju4wr 8mxmHQT8my2C4V+TZVBQl7CpB9AmvybFYaUJrk2Fw16G4LC5NgIMsjghhkntVJsoDNQTQJpVBJIQ ih3C5NqwzUEEMdBAgggXYIhlkJeEQL1hLybcDcjpIJcEQzjghQSIccoBhlluaBoFJBCTYERe0gkk ETYEBOCCSQRlPJGXRgIamR8vnZkCEczqGXwgSSR2tBsNoECiJBdxEhLLmU5SmUOVBQ5oOgmOIZHR dGAai1wJcIFSR26MZSIui7I7I7CERoQYQkvKDI7BJghDkY4kFA4iLGoQSoIqiLhlEMMgOXQQiIiI q4QVUUkYZcMgNBHDJItoqXQKkinyOGQGvIHhB49AkqIYHgrkcFYjhkkRzI6Low+EtBlwPAokY5Rz YRHKDKHIo5OCMchByrI7OOQ0nILjkDwccIREeECpCQPxypkxyDccnZW3QiIs+hBuOXxUHGGHIaMO OW53KcococjHOOSTIpoJKQ26ihYkOVImUqnw6aGYQVyGmAxSVBUibkM4DEq0vDIQBr4QKqHqq2oX 1QVJeF/S0vr9L/Wl//WvXrr/+rluaouiOBBHRdEcJ/MojQzYaZVgeGeup2tZHA8z2R0RwPDL6ud6 mRzJMMgFO+pLxHDB/KgMwvEcMgCz9moNQwz6CESGQGkO68hhxESGQDcchtj2Qg/XGGQynM5eIMqw gynS+QyAyxyrM5PUqCxyGcaKHKHMOCI6QIRERafshkFQpZO54BCIiIhL6IZY5BQ53KcgYDOOROKc uRbvwSKcpyjBBBwQiI9PZCOSHQiJFsV/CER9de3Hv2vDb8N1lsCq32ymcLDd0O+/vbC52tI4iOra 2dlaLo8QIQZHRHr+d6ozRHR8EI6iIg7a532R0R9TCCZfBCIdt3JKiPF4uFwhBEcCi/ZrR5EdGpGw PBqt+eiOGQO3uhIHgy6PD7kDw2oKLlRKaOt/IHhswoTKohu9sgswZzbHVveQVNk8NvDZcnWHht7t vbd220+rex9tMNXDu9btvt3fu2+w9h8MO2+GG4N9u78HYYeW1r2HbD+w7DDI/jDDbi+w0SHYdIty Sgw3bt4Vh24fGGD7DfYN2wdZZQMGLYb8MhnIbDfgyBexhrhix7vLKVhtrZQ65kUoWQaY/d3ItxJu GCgfmWIm6qBGsQYJWo4/ev9/W/q5TZUv1H2///f7w/othT9D7dL/ZaldJuC+NPt3uiul91H1f/b9 9+9ROyTvde6f+WUvf9+54MF1ybgUdp7UjgXctUf4TsnDTTHZExQmpwGyrkDBFrvZDwTT0vphNVgk iup/dNdlDkGiSmx9pmvC6EgoktbeiDEbCmfyHHJrjrtwQbuQru8MufLZCL6BcUt2K4+KbYVLVLth dfv+v/X9dL95agoV6utV8L6dKq652aNXXX90PrpYX//Sv19Xrav+l4Wv+6g03C/648+Cf+6j3/16 W/pwn9r2v+9B37v7Cf4vIg6gny3K/vEIMmKLLcU+4yI3t4/oY/f/+39S0gRe79Dorx1bRCjlOUpP xEht/0iDPG8d1KaFLbjcLaDxl3widEdEcNhgGmECERE6RHRsJZWxwUmxKhGP//yAspry01JDH//I C5ooy1Sa8SbU//H8tMGtx///LNLrxlnFV4yFfjIDAVePLYKeJEKP/lpjPUf//////////////+AC ACANZW5kc3RyZWFtIA1lbmRvYmoNNSAwIG9iag0yNTAyNg1lbmRvYmoNNCAwIG9iag08PCAvTGVu Z3RoIDYgMCBSID4+DXN0cmVhbQ1xIDYxMi4wMCAwIDAgNzkyLjAwIDAuMDAgMC4wMCBjbSAgMSBn IC9PYmozIERvIFENZW5kc3RyZWFtDQ1lbmRvYmoNNiAwIG9iag00OA1lbmRvYmoNNyAwIG9iag08 PA0vVHlwZSAvUGFnZQ0vTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQ0vQ3JvcEJveCBbMCAwIDYxMiA3 OTJdDS9QYXJlbnQgMiAwIFINIC9Sb3RhdGUgMCAvUmVzb3VyY2VzIDw8DS9Qcm9jU2V0IFsvUERG IC9JbWFnZUMgL0ltYWdlQiAvSW1hZ2VJXQ0vWE9iamVjdCA8PA0vT2JqOCA4IDAgUiAgID4+DSA+ Pg0vQ29udGVudHMgWyA5IDAgUiAgXQ0+Pg1lbmRvYmoNOCAwIG9iag08PCAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL05hbWUgL09iajggL1dpZHRoIDI1NTAgL0hlaWdodCAzMzAwIC9D b2xvclNwYWNlIC9EZXZpY2VHcmF5IC9CbGFja0lzMSAgdHJ1ZSAvQml0c1BlckNvbXBvbmVudCAx IC9MZW5ndGggMTAgMCBSIC9GaWx0ZXIgL0NDSVRURmF4RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAv SyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3/yAoW8f8sAirH8sqOJaaRWU1iB8shR08O uy1Ei431avu8P4lmKXGTYmFk2LgxJtWDeC1JtaLMNEWdKUm0waU0xohoHko07hEMTCUyPwzuncEC CCCa6k2/egkSTnUHH9abDhAkCI6wkOwuhhELoEIp45XE/oJBQS3eVyVwQQiqqq0CrvboLpJI7HRk C76WlxHpV19Ba+0WSeW5U9ekdg14QKGCdJbXrQoLqqobTwpSqvog9lbLhcIJAg6Xlcui4Zl6RXGj V9LoX9BEM4WCI6CLHe6wT9QQNBDF4V5XDIjhpZDRdEc1oJoi7H1rjTPARqCoI7mPBr534ajC1CTe QRcvwiBccjidjikcNKtIIJ8g3XInefMOagQZSJS5E4HDMilEcHwiCQVeryGUvP8IWhFCJh1ZkBsj hs0EJOi7V7B/isSGwcIyW5I7CtDKvMIjSMCpIEIwrsGdjYVdSqvkM0cEJ0ylIwt7CmtGFaDBC9BB J4YYQb5UZ2ke+TSI6PojpGggR5QFJhEIi6wv5FwbkdEcghHZLhs0kmUO5brQZgKQ8lRqtptLhCyP hYwZVENj3+togx2CjCWECSeTaA2BB2RQK/pq2a1klEI6DCCwQ9FJCIgytlV1kTQQgRTlDkQcoIQX XykksmxwwShEnqoT/O/17TwgQJiI9t2RjhqqBChEmkC6Sbk20BCkDChEGHWvuoW3TpCFvdJv6CQQ RBJYVvkgquDDBA9EHo8KvenkIL+EC7h3dumggiKBhAiLsd1Tw6eiFD6IUe+p0iTtEb8EHSkJWlC2 GoXXphIESyTaVeGwtwg6hBA/4XVLwTtQTKQegVqw3910kC7tBQng3IJD0EOEF/phOkvC6ppkYirt JPT8EGsmP1QWmQnqpNO7oikdKkCq/VbQT9qmEwna0ixwT7aDVeukFSraUKvsNBP1pKu6YXS9aVJN yPJ2mlTbSokOG2k3ZHXCztCRHdh9JEU17oIP10vpKtUuERHKH6p2NhVW7BvCq6p8SQ5kiVLhWget JhJ+kuqoLfdEY8Lpfsw/UFV0nhPV+gvS4kKMVKqTynB+sNeG6Xq0r9OvVaoIR6SIceuFSUg9LD3J D4TD/ZDMI/1phhrXaCu4SC6VBBL+lhXQVLrI3l0EC9tXQSf3QQIFaSvSwyDT//1Yeva/oJaXT/SW iIP9XXXELrapp/tpoUmmG9Kw3StKlpN+SppNq+6C/pL+k4S00FrtJaC1SC1S1YdoJNJaS5KURwMK 2uqpAw9IE+iOgv1CWkqXevhBU+vJjmHWlhLfXSTdIl/0EtB7rE9EcCO16pJvcigegxaCUtxrvQSj r39LSvVJUhlDkQdXWEC4WEvVaUjq8JdJulkGhPBnbqtVD5ApQVQbCCf6hBPpJL6VpV1vQn8VXqpd ljhcjHKf0q3b/raSTiSgEYPVUkr1IpZrjCBOk08ZbleE8Eq0lfddBLGqWNBKO8R0/wV6oJKgq3bS ztxGDI6+lw3QULlAat2k9NsIodHAYX1XWsJdU/EJEH06hAus6AvqkUBdLSelT4hr4QSWva+GIXtC IqulfitBZhYSWuoaKHxaRQvPIwGdOrCoQlVvO0iSfBg/VKE+ggrrVLtAv0/4rGvTqFjaCceIkEfV xVVXpr7IMGNYVf+5Bov/g0Frhe2FUHl1C9KoSdJLucWnX3dxTaYZQ7W6QS/QTeQyp7DCI6eZWJBo k5BuJrsL9QvRFHXuwles+ksL/UJUva0Tdiw/wlXqiT7a1UUqDYYVgvwv9Vsf103X7IKMDHaqF0/W FbBv0KUL6XZGDfS6DhhIMhCzBwzAaDiv2qzxdpVUGglTSQUPVprhe1pMMhYTSgsL6C2xVr+wyECs FvEgkNL6QVVOLJ2q2HCoJUGQTRNck5GYVWawmQjqwSbIeYwfb6CXQL7qEGtMMg3DTZCFStYX9rx7 KeM1TSTkfa0iISsm5Q4UIdiCpPCWawlNnMIJkEfDD6oFgvgk22rYQdXBiFZ1BOmFG/VV7In+h4sb SGhEaopDF0wtkhBadJJiILX0gS7S79PqdlCBhQZmC9bBUvtbjFDtNRwXik4IodYIdeTCBBNJtaCw QLwl38i2+6YZQ4Jir2C36FqnZQLBlDhY18GCFUCQsegiXBcEk4hYJbhLYNJsIEGQcSXxahbQZhi/ HaERGFtcVYIER06gggZGLXpiF2EF3+HWGYdJgwQYLUfw1bBUI9YUfMA4ggqWF4IK2D9LqLBZ9E8R 4leXGwqprocMh5K9zjhMSC+xdRCJlmwx7BdggqYew0EGljiYRHDiJFgX3rGgyh7BHYGsMgQNkCNl oTCwkrLfBbDBBZGtkNiddMocJLR8M7IQb0OogypDVeqFkTcCccigXVkIKuIWCTIF9LpCHrIo7F2m 8RrYUh5AwUSxJeDMUpqioFYdQ8UoQ2h8XZEFwQzjgvodgkyMCshm+HDaWVy0Noe8GU4UEI7+wsEQ mwsNXGFBBdOIr/hgsoDkdB61yGq3p66jcMoThBCHwcugtEGtvr9OtoaPAgahWNZDNbiFjjQqCIeR +5HaU7W9kFBuaZY/iCI6MhDsMZjS2di2yDDJf+EIi6Cgqpmo6j0gYYSI6t/fyFXTwo8rWR8jmul5 kXDidwoIj/KoiODFL9BcRtoXvt4QQ8Eyj1esJc0gmmr+oWnYTT9/CV880QzueKvj4S+EHCEN/3SI WPtNev1CVeL9LXwl32Q7ta69EJT7nHWuu+gS1xq0vuqC9uQ8P/68IKqpPSaWt3oKu17gl/1S3S9i np2tL/e1qvpL4XQJe9ul/4rXSahIKtPBWquKV6I6fpwr9f1WFDBKtUuNaCY/r/sFT+lX0SHKA0Oq V2txYTuvp9haVcYWGC7Xiok3KV9dy3KMfW6hB1pVe2n4a7JZwtKO2E+0uwePXBu8Ldh52Yd127dt KodxsLysTdxW5Fs7ljka4G7a8REg45Y5WwMw5UH2VOQzufDjmbBmvEQzBnZqKXBoI+bTcREiudsE oVqJBysqBEWTp4g66BkaQIOJF3zDIMrYCl2DI5EcZ8Dw0yPNsgcNgECid2GSEL5dAnDGVylEDZHA 8GouyOB4NyOiPmM2E2RdHETMDwhiEnA8GUOQIG8txMGQuQkSy4HhrWRMCIZDUHK3pbIsDEtywMF8 joTsCy4HsNkrBIiIlIGYRwfDDlkIR5kYbYNxHwYO22DD2THbB21cMH3bDB3HDB7bDIEANq3DfsMO +GHuww+53AYvYP8GGR13DFmQF7TD38Nv7e7uw3+G26dhsf3fRTuWQtXY3/bLatR9xrJjsgSIWmy3 AkTPPFeMRbLcY0Q24KV67cRJQVV/oResqu2iFAst1Ve26CKoGZHkx43ndojouf87mncR67jf/29f e27XreU76/iq6Xtf+3/1cH6S52T3uu+v//d1LUJVr03yWH3VD3yUBfrpD3jrW2HyuVxe+HojHD8S IupBUgTpBvogXHOuLSH5A0lmpQm1oQZHRHZjVutTuiOZoyPGEalgmkHaxESBDkoIlnHKGiUrt2Kk lyOi4E6keLvv7oRERIZxz7VEOEiCIjgeVISDA5Q58Io5tkuGCOPC1ZeFDiRqpUEcGHKHKc8HMaTC ERSERIsEeyi4XCXoTMMgZLhDDI4NhHI2iOjaqkCIsghEgocpycFjlbt12RwtkEy6qRUMkNi0FEIR ESQ5FwjLLrFKVYZvIWZ4M5HMjhkBqKoIESkMwxmIhokI1IvmwPBYI8Y99hNHBmwbeIidMjhkBmUs hgcocrghERESfL5HRHBcjguXA8G5HGbRHUOGkwlQh8SUAeBPoIk0IiIiInRI7iIjdIGC/mQwD8zR HRcGjBBCIk6LojghfMAeDtqPIFaYGUZKMj5JoRBlYUPoJCIiGcc+W0tkNROtiIiJQLQJCJEI2Cqx XIZqYC1S0EJCAYaUh5tXS0EW5WdYjqkgQX/SwgluvSQQWn1VQQLT+kkCCpEof9IrAMWk2ulUIL3+ ggih0ECpJv+4QSpN9UiGkEQoCH2/hLSCSpX6UclYaNJ0q0kRcNlJN/SSBBEkWtf0gSHSH0VxZILB Av+KpEIjAGC9kdNVK4G1SUp0CEE8Ya8bSR8NYcVq8SGkbAX4ggS9ot1YKf3RBWNirlMCy8g2mwLx sMMg0mxL7luYiOZHyOrS4iI/5DjkDw6ZnUfYVwz8fyY5CnKOfihyIOqDERERENGatY+u/H//8swQ y1ik+g4fQa9O/YTupaikr+RTLU4Oid+WSicEy1DVAge+/oIQ6cgXxUNFctSfr2hUINfvVyMcqgfS fDCzItSQnQJ61ZTdRTMuoQPQ/LOpIe09tUrjhb7+up11TDfXLMBpTtaCwVsKUOm/5NgQggbnaqDC S0LbVLybFQdNTsL0zi1XYa1wW9DVKvdteTYTDOuEQwO763w/wkuiEP1XTda4IhnNhvwkrpfsL8my sCKUIEElr93+CBVaR9EdBBekdkzpvruEQXNi0JUExCvwTv3+kgtIMrRKkC19/RBDYLSO+hus71QJ X+vgh9JfOzoEILe+toEgsJX0EJCgf/vBHsf1U7sNHf/oeFfR2OBBxfX9cLM61CILlPVc71PaRN8r hf0iFdEIjAhHoZdEcibOvcp1p/CDaS9cIIUIiIkM4QpcTIzlbWa4JZO16Ic2S/qvyMbZDCmQWiOI YwmOuvhPoGtrvqgqI+EjIsSEw7TI+E79LYRH0yDy4t4a9OvwmwWKiLU1/WglGDKTPBFBCHW10oqt SVhrEcwRDwgjweMrKhNVsF5EBy6CDU6g35bmiTT/9skoy6FBChiJRJJvREBjCVQYoT41KAy4bCci jlDtf7ShtCCISSmEOnqQwUauyhw2Ca14WCE4LelXshgtQIJBIhL3pLhJMYMQbRCPRDOOUOqluLrg g6//IZymkSsHIegSCwXriqCB8LkMDofSYQQv/T0yBcSoESoM4IhygpzrMq0kJ8CNchSCXJODtUgi CU7hwtL11DIZZiiRZCBkDBFTSXSyVAXsOGH0siEBe0tqyH/eDDwprQVBlQgqBWFDTpMmPIoiOGXu ynfrQR25K7aVSI3EbpKs7qBd0kwoVDtUg6hJggQlHQQrxt0lgqpsNJQZ26ipD9fOy4dUlRDOPRCw wSSwtNqIiEC0w3FJY3bVIfvCV0dkxcIocK5CDxQIHTSTWR7U4QVeHpe90vjrWDfFKgg1CDohRzQC I/pBaVWElhul6hhpBKlwvg/WgtAgqQcIIaVVcIKccmOend4hX4o6pL7W07wkEkER0rmGYDwW6SSI 3oh9hVKx3wWnuHQYVvwX+qWh1Q0EEgghUJBaYPCCF1L7YLSe3hmwSuGiFH79oIJIJekhHCpchn2U Ql+hW/DbEJewQX/Wv01R7I6oEgRQ4SUPCWxuEE3dOtWGCXWq0CSrVUoqCQQp2Gdl+IXC0rqmwVUy HcJ7ylpJ1BKk0wyxzhECBNEgNASpkDG62wl2mQQG7omO6pKKvbgwSWgvWI2EszDUcgaI4Z4aT0wm m6atsEOwV1sNfBKk3YhRCoTgLwwl7Cab0kwwwQgwX7DCRGXhEMDtQlaUhmwE0GgxStMhBpPtIOJ2 Wx/DBXeGRZp6UJbG2QMEqhIILBeGU5Qon6TYISS4sRwQ5voCq8MVGxCh3DKgCITQetoRVB6SbRDN XViQ0G5ByaSbYTyBFFIMDpsERMchs0PtCDCsXD1SDohpjlDnXIDEdwa632DMIuC5fs7cHEWC1buE mzsWaEaIKhcqDm43wZQ5DjSYKmuIoWzvER0GUOba3r1WgwyBxhUiQgyna1iLsFQYVMJhiIjX7S25 B3IbQ+RhBFq+KhgsMhoHCDfkCqqEE9hs+yOGk5vNojA1PD44aEH1JdFwxqt2xPg1YiDIZUXcawyh wT9CUFwkLDYYMoc7mHBwZEwY6oPiNt8466TsMREzAhhEsPERyNNfoeEmzWEIsGECH2GFSxqk2eRH TYN77DBL+gmxw2GD9WKtK6uCBC5BQj3/0gQUMQ2GGtdftLLp29PBp/VNi3e+GVBCDglXoJyOnBhu uM453CC1/puwbWsRER6vXt5VP/8LbDeQov+o+6pe9cmwkIbyOEI8X3w24S6/k2V5cGxW70C/9k2D GEJBlgoDb+l/8m1APAubwX9BX76JtwHgpfkbX/+Q1Qyh+6ppJewuiGWJfVJLXHogir7IcXRHDKSJ 2FXoNeT3UUOQ2DvsuBwR4kxSBNda8eInAphPcRIYHEhnvaVfcf2I7pXOL2L5CtNtLVEF2gr9aTkF 4KOUOUOfChysIUffXIGGgb99Nk1QSDSOU5ODD2wkrUg1NCvdfskuYRHRjLoj5HMRE/m8jkeyOiPE fI4J9miTkFdoPr7eIiIiIiIiInBG0s2E5AoHOyma+Trb5Y9jYuoka4Ec2J+4+/sLszAsS/XpJP3l OCkR0CBD4a/sLeqJjI4aoilRBDcs/iu1iZo4yPkfI8c+n+wtqQQiIiIj3pVSUNzA5aFhLK4lJr0L 2vD6H6WnSxVel7/qlhJ062qutaJDtdqzQ1SSXDfhqlINzcT6Wk2ONKGR2R0bRHSVBJ6b+hEHEGXM g0UtHDI+bRF7VL2/TGgZHDEmOctBKRwMEcUjg2kcjCXS1+oIocRBEcGC7MIuIR8ujAUjm8RESNzw YcpeaUJKkH7TUREREREREh5GWknp/aIGLKcjHEhkAtSWOglX+yxyGE4OkglpML6VEUA8MGEZsjhl EcDwyyORHyYzYz0YRHzGR8LhJ8V8UTNEdFwblwQj4iJFgPDkeI6I4KZfIeQaIqwRQ+klS7FCIiJ2 WgeBcjgeEI7I+Qwy8IJ/LSFForlYZAZhcNRQlq48rgoZALVBK67CB1CC9dFdZRgy+XDSOoHgb4QS 18REjIuZCwPDmh0EuuHETt8kw0KoIJx8kOhFUgQI2tqPQU2gQSr9IKkZgw7d/TiCI6HXpBCEO/VA vJvWvSINQ4V3k2El0qFsjrEenIZS5cSZJ7yDDlLmCDAU/siQCFEGS/og8joSOo+yhwjWiPDpn0/E QghBlDhDQlcjLteIiOmyY53NniyvBCJRGEXy4GCPmLiIiIiP/ICoa5ahaviP5Zgfwg9J9d5NyztK TcoHvBb0Fp0pLrtE3GwYTIyvCLczQW/iW5J4IIveWVZ94hBL63EEQwO1SW+TdKUJggQ70+TYGy6E s4oCWRx3mT6fQkJsuU3qLN9QrN/aZbqVRf3iFCBY9ekGUyk9MKgXCqnof6Xqv9zsulQXdqFXhm+k tX118Q/UL1OyhVrpRhFuLtBdZ2KaIqddejstUIKqXghqv8Wi3Gwwl9HYEBG6lcWXzsuxCKHf6hEH H0SxKdq8+jf/UXrXOwYZ6NGR9yKsS3hIhjehG4v/QVLrhBRQjI0MIKLCDI4i/wRx2v4IguMDgiPl vAbCPHeYRQ5Haa+oQ69JEOTLHIZbniJkqI7QBikIlONRrUhhynS16CQoIIjoJkTz6PeU+RJGsFBH IIocp2yhyhyhwX8JD/55AjjkY4TGwkIuyGJBpAwkkIj4L5bikQOVAk0usYoWUOkERIMrT0CFCRXS QqdrXrWibC/CrSWgkIYKEC2E02RB2mGhzsFMjr9pYJoJUv4QYJUzoFKSI69g1nygiOhwhb+0l5Hp /WmWORwCo6YSCDIwPgnBgytKIkygKERZsyFj9pUulVelQilDkMsdIMIjH+opWOczDQLBB9sJKdpE tBVXzyYd1yLUFCUIsceqd5HsE02Ekg634qkl94yHKXSYQIRCx6IceiKO6iRgQiyMNWyQiO0+2Euq CVJLnlIZxOlraWgg8K+QbqCx2EGSaVUINP6VPSWr5HQyBcCS1RLyIUegmqeEGuD7TV8EH8MMJK1V Ktewf2gSaIo45CjpNBL3sscONg01dNP3VD0qriw+kqWKkraq6pYeGmcYQfWE5Fcoeby64dJhCEqS 6h3S4LVLEJcLxIccNQgodkP+ztQiOEQIQ4QklylpMJClr2D6gqmoE9AqSwXBlOU45BvAgiOk+1sI h+oSC4ROnUNwksLedqAb7hKiGC9R6ZyiqET4YptEfHHdJ9ILBA0ovtpVSfnYoF8EmzMNEFBQqBAq TBnd1UIbX0ITYIhXMO16tpQtER/g3pBJClukHa0PRHRHQQSV4Tp9EUOkndil0usP2R0CvIdQ06Gs HiI1YenyJq0CJdql6Swl0ofiKWTGtINp2kqDeCSdvS1MOR57VYSq299kC8L64S6XuteEtUFddutK 61XZDP+26hJavhtQXqqSRh0NpVtImMjmqCz+vW8Et3wmFnaEsgg6UK4VKFoJQvHtPJ8IU4SS/O0Y KlIYzC2Qgw3OoTC0wqsij2gVCQR2tXQSCXVpNQQfYQTaTvkYgih7bWbQMpyhzjhcgxBhytGuNVCa RMcJJTQCEl9JJUEkiY/3GnhLVeDKAYqCsRER4u2ChdkYEaDUVBlwb02talOFBLp+ESd2lhBYX4RH YRMdbC929rwRQ6oOxwk6p6BUl/pBtYVgl1TsQ0Kx+nx20MNaW2tYSCQQVb7ph1UQo/iC+mrcZFwF woTBYUUnChLw10g3X0wqYXWGUOEGqjrYVMaqfwUElx0FtJYKhVkUcKtRZxy3DcaqoUINcREFX4Qb JsYUK4TtM8T0I4g4YNMGFUKQ0Jwn5DKdfsJMMZB67VCIi2LRHsIijnHBEdeDCYJLgoSr1bJsrRHM 0pCF01WhI5qOd0IpSFUqUhnoq+EEwY4nEdER0fzXl8juSUYTCUMZXUzTegZZKEsFC30oc7MKhiIi LhYYQvKHUECTCENDCQKQtZaf2wk3ak+bRHAoDWOMm8REQ0ExVq60HhkCRtREUcQtJMUwg1CVfWmI yCs5EHNBUFXBAhrDjQ030E1ZJishmFsYWGh4P0DWiDr6kex44YXDMfobQMj0FWVWSYg/BNoQf4wl 47IaWFSJfi/sISUlKuwvKfB/hhe2/6HXyKO/vbt0fDXX7Qt5HQZZ2+lXYsjvOgN8liLr9k3Hy6OG R/hBMjsj5Jh8lAY/k2BAOHbEQ33/JtmXI6xHRHRHA8Nwnhvr+W5oDBgDwa3b5PCq5VqvG23qOK3W wb2/6ht8kWeLLPRZXtVkD7Q7vT4cNe8byCqWFDlOVm/ynBF/7LwzkOOdz7ghIuFMgLWGETgVtrxE GCERfbHcJBhcVx22+0E+//2wlelu/IaLogRkfptJdvu8RIxyNxIVyrPZ3K2HdJO2tXcREWEMjoj5 gOR8vEdGeXRdEdEfLswttKSHdLbd2IiIiIiIiIMjiF7YpJ//xEdb7X9Wus4MftpukuiHTJ/2QcYU OUOSc2ntLkGEzm3sm7EREiYy+XCkcUvkfI4KTcdyChzphK1XcREREiRkdEcInVIQZHBuc+7VNCJ4 9riIZHVfsdBhpOIe9a0TdhgqJAFhNypX//GzWCmXQ/10ncGCH3/t5EkYR9EdFqpL1rq3iIiv1rrx 316t+Gkq6T9A+v/lcUQQNdLSb4p1hevhNUq1rhMm5iSwlpfCk3LojguqXsL5N6Bm66QvCZNhcGdJ Ba+ybeB4ZlJaXRAklURRyK5WEQTIaHKc7lDnHPBY5uLHIxzjmguynKHShL7yBRBTkEOU59iRQ4iJ BjynERERERERERIHgXhJBeFkUybrCsRESMgrCHBRIG44kMgFiioEraxHIxxEgwKCQyA2OT4oTQSC WOWYFqHZDIEHO5Q5A8CccgeGpZxzrUJBL71IZ8ERINsEM45KyhyGYrJUIcci+VBG5LD7UBYQLx8I 65HDIBgREM7kLI0SQJP7UTMZBooZHBQRwWS6EUkgRQ6XJvosUIiJwFQj4oKohfZaphaBkDFlt6oQ RqDY+gY3EUFkgG/hPVBJBLaDsJJIEccLeSHcNZjCEQTqgocrlg0KQLKkjMGFZQ4fqslQaVDD9Ig0 rokCBVSBh1DBIhlr1shgV93GQUWUvqJA4HBJGoUj9SbjakMfEwjikNscpyhyhzuUOVxRuXxfEGdc XINcFHi4iR0JIWXT8SuWsjhRERFITyDZ2po7JUVxVcRoQ4iV6I4hKtXw0IiTYFd9syWUWUIk69WM hG9Xuq/+H8dP/D+nLcocH18W++of6luNLb/RkFoaBlD/nYr2mdgsot/hrpu//06+9zP136p/wS/9 V1393vpP6/7hfv/VLHTp9PluKdkZ/+9fH6JD/6X+7f6376pJTINdB3r97p+ZCNBr9e1T1VX/v+9b f/6rT4Z2Up0//70toP/lSnv7uiCHZAtNt+5LUEGgs71Ca/hNtMk7YfqwgohwednQIP23VNtSX5GK O+mqFtaEGEUOK+gocKCENP//oRv6dhBBbe9af/6bYSTv/hb0SPUu+kyNdhBSE7wf20vQIjAQp4pB ndWRwMa6thKTDomPB//qkVYuEGhD8iSRCQ1hhAq0m7fuktV6YIHkNaaBaDYYWrV/1kw0vWlCYW74 p0DDFb7V+y1iaWIIjp+vu9ST0kg2iC5ml9t2/D8SULpL1/XhYRHbgvwreRYyOitekRRk61BOL/kW czBhLtPrphh/aSfIiNAwbyB6e2DwrBEVCtaVIIQg5DZM6daaq4SDaCS1W1TTVV8gxZnlwYDBEmKC OOSdaWqSlSRmxtwvWobqr0rBDCd2nqIioJAiOD0vXSY9a16CcJrWrZSwbVvC/ZZhkdi1+kveE9K9 sF9CsrIKq+F26UUR1X9KRdfgvWk6aqgrCq3hTVcMKgiFHBD9aSI4kDRHGuoL/uCIccP9whIg5X78 kD0WsKRHDS4rSX0CJw5rIjhh60QR31SC0RRwg3mx9cgqQhdtIKuxlDkMscK5EULXSoSgC5H/zwL+ lqqdxDC0S+6VbaQST0IModDwWqr0o94S/WEtA8aDNhsb6vsKvE4i4yPEf69a1RDQOCW4p1pdQQV6 HyGuOE9NxrxDCEegthdLkFxLwX9JBQgr4TaIZjnThben/cJuulSIQp00+kEsJBBA3VPIOeKTw5B3 QT/kQlC6+skWeQxrf6BUC6RBrGrCX20w69NsoGLa2ERX/wvo2vpLJwxhh1JOQIF8lX1eFhEO7+me Cpp+3aWr8EK8KlCTXVHROOgm20lCT/YYIt02QwcwcMoCWkva7BP1sUlstz2eAWK/vCiE13QibQhR wthglDeu/heKoJAg4iIpNfb139tjRQ7iv+DI66YL6YUJvCt7d0gv7UJthf8SKgoYmhW9IWktVyOl qFethBrqqrYh4/UFTVPsRwqf7QYIOwnFcpzDX8JhNj/tJXvBlDZQ4VMJLhk4WvxBkJsaC+2lpv2I zjll4YJ0mGb0gyGwcE1udp4V6DsKFfxERqoiiIBcR7FLVWqe9QjouEDCS0noNDCuuKjCHwt4ZIcL fZZ1UDBUH7C20vEYKGX7lnA2eA93sFSYS+E3Ijnka0pHA8JidUSjMRhK2Eqp2LusViIjwy3FQROx i/Xh/2CI/5BByhzDlhCGWb60mQjcmFpBvsjCyoKn9sIhjYS7BEf6CEafaZIddBhD6+rLcDWHO1Tv 1q0LiPdehX961X//+l/+l/69f69dE3mtavlSWyp1XuSwLf110D2fmlV1T31Wrrw9KvoiP29Sbpen +CJ12pNxtBJ69pDsYQof/kT+iyGqC/I2qyoDUDyh0nVdPJzycDhxp1+f/W09gorSoMKmXDtQ3H36 CY9P7vadL9UthpO2iBgcpz2fihyFNk+uk2k/Ig5GOUbLKa72EpCDpQaERa6vhnHKx7X9tBCP/36r Dj1bXca7f/biq7pNL12vu366w1vXv/hN736+tPrfbvfRJw/qTcmtJx+EHaTfoFpXvp9N/XSb/erf /pv66T/C6V9/p6qlr3f9rr6QaX1qL9Lqv+n0tp9VtVV8VvW9a8tARf7H1yFTIR9SDzcR0XRGBo9N k6wgguJgNQtBRVhIIUIjI4No9qzeYRHBn9FvM4iKuIISB7HLZhgppD4RA8kyCcgyDlJodJkMsctN J7JuNKQRNC1CO/9VLONoswH8fltWr9r/6r07/6V6epHUyqWoe9tKIxv1e0THRXf5NwPLM6JKdX9M twJIO4wnpMQ2miT+qdhOEq3UN9v9dNJa6boiD+odUg2aDSBzQ/C/0QQuEKkcyWSqZLSCBEfLrqmF oIWE3aiIh+m00rSIMRNMIpw+raaqn1RkFIwkIIvEm/T3VmkR0mg/MhZkdAqcYS6sa4JkcpT4PUjM MRHJDkG+pQ/1Ik6SVKhKemShBDzKcXDPK4M2kLIhF0XRdekg3ToWCXJxWrInhCRBy9CbwQJlXFUI P7CdUWOF1SWGkgmdkwYI6BJhZ8PGEEU4EHX6XhKg16+RIUjhVIRLYjhlOIhIw+DvTTrikq2oK/pk xkdIFiGRYIQcIECBDTr+ly6BXqqO90gmEyEEhY0KBAha+l6VIUKiiTQThJNqoT8EEeUSFHKdJ+r/ +Q9ohAXpZQ6ChU9FOk0Rf0v7S65nqIRB5ukI05BQIxSoKKvVfXoU0kCr8N4QWECJjhL3Rh4S01RO 8IEVAJB0iC48IhHhh4SLoLCOaO7Xpf++GCqJMcK+ngmythsLrCCQtXQwtX8Jbri0S6I4UIQzYhgI qBWEmUOgxpxSl0EIVQ6W4S90oZIRHQKxHuk9Rh30IvhWu6qyQ70QzjiIVB6pUE53CI4JpL3vwk7Z Hy8F9iwinIKEU0qhY3qbQIpyMelX8JaERSYJHWDGgg/XandAvaFsb8OrEJJtvOZHQIFJjkGMQ6Wk 2H0I0rjrTBaERhiQjgpBBwmHSqoPyDQPhV4QaqQrnHlIiOSCxSQXn0Rwj6IMQShkcC6BemELBMRI NxqIpEdBhdUhklvZCz2bDkdF21e0EDLHCcZE3gS5gQuOgXhQ4KRXQug/pCIZBeAoSVIRqrwmEIir ZCl+qaFVkNg+ygEWEwWw0/GGmccKthOhVCOEGvLOL5Bo8iPkciXC4Mw5WoVJVyMcpwmmw66CmgM8 w7ERrhXEY0/vMAecVVQWwsNvWJBadS4inCdJMiERx9ZDKHOOeh4KHKHIJ7rSDO4JWsYJbUhNFTZe QRHSsoc7lUKuQitNRFsMLHrJAaERxSEIIjofLor15Iz6zXnEoZC7G9ehEXHoRccRdn2UIiEYRH4X pehDKK44iI/6x3vb/qWcGtV2u409foyJyXV/Ttf9U7Hy39P3rO6qK/1Ff//Xx7d2/2FTciU36/+s yG19fSH+f/7V2n/v5ED0tL032t/D6WzP6kx3/Qp7SDetXVdvpa5VhXbX+TcbTnpFvr8tylJZQ7Qe mEuH9CXS41WwgvC9ClcLuEqYrEtytAih9U+0utCK67pOwqrS7aVMF1/YoRsjhwYV135BRB0yOq9V EiJhb+nuQ2xzpgKDf/EjTBWq6ZHXIE7lJgUetRM0pIBkr7DGiXDa6SSuRQDGvk35LFvVW1GwRHVV UPofhJv9b/+1DfutW+0l1ft+vrWFD/nH6VfoMLx/i6/FWvt/8GF6x9/1fX27XsJupZxJLWh0/yDd M63mEQQNbWJEgUuCFU5A8M6ZJuyB6HMORUyBpFlUIliZBkcuyuCCZcZPk3NO4jJWUOUOU5AgWiTc nFIkz6MlarQiIpY2KRXTot9VevxG6h30xuLWtOF+hSst1tFvyvomPTT+lw1r7wa/S0HXLSHXXqVF x+4dJ2tKml/7pJe9ciSa+vVpilnY33LcDWl9OE+JZgndKvrChB6peqZE1cL60rpAg+F9LLcyT6CT qF/FP1XrahBesLuEQj+guvwugn4hb6Ce6CX/vvhBVpGQIiPaTSv0ukEhZSmvDwfpdhIyLA4RCbBP pDVBJYQQUF/q6C8EEqIZ9lK9TsW/pYQR3VKEGvudjYtaXMwYIiKjVSrWad+RzLpI7UAR0FVBVsJ6 aZgUls5HMySkqESW8neoZdUlwiCRVQsjvyFtrkoUSCiRS8hAzVKWCtepCy0YQVXgkgga0CIaI4ew Qs7q2sjA0si6I6I5kcFjlkA5pOIWuEoQ8IdfU5YJkE1Iwy4Hg9xFOC10vhZUL1x5BogEeQIhYM4i qqZTDGFwgkiOuggS3SnXT0QUDGdETowGQJdMEFSpIEo6wukFhMl16BHMxm0hEQXzI1QRBxldKukl op+SH4TCZF5SOjGRwIPhkilx1REyEKsIiD+CrVBfjJjlwUOaD7EBhVOgLYbl8joJ9EjztbQXS+F9 ILs0y6TxEROwwXCoSGSBwMXQWEJBH4S+l+lofoIRIZIFYkr+EC8JdJa6Xi/ILZjkGILcJLoJJEEp 0tap+l/kMkFo5CasLSS19BL30kkkq8hkhOIMOSsqCVQQTS3pFRSLrwl+sP/XkMgNQcgoHKc4ZC0j pJoK9aaC4qq69LquQPBpHIMsGsEZo2j5sEMKqhKiKOuKSwXWnd0tJKtSB4KDk05ICiNBaXWRR8VV U64Wc+HkCr+kvkGcMupfFJL0ENBdJa4WtsHv0l6ShkDgRf60l+C9Y9KF7yoFh/peDKcgYHIJa19U ER1VJa9V6itg6CWvBrWIZFmIX1VViFukq6S8KqD4JLuS9ar0/S/SVJLJv9JBW4KmoeC62dREGlVV XDC+lQQXqDKHBJdJAsap7LovpNUiFcodBsKt1C8zCf66VCP0l6EN2KlwI9iKbCTQKsJKNV0kF+cX sJLwgeIhL1GqX57qtVSrxrSSJj+iJl0/tV1CwQX9YS6U2gRTvhL8Y4KuEDTTXCtLJCv0kvsSk0n4 Sgvaa6ZAhQELSVIbCHp8IJLMJsKPVIX6hUk01XVBpetJ8KwZDRzBBXWttlDhSDBjhgg0KVVBVtUl ocREJ7peNMKspEDC4UIH8UK9kM3X5hYLBlDhHYtDiNDCIovhNVCviGEos+wopUC1HahDQYJ9C0Ii l4dBUDIYJ4braSGSJAgZcFAbhSzigZyIRGmJXIWL4OI/CGdAbj+N7jSaV/0L+oYpfk0FOQU3LZSs rcyisrUo3La7cSnRHZHB8Ts1QiJ2Jo7xGUIgiWtYiOR0IiPV+khHHX+//f+tL//3+te8PXJQsSud X06Gukfu/dX9U/9dftevX3//npV6XZ1v/6fSl1+wS//2Er8btul117S+9egquq7r121iFv0qafS9 0N33p/StD/X3r/v1p/e6+iMd/6b9qrfp6Yf1Sfr9/8N/0m/0r/6f9//p/xj/y0Zerh+Tdd1ocm5d Q/1cHrtW/+RSb/6bD364NFoF1q8m8/TaLQJhfXriWgCDP09tU17UHrgvW9GHyx5ZStJ3cpQO9Oli FqgZHRGw07X8m4a/EXFe4RGbFyDETqvtWl2drCkOeUC9ybwv8m+rtEXWvZA8hyjf2k+kHTlp99kG c31FKl+KhdlnCkR2cIwzkGm9U8JesRCKrPQo3FahTidV+IQQkdGGJtCsYnZSjtOiPdBBTX4iIvQn kVhCGypKGQJLj0tIRFOhzI1RrQQRHz6MJzWjy/S9CISERxHbYSusJZJsjxHuWaWIySlSuukkCEd1 HCBP0nmsNlIswNjYS/h5IAx08Euu0jMMv+EtMJXmwzOuFtJtYgqp4Ig49SgTwzZQK6ThBVFkrRVp JRf0uEFnSOxZHa0rTCZGJKg3IFxym6WtRBen9psoStvCHpVprglp2lmQ3JMgwbX1C1VTMNJtb9A+ QQ2nwgQLUlwj8LtuuwRTplDkzYPom6qC6pAgwmRVchlqdXXwhiPom6kGfCnUNmRiBPRAgc63W0tM rSC9hE3LAMa2yh9hMjS2EOiN3DrtBhKo1SgmlpprhlDlOC6dtSr+QVAYheQzj8KumqeZrEfS78qW czxHEp2URIyOZHA8GXULiQzuQ0oKJEQ/CdoPpv77KRmwPMjg5cFBiOZwUuRHCGAyAUEczmR4jj5Z mp3nERwPBQXI99eYSrepzQhmeEQIHKmkjrlwMw2jC4ViIiJC2ZDHCD9fIIj+XRHJCIiIhkYgphEd EcDQEqEybi4ZAKCOGCOjCLhQiHeNp2ptFRlwwRwNgZpHV+IiIjI6Na82zGbRHAlfU9sYoJCIiQJQ MNx08UQyQL8bhd0mIkFsCgchkA0Dmcg8HHIYHIIOQ+pXlDkx3SYUgV2VxJyiDQYcgaASDhI8Hwhk IcvAQiInBUEIidER0RwPDbvLNwUgqTCI6FoREkI8BpkfI+bQiJGIuZ4GgwzAhhGEXzZl0bzaLoxi LFCJJ5HA8McWSg8Fp9Dia0RyI4ZIaRHBrI+R0fGXRHyOB4cREXkMrVCIiIiItCZo4jgLVWEPWoiU 4YI4ZAKpJx4i6I5CLBCJmRsFyODSeNwoShCJDyODLx2ugZHMocgeHHIH45Q5Y5RZpoJ8sdHQCHVE F/0S5tCdAQwGeqj5B1CyEOQUxwgZxyRyIQT33SpYqtuCc+kgThCD3vsL0ahlxkcFAi2cBO/cFYUL oIE2KQJ499zqJ055Moc7kIOo6dJBKq1fC6ChP/DNA+qiIhrr9Kgk0k8U9AmYS0vsjgR1rT/S4LTB aVJAop8swY3uK6Wuv0sEEGq2EuZhnI5IivuC8Nrqva7QqKGugrRhEcG7YSb6bTtVV1QYUJagmccL aWIgg6V9RDsgvvrwSiGChvwhHwkEuE31DQYWlVAyknphdLBYL9RHGsfqF0CCgrpu9UuLoEwlBLhN IJusJoajDCagiOggmCUK3wgh0hWEISZCE6Cf0rXDKAwGWB0m+lXyI6FUm/BfxC0vwt1DWgm+P8FQ S/6Vahv/hhJoKvVJAyJt1TdfoVSq+69da1pBdx6VJ/rX/SqmvhJVHuEv3pKlrBUoX0qflmCFhJR2 WYOGacRZf87GgxXLOCIjgb+gvhCGSAg6CCV0PDI5CetYZUhdeQzYMOU54WP5blWcqIMOFYS8IRBk J8shav+ONL/0F72kuuKXfXqklfdKtX38Jf0vlLWl8rI9L5K2E9BV9VSvpK6MOqf3p2t3wa+sz8f4 pL71/kjun+nhV/dJf3OmR109/CH2tfS7/67b/sJXDX9pYf+6CUG++6Tu9Xj3/bCa/10uR1XaFK/w gte3C3zKi00q691/04Xx7a7KH6JDhhq6HpONf4f62/Wgn9rsNb2od/03+t/Xv9Vf9b+/Hqtf19Fu nVBrre18cf63V61/7qpaC3/p1/O1tZQ/9PH6r2oPUyNf53AYLIsO8iNfBkUBVtbT/Gdk0npQ8r8v pFvNEGlOy6J0mSH2mVxwx2hETsQjUk8do6ojERC7c4kD7BCKQ0IiPeIKRpH/hFWQPN1zPW1CiJCl xBkNKyoPMpyz5MevjSIQczoJ8sw1QiIrt/6I9KfHS6/hJEoadUnrVdJSKChPuErWvQQQQVO0HJuk Er38JBBAt1EEHvS0uEECCRJ3wT1v2khCChfRQ8p1/roJBJN3CE47GtL7wiEUk30yPHjX/VIILDdQ kNFQv9aVJJegsS90/XSCSbuggoX069JAhepZphIKuvXdJBN8UlfWtVwk/pwRh6/W6SV8JIER+M6X R2IUX+gv1Tcp4XUcrK6SVvSioIFqn+mVfTel3hKI69FOFCV+qpN9c0WuiK7zX6akVyJojpaSKi6p KIUKR0XReJ0bBXKqgv1YQcaqQiq774QMEIiI2UQlIz1wQYK5TqiHkcHSTfpBTQQIbKp16CphaOou Zg3SbIT65ToIRkLBpu9SEBcKlYQebDKqwT7hCKJYGpt+RgaMJYT12wV6lrAuXDIDUC7qFBJVeyMi kSqk2ldwQ116QWgsJqE9awSe5XChCOlBEDA5McqF/qoS7BU6kIGlbCC4UrlgLohkAQOdyPCrCRY4 IEpVFTqkklCVVXGkmwgvyKOQRpFJA8Noc8FWcchXIu8Ehxyq+nWEQ45Q6SSdEEHg0v+gXqzwQgTR TkDwai70QhP61QtaWgTap6SsQm7sMzFCcSCyOUghiEETH1BLuuECTQSWgT0q+1XDBsMJMgbnKoqQ 9BLrWwSQSpQkH0SH3pMK6YYM+QKiBA5IcpyC+QlC0Ka/WklIgNCT0aL19ektMNkQ4KRcCiIWgj3V SGB6gvhLwkagUVFD6Tt9BX3EVCBFDuqS0lMJELY6OqW3VOgsF16XdKvoMIGxYTCvFgog4JJK0RR/ YS1BahV4SpvpNdgwhFBUoZWhBjAk+kn4+LDS62E04fhEUd/BprL1DIrnHDYQT8Evr5Q+qrBJ4eoS DfwyGa0hUFEcIEInfgiCD3ZxwlqvEnPoLgglZBefCCb9Fu8RwYYVMQhivWrhtcgw99pJsuDGx0Er +IZscFSBU3cbtJQYarIx2krEE7ekG/psMMFRFya4hZdJNNQW2Cw2EklhpUEw1qkHGELC2vdhcE9m gWDVJhYfCV/q+E6BRjBNBn0wZHDDdJUp2VBgutBBh+1DbCYKgwWNDxVtBJgsR0E3Wlb4XCaq2mxC Upywa0nSvViItbtU6iin7SCa+uyhyFVoU4VlaQQQj3T/psT6Pqt9NL0EGq3uIvgyPiCDpwk/Qrqy 6sWxYpQQS216sXvYYJK4pbvsqYcjnFdpdsjpWmU4gqX/F0qSIu7BPaC7ZgO4hhVTDXseNKw6000Z TdSBGz9gwRN9E0Nulot9Qgik1Wx2El8yqJekKXLOCrS2W+Gmd3mFhK45xGMuGgqEXDHVYaERFnad EdUl4oRLIoRX0RA0VhJggrSIHn0REdfXQQXkC45UHHIZmq0FbkMKChy+KCUgYVFDotxFIm344y3s 7gr+rhqvaZ5a66cftrap9Le3f6XakktL/6fW/39tXkWS9e/TrT/fZuXq9v/9V/XXLOULh6/X/7+1 1isL+Z5rlS9KH/tdQRB6S0wfwrr66Hgg17aXYS/ZxyEmrxWqCI6QrFiqtdhRlj8Pet1/RQ5Q65bo E7QSs1kQdYjXGnSoQwQ4P+PrLTFRblui4UJeCpWrCHUd7hrfVql9fTr2VxTI/et/BC31/gvp6XBL 0Ru69IFek3XwS+n/oF4XH4JWCKfV+0QoXHSbXyGwcqZRyoOOccrOk36DEREREgyGwXS/g3G3XK4m B4ZcLy0iFyulAf12PLfQUjZK2l6qn+tV1vr/9UH60OPa0Ev9/119Yfrr/6wX+TMPXySho0uStEcM 22+RsG0m4J1zssWQgKXbwghz6MAzVqgrSGNtUEMgsDlDlDsiSpYyConQk35EeIsjnfkMoVQwhQRb 6KqCOxdMgQCIIITCEe4k26Em4ojHa8RLIMSikEEdpTzjvQRHQi0XsZa4aEREeP5ZlfoE+F2npd/S 6Xr1eFVLtFrBfsRtV9yzNXwXheE6qW0qr0W5YkH4QhvUId5bli7BDx/LUELQlcWW0+1xvyzEDqvy 0kLpj0uWcta6eFy3NcUthMiOuCDOg/pugvds6aT9wxvfW393/vvV/wrLUu00/elT7uWQYC4crp1T fJvqDWUgF7T/ghtp1tQiB4aGQp5bltdh0CIHgw9Vvsg/5BB1k3J/3wyDA9AgZArdIMuofkNfDFQi MRIzYyOCWwhO3VkK7UTsDPO8zCtPQiIoKh3zsNHdojb0HoQ+DUzxVxoRuu4dQYS736oPT5b1Cark KWUi3T74/uriklf9p185/3sL6vukvoi32C7+3jrtXcFx/TI9/TdOVySr3tLvhbxK5jW30W4i2ut3 s7q19ZWA/DtLWnfT1qV0vL+Fwn/qt19XQtyVHfeurpZ2LK7O0pL1O0muq/1brthB/9XWHtIiwcda T3r+nSa96rBFP4RHQj//+nfa/EOKpKJuwtnSqtV1SSC107faC/oNf6/w/6Yf2v6+ZjSa9LX/ZFdu yJvbvC6fpuvaWkv1Ctl/Xj179M7W4oS+sLp17wmJGOc3ESRJO1rhO/QiHkTL/1/jEH2C2GtEQf/h OHoP61/6D7CC/30RB3rkubDVOtUksJl77+lbWF/brRCDtB/aa152B+hIh+g+2lT8LdLvQWmQRBkN upW6lKvKH3yGXG2D9qqeEm9J6jVMS5MocpwXapAg0sJpMPjqyO1toJ/S721S0yUBgRBmc0HI5poi u6UJ+g9h69hi+EF+q63wtMg8EGIi6mxGvSCeoTVg3fvsVd6C+F/2p8MpcE6b1906ZCVwe7e1+l6v 1psMEcd8Wt4STqk5DRsmHcuhCxNfVu2FVa9pN9a8f6tpGgObSQRAjb05DK2DD8cLph/voKzcxV9e xINx37qhQIQ81BlqoQMG/UE++mNa4Tp+tEY9kCEfjrSQPRBx2a0gzshsP6X3relF9rSXwV6dUnSe gmwTTCb/YXbeg2tILTevigXyC90tBwrQhOCaaYf6C69OFSBkcMrbquqrRBJtYXBPtptpt/p9vkbt q0KrTr61diCSRBOChO1+ER6f1qW/Bn0g2P09VuEl4LCCgpwNSoIIOT9JcORNTud1T/hSn7lcyMF0 mHwnvpbrqmCBJBXiDBCNYVxEQl3qEQ8IIiLmqoXq9QRT26XyE8ydLtBhGEEFV9UrJjlD6hf6WF7u gm02Qai7q/2Lqumhrt9BJiO6X8VrqSHXt1Io6vb1S6X2wSq296bX30CUE7dFAdQk+zCO9pPt1W0G QmQkt2qS/S91gn9+m7HVp1qgwl8RtaynV8JUtIJfWEvvpP97G0oME0v/i/pWlpXSX/+rrVr8mD6W 5DxdSGrqlrSX4Vft8K96QuNC1C20CyQE1b2gkuoJNXWt9vhdbtU97bJnYRN5mgiBDo0bel/QST6V qu/vvh+FVWLhJCI0m6oEus8iODvoLDIIvn/6+1i04by4VhbahhJepHDP9cmuHu/Q6sIMLGtimEwb eJ8F14r666p7+HFzutuHphQ287IReLhsYfC9pf2+O4i9W0yhwTHxEF8LIjpql+6+ItQQyC4E9hJL CwuPf7fcWmF1XUg4FIYv+3+mhEPcKuRBOC+3r/F2mccJrHBbWH1pcNBoQynKHC7sJVTe/1aERFph 4QXd9u/LIa5N1uHiE9MHa63y3ohYXSw+2tLYjCHet1fQQJ26ZXQmGpNw9LpAkg99ivBRLc6CQcPc Q1GVkNmgQtaBrJYGnpDsGCoiYKpZXxCCMhnUYZ0zgFClfEvzaMlmOyFEY6IQelcUELigv4yB5DlX LMoggn+iBRB0Q0XSpKt5LCGVZRREsoxOR8ytGarGudcj40IiIlchIF3cREUrMq4yhfLIZppxHuKX XS+Gq+WcXQ18a7j1/zsFWWgmq8p4/0imBK4xv8thaVLxGuWusL4nYLrUthbQmQGquWuSoRWrO3IK ZFhVSC1D0d38KoiI8tck7v1qpZoGvCG8OtezJbXxK4tmEV1VctcaRdZCZSLEj49CDURoalriAXzI bV8EFlTQj2EwiOh7IyYzvTqEeAUIk0N6FlK3xX0WqWdDy3w87qx2CZHi+IleHcIRl5rSFjtMs2f2 RX16JxBrgwi0ifXFb4+/XYfb/31dW+3b9Bv2Wk69+7LNE0NWxMjVaBFOxuV1sC5NyeWpahW1O+S2 yuqIGpGOQjkxyQ5ISYk07idAwSpRERIMYVVWdlKy3DxK5SoiGW5QjiLIJXGhHK5KhEqEdzRBo7W9 bqkInVCImXqy/d8RxysozXkY5XHenQiTe1eEImrNERwaSyVvsYWhE8ZHAhTslR2lf2yuS7iUZhk2 7CKHaapVfx37/6SriPfqTcpV7bXu6cayDm5R7W0kuyGc3EuTaeutqWU16hh+K77d3BlWDp5Id60o XiaB8qSI7ybTTXf6dQ3ZFMEINMSU6uvT929MwDDX+q4WraWE8Xvd/u/Fa/6pd9fatV778hYK8L7T b6Xr4hBDddJevXhINdb9UqluOGfQS5bjSvSf64SLcqVYT9akh9vrpK7oFaF+PS+jjtrqy4YulKla +tjLeworHS6dOmdqSyuJ9aB/9JZMernQx9dv1f/9J5OJaX8iK/bVD001VP9w7pdLfpaCyEb09uGs gvH1QSlWjz9PTta2gwlIg5U+WSF60JcISx/4QaDMiyru2sEPk3MwnVWCYJ+p3qE1TMhYWoO31rRN 1oGiinVAmn9ndAxp2ZDQIfReI6LyUJ6DSftSRLeFJdBfUjSI5kdhLTKRGOyBR26KwDBcNhqXfk3a 16X5E1gnYJ+mCEQ1jQkpCTTIGgTBCygfXdiunBFD1STJNEcM6qFIwGNVCeEDJcegZL4QZHYIMq1h Uta0Gvir8ENbwXRCvCdyGi4TTIV2mR44gQiHBmoVW6/4+CKHII5TrIarBV1XS1RC2UOkFKHqmRtB PQyPspzj0wQNMJ1wuGq4kQOoTXVdQuuCCI6hIVCHVNO5F+kgYYNQnIMRXqEt9YRGD/wSVQiC49Vh cIUlrXwtBtDT9LCkSaUOW7hjBqER1oKqtdQvIX9YXRBxzAQTOtqwTVVdJAgoVNAiOqwn6K5mGd1b elVUlCIKHXcI2tap0rUL/d3twr1hDIpyx1hV2EQYNwLYwlWv0QwhBBIUKrpaIXuEkECKfqq1giGc dNohXUgg9gsR0KvCVOGkF6XglkMsIqkEHx6QToIKh1TtN8zSFLCEIKmugXlc0ZHVXwl9KkFohoHK MBJyJelQScQqX9fiQ4whxzDnHpQgmtqlUR06SX1VhBKRHCGEkmtcIL6TpJL2FcRPGlBfqF/3rSpa CWEDSfHT4JpJLWumpHAuGukO20lvojcPoIiD11ugVRJgGEuqQ22lr10PTS7vXdpX4SS2qrC0EUOu 6XTSpBSTqr5BuOlWkm4eteg3VBL0wqByEjQQpfuGCeFkM4hOhIg/LhrIIKq7etqqbtQlfpOx0RsC /wqsoDLqpKzuUQX/CvEgXtKFrYYdL7avtAk/GgsEcciDlcVMpwlkNA9eDCIUd0uqkcULDRQ6rkMu lQlVAindvIEQvq32eQQXtUyBcfUQYQUkOK9utEFA4suDHSERFRH6BJUC8kOkm25DO58LHKH/Lej0 n4YIQu4XWMREg3fVdbCaDdBKpDYITaBVlw0LVAobdiIil4IOt+Kh01TXUKj2R0GCdq6hO0rUMjsj 5wIRw+gVRXYaqnSe2CxT9e1sLYLkIPFhWlwTIEa+kCQii4ZWyI9dIFDBJNt0/TqutWhJcLwoUUQ9 usNMIjoNlawk3HpNe8ggR29JdPHp/GmQaalCI6H6kTVDaYSprSBUkEp0DYdPD7CWq1wXsKwwQyMd C3WS6DBB6SpkNSF/1ZtGAzSOEhvs0IPe62qtrDKHIg5NSFPqJVoMoeoIJggZY5DPqE3FbURFyCPM 0rEhlOCWqIr5Y6wwTWLiDOlBO1iPpBkQcwsVNV0sFIZbhRmwYZBQdfq98m6xtPiwrHM0FjBoRHfp BPWoZGOU5xbdJ8cRpJhMLI5CFoaVhUwoKEyKPxEX//4ihDBYSXSsFQajqUOp2hXTf5MvcqYwWmE2 wVEVRHQNMocEGqjj1rv3IUlHCV2CoRoWtljljhPVBP4i6TVUg4WwQYIqAcGMauGG/7VMJ21XEGEL XQafuGCaggwrfDJNyew0tWhaDKkXa41h/jCHcPbDH4ZEHMuYapaaJvqdkrRsZ5ZaRaiOhZx1Uo2K 1BoIREXiIax5b+NtybjaLJND8axOy1EhFcDQvd2hESuSpMy0WsRxqHOzJVDZZygORwyy8R8jg49Q RTIVFM013Eflvqi0yb62ZKqeu9jdpnkqb23aXt/UMa23/+mWkFJf38tzUDFVcJCtQgi1Cv9oF1qQ nlNIaKkMrRh+I9Y2y0zCI667Yj/bLTGIqa+2Gy0yEIpVScRG7DLT1XYMtP/OxT2VxNkdFwzkcF6E qFXCERBiR0IlWsINspuQU0iSGVxeI6LhqsrYsU1UmImsG4SCCHlvwVRuNe6pHYsq930vj87LrtlV Q3oTsHctyH1UrrLBBuPCaY9b6r9Ebstii9ePtW++5a5qt9WPr9ZH/t1/W/fvSVytfs93j26Slpiv 31r6EVqQpesm4gKR8wibmSxtA6ghEgg5RuFSW10wYWVx0hIg5bJrXlua9cSHZO/HFEHHILA5RuS+ ZGnZbjwWXSDKcSY5CG5QnuHfzeIgyhyhyrF9RCQsJMSOi6MK1BFOUOVD1mU96oREjoRERKERwbS3 EkR0t30sRJAKCOiPhBCJHRHyNo7To33RKEZUzaIsorTnfEFEREREaxEECESbcuKTj5QhEyDXf9lN bXT/H/f+v9dZbha734QfT/S/+t3Kkv1LKFL5BB+qrSVP/zskXe7XCCwQP6tbm0TxdIKwgv6uCERk eO1hVoP3ep4NQOg0FhfUjHumCBCEHqvskaWUBYkGnZoGkVzCpLfsLBSbi4NgQemqWqsVCRNxrI4b ZOapXdXvOsmCk3VgrhNP6Spu2nGTdODaR0R0YNbStZFlTXwmTegMgi4TOxZJ5OH3S06epN4BkI61 TRFHOPzgEKvr0smywCwKraCENKRwb5NnzY9KZAi8NpJSDJmkRR/COjjsIRVRtfTRDaI6TtpZCxSC MJ6pad1TkMtJVBeobBBqCXnFW7bSkF3IQfSRQunIPaoSUAQFXx/6wVVIZxyhuOlohN89NQiDXviL smSSS3ULa/aUKsm7ofSwgbakCRHwqCRDMUHCwwTaK88jojx96DS9OkwmsECH0tOsqwcJBJEC6sNB gnoREiDlLDh1XukEwRhYpaWt0S4KFQSIaAIGEztAEAih0heUWRRGBmER1XuNhCt9Ja0kddNEE+kg RMBns7zCXkXFzXG9QQOyry5IRY6ppFGNqkkiLfVBpoiEBJQlQYISCCUjeCYVD02Yc9ljhBXbIzJP veNeuEPqNBBUFP8KQLUIhgVIO5QMUdiZ6DdMREGEEIwo76tesL8g49JH0OXCF1CawiNBmAinRFsr AMGOk1VIIIj/y3KBdp+PqOOFQLWoQk5pAkHEiFIZMDjkQVunCRQ5AwONdD/UJJqqVIwl+lGRigZ8 HNwJgg1RIo66ETuCyntukktdboIVCrgoQVWlkmGAqdIhIarQSFcnP9v101VJqukix6Cg0CyDDQtr CD6eiGi0mqf/1VFjnHCWklRnQTVhAgTTSEEoKC9QrQ1QIugWlCddBrRDVUrsrdeER1WlYXYLpKF6 1VPfIPw0E0F/2v9CLSJwRB4qEKpGfUuhRhVbIMIKcLBVZD+UOF/IYykgQWrT+vjVaqZqWOCyGDqF 9RQSUg40ekTwRUQzvVBCKq3CMJ3VJaC316Vd7ERwgXBfhKkQ2CuEqCwr19DqgQLqF1ck7wRT61Vh mpHAheI4MYQUPVBKweqwvfXp+CBUkP0k/pa1SDJwhHBo0m+wklD6CSCwUNdOl6hKuq9uPVeyDuy4 Zmkw9hpcHSQWCVJ+tK9QqX3V/9eI8ECGGqDIMa2sJJEVwtpbS4XoVrbLfQXr0q9WtO+wlV9BKElo Fv9JfUgvekCa/6pdSDQPNpUCYdMhjkoPqC0NJU2kqXpE7XfZXMkE9Ida74TIaB4+3xVHYsGfSC3w uyBH/00ElQLuCanZFuaLqk/YJkHHBcU+wlOy0P4SvgrTS1pdKFddVCYIPx/ourNT2QIDBDwvgkjt TGlRHBv8gg3bJcJX5tVQS69VIjwgy3WF18KOLwZxyMuWH32sN8aDWTFDXbCC1poEEPIF4YQXC+mg m1GvSH6ER+6DST8g3fD6QRH7kOOTcFrS2tUEFwkvr3/1VcEjukwyBBdfWUGRwukRsh2I3Wo+Qzzk cWoXtJJ7x2FVDpJB6IoHztIarC0E2C5SBH9LS6jprvVbfik/rWyhyoKJqEC0gsEmyOD/tphRqpBA 1TXVP7Uj/TXqFoRFUgS2lMDirIwMbCdatphNffX4/YJKsJVWdECSyHIp9keBBbVqHoaEVq2lt/CY XSFOkiGHFbUUGosILaiglwv9JBbKzEcGCOMWQsklqh26oYTyGBwsMgu4LaQV/itIt1NSC9QixxSq K6DUQsND1DpdPWLFdVCqg7BUdvl1Q9NbaSDa9cErTtYi+/VhbTk2q7hMIMFwiBiQumgwq+Y1eF0w QnZX1CBoMLaEU7QYIaB5A4HIxzDoaEdrBkOTsL2NCW6qpblDmsw5hyChxM4sjoj5HRciOyPl0fWI 4Mswce1V0hERoOz2U5xzDlYVWEIjCGhI6Gy3VFihUpwr+IiIiIjRhCJZBNHZWky6OiJCOIrgSJ0P 4r4IRE7AkLWIiVwiEuhOxiOiOizyI6f+IqIiIjiNFYQvCtKGEJkaog0troGhFrZb+iyUXi1SQYJr /bJupoLpD0GKe9t1/trmRqupXS+11W5XWBLhUP0+v0twv6vXVV2l73jXWSH/3jfSq6nfl3/O4DZ9 WkkQyzYaOzkmr2R0FZBoNlYf9iKgwvXDCDBkdZNyQ6XhpkWYtQl92CbJAEYQL+yLsuzqC+wX1O1l ME5GAlDS8RYYN11fBuv02GybTX9w2Kr9ulq23+yulPDZaimutJtvpd4ZgEtu+txBvw6WkiGvse2W ko7WvIKy3ybXDpd4PcLFJVgyWAu4TddSGjgyKBssLBV0StkgG4JPj7w2RAOEsKusNkIERDYVOmqf h5a3SG+2gmF0WUoVVcKLoIdegVUWRUU7KlfwQwSca2xH967d69rZNxJ+6qRWcLd106vSr4YS/sfB 6aOzmkiGxnF22CO7DP0R/g0SkiGiOGXoVUMKIy0rVNaFomyjI4hH01rhgibVmRwbkfI6vDIIOC2G QMGwEIiDWibluCQ8tzJG0dEEQVRhZuSVESbJPTKiJxE205AkHJjvwT4iJ2qpNCL9eMZEJdLlvUpA iCvK88SOhJss5AlQIp5NyTQV4ciiyFzwy+MIuhSK0i3oky3JOu3RKwyxiIkMPxVNL+VXLkYaGbxU rkSrTQZS/EaiQknJtwPrWuHBEdaDQaQXWm2sa4Qa6VaK62fq3CL+uQ1rtb3pkD0OhSpIf0p0QVbT kCccEJdoJdKvnMjgvwWGQ45TkY5DjoQTS116ghCoK0IjLGVRG3Gl/eKUHuqTpa6uwWl9KQLOw9Ja +sFt6qFBO6OxGq6+/60gg9U6/uiUB2v6prS66wuaAm/6Ij0/JQKpGJL6+/trStraRG0RwwoU7QlZ Q63vhu8i0df00Co1hofCGQLVNPMi1BC/rh5BDZG0+sLqlVIagtAn62tth7af0kqsZrzMG6qQJEca 0of9/DX9VSpVTCaqCEGjjpQv+m9kG7c0t3+l1UYVU69f924byRf1SC66wkCQIIdJfS/hvzWiOm7/ SwappEKOlCipMDIWsJf+HYa2wgovfWK5DjqqSTVPCZKQ9EbiOoedpwMKS5dukePoQu82dJLJRhaB EdK0FSJdZIwnIMdKQEKRJ7GE+GDwyvCu1TZx8Q8x1whHoYWktpXYIOgmE0RjhYbWFvEX0nLmOkq1 S7BKqIg6kEuNKFh4XKqq1OxIGkLDsUlpIUl/WlQZB3CrS0RDtUk0GRySsoGXRIDQk3g0iMd1dt1T wl9brJ+hWwkqJaa00MK5cFNV5LRQnu0d0VWlSkdBL6NFp9DCiFrXpoi3UJBJK38L8MK9tJYiF8IS Okr9eoWlyI9AiQGxequjutfS6LfgjduqSWqj3pJUqS6hAg8IpwYWKp09JJLqJ28cxq0F0h1nOH3C rsnDr1qQYIkgktx3XvEGR/4SCSqoqQX2QlKdF/hJYLWgm6DVSDKOUCX9UshBaldZkL2Okqaq9soo 0ER+uwVVSpKEgkhq/0sEQXbq37T/oeHyE4U1VXH0r6VSCoSb/SUIOFTvagi66p1Q1ZUwrSPJKKbS WpE8ijknKHKsEgn8wkkqRAw3Gay3f0LId+l1SXUh8Kthar+Qg5huIiI7rrhLRFO++2CKjTCgg0tN cJxqGEEIcJKr6SIylL8ekqBAt13H4KEpNyfTOOgfapgsZAiBC61CwvvIRVoKkOt4fUWE/QjCUNII bkHHVJIJcL69GrI5Kqqlvtr2sWE7UFsEwh/oNnUGFS3UIdOgqQWq2FqOJ3VKwhZQ5acFSpOgzeEQ 4+0sJZoGKSCSsg3bk+1b7UcjY2gYLqFoRVWRFuC5wCKwlojblf7er4iLCWlfQZIFpSPFwxkcNFRV V62/6rYJ6wxWhFRCev37aokO7oUhqlQSClDoJCgku19/l11VME1XvTXd730mPrapWFQ0goVN17/e hxZBgNrwggmEsM2v+/eTdWmCDqwVVCHDEiNyeVwWo1Cv9P4gyQhUlCRDOOF3cIQzCI4MQ6LdLWvi IVkEA1BQhoN+IthhRum9hPQYSBbCoofTFU+mJA0YxGswxxgwXe7iMijhR8GEGv6YIEOFwZB9iCFN uu6aCba8j2BBcJ3a2F8VxUsgL7Q+8dRCd6fqUPqkuL296Sr9velOC91p5h1mBvbUmVxxD9Vapl0T oujaPI9nEbRdBP4aT9lOVkWUDEfxb2IsRIeYBr/IU2F0DIGHMOKvhhkCTQYiu2yGFANqQPoBOVyl VLfxshnrYgwQ42gTBjJsrBXI7I6+mDTKHINEHDj1QZCwahDKchBzjlNYtCtojHYMI7DQiIkhDUrq qw5WsjhxEsk1oJ04iN0lvd7ZaYhf8de+ER/3x/dK0nhu9TuFCVVw/a5CjkYDUvb9EF8DLc0RZQNf WoxHd0FDZZiktNpBIikDV9ikECYML/MKhkCh20KY0CI6aXFhq7jWnu9QYW2tL0t1ahV+leq18jR+ gQPiiC7WNTtJKwgx8k79Hwpahj+DZafIJ1sN66dof20t7H7/b/fVv7DWrZaY67ti3SYMtJL/RHQL TDsodgovQsK52MWgkDCBEI0kvRCNYchhpLPCkM7SVXtg6lcUYbBvYQbDLWDHaQbZHx8G4k2BWfyO MjoshSVIMgvsSDJsRERkfI4aZQk9gyDGwN5oBwKfBg27MAei8vZDRtWHEdcMgX2GHokP0GDI6IZp sgqQVmrps44kb3kDA5xuvxncYakEHKUvfzwNYPIiWVDSa7ZQGULLHCF+9BlBhKP/Z6wn0qyh7DHv TKXW28pQ/aTpDZLF/rbK6zkf0DT9eo26e/S2g32n//7+lqFDOble3ybCX0t3Lr+wv5JCuVytRbos eUH1qkVMH5XFzZFNxTCbC49YTISqVxoNhHwyFHOOSNxEdLXpU9oSFwRZVQzLKfIhLe2pqapBMgna QNQnrH5N0tMUE81HhK4Kxu+len6rQSuDlcpBlB+0kLBEJRX8IFeHK6kDYdjguvMOsEQIvkM62Cmv cr6IKV1sMsW7Q8IHQfXQQqaq8ZbmqI4pfKnkD+6dEQc44/rBFD6Tb4iKZVi7aRqCoEJwF79sIeFb 2mEH3RhukH7VTUELireQfpVw6EPQQNP1oEw6RDOIlOE7ojd9qnQP2tFAoYPg7IYL/hBvvCpVulhB UqJDg7CD+k3uq691ggT1gzjg9fre2qIj/t0sIkEa0JoI4RCc79Pt0k6r2uCBW6t6BBu9/cUl0F26 iEmlsO0n+l7IbByqfT9aRN35BjVLhSuFL29oYLVWuqW123S6gn+7II4UK9JbS1f/SvX/oiDghhfJ vt9L/eKyuo791qHEawl7aVO/apb76/u9L2Oo8NhaobSurunthK6r6TBKvrfr7YSy/tbWwZmD0tNB euvDCCf9thMJiEgvpOlvexCj6Z3g0LTVdTCJ0RMVv9Pa2E0IjIKNAl1QnAwv1yTtw1i0GEwmt5tI gop/tLVkWtBwwQrfEIYb11bcGCxMow5GwnurS6pvFoYKHWwwTfSpN9CG9OdA0r6fvaBu9kIDtpah L2E/cHhql7bYv2w3OOK9Jh4ftuIaptBPje7caw/CthsMLSu9u46t1dtvS+kw2+mvt2qQYV3DDd8a 8Nvq+3a78MG319v2uoZBK24r2/+wbduWkSK4YZHzCI7I4njUtxwIFhZdEdF8j5tF8g0aIvm3cOGO I1EIIQzwU54KgodBBCgi6EEHUOCEjHEGIiJtCIyh2VzJHadVDUREQxEtFfDg0mNS30DDey3UJ6iH 4ZOCnKHOPtUIiUZHRHA4Juaqm0IlOGYYRjW4nZriPcUq1yzAeNwvC1Kqizqwnwt0l3roUqoK3C6C 17SrJJoQ0wqjbLWWvCfY+mWZo+mW2W+lG2tQl+6XrpeiyKX2vg38eih/Q/lmDFmV/CePC9036j1n ZUuoulVK9VCXYXBrj//SLXB9sswrQw5ZgwM2FLMQDZyzlYQjojouCxwQiL8gzDmfDhkFdz1lL8U2 itBFnF2eMjgoI+GVx6HTIVDxNaERvaipaizfx0l0/td/Kmqow+iCjWxqn/sFvuiCDk0yK+E0If1s 5+kbKJjhDXFqJMcscpMlCrsQQwb1QUF0v9Xq0pTv6Qp/UN30QRH5KNXLKFr51gW8a6YIJJf2FaaM ir9poEiEHR8HT7t0GCFa9aQtDf1qu2gg/tlDwk3a3UlBb4rr132utu96tMtzX+/Xu3X1eNe0u2m3 +HdpUTh1T0ofp8Nt/Sdfq2/6f7pB7qu123SrosdK4a8W7CG72L9/S/1+/b/t/S6t1fLNFe/vfxq/ VOH8mYL+GcRhEsBReIkFESbT6xQ3cjoyn+hqpZyvI4LRcKJZTNQ4nREfI4aYNDUROZtG0ew1xERG vLWNVdaj+W2GuN62qW71v/yAkJrj/T+t/2vC3//vX35AUJVMliUYJcEF0C4QLpdL0sX5TKWq9x9q n/rf8ySfpY5ZgOMByOLyzqQOfBV5ZwQDy8PSd5Bn50yyGSkGXyiNxRGcgYGtSzlHNvFfrLWEKV+X jjF1/8LXe/r+v2vyCP9IOvpmqv9lA/8zwSr74RH+uOEC/pILvpUnfSSrWl5ZRip50kksfcNK/1DS /4bNVCC9dtCgT/thIERRxw3toQnpbaLHCf7hKCZDj/toKEwVdWOYYc+ntCP9hd/9f/T699vRY76W k3eZ+k3WL8N9rSh39W+vTff2/6Tf9IMP/tvXSYa3SSDb19v+kH//10g1d/Hrp1df9wr/T/FfX1O8 BCOu5VQ1CzUpXolCMArjC5wZuI4Hj/Bx3LKIQxXEl0vG+GQPDcc/FOuWcLDXcQcmxYi39cs5IjZl 0R4uxoRK4UuIiIiJbgahRvD0v+WuB/+P9S11hcb8ppUVSzVlfEfa+6lmpS4/W9W/W9b+t66/p/w5 bCqq5KVstcyQjq7j7+E9f3ruzjquWnUsXzIkpx0WdKDLHoWWdVBTtNlnCgK44LaCIPUeCnIZxwuE QhQXRbRHUVWVqd3SQIRGEW6l3QJteKj72WcCnvd6vpt/27v7/X7/TlbBLdgvoghp1tB8PpsnmFVR y0wJQ08t7rCegvG+P/IellshS+g0lWRVB9s6aWMftVWih+2qC8Xvqv2GgkEZ/Dq3qYFurtqhSLdU lvQSWWoYUN4bqFVj9jQLqF3kWr69lDlCF29oRr7tj5Q/8tdUVDu7H999PqTY1XLH+h1b/pN9v366 V/9v+k30cfpd2Olevdd/SdrWkGvpKKdFD/e7aWW2ar1WnvrJstKr3WvWh0kFrxG9/+F+/01yzBTr 9yvC/aj+V1BjpSJKgwryHHKsqsFZHRhF0Yy+YBcdsSY5QGIiQ2JkFaLcmRvYi+W4MNl12eaumJIy OGkR4wjUVFD8TWhEb2NS3j7hEUjwnUKEwytMPY9VqD3lctVfHyLDrwg6+n6ta719CvbWoWu6+lWq X/2V1RBLuE6rquWyOi3C1yuDwmlqNK1g8belILjNbShv7Svh9b4I4+Gk7UewkDjXSKsJqHCGD2lK +qCs7ir7X6vTC3tV1tCvXafREH6QV5Q7Vs7C1XSbHVJNlqoVC6b7hcj49BMWdjTKmDH9MEQLgNh0 EHslQatQrbaIK8hIpN69dkSDQRw1B9O2EQX1IaYDBbpttSERcMwshpUqdtMQysB1fe4YlAbK9NPZ Kg2XVoQ3PzbK5KGaR+rY2JDCEtRHDBXCgZRpluLIxng0m2GJ4KVygCykW7oiAPEYZKUDDK42DSRw 0sw8rgSLxLgeDaR0GGIYZXVhlkIjeRwfGhIQct2HBsr6ZcMwjoz8TgW0hGw24kCAyiClHOPTBw3I MLKxaIHgyjtt0QpoTTKk0iB4O5WFTKJ3Yc2/VQiB+aO3+qIo5Q5hyGdzjncw591lw3bS+GVL2235 TAWoOLbv4wRT37/He9r222+u9w/yh7eHyL93d7wg6pNv9/7e7NBF9vDwdcm60tvpmS03DySENbbC nYXlxTYbDoDXwT98HOwZngPBt9P+mdnA8GdXNn38qoLkzA8FcjgYXC9W9ENg5wyoLORjkDwQcjQV BDBgElH/tCIiJDVsibAklCyvP/yB4ZWyWlWVaq+2yB4g5pD0oVCNfZHZBUkEmmkv9uEyRgqQ1s6C GZ/r0sbhhIEL7+oV2wmC/d6rsIjcSGHf11DKHC7CCkGIvddaEXY4KHaUP6WwoKK679tC/erXr/9a Ya6rr7XeunTHLVL9u9JU8YRQ9LSbRK3dCv6/vVJaTf1+1b9lfRFDIPPI+jYjqvQbq0ZFpFOi4NRH ZHBWItEQl60vyC4qQwYITdiIiQUqinPBDQOTHIQhaWlfRBqwlAkNmFIOOcCERESBEa9W+xEREhjx qlFN9DpaeoaWq7yGQBuOVBBQTO5EHJhm1VLT3kkhDZZkEG45zkD2nI9pCGWOTHK8pyY5GPVJXqoi IkIi6I+eRdkcM0TsLQiIiaBYVY/ERETMGBBpUq+ZJ8ubnRJBBQ+ojjQX+kqCq8odVQWvHqCVUVyh W1oIJJbrShBVj0kgSp6+EEwvqoSHvSQIF9UggRXJO/SQIJe+kEF87WVpYQSD4gnhIIFBtw9UCTId TD0qRdBAmQwUh/CDLoKY5DKByzrS6ojhiEQT0DFFkdD0gkxBC0MLSQJAwV1Qgi3JgrFzpUgi3Eg0 x6SCLcFAgs6WvpCPSRDOmy0qQ2sKQwA2sOMhQGlweYcocFK5FiI47/117dfel+WYHXCDqWZ4e2vT r6v1v9XrwrtQrXgtD4NwRT4pVt1v/CMPLMD8ad04bQcJLlO07rX0u69XkaaEK1w+UPHHeuUPv5kl yx73ryzi6yh0OO8J2ibma48sxF0HdPp9ffWvXugvXroKsK3VYWhImuP9Yf13fVd//W/7W////WHh K/3S99+t/6//+9faqWdTUONeWQhFcVVRH3LQCdX4//3r/epahO2n///eupZBdFuBxvIT7eEJIZ+I J3XTztTXrg/uiC47sbp/15C/v8jQtvwn/k3ooQIKqqIgv8s3EF74Idesx/4uu5ZinXfUt1GdrECs hbfw0k2W63hUCCKi/xGwgpMN/vBIeukw6D7cr0XYQREgt8Qih6YQRGgTuLKHtoIgVBJce2ow7yud YbPiVmQF8duEljyuQtwsL49oJhJfDEJE16srkLaYIjr9tCLx3u/26+n927lmCEEe3wRT3b4phW/g k3yuhbVmFxcJMX8K19Jv6X8K91Sf9Neknb9D+qqwu6/heh6lmqqPB/lmmBC4aZEzMAhHfyzQ2eAo IgNouiIyOBBHP5ZnmXZHUSB4bjiIiQ0aHH8s8RgUwiPEcHLgpginEgeCyOPIvlDkGHIKGVIVoccr CEHERESB6IKc+GHEeIiQK3KGEGDcuQz0EREREeIkNg5OZDO5IuQUDk2/lFynKs45Y5hxILaL8REh hzDiQMLqaPgtgbkfJQDSXRjOuXA8MyxEgeIOVBOzL0KyRwWwJxIIC5HQiJODcjmdcjhrYiJFJkCI KkGaBGUswSEkjLoRM0XDMsocgrjlDncgoHJDlDgy6JANpuO1QDMKIiIkujlE8yOIbjAhHQiaBgRZ BpHERIYcgw5wMw53Ks2HwpwhGIiIhkgZBQQU5BrsocREREREhkY5DA5OCBA5FHLshkAofERNRCZg 0FCI+R8zBbBZNmYRjI+YQiIiZhmHmR0R0Xi6MMuB4y6GIiIlQjALYZhdCIiJ2oxERETQQj5HZUIx FwgxNSNmYDJDBPn88jcIoqCk0rETMNQujAORwPBnI6I4pHyPCIiIyyEjNhyPmEJqRyI5EdEcy4cj sjxHDUI4KoZThCMRERERERFlYQYdkcG5HRgxGJqzpHViMRH//+WcDUcs6ko//+V0tFkAlEm4VDLP SMZHRHRsyOrloS0KiKKAYBCIk3UlE1KZGeN4////+TZH/u1H+ZE1H/lMk694////LUE1LQI/Yx/l Nl+CdAqCwo/5aoTk3JO41H/KaJrcf/8tCdR8swDOP/5aZZ+P//y1S68SbT//om4vxH//8gKqqj/L NCLnZfjUf////////////////////4AIAIANZW5kc3RyZWFtIA1lbmRvYmoNMTAgMCBvYmoNMjU1 ODcNZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAxMSAwIFIgPj4Nc3RyZWFtDXEgNjEyLjAwIDAg MCA3OTIuMDAgMC4wMCAwLjAwIGNtICAxIGcgL09iajggRG8gUQ1lbmRzdHJlYW0NDWVuZG9iag0x MSAwIG9iag00OA1lbmRvYmoNMiAwIG9iag08PA0vVHlwZSAvUGFnZXMNL0tpZHMgWyAxIDAgUiA3 IDAgUl0NL0NvdW50IDINPj4NZW5kb2JqDTEyIDAgb2JqDTw8DS9UeXBlIC9DYXRhbG9nIA0vUGFn ZXMgMiAwIFIgDT4+DWVuZG9iag0xMyAwIG9iag08PCAvQ3JlYXRvciAoSFAgOTEwMEMgRGlnaXRh bCBTZW5kZXIpDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMTEyMDcxNTAzNTEpDS9BdXRob3IgKCkNL1By b2R1Y2VyICgpDS9UaXRsZSAoKQ0vU3ViamVjdCAoU2NhbiBGcm9tIERpZ2l0YWxTZW5kZXIpDT4+ DQ1lbmRvYmoNeHJlZg0wIDE0IA0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDAwMTYgMDAwMDAg biANMDAwMDA1MTgzMSAwMDAwMCBuIA0wMDAwMDAwMjI5IDAwMDAwIG4gDTAwMDAwMjU1MjEgMDAw MDAgbiANMDAwMDAyNTUwMCAwMDAwMCBuIA0wMDAwMDI1NjIzIDAwMDAwIG4gDTAwMDAwMjU2NDEg MDAwMDAgbiANMDAwMDAyNTg1NCAwMDAwMCBuIA0wMDAwMDUxNzA5IDAwMDAwIG4gDTAwMDAwNTE2 ODcgMDAwMDAgbiANMDAwMDA1MTgxMiAwMDAwMCBuIA0wMDAwMDUxODk1IDAwMDAwIG4gDTAwMDAw NTE5NDcgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSAxNAovUm9vdCAxMiAwIFINL0luZm8gMTMg MCBSDT4+DXN0YXJ0eHJlZg01MjEwNw0lJUVPRg0= ------_=_NextPart_000_01C18451.E095B6D0-- From owner-ips@ece.cmu.edu Thu Dec 13 23:49:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08708 for ; Thu, 13 Dec 2001 23:49:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE4AjC04054 for ips-outgoing; Thu, 13 Dec 2001 23:10:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE4AfZ04045 for ; Thu, 13 Dec 2001 23:10:41 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 289883035; Thu, 13 Dec 2001 21:10:39 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 01FDD2AC; Thu, 13 Dec 2001 21:10:39 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 21:10:38 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF76F@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'ltuikov@yahoo.com'" , "'Paul Koning'" , "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" , "'Julian Satran'" , "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: found the constant for divide-only circuit! Date: Thu, 13 Dec 2001 21:10:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C18455.48ADC980" Sender: owner-ips@ece.cmu.edu 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_01C18455.48ADC980 Content-Type: text/plain; charset="iso-8859-1" I have modified the preferred implementation (simultaneous multiply-divide circuit) to include the control logic as Paul suggested (similar to ethernet spec). By showing this circuit the iSCSI spec becomes less ambiguous and, just maybe, Luben and Paul will be happy men :-). Vince <> > -----Original Message----- > From: CAVANNA,VICENTE V (A-Roseville,ex1) > Sent: Thursday, December 13, 2001 7:46 PM > To: 'ips@ece.cmu.edu' > Cc: 'ltuikov@yahoo.com'; 'Paul Koning'; SHEEHY,DAVE (A-Americas,unix1); > THALER,PAT (A-Roseville,ex1); CAVANNA,VICENTE V (A-Roseville,ex1); 'Julian > Satran' > Subject: found the constant for divide-only circuit! > > > Luben and I found the constant polynomial, C1(x), that makes the following > two operations eqivalent for a divide-only implementation (attached) of > CRC32c: > > 1. CRC register initialized to zeroes and C1(x) added (XORed) to the most > significant bits of the message. > > 2.CRC initialized to ones and nothing added to the message. > > At the end I summarize my recommendation to Julian for fixing the iSCSI > spec. > > C1(x) turned out to be the same as the magic constant specified in the > iSCSI spec!! > As some of us have explained before, the magic constant is equal to > L(x)x^32 modulo G(x) with L(x) being the 32 bit all 1's poly and G(x) the > CRc poly. For the simultaneous multiply and divide circuit we already knew > that the constant, C2(x), is just L(x). > > We now know the equivalences for both implementations: > > 1. For the divide-only circuit, initializing the register to all 1s and > applying an all zeroes message is equivalent (produces the same results) > as initializing the register to all zeroes and applying the C1(x) input > message above. > > We can also say that C1(x) is what you would add (not append) to the most > significant 32 bits of your message and apply to the divide-only circuit > which has been initialized to zeroes. You would get the same results as if > you initialized the circuit to ones and applied the raw message. > > 2. For the simultaneous multiply and divide circuit we already knew that > initializing the register to 1s and applying an all zeroes message is > equivalent to initializing the register to zeroes and applying the C2(x) > input message. > > So C2(x) is what you would add (not append) to the most significant 32 > bits of your message and apply to the multiply-divide circuit which has > been initialized to zeroes. You would get the same results as if you > initialized the circuit to ones and applied the raw message. > > For those interested here is one way to find the constant C1(x): > > Initialize the divide-only circuit to 1's and apply an all-zeroes message. > Look at the state after the 32nd clock and record that value, which I > called C1(x). We now want to find what 32-bit input message would produce > the same result when the circuit is initialized to 0's. I reasoned that, > until the 33rd clock, the order of the input poly is less than that of the > CRC polynomial and thus the current remainder must be equal to the input > message itself. Thus if I let the input be C1(x), after 32 clocks I would > end up with C1(x) in the CRC register which was indeed the case. > Luben had a different development (see upcoming internet draft) that is > more rigorous and shows why C1(x) happens to be equal to the magic > constant. > > > There are several ways we can fix the iSCSi spec: > > 1. making it explicit that the assumed implementation performs > simultaneous multiplication by x^32 and division by G(x) by showing an > implementation such as the attached circuit OR > > 2. saying that the CRC must be initialized to ones and not saying > that this is equivalent to adding 1s to the most significant 32 bits of > the message (because the statement would be only true for one > implementation). > > 3. saying that the CRc must be initialized to ones and explaining > that, for the multiply-divide implementation, this is equivalent to adding > 1s to the most significant 32 bits, and, for the divide-only > implementation, this is equivalent to adding the magic constant to the > most significant 32 bits. > > Option one is the simplest, and the one I recommend. In fact, for > options 2 and 3 we may (need to think about this some more) need to fix > the examples. > > > Vince > << File: BothCircuits.pdf >> > > > > -----Original Message----- > From: CAVANNA,VICENTE V (A-Roseville,ex1) > Sent: Wednesday, December 12, 2001 10:06 PM > To: 'ips@ece.cmu.edu' > Cc: 'ltuikov@yahoo.com'; 'Paul Koning'; CAVANNA,VICENTE V > (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1); THALER,PAT > (A-Roseville,ex1) > Subject: assumed CRC circuit performs simultaneous mult and > division > > Regarding my earlier memo "effect of initializing CRC reg to 1's > depends on implementation?", here are more details and a proposed fix. > This little detail has generated a _lot_ of discussion among Luben Tuikov, > Paul Koning and myself and in fact we have not all quite agreed yet on the > severity of hte problem and how to fix it. > > Where I see the iSCSI spec deficient is in not making explicit that > the assumed circuit performs _simultaneous_ multiplication by x^32 of the > message, M(x), and division by G(x). When the spec says that the message > M(x) is multiplied by x^32 and divided by G(x), if the spec said that the > division must occur simultaneously with the multiplication by x^32, as it > does in the attached circuit, then the spec would be correct. In other > words, with that assumption the spec is correct in saying that > initializing the CRC register to 1's is equivalent (produces same > remainder and quotient) to complementing the first 32 bits of the message. > > If the assumed circuit is the divide-only circuit that I also am > attaching, then initializing the CRC register to 1's, as the spec > requires, will _not_ result in the correct remainder specified by iSCSI in > its examples since initializing _that_ circuit to 1's implements a > different division than what the iSCSI examples assume. > On the other hand the receiver will still compute the same magic > constant that the iSCSi spec specifies since the magic constant is not > dependent on the actual message or its remainder but rather on the fact > that there were no errors. This is what Luben observed and what he and > Paul and I have been discussing (and still are) for a while. > > This is why I am claiming that the iSCSI spec should be fixed by > either: > > 1. making it explicit that the assumed circuit performs simultaneous > multiplication by x^32 and division by G(x) such as the attached circuit > OR > > 2. saying that hte most significant 32 bits of the message should be > complemented - rather than saying that the CRC register be initialized to > 1s, since the effect of the last statement is implementation dependent, > whereas the effect of the first statement is independent of the > implementation. > > Vince > > << File: Scan_Fro.pdf >> > ------_=_NextPart_000_01C18455.48ADC980 Content-Type: application/octet-stream; name="Scan_Fro.pdf" Content-Disposition: attachment; filename="Scan_Fro.pdf" Content-Description: SerialCRC32c.pdf Content-Transfer-Encoding: base64 JVBERi0xLjIKJSDi48/TCjEgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL01lZGlhQm94IFswIDAgNjEy IDc5Ml0NL0Nyb3BCb3ggWzAgMCA2MTIgNzkyXQ0vUGFyZW50IDIgMCBSDSAvUm90YXRlIDAgL1Jl c291cmNlcyA8PA0vUHJvY1NldCBbL1BERiAvSW1hZ2VDIC9JbWFnZUIgL0ltYWdlSV0NL1hPYmpl Y3QgPDwNL09iajMgMyAwIFIgICA+Pg0gPj4NL0NvbnRlbnRzIFsgNCAwIFIgIF0NPj4NZW5kb2Jq DTMgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9OYW1lIC9PYmozIC9X aWR0aCAyNTUwIC9IZWlnaHQgMzMwMCAvQ29sb3JTcGFjZSAvRGV2aWNlR3JheSAvQmxhY2tJczEg IHRydWUgL0JpdHNQZXJDb21wb25lbnQgMSAvTGVuZ3RoIDUgMCBSIC9GaWx0ZXIgL0NDSVRURmF4 RGVjb2RlIC9EZWNvZGVQYXJtcyA8PCAvSyAtMSAvQ29sdW1ucyAyNTUwID4+ID4+IHN0cmVhbQ3l tgqsprcP/y3FFHLAn+P+WRHQdP79y0zPsJb3u7sMs5q7vcRLQlIFKVSyVYIYTuWgYqQcUGWYO6WT Z0R1RXWYKVwIyPlYCpy3Mw5Nsu1CEhy0FKxy3WA0JnZ9W4IEQg4cIWcdwsPK4msrqSvBDCBMXBTJ UnTQai1QRY8L1JR6VL0oQ0g8tywNBHCp7BXWZBS6RAgfBF1dExyFwJcbXS1CIQc45VChyh6j0JKY R1Up6SXQp9iIgwRH0nluLA4RQ5MYwTFaS7pFDghFIN0FEp1r+9aFEYkuEQmkRgl0l1CBCtwlKXNf 16ULoENUgiOr6SSuECWwhIL7T6MijI+XEO7Vwt9dFcYDX0ZDcCEWUiRFkZ0kugu08nBOOzCJMF6V J6XgqlwUWdhWCmtEdEcw2S4aNBUTTThKsKdzDUuwiGhwk0NEGB61pva/O4BtMlvrBFDkF8BUiEHB EfBEML5SSIokugvCIGB5M0ix+9xJ1BDJKwjs0Lqk1+tSEc44I1wQjVMLQkYEQQIPS0GldKrRtAhR BtHBHXKVEfbSwggiMCIcpPtRfW0n/1yGo8cmEU6N4Ipwgh76VQrTKhLVWvSXGzs9JjkCOCFf8Xtb pJAlWH+4SeutEyFI6BBBBMnwQ2mIi2S9brVIKkRYw9IlklDCXao77aJJZWAXiUI8NwnrLH4SQXBN oGuSgahtAvrqugUw6tu/eCI8ukgqU7Qq53BvkUD0GwvQPzslu7kQcIjoRV24YTtqrva1V1YNcLtr 2Qq5fa7mtUEccsdCNYYOFoO15CjaX/w35AgI7Xogo2FFbJ6KtBB7d4IFGOt3QLW7IEDnEJJdJUg2 qRrBp2IXkMvYsQuwnTO5pfXiE+3DTh2ElYkIQ+usJMHka7KA1evBnYGC5W+9tVvT0CT71RGPXeQa p+lVVDtBSJ2u1y3Jg0BMkRFcEDX1TohBNMg4gWVRYQKnhtKgVulhtLX0kg3pBNuQzbe1VhhPQ/8L YIPUJoijDhHp1kJmYqqt62SgMur6pJJ1C67SpctxsM07fVQX3OuSdoivwT8JhPI6VUtaX0CbVLIW GhQw6tV3eleQMU68tyoNhGgtogu+17UJ/C6XUJpjDW4V1h7CIrpX6ytAxB9aSTekm2asjiVprLcF BgIw5BBlEEpoJ9ahNUntPVV1pSXn9hukqt65NArIIKegkgtcLYj4QfLckDhC1RCaPRC91010vWlW 2wrpKFUdJJ6D6CcO234Sv6kh9+iEd9lvCegqUIKv1XQXoijmgofqFT1WreyXTdBJaT1V2DXSQVdK Em7+CQdVTC6CHkaE/qF16QiNURR4RDjtK10cetQobulrereGQIJ/VJfCC3UNqGwllQLkT31qt+mu klojH6WEE6uF4pRTV4YSXfOyelpkEB9YhYW6C92FQIMgg3jLHaJa3Swgr71Xr0l60F6pNUpUPS1h OlvpNomO2/hYS3CWw6Dar1bSe60vrRG9EUfpfFaShKtwqqnvCBUNVDfdatg3WlQJdhBXB+kHS02l 66CXtacJfpL6WvSohB/hVpMFhV/FYSYZUhPhKC+l33CZxwkqToJUqVL/Swl6Xom5ULSwiFPk4BaB e0dQwew6TZwMNaV3Wk51RiB/S0vBKgwe6Qyh1UW0glaTSX/Wl9JdCfy/rpPikn6lAZxCw40vfpsI JkT3bbelmYY7CWyC45RdN0Ir6V6Tr/XQXpdUI6UQvoEFS2RwzDi9KFVe1n0CTFBFQsJcFZgGPCBX Ej1Sest0TaQXWkl/S0ljXXSQSDqK6iQbj7XYKlSXIR1apMQx7jiF2EFkawwew2qj4SjVLfdJwluk rpJUrdZouNJ62krC5GC06lIgggwiNCaTW2cB6BJkM37YhFDhS39aQJU9L/6X1qxTC7QSirIKMDFp OFCfBLBavU0ClQKR0tcFxTZCCt3ocTCfQXqqehVhBUY6C+tV1VIEg7akWAlTpckBgWK2hEEE8mPZ DilhJEQEDdAwiOqjqCVJf/11wnuoVMNLPSyhyCaKkwxBBhdhLMwIfNhylo2D7WyMpsLQQdUNadJe kFd6iFhcj37XVyMcJehpBOwgZZIoMwDDmw2cQkwiHHS+PCzqFDTQYMuglLcbRHy6h5sGK9dWFUVU a6VJXdBBKNDY4YpQgTUKKGvwwWUBTszzAOrHCpIIExQiF3hfWF7CrprBkQcoQFaBQtdBRIL7KAmR NwQolvwZQ5Q2wQQkg2w4IocKW5fx0CVLC+11n7ciJ6VMcIOE01bCkM8tAphzC2PEYQIhV+odBi8J py6wpxfwksdyPAkkLQajGhagpDA4QiOzjoYkhwneW+qQRHQQQhEnBLGwwVfppquI2sNUKKHsKQrc hIeIjGhsJAyDi9YkPFL+vDWGg0MKLaRGOh0FSM8S6BJkZbdrW/arGhHcMii6HkIzIoxphMJVXC0q ehawwqbDKK3glQhw8IJslxdYTH+OGCYVD4JbI4MG6myGD+GCp09wZQ4Qa1oIFmHxEKDBLaDJVboV FlDlDhC14SwkEgoroa3oREW8JEdRSRQ4TCrrG1wo4QsochnHCkC6ir/VBEEHxEMIQ07Qv3ohLxBg lpP8ytBKoZGKR98QksadL0Fw1vSoioUX7wva+kCqK3hJf6Cy0La76qPWoX30q5NgLrSStDtQr+61 HGlvpdJd9UtK//S9/oJf72l+vpdtfpe0u2FwoqLUtkTRHVRENatQwoMKPmRRxKdzIo/QcvxY9YUZ kNUyJizIGH1cppKVoTNWvQx////ll5UyyGp2ib0y4yPl0aksSbBZngVBI6fERdEFDk3OOceWUFVE KWocI7hlzqPf+WoCq+O/O/h+nVnH8dfXu2QRfJSE+n+Gu7auiVv1Tfs66hv4Tp18PXLS5Szmi7KK guJXhSzlWR8vkcUEQo5xyhzOScoc8HQUoK2SXWwlkpRHRhXK9UXiyeDLHESLYM5l11xCyTRcMp8S Kb6lQTHNBVlVlWIkNDsIocGhJQRHKs+FDm3bdWs4Z8G0aIbByhyjZaNAiECEijiIiIuIiQcc8EJZ QtbpgtC8RJ2azySFDnkNnrKsjHEWRwyQMEfMZI7bVhcOhEGXZHMwRiL5xEhF0cjaO/R4M5HyOZfM ZMkcjDOZfIsDBHA8FYjsjgXPRHDIBX0idcPEREREWCO7CBmAYIsiOC0R4jojg5HMvkcUjo+CBFOG hIZTiQPDSHKHOZFDl8UOUOTg45Q54Kcoc/JhpDyGrXy+ERFkwGQNCJA8NxyxybkJZBo2lHHIGByn tqsg0Jk9HQMgQj5HDJDVI4hHIREkIvF0YQiLO5TlOQIHsVmYEciYGYNDOOCEREREROMuMjhmNY8l ebjxEcHI4HgskcMgGUuhERKMj582viIiRGR8uRHZdEdngKCIRHyPmEXDaI6MIjxeI6I+biOiOKXD UMI2hEdL4iIiJDDMERE1oREREREjEYQj31MtIuEERVNLiOg3/Jw/6Ta69/6Tf9W/1V19XuqpWlrS b76TXX6/SQ/+iy1r9Y1hhr+K6/rllqVf++OvLLUv4yvl/Q/rkVRHBULVSj02XjOLgzw7xEQl8gbj kIOk7smOSchByEEiTWwO2IiPk3SLkdaJ37ZZnJrcgSG4iWoMD06dIpuYZ114IP+5XWUEHVLxRNw9 V6sococrGo+8REnCdXLMEOg/9A8N61TW6Stw8NwRH+ksoe8dXy0eht1/kSMrlmg+w37vzItrdul1 1/61XFVXDr+tTUoRHV/+FqnQ+/drMjXhe//DBZ2sgiS/b/GztU0/977lnVFxZvSX/XY0COPXrv69 oSOOl7753Xcswu8IIHvU7V/argn0HhAgih90kCf/kjX3yRArXBP6U1emE+WQmk9IIL6BfTdfUg2R wuxVQkZhPU7DQS3rCWDDIkjPTNYaOTYEGqoI1L6O6AR6elwyThI4dU+CdaQp0qIONS3Ln1dLIQGg RxzO1KAy+E0kcd1a524MWEHa58tgxxPNVqTYUAit0r8ECyuKMvGMJ9EmLhXDBi8hB8gRG4ShJKvp BEKOUOCsvlcJgjjoJqR2pTrU1BnVLg00Fohj1oIgwbAYVOgv0oog8jgqEJ0EK4woJ9EMC7GoRNw3 pUQg4ILsmxMCGCH0uggQoWQwoIIZUBDpJ69PbB90kNcEEOgmYf6BZHwWLE1/fCUlobFDhvrhBHNt aCIMM/1V/hRQRFHgihwhRCRT1yLojgX3Mw9pLCrYQLr1WmQ2xyh4KLChCtq5E9CvbelaHUFr79EE yPFwhHQnAQEFRrBfSZY5Y5MdBCF2Higjjq/BPT68MRBghQJwSCuliIaCBeyh3Ua9BE2MjtKK6kKp QgiWER8jEkVD31EfxfCXuWbmr/dWQwW0ESgCCcKShEdhBEdYUHwkwv4hP1Vf+Q0FEIEoQMgYfGwk iFHWlIrlU1YKlfIEkknWtQyBccoD0ChBkIBCqrCHCTOOEPmJwV+5UBaT31oMQ3CCNWqIQeEglQVB aCEX6iqb6SrpbeGD0kwiEHqG+k+tLjwl9BSENll/XndYOqXTJQEiLRhEMO3oKg8JXTwoeyraIYNl TevnZcK6CVFDhUMINIhXUJHHhURR8g+wWEuqZCq3xQf1XnasVVtCuk0ExCI6igkEqDIMbSFBtKql DpFDq/D8h2F6B+kqui+eC0juhRx0oSVNOIXjBDyh97X8L59BvQSpKqGggwhpQklTDbhPhgqFvluZ u6/S8EEPSSSWlUIUKBIIJ2Dh0m0DC76yaLIjcv7CvYv0FQLpqj2R1nUGASoMgX3WwS2hq9rBNwnX Vf0glrhpIKOUBpZFAXBsECxw/LcXkhcVvC+vrryEEQgoIjoECcN2RwfVO9oLdbkR369BKvGIURTQ OhC6f2gvaslwv9aQLq4YTIZsBCQQYNelUMNapWGC75S8JeFVbQRHUKg8LwX3S6wYILXgwqqC4LZG g7ChCGcc+1upB5HMjidhpJLsV7bDBSM9wRBgdR5SAwiGzQpuLaqU6avar7Cv2Dr7CBWyDA9gwiIO 2UOQQcEPiIvsNpLSUhlBvcMUxUQv81AgbEMxsP5zZJxQQQ0DT2rC2CTawwZHDYGGPj2jrYhgvbBp 4Jp6YhX9sPZmEBkIEXgwT1TC4TfXDxQjud0RHZH8MkOCUMFshoB/9tViIuI4MLBwb16DhbtYqGTg rP902ETYSR4fi04iCCH+nJjuCJskBqq2uGF+HSYYYQIGTbX2h4YLfVXE7LEXzCLpENtOTHM3Cw/2 Gc0uugg2CERIVcIQJHFiIqGI/4SbRBrgy9CKnJDj6/pNnaooponQnA1Pf6TnZQ1RBlHNIyicQMgY vgwtLq2mCKexIjnkqsSIBfyVZHFLmv0nsRZBxxVkrPwynPad6oLbDZIDThD4iO90u7NQaSX/pJpt sjER0XZHyOGjf2qpC2GGIiJ8F9Px2EE4RXhgw3/9Njhh9UGtBWw2SsEJCVvHoLbBhi/8JNhsGG/9 Jt21+oSbDYYeVPpel4byCltWkE27dBU0609g2qBfut3dKq1Tdhvhf2F7ql9xO9chojjI+YXd5G5L +TYS0IiJMsh/VL+TZJhCQVIKcxN96Va1JtqiOB4YI8XRHBjdShKttcmyAPBW8Kg0kqXk28FcwB68 hEbyOyOSr/+QaRylHzYK5EgQ2jNHw5cTtf9yBgX+iB5QIiI20FWcBj0iCbgrCGyPEeq8hlNAHvL2 oJEdkMgMoew6+Q0mgvqIn03kLUhoHILj+1+QJGUyKxca00QwUkNOzjmmU43Sz7LrkGdlU3+9Nklg pyxyC4sdyi5IffYIWu2t17xEREPtpRe5HSpf7Wt6fJGR8jgpbHt8O67HWIk+XDTFrrp9f0JmihF0 YQe9bvCw7CxERYVf8VagrG/9dosv/7Xdf9JBPf+tR067qlXa8J+uibv8hzct6Wrde1SCXQbfrXWr Y8rzDRql99dIJaT5bknWtLp1qmulq+CBDZY/oJa00NBOZC6OKlQXQYS0kQUQUOVsqKckOUOU58Kc iDiScguOVB10nS6F/EQZeL5HGSMvmMhaI4oIEhERERERIN4KXjQSwq0kIiIwzDlDlcVqezwUOJTg gWIkxzSW6hBf6mHBEcoiIsIREREMJUk9d1iJDMHEhkBlwcpK4kOeyvLcvdZQ57KjpJ/4kNA5CjiQ 1hxDI6I4zGamhEREiuUGbjjnwociuUXJjiIrCT1+YcgunIxyhyB4YHL1Ks8ExzFZQ4iIiIsjhrEc NXBL/7iJoKR0RyI6I+XDLLguIiIiUkYDJCpBBKGF7uhEREkGR8RIYZKUEE4/ihEyAwyAUiOJSC8m 4zsUDKHIKYZQ5A8NWiwS2x0JEgokbiPEcZHZTojgwR/UIF9hCIiIiKQSNQYv1hSQC/9UjwbPvQQh N3dJAmRVnK+o1CBIg6o9VCkDFnc7lOehh+1kMtcYIiIj/IELmJbjF9kIOdcSjqhErg8jmEQPMcIj rsENBmqOOQg5DO59PEREREfvX5TZRbLOJIshiv5LME14hBgt9MFUjrlnEkuRERlsxuFFSNcVJuNA xegh9OC+Tcl8fhAjF/9IJKqmTrr0EQccfhdP0EE99q12ECIJNf0uxQUlf0lW0gsYSS/yboUFf/2x CC/w52kjyI6L60yzNJLvOxfoJhA1i+4WF6oi1oIg+yCnCsjml1rrOxoHy3LQ2AgQhoEcfvbCoL6O zAEOCIaHggSI4ERSKHnayuTYIKcSa/haIrmECqhbPBbgnvoQ0i3FTr1CIMDzNkfUKEzIFR3QMsUZ wRHGEUrZ2WiuZFD94IER5JfBIUIsEcd5TxG8j4IgX2gRKhDQQKzITC/oELX+CYZPG0XQTMaZDEik Qo4KRR4phE0b90W5jTp9I7Tg5dREWFEjWQ90Hc44kx6jtCEH3YUfroELCCaIo4dhYNiRzoKjmYNI hx0fdnmhTSSrhJQRGwS+4MMofd4TTIjToIGnTEOCKf/ggRFAzUghZqGQPLrC4jSIYGxGgZSKrRxw 1OLSxkJr/CDVKEDIQJpp8hByIkYTXz4MSPoRCNzW6CIYytfQQQMhn+gggYImP1kxyh3xIOXLHcGm lqdk0XGR0kG0H9LFa/lwT0COsiGcck8KCM4rRCwkm6kY4cWiQ4f4TQiGEmL1hAuqVYTitoiWUcIb Q9J0g9sW5w4vOi9HHIQc7sIgoGL/CVf2GrCVExZ1UJ2ER17IOOGmECQPh3xCHCIIOcd0n0kCSpfk KUtLUjol1oK0tPoMSY7RDZYgiPoi2+6wk4RFIhV7sJa60QziaXSEJoiPkIPVJbC2GfBdYwgb1ViE 3CKc6mHXUmwpUEtK+QUAVVhcVJWCitIKok4Y+FeE6DSaC9KSxXwmkq/shlE9KoVKEtbFVKc4+gVK 1W0E4IJIIw6hQ1ppKklS+GH1uCtYQIaU+klEQ3FKG3BPXr8VrRbisQO1oJaS8O8KkagRbTrLsad0 qbVVWEggoSVj+utJavTbqEsFhXhWksNJbeCVQrSSCVJe1SqqVezsGCjwSbMw0V1DEPrXuE+FdKgu WPraC91wq52kZHB+gkhUschBD7S9kO/CxII9WtQSCSWH9rtDCpfIGhPCLhX2UBOqkQxO0JJWRR0o KFvVKgSCX+rCCVhBLXxB+Kax6QXppNIux5mBELSa0goS6ft+KWiIP7D3yCiNtrCYW4WnRnSGwk+n SBIJeGttpU0qC6ra2QI/DDDqmCrBLEIU1g2rS4UEElbC7YS0Frfa7IZx6IOiwyXX0PgoaVBMEmo8 RXj20EkuCX68JfkF8PYQ8EwuwSa2kmKQUgYcKv66WgmvO0IF4TkdEYtDFh4vIxyrSoJhMEHuEwlX TaQtaCzP+0thRY7d9MRW1CprQKF/DYSUjfhdd0GSERwdWC9w7jOOoVSDBcEFSkGCAl/dJEmwnpKl 7DCCsuHxhVBdCyQ4WkzjoQwSyHqBU/DaVE7hBCFhBdbYMIjojpCK7waDiCKHEiFUYLQTOOUEX3tB ZwIhdhBWFSwhFhAuth4sER+EDKWliNUnVio1cFf+JIcKqyTyPkcsNC0LVDsPunCiCimqZxxCarEW yP7KlqFSw9VSXjQysJjn2SuJKcRGpAhcyTeuE1iI0wZH1pu8NJ2FTWyQ4imvp0sLGw+LC6wk2oVM UGFVEhw5BK9NJuGUOdvnTaIoRMEOXQYIRukGHBY4hmHXSYZNhNEhA14j1Dk2MIE2U5Q5WpUyqiDt y6a6TDFIRFMjhq0u0E3kYBwwX0mGhj3BJhnYGmQVxyhyhyoKq9Ug3bIZUHKv1bTkQ0S9INWRJSe4 10nQZViUpN1Rfp3RAhc/H8IdEDC9/6CYchpSSv+FyCrIL9cZQ7QP/i+vfBHdyIO3IKss9ElreCBh 5Kgft9jcGySHrtr22wjDyEBOthke1sIRBvRJynBcdsmywRHDKMRHH4bvEcNVJsUo8CwCbbdZ+I6w naJt+bZmj7BAkIh4byHtoXg+ybGsEIZcDw0mw3w4dYQXiNt+zWGx/q2ndhE7W/RA9nOOUO/q1ax8 gqjmVLae2EEG78hrbHKHN/vbQSddk0EezF3V0lu4jd5C8wntK+vtl8j5dEfI8XjbLgYI+R0XRxG8 uitpWKRKPt3iIiIiIiIjUjxjI4NyOGYRxSO8Nf6u4iIiIjpLzjI/d/fpJCSTI3e3h9bkGEyk+l49 EM1y3PZkwab2yDhmchRz1FOXBQ5NyDWPTriIkCEwF9uybxERERJCJmi7I8XPrRA/TBb614iOg2Fs HtXw46YMw4WdAWC2xNd6x5N2I5TgrkdBbX+r2QYagjt16p3Hra6w+lf3T+6pdX/1XT99dVuv6uk9 +lrq66f61e6oL1/XXVhe6SS6d6Brpaj4Mm4GGNLXggybhxcDGEtBXTJsqoujxlw1Ekr+mTYqBmVK q5XogTJsjI4cjgeFoJbCyb1eMtxdEaA8GgJBJsdO5kaRHyJIuDURwYLgeBOfEoEl4cJmQmG0TmR0 RwyA0kEoSfCDyCoOTrK2pkGscgYHESGQFCoQQQS6dCRMIEOSHJDDOZTESB4MxBS2EoJfJDuyMcRE hgcSHEyB4Ng5hyoIKo5Bp2DVBBPoKGWkLHeUOJBXggeOynIZUiRJBL1DDh6iJBtKTjkxy5GiCRqD Rt1BhB3kNEyGQDddZtEMNiqkSERzvwjXmAII6NxHMjoj5gNQuClCSBBOCKe4wzaQduhKEIiIjKHI azdAQSCWVMDCTDW6GIhkKOWOfibepAih5sDGSoNJYhyY5McHoREUQQgRBZMArbk2UKgxDtJQrNYH FAyh0nhsyK+9Ig0r0ZHA3I5Y5ksprDjhMJEMwcKJDTwpzG4lDpjQM47tBhSChdOQ0lZRuYvqHlcY ITcT5Bg5S9RDQ5RuZ/3hotzJCyEZyW/t7EcU94XotxJbw/mQWkH9XIUlVP+Er7va+Prspur7Xgvv nYpepbgaf/d6CvH9zD9BL6f/7/pr390/+lb/+91b2u+ujIR6709PVNvu379WdlF/+lMiLW023rUt /r7ZAsmFd/99rv02WKht3771ukiCEw1IwHV//rveE3SCDu760/36tkYKtw/umvu6SDbQSIfPf9/2 /VsJSSGiY8O/yFIj1Z3oFI617pMjasEEk6TbfpwQh24IQwihx9apsOEwva/fDW0OvVNYYKreG28i 7JXnW6YK+ELkI5LXkSSImNBsV+u5LxphELZwOE/p9SKPMsBo+0nQMMKtVbTTQu/04X0TIlPlIMIH ZDSoQnRJyIlq91DecGoTh4Xf3aCKgVQgYT1KRVTYSbDSXSSndhqJ+F6hdKvCafp9NUGGgvVJhlLD aXwmdbt1uv3daegrCg3VcVlZBWsjnqUDq6WtahYV2n+lprpWEJCOVatUu5awomiBAo6SrkTpoFLy IKIKc45VXVUtBBwT13RBVcELt6hB8U6/9BCEIbO5xzchEfX72wg/SdKF2oL8tYxrRKa+vhBMRHew XrScIhYecLhdfxhayQidHCIpgrGtaS/p9aWgm8j6BhbPRjNjbprDaSekHqwRSRHyPoQRH/6rIqvy Qgv1WEE2hEaILjiL5BqHK1VN4XbIMcU4wwirHFkdF2P0qgoIP9CRIdKqS18Qm0QzjncsuruQxe/E cECFYaqvqSuVAP+CS9eoJBv3kER8N1hELH7BMofj66SCKERxDWDfXCTXSwlgg3SC2C/vUK+mkgQg haX+hEoAvUPI4Z7uksJAgW1IZQrk0+m3gqCBewa4JddKkQ2JHUQT0qWdA6hukSww5xyoKKY9O6Ub egZY/REHC1C+sgwNev9QSpuFiIi9ppt0l8QyGUDsEK/1ohxZPBd0lggq2YsW9N3UK+WsFhs/sKq1 JDlFXr4VRSBWKpewwrST8tZYIu6SCur1wh+FfSoKg9fx1CDfDjbQXCIo/VUvZEL3HDUIO1/SVJ9r tdLX/4WtIIektN6avptk4tptpWXWlw1oGCp6QTQ/QcNIJvSpgjj7CwwSY/7I66H6DCpb6Gn27lzS skAhx2cB9/iQvlOUMj7TBCr7wn3psQTHbEKqrYiH3YkwSXgyhzDhVBkc52nVbHC66XfVxS6ERaYk I55DB3pmHVsKhpskRHHCqsJawo/hgg7IEDhOwtYaEJkFChdhLcWD6sEKQ8LqMGh7QXsF8SBhWgyK IWwRUAiWW5QCKrXeccwRDCqh7DXhkUcF0xERGuy3GkRwfoPC+wVMNZCbV3EfQNEX022J3Cw12y3C IaDBiOPx9f0/1UN9yzBwQqD6rqWcbjoG0R0Rww6hpemYA8fjXQ1S/BP95DN1C0kqbInFC53OOUOV a/8IRERrqvC8gSVfXikTdbX/1//pD/3K5Z6V/JvTT0ibpeFq+2+lb31daCUVrdldEEUPa3feEKX0 VNLbtfsloRw3hhNeggfDwk9K1V8YX1//pOxtfkk96yh+krY4/ciQZr/oosgw2/5G+gnZoBR/M0mm tXX0Gsem+u0mr2v2EvRBqHIxyEHLTCrff8gXTIhLbQTXIg5JMmPbUMivwYQ/tIf/tpeH+2ktj9+v 7Fdcs4Etrvjv/6/21/73pd931/69U3trtaJO36nYl6TDS+PTj/Sf5NzC+76eEmG1wTK2tX7p/Ta1 CspedW293fT+t9BWldR1fqv0/XUNLf6H9aX//pdPWsNLcLi9Wv9f/kKmSza0+kpWA2afNeRGXBq/ idA2r1msCiE4Rb4B4L+gRA8JgVpoIgzjlJrOFIMrOClNMXxZAiC4Mzmj8tmE+xXltQr6rq/r176+ r9qDC+PWlld+8setNK077ry1xJ/6LWKWml/tPW6tp+9218yShkf7afmSwDl1/Wpx3DqTcbw2Q5ET Uoc8u6EQiJ902icVAghIpYbddIyVNBkfKsuthEHLpMFIQvMhVkfI7CcWEUOvd6rhPwY4iXBBvqLI xGEYRHuradWE4fkZmVECEiDgpIchocqyh4oRD6emqZOjNI49OPBEUcw5EDQOhFFPIw81ZH+radYI bnKDBJSKZ2kAgbMwII4dCLj0rEjylqCDVEngih+FgiP0QwLlPqine+EHShJpcLInNZCJNRcMuyhw mMJ/Wg2qBEddV2EJT1VSkKEojQRDuVCQuvC0pY8ZOEqrQI4/pQmCe6CPcjmU/0k7hcGEg2r7ChAt 2EqCI6TCarCVUKT2tXVDMEHGxBK76rZHzCwSCon5Tk6ixyh+q+lVchHWmEMKnEW6QWgQUSh0EIqZ aJ6ul/RB0gk8LH1KHGrBphBGA6vFL7/65nUscEERDi9CQQeiLcrYGHSC0EFHxUJJpV0E9jIRBFDt FDhpJaCcHqKQi//93QahMQS606CBw9qq+px6X9MFRBgQYJFDlQ+FqFO4RHBOj316QsK+uOa8IpxE bugtJxukwQTtfmekl6xdOkltKdnCXFgtevXsEd9aKHJjkFw/KHWlhvS0RGdZ/4V2fFtTqiOmOKDV xX21Ugw5J61dr0mpCjrClCjDBJDoJUgUHtKwxKghh/X7BLY7zeCBQcKrr0yS6eyFm0VM45xzjguH 62KqrCERs45BBwUguUoulpIFsLpYiGEPKHZCv+lQaZCYhDKHLHjIcEKHCBRpbMCFyVLkepQ1GGvp WEMFEEyk6ERriNI6B6Z3Q6DX7wpGOmhkXeJKQ2DtkJCxG5Q+/SqVjEMgu6Z9nXCdEh0CBC0yhzD/ /CFphCakkkwuIkKPSGP0+lTMOF1oLiFkdEQi5//DI0WEPsLqMWvYxiIwSUJvxr40GU5Vdgv0WYWq YegxHBkPsSY8bI6I7K6WqKdGGY1DO5/K2BBcswpHjiog2IIp2R1Qj8s4tkwGw+DHsIRcRWqZ8D1q wt75gD3tEdCkZJNLxIFd/F4a+Q0eU5XFEFDmHKIbpLQRQ/ohyAQ2Ez6EbN5HUJW34ryMgomhEa9W PwhHtXa77VKn9Nd3r16sFRQ/3XB41v9DCr+u/j7v0+lvWvrw/tVVyKfpe1v6uuv/fX+f+q/erluL L94RCaUhLoF/34tf4a0C16ljt8Eu9hQ369dwbWq7ZJoK94socFfPIJkcl8Qe+gwlT+NdQQV2E/k3 ElVpUxBV0GraX3ddtBOwqhFDwu60wrunbGIZxwqLh6/QjEhocqDpkRrTURIg5Q5SZo/tREiJkfC9 yQ5AkTCX9VyCymCX9B5wCjr6RrBV/puSeRwaPq3iPXROP6SW1t+7fqsJMP6+/d3p+qSq39q+/q9X +lSa77hFD2utcb3f6Gqf/5h1/dodq+tj8f9P/99ey1hivVFpFSH6j9hkcE6oWTczXchYa6fBFDyX RTgrk3V6loi7IYsSGs4RNkLtehIFhuU7/mER1qW5hExLVkFIcmOfzDlDxziVRvISvINg5xhVIj8G kvLIqKRuVQqZRYu7r4tCI+sNbrVaJvTOL+Gn92xSzsb+IpV0lhP/0+v6uTcJcJkatauI1pBB29Kv q6X5G/0l+t/pL+uy3S0/TC3pKqatoJ6lrFavr/7tD61672y1R3pLrvg9Qn6Q+qQ6Cfr/XCvhBV69 fW9/roQjIEiZWvXBEKP8EwiE2CfLojsj34J+gTBUuIiR7jwkloIKiBGylld/IQMz2gvBVCD1oiAa 6tJeECTUrXkdm2XRehWCZKxrCoLwQR3rqVHZwsEVAiIke6z7EOkQzSDin6VYSIhBfjTBDV+Q2CIT yXjsc7pLhJMqILJWlRF06qugVrSp+qUFvTCCJ1pP9HWvkIOcd4TVQltJcIg71UJUPCoqPDWmRHSy z8g9dV9JOEC1cEq6QS2EccLBMJ+PqiHfqF6C4ha4SXSQXRhIVqv1hNBXSmsaWoSkccJJNQgq+vEh xBhyOiPl0R1qmVH/sQvSBMJb4wgWvC3pJKnk9lMKq32rC1SCdcUwWwugkk9Auzol9V/00F9JoL4I hipLSBfpaj1hQq101CWq0CI66YILVar6T/5Eiv+tVpBNRuoJNoiP69JBJf6WiIPVV9IL/9ELEFwk ul1rWvpUk9deR+vSSQLokdgiBD8JfSv0tfpaS1/HSX/0qCIL90FVdJpeq8QlS176SSpLhQpkVKuF 6Wv/VJJVCoJf0tYST0TdfGqQL0vv7r+6wgqpL0koVJLKcpwS3SWR1Yr/I0npdL60u1/wv4iNelIR oLQXw8pCQf+kl6rYXrpBfV/SThbWc+Hgla6Br8LQXmYT9UutfCpa4WFsMHgv5EVhKviCI64/SVL8 EVe4qtdUEuHhKls6CQ1rXGjyaXqglXZGn1SUeFFYbwSeooNpYLVYX19JcumwgrvX11eEq6ZhxWks ER0qTX+gtC2QfzQvpK8FVPDPgRe8aW1jFNe+En4iTDdUlsYVA3FJVQZQ6aZQ4SrCYLcUIVUwnuoX SE0QeC9kM4MQhF+sPXVPC6SSC6g1hUlCcaYSCDKHBdUKTOOQIUPpLwTIxzj2n2EGlhUI7ohFJCwX bCS2LEcF4ZxwQMKhrGSJQgzjlCnpVtMKsRDPIV2u4j1MtMJIt7sJghoaheLf0oV4YQZTmbicWq/Q SF9nHCEfX0NeLKN6417hQsa11Ca2uuIwjKtCphHaWriOI1+UxarZbQuh9CtSzirLkYRJD+CESDA5 Vd/Eddf40pCOrhmUFQQynKRt4nRF0KUIodKI+L+/////v1VbXVf7ko/dqZr6692r/WqfTv+/X0tU ve9/oz6/VpmtJpf8J//tfX+CCuvu2F/6eEEt/24Tv/1S69aCerLNSvVxT3j9hD+/fLQGtbT4+ser rV1+unf7/ppatB/eSjlqE1/Yf/Sbtf03Q11YeWjndJQ92WgKXun7LQVBa6TdQZaBMGL+/Bp/2sm6 jcF143tha9eRSDDT6+qg0TdXr3YX2ynCp/Q+oiKIREkD/rwTp/+ybhqZPX+qYRHtaOuTC/+uTfR2 IJBd+jvmeHULer1127QU1/vXutJC9fS/tQlkb98iG6LaX6tBB6oKl6TqglJNsIj98koEE37S/JsY RFEeVtBLCEV8lANbpaSiI1S0U4Z6oW16ldY/hqdAb/FtVVVh5oGV2C416tIEC8geZuY1de5gMrgy BObi+n+SehC0WdURHI5m84jRNoJ1UXhWxERCCEaC/g3IKBwXLOlIIIbCC13QQ1EcJaSmQ2kgZBzY v4JKQ4j6ToHSIU2V5XD3SzaI4Lkryo64agzGwHjhKI8JkYvU7sQfgpXBVpp2u2VpBdFmaWEQR52q 4grrdHYqnTtBdPBBZ01O1hE4NTatYrDQhbTtBUnegiOlsSOksyExCkb64hardDp2l6dV4XvogwOW tURj4eSa2GRASFsKgWFJcKFIpdDaT2q4dNkY4XoILzWDEoeRCCdMhdxrbS9hhBNDdQSsKCY6pkDV nVuk6b+2EEOkibgoMUqb2E1/rtL7QL0TcpBvqmqp5+/XtVIZW6XhKqS+mmmv0oQfq0ag5V4bBAq1 IMR1CIJ3wtK366JOzapU8EGthBeoXSotwg162vXSSTBj4T08MVepC06Io9aDekiFt1f3WobVU7Cg sLQgyw3hLglDXwvU1SrqtMOqSwmrVMfquh9JvSCb79U+Z6QT069cUopegtDrr1SfXCIeOuQiYXLM 1Z2U/X6FPv3pJUG6XQV6IP0IIlyrYTfrSev1S9adQlgk7oIHUJhOqi9Vr9Vu3SQXsEkK9AnSNQOt 07he9euuqC02OCfpugqelV0qsj1a6v+0FqriFwiQgTBES3XevikuRB1gq9BJQVKtLVCQQf34Wwny D6rpKDLojh/61eFtBKj4aHCT9BKOoT60uI+9KgQTULpXMAobSb0wVq4JXr076S2CQMKthKhIZz0r 4u9gtVddK+lEIWvCSWk3syMLuGCTpLStPxUEPSsFwnqPcQt6Vphd1T0CLHCQThK79tJILrKQT1YJ QSQoMhgQ0nrt0Vjd6xZ0nhMLapkIopN9rDCHpJRfhVyk6hUgm+IOwW1TixQZe6qYJD78QZY4KhpK hWGR4wDGEFeizBkI461EVq/CY0+GFST9P9glSbphfWiUK0E9pdrYIf4dUtIMJJBcLV9DpdYXrXXS r0kF3S3S96wvXSHoL0l/Ca664tYKlVx0q/pJV8Fx9BJKul+zsbQSSvhCEv4X3DOOXITVcRWHyulp a52LIUq4pctcWWlcsyoT0uWczDTvS5ZwUCg6BRaXhED8cIa6Gl4IjpLlnEkiBcuVhQ8UuLMqkHHK tBd5WmPC+OEvqgrfoLXr/Bgq9Ddb/9/1/KyP6ksYTv3p16X79f7+9+yo+nxS6rf9yH6/VcJZZwP3 2a1VY98La/Wwqt9p3C1f/V4fvtBWG/9pYP+2ggsP/v3r7Fdv9ppfXQpe9wqdeEF7XYSctJLX7pR2 6bX/YT1VB165Mdj71Da/oN+vt96Tf+2/6Qdcof1b4/D+l/9KG/rtf6H3/68tBb/a7O1tax9Myf+p NxdJ5C0t1f0xor2ZHP1/kZJhCRGQE/HW8Jk6PoiOupZEvC952FIFERIV9dBuqDKwsUgn/09seRok pSdfTsqE94QJwVP+WQl0yLpIVfQSQJp+oMOMseo1QSBJO7neA6/SpBBBb7lZDLkh6X6SBAki47QM uiYBSf39RCBJN0ojCXquklTd2FT9egkRFK9yyDagqr/wgqbpluNoWQPHf/9IJJfsm6AZCOjaLvJu YFq6+0kCFulk3rGRzLiCI0CDXvWtBN8REVBN+uoIj6SCe+FX/jpJy3W16T9faVKx4aCIccqNLrrp N8URBwhff10l+Ehok2qXW+l+S0/v/SRCf0kvwqVOqSbdUgoWvsrC1SKvq/oLU6dq/DKvVc1AgSv6 tsodproaa0RdEUV5mDeFZEG3qph40F6SrsINNynWbDKVwvUJDqnWpr7WwTBNToLrUMJP6T1bSSUj P1CDC4QeqTgl3XVVUIof/QKqLHShMiPRDRC2wl3roJVnaRAh6fgqhCg6aZJyUhA1TaBXVUlV1Oxg Zd+pThsVEh1pqnjrhL7CVJbzuiI4aW3qEC0IWqr0rYQT8yS3qqS4Q/0lUJLYVPWmIXwkq0rpJL+k lCdQdf2l4JJBUglGEQaMvpUEqSwiF5pLqsE/BAlS0qCIFxyjpdVRC4lQXBB6RIffSrwSoKkpJlUg u5VfvpJYSWEn0u6UJ/CCUFpEQdAuiIOUrvS8EoQVdevfSfcIKlQhUC9Cu6WglIMCKivCC2/CIg76 mRUJhEEH6q8F6aVUEjWDdTRU+vDpIIIN/BEVqawglhUFSo6ILTrpBUCoXWwuw/CV9TISCOk0aKtD SELekm4WqpcJchnx6TfaBERqBEfBdVqpQ5DjrC+C6QKGtKrPg+xqgg3+UOU1DAhaCYWhI80iI/uu ORR9UFcJJt6CYa1EYTigkiOaBLhKuK1INB1aSiCaDWErrlcLZHZHUJTbYKIMji0npJ+0yDDxe0km sHpBBh9yuWgxC8ZGOkCBJBAuCXbSIk15Tn0lCs7KxC60EG66Ig4NhRVMSoGxIR3ggnpBNMFtkMWD 0mFQjYSrrngpMHCqMauGR0CTmFsKkRUYMJMHQLXUJ/sGfEThVBU7EQlT2nfirFBSMJdJpewwYYJB gmgwmqqKDTBUPTYUpNU0hrhhhsEhhDCuCxGtrKUkh3hLcMg+EJMKoTUFtXWqXjXDEVsLDWOwm8En tKrCaO7QsINYcjjqwggk68GFQhkJGrZnK8dgk3dcGEIjTiIaiElaXBkMtsQ5TmHO5h9bfy3wM9iL EQRHTBcGlwy8bRVBkcxapkCNn/DeHgq3Sqr4iyLvLSVpbcGErCS9BuhwYS1W2khrpWOEt7apa316 TbhBd+gih1uGXTrFWrFTtOsEF2G4qwvDSLZOsd2XBBrQY/hhew0ugyHNwZWzlNNURkY+KZL5HyJh ix+bR8C5HRxkcMuF+IiO9oSDPetFvfCpdjILWnrIbNSDFgvvIIZ/yLuK+EtcNP9erluIv+W9nfa3 V8knWWQtVb+9If/2WmEkvaetIP++RXrkEoiyg/3fZ7SsGQd9dftbwxQ37/XB6v69bX79fBlDr39f iHp/meU/rm+pY4X37XQi7Eb/4XXvX2El/t/aX/a+lpf/2qtcLa1aBbJwXXu2krrQ19im4r/1UKF9 WU6TaFeHEMjN1FhfUarW7+1y3Q9Olrqt/fQf3h6tdL0Rw0u/pNv1K4mJ6WPULfT+yukB31v4QL0m 10knpN9sIL0uuEF+38IiwrivzDpDUpB1+NiJBDYKTa2wbS8tKiqV1YHhqb6dorioUjgeCU/wih4k aGRR1X/6xpPF613rqvv15ZiddcaybhSCbRNxpW9fJk1Ua9ahBlfEF/52OJQJBOrK6pa8rIEDCK7i 1SDv5Cgykgqtp18lAaZNwTSO3U94XD9ZAwVCblCBAsgqLpIR1/7kGCmIiIpf1fUzyODMTcsVHY66 yvqoVcNIYREVEEDI6/VnZAp8ZBlDk3Gsj80LZUR/UYWkQbAlWwRRlEfztYv7INxyihE3J8IRPr/C Sw9sg7lMoj+n+iblcJZDr/T6qI11pZ2MRkBq3lp8m++qVOtAn/0qr6T//1vBf+uq6Eslyfa9elVP /v1q2Ck3WUF3660s48K1p+vVY+rTI+R/69aqioKHksblfA0d//2FFhLK5qGX/63p/zJKDT+vrpRO 9cECC+d2d/3p2/BR87NRP6rQ5OuwihwXgnp6+Fr6EhmjlIqQYgXakJKrWibQ3HdlDkOhD0U4OFyO F0QIlTB6XXFkqvhUiJhl2iGZI1wo6vj7acIjQaWg/7a5B/pAqIcbD1Srtmtgjj8J/oORRT52EPtl mVa692C96IMRQVZQRHVX8EwvDHwvlPWiD++QaxwWfDEEn2lLcEStrShO8EGUgR0C6DIZxzWCBIcI GDJ7BXwoUQunuF8FCDWqcGccqAhEeHr2wq2vgpEl4KE+CuGIvhBkJYT7qrhdVKQOSgJ6a6Ww17XC Ig/9eq4TBBhPSU6JEKP64b6foL/T3dOCIMPCYJ1YVBhETH1hh/IPD+E3+F5dLoQqChPoLEfXD9Ee tdL/hX0QjzmnCwmvog8a/h1FA9Uk/yyBaYJeO0KhakhhPwgnf1DD6DqqX8R+E2zj61tbiCt/5Agb /9f0Qg7vsPC9sIgwO+kq/Bh3XWlf0FxT1C1tEHpeE6C7Vhv3kf9+oXavrSYgv+FuoN1VfkaS/0uF 9aIg4VfCtEbkXcbw/r/DrqqXhuoXR5F+F8LozSwYVv9R21+zvQXUbXQjV6S48ZL4bul9uvxpPX2s L3r3SIwT66Df3yzCCSV3rdBEdfC93OWH6Wsa/qldO1+P/V4RQ4Svutkf/+q/tb0vXe4Q1/qNSZpV 76C3d+Dr2v2N12jPWv0vquaXQ7DI/11weyC7pMFrwlWP/0jYEEcJ6xZH0tw1sgvZxykqGE02Fxhh a9fpIRtO7EiVfHiPNZ1HcNJ0sL9JPf6V93HrjrsEsgn9Xa/p9uqhPT8U43SVp+UOmFj7TT7CHaTr StEjrEGvwwhaYVNNeRUXwkhxyoRHMvveGELBNtbWSYEeCkG45hwhsREawZh7IYHCdhDTkGGfjIMa Ea43fEREQwmCyGGWdpFUrmREZMhBCaYTjCzNAiGVsD8IMhjklEmDxwwsEJBvsTXVtha4aGIX4djY TK9oZDKHO3D071EIIfbeEwiChuE2+goRDY3SM4/bwkdgaCIMNxKPosg32ElLJqkC92WROBGEqGYc q9/JuMBCOiOELog0R8jgXdBCI9WE5N9APDPoEZJNr1YILaq+Sl1hEDww62EP0mtBbTJtQRKhdhPo gg5Ba+Y2EJkKLCRli4vyIcpzjlQScg0DlUKuIrj+9IREREcm9p/8NKq1ceyDzzD/Ind9hkdL3Yn0 LfwxFeliWhb/YfexLoe4a6/pA1XiRRPy30CjukTY0XcVxZTJV+pNwpfVysB3CY/VNKF/JZK4/wnr 98JuWkQl/CkUcrWTdZxSr8ITHiH52K5kDLSaCe1dU7btVGop5FPTTctd1/T2Ne7672NI7LUw3Icl hp7ja2C219v4XS9vwlh+rIMG6vDV0/sgXN090l/w9tBPv0+IS37e39eD7Cb/Qa6qvsim5jYeu7fi 3RN064bdf+6oOFj23TYXWGsjdj3DbaCDfC9K35x92k3zJZUb9N5N0r73rfcct+DPoIPoHyuZMLpP 0Wcn+L1b4Ir15bk9a6/k3FvkbcRu8m6er9W/pZQF0nX/+76Xrt/1f3/dfdt+1r3+UP/cdM0VN/fb 2FpDmQH5ktLy3H6u6j3ptp//+kZ+c1/cJfb9L9Nv74f9f/7XGdiuq/oLvVypS+VzK07b//7r1tR1 v0lx3/x+vpevpeW5Iqu/1+2t9lczQ1fXS/DX+Nwu1/okPH1Mhrotyhe8m6Na/ML7ytLGxu/5MgwP jXkjK2iOsfq3XlUDLf/E+i6EfUtwNe1iiVhq/HiPTj7SyJgqrmFLf6rRQ9hm9bIiI4HHj/V5blqj sRUgjnHGW+J/9Osag1EY5nke/KnqdpP/lvMMSB4/RhHRREX1en+TYbWwwTILIyyjcarrw/1uMhqj nHOKxJuDDTKe17h6481pEvKghGSuCf9P/cXESyIBVCx+nVVXLIkBlCZGpIjF4YV+VRVwVQp2XBdV 2qysIjRqQpfcIg2zhNTuoNi1kGiFodSpjKsK+JXC1DTyGoHVMF/OiQMvl8IH0QoOqiOxkMtwVIhL 4SXNSCiCKgRYQfk5AoX8hopwk6hcnSSkDDDaZJpLCaa5n+RIPr4WRgYC2n5UBstPMCvhMKlgiENz TnSYMJaohoHSVeCqVHqEQYeoVJLCD47C/CIYgE/aqqaHF+E1kLsJCZ3h/VBEdXoENf4RAgerYWtU FCiyBQJ5Q/Yod0Cr/QLWQg+ONEIOkrCalcYcfrdBLWlogk1wg65dJLCtMKsF62kEq+qBfWiCPkCI YoIIdKmFKjHWlVIJav0qTSdEJ+tC31TuG+lQVJarwuThboLp+0QXxp61/k05SqlV0tJc0CJdMp6B a3BB+shnXqsUguvwks6faxULXoOq4Tvwrqgu6rS5tClybvr2HVqnrD/rgtWvSp9Kv15Q+nXwsEU6 6rpfS1CtivVBYSqFYdarp39aSJwwXahFD1rBKQo2v19M2Le6rrvr8F8dJYMwDEMzX+iEeS6rBCmH 9SKOlXWvxXthLjYg0k6wljWEQynCbS6p9f/wusJU9/wwl+RwzKf4JBB9EI+u99fFNyCgf9LFQ+JK wUJv0RgcGtBf6MKjCkJscLWha2q3raSkIGm6WlHSu+eXaQwbC3ela2tLegy6wn0ukP6l0kXT/wlO LphNsJriFjQsJ664T+LYX/hkPUxWgwrBkIOELC6hBptpL67gkItDud4i6rYQMFiIwthC+n+sJlrp 8juCtWiDQiL0PT0VtBWktMoyOlbMhVaYgiOHrI6cWmE0wqFDFc6kxHC+7S+JJshEIaaafCVpVWPC TP26L4iIwhIa1gzCI4WFXXH/DCENAlEQqX9bTQi52nwlTCr46QmEGlNgu1VOZC3stYzWIg1FOGFX 8cMrYRMEwW5lp9caoWvHSwgwqse1QMEPV2EL7FkJL9wynKkjxHqW/L5buKR09oIQZH+inoSKm9eN MbqWaCK7I//yGY1xv+4X7ltFvDsMtKiGuJJo7Ar2LRZmiq4llS8fb2w2Omy1ylESRAlCuWqFoRG2 2TcDRNlVDdNMSLomnq8nyniKxbkqOYjUNxEhgcqCq5loiQhG9xEhBwxHZXWwURRaQKtZXDz6UaOP ByoQj3yuSooBccm39DEhOWBHHK5DscRNWRwcjuHcRb/ztJpfH/+TcP95NilLcrrP0NQih6+TZUqj 9FUO2u8ghuUMimaBcRLKaqFkM5uJVBPC3YdWFxhSuZRHDGoXuJwEWP4b5BiwRH8txNFcs6hvkKEi ZJWlcN9Gj8f9L/Degk7S/4X6v4L/Wo6q5bwBH48EuuqWS//q/vgwkyOgnIMP+W/iReyFHXw4eGEp NwQ+TdVUL2uK0JapUjy6dpfZZE+P3uv2x7ctw0qax7eGMNL/6Hrvu1ZZBL3e15NxZZbi3/DT/qVd /dJrHW/3ViqfS7H6uCWnr0gveWTkqVSuaARp5N1RD1wQWn5KEjv4eQwbgeRu1E6Y/U7GLBkjcVoK G+QiH446hvJvREp8SvVnYhaluroXoP7uo+E4PrDxsb6K4zThPUPeviFv00pNzFd+t9J3fpeCI/WN qt79BD5Y6G026+udhoyWx9V3+lxBY7c6J3dfndSCbM4XaD79K4hNRrM9N/6JuZLrduxY9ePvpV7K FnawakIraIr6vTJO1OBwoToa7f6oiipTlbBDGWIpA16T36ZrQTNIISY0T2PzvmRwaDCI9der1Yaq E4YQMEwmVVcQh0QIkfzsukvfWId2gyNGR0FHhZ2FpBkRrxp9Sbn4thsNNMqwcJcgY1aElc6hco71 +W6wqkMXtOzrpphK5DQI5mQQZ2k8jgxUNvlUI2sRrkOPtEce1SwyMc986toQmCKcRD8PJvoGCPk+ XMjhqW1oEZqeHClD40wgWI+nSZW8E8kou4NUIiLqloVvFnHUhb6BfhaCIOPUjBKKoGPe7QIp6pba iMJvr9cl9ESk1CqFaCD0x7jrVt7+gv1qIVlALqoYS7DTiwqNGlT1QLIuKiNIjxHX4Xo+ECB4QQZB ulvlvYeQNx1CdAgQzrpvxwqSKQCP12y4OiGZWgkQ8jhS6u5bzIMgqOEFkhyY5RuUH/TFRV66SQT3 0RB5VowuNUoIQwQkwgvEm5iI6PxHRtCIiPQVp39thJBMhL8ILJcTULoJykDEhUaiIiIrn0Fd+saU jAf0tB6CRBMpJZTgYQJu0WosIIofTu2tXVqulSD4UiEeEqhIeI6yx1e6CdIKF4hWg9AkERhLC7CX CKH0CBBXq+FfQXrWpJyLUuq2qhFPcwlEVV+Cf/rRH1UhhWvT1Fcar+SKHWvX/VLSfVe1T/2+pFf0 qCMB369vQS2y3qWkl918nYSXXhClSVe+SFFxI60v8iLbh7IQYkWP//dVh9JdV2tWzr+8NI6JKvhV XXdMPUL2HFethPyniOtvHVf4WqrtrkCQSpXm/1bCXlAQSdPDuktfheqJP7qwh3ss0+dkLCRhdrH4 QS7DdCFvXJDn3fBGHarQbuDNYbNt4oJofCtcQtYd0q6pD0FhhJ1fZDA5DY6vfjphXphIMjh27hL0 7+CCYZHjAXw9RXX2nYrqFGHbpfXfCxHW3bCrlu7I+FGqdhZHUJ27UL/+EE1e1TBLwhHkdE+9BpIX 3TCpf/YJVr7IN3BfBKhEWmlI6gqDhsp9DOi67YUMJNdeGh9ILOiaDQi09sg44xr8YhBqs6ILgzDk xzp1tEFDTNULQMESEGCDCBYkGB+/bsEuFWhEfsiNMPQggQsIGEawXYJkMD6G4cIgxfwX9w6DBCIg ih7IKBwqxthsId8uDqvexInghhhC18hjYRdRX0m6c7cDEgg4KumDYLGE1Xbxok4QwtpwZ1nUL752 JpkCDIKqaHYIWuGGdhp2Vvi9nSiGthPdh/kXxKkvDWDBD4Y6iI441K4oMjhrZ2rQkCX3QvE0Q/bD ZZqvxIv11K5QjQyOGWPV+hE6AhaRV0Otst0GNkKRB53qqqo9iP3//v/LXmmh0uO1dc7faq+4r8fl vp5ZVNJcrrUCDq14TCD266/a9beK+E+reiKPdqEvcWr9Ntd/LNWEGFX7EfD8gMrVuCI9uWkYRZVt GQxEUQ16SxsRvFbjei/WTesGss1KVP10Q2nLNjUqTlScrdZTTVKbEJKhIYbkpUh4jVD5A8PZ3KHO 3SFTPKymstuGtFueChyQ4iIbKyXx7VWInEei6MAsiI8rpYnZhBBC7KmU6KEWpa0W7/QiOIZXEx4k 20RZAPHiR10IiZoujERxB8NMJYiLLTIK41S1q/1/rfjroshV7luWLlfVD4nevx/yh3/isqV5Z1Ra yCC2N67y0wQx3p0nv9P36dXkY/u+Q1CUkO2/p1mYO/3DWFbMr9dnSFQUOdiUF/w0Nwq7+lJsPllz B9f3pqmGFpf1ocdf2kq6Xw6p9V7bqQXHIQdlkGulW76oFVFkhL6VJb2FVKU+qnZout7hUmlCrWKp a7hQVNqK+tXcK0Kglpf+KhOTcDwWsyMxaS9uijDSBLVD/0NYIEvaX6sUq77e1hBZFEW51UhmOUda +ggSiksWRy/pZNxVBBauGI694oF1lfw1eW5aiPlbXfWKhkC7vQiOnoL2RiEVHb+ybDaS/yIHXXGF lcX+sJ30SfpaB64X63RbiyOwVWkSEZHaIfZqcKkcEIGWkv98QguHiCpnUJkSIjg1EGE8KRoe9K7E ZDlEiiI+mgoNUNUtMIHrp3YMg8jojwRBHKLiippURBwUNSQchqDhAvQULX9MrgSZAioRESdUECEl 5UEMPCaQgkduq0Q49fpPWwchrzhMJqrB6sEEyTREZIHqgTr/FxDIN6BpEqEVEV9Q8JshlKCGHaqE /CCwt+sGQUYEgQUugnVLJw9QZDOkCW8L0EsF5bp7dQYcER9IlAZ9Iaw2qlIQQL1QfpL8twwtbk3W AIDIN3OOchHkCILj1pBJE4RU9AtdNVCWtQn1k3SgXJBCIQSYS0kqw3oiPwgtJIIjv6Cpq5XS2mdk H+D0qggXJD+qfS3QS6pN8V1UKp3MJjlkgTQWgSmYnqrelrT6VPwuCvoijwTXD2kqC0O+npJ6QSS6 C+uRsj+kG28j+HpLQL9JXQrv9Vb6VLek3cZNFh0vQJf/oEU+ktdL2vpKvehIjkzcz6XC68K9DapK kkld1X4VbdksDa+k0FTtqFuu0vVXbYS900vkGIKcsc47JsspdLpXKdZVVRGIjg51QS+q+q7YKv10 3ERFQ+qVJKhsVCEjHx19BUkKewwv2muuwwuTpQWlk3BN0YRmC+lVeCXXY5dp9v1oOko0XAjCWPEQ rVK9JUkm3im9aCSVoVzRIdhduE2CVV4L1trfY90SHIMg5DOOEQiS2fqDBJbhJglXyEfpOQaYXB1q neccw5Q5FHIYHJOVbI6Ns5IiZEm5NJJfHvCYr+NKkxBqmH2sNGQUhFxnmV5UwRHQiIiGCHCVjIaB +3cJqv9J2qYfaScpSERERESbgXhLhYfeQzjE10yBcetWMK/RdEfzuoQRFKmC2Q0D7tqg62wuvaeG wwhFISzSzCVMioZ+hdkunDCoc4uCvhbCahRoUlFwSDVMMhjbOyEGFggh2CtaxD9S08QILigwWyHg odG/EMKPabppsMFeETcysIKqBnIxEEEG4YXgzDla9psStqrCBVBLaHpBmFj4jWONxTwgtgtpiOtp qutgltbQdqnf6cQXC2FTW4vy3+Um6xwsVDBO1QsER+t0MFWDKcEHENCPbpghxEMoePs7CJBFuSMM LENTtY6sYSBBmcFkzibg/XdUdl0I4vHK6XOwh8dggcMR9L+wn/39L8P5NzL4WTfgnRZUpXjzuhEd EdKW4axq+d4Gwjqxv+hBr/WQaTYv+5HwSZDSNq1VNiKZDVNg16cMi8HXcME2SAz18MJs6guDqWRU VWTHK2EZGAg43aFyECZZFVcWw3Q1bD/2y0lpLdsMMe5lC3omi0SRC22TbljxK/t2wmWROlLIBe1O itwo1VZEHIY3rbCbjdCQUb/qwvIKyVbx8GVVBXCXkDcqG/SsioN9BeQ2eyNAYuuiWTpFwXCBOlXD Ynw6IccildhfDZJjkltwV/SDBcIslf9sJDQ9Vwk4mVat7y2zWUzCn8Rpd9v+/tLt0WsYybg0VzSI +XW/QZNgvyulA/bUta0g3wvgwgi1A0NnZ0loIjq0xnaIjmTZRkcUj+pW0OKQ1aO3DQTYMGocSDQ0 R1sMIlJmsMoIGSaLICK00h0GooIgqp3tLBcGccFk2hIXspwlq2Isg2m3hpmEd6IRHZNuJ0DIZhtW IxsPRx5NoMoRNiFIZxzjlUKg7hJQsYiMhYKGgRHSjeEION+ER0SVGZ0W4EirRNrRHVS3qVCMJSD1 TQvna2rv0jIKlVetwRHVqOnmRaiOl4sONy3WvTXQ+dqSbyaLUf9OvpoO8sjiaVKrxrTgiPYT9e2C u346D0vUalcyX+g/+uCd0+E/9aa619dF11Rx6ZQiOF4bohe/iR/9LmAzr8EK6EHrFqgSqtL4NeCx IMGjBFPtL0QL5OyaqHrHKx9UdqHhB6p+vIv30RdZ2nGR1oY3WSHfprpETCKC5SlrV6Bv27cm6kqC edoDCIrlQUJa/k4ftu/wXO/BhCx5BpH/3hr/aQTwklyGUOC/4bkENqSR3arqZR0gq2QheQuSnZRr bbDayM3t+giCRKRHzKhKdoBFQUiles1af33h3YK3+oQIKFBME878Msl2gVYaSIYwnUV3ZBQ3M9qv Zgd6QSCeCeEggaCtSQvCha74bXSze2hsYQJdNMgSPpVCDQK8dQmq3vDbvWEwd1oJJJqVAEEdYLaC Tfwmq/sP2ElVJIr1JpGHQSVMKh6qSaI6QIJqdV6pUdjvsG8zr1jwX0kgkhqFUg2iDEHHrF1eKpBV Oylaf9zw93VMIJaqISIxyFHqFynCohRytK6ok7/VTsGi4yOwgoyI1JGQYSrB1jpglxVdJRBWiLkK qaQ6xCSfpQnZ3UGsE0lKcGLsPDKNkQ4SShDxCSdL6QaVX7f6qdkBt2dZJNAyTfYxt60qhILQSqqo LSpK9aRBIpKv6hbtHdFV0gktgq0tKlha1Qb+KegX0lVe1fFLXCrS0Qp+mkvq/oLVdV1WrTfCpahL HwoJdJar/r0QLjhEdJdVIg5nKHa8Gjt0O3BF18mUKlSPL0RedddN9QtJEH4qhoKHjpd4icaCO5rl vQ4ZHGYXTQsgg5Q8t6l6ULQQ6STarJFK31hfIR0IjX9YoIIHxQi7pqCjH6+vOJJ6Wtf61Udb+yfS NRkXzMH5XWlCI92gTCI6DXRSRHXSVLXTdL9ftdIEkl/DFUG2FqnF9QUIbfIQYpJKlqKuqUOv+kuF rrcgurVhV6yx3WR0NP4JVXgucSXQWQcaqEumF1WHX3SQeurVu1Ea7OoJVLS0O9GoM8hlp+C3dekF u12GleE7rvWpN6tSQrBL7UJKleEQcfRHXhcp1l01UhdnrXXdNx0337tXGQrqklwXp4Z8CG8awXCC 4gxVEe9VXS4YPtEGB9Vw+rjsV1CoJUlxW1xWFF+6XuFtpdevZGbQ0SH9wkq7BV+qevBevXtUr0TH DRBJ79t+2uwVVSHSXC4JOE4S+Q+6QkuthyOlSDaV/ph6TZHXwt6da6wwTVYQTC4O1puqY/DcKt3t /i+GqENeqTC2C3woYK5DO57OOUSwT4YIodbaS3XfVt+DXYVDIZ4m/rrF4WFGGxEQbDS+KU8g/h0r hFPptvp3yJCmtO04JpK4YWJ02FpVwy6C11IcI/dJ7//riLCYUQtoNMg9cWFEE1sScEM71bXdLTS6 +6pNu4sKraEGCdhbCaimvpBNXvX77/VQyYescyB9C0wmuPIhN9uglv9f7jWIjCYVNdSMQFrwwqVa yMr9390oRVUdgQaGEP6ZjW467lcFJTNlxGGk9bu09Z2Ksj7CppQhFQq+qERchx/t4nakmmksRDTV UrVIode6Yq2mssp0IiEhDCGUOtINY6Vpgg+I+kDBDVIER0Iar4NBgqyyJNSbA0kLvQ1S0yuSAwYQ YJVERVpqsWodkjcs4VoWTHIsBBhLXvJuLI7K0oYIGhENVXz+YWTcYhFREe6uhueITIulX1oER0hf Io5Q+/9kbROjiUUh/qsM6ITeyoFoLa21wyPkdCKGl/9iIZGGRw1/MlJBgiOukTOpiKLSxJYiNdaB kD5wiy56X6sNMER0JkaeNdxhiDCH6+yFNkshrucc8FQuq+2QNEdAyGauJRV+GQwoFhlOccjcv9P8 tztkM459GIhlBCmmE+ggwxGIlmii+2CYNFqCiMhPh/0wcr39tsIjr6ZVAzR2g8XfRFHZWUXDBaaT ERf5XJVTYiL/Ce5ahbkK7ztQtpJt090Ok2sRbvurhh/+/37lkLUZBaYbkbX68bUL7VsQw3q/53HO OERxK/wip0jbIm0uvVognhjKHjdtdDF/dKG0UPrqk4120lImzWCgf4QQIMM/BdiphWI+EKZalX3T Hhq+zkktZUVIWggfcEHbBhFpDd0qQak2FO+nnaf8oekuRVJji4SeTCSvVK0I/VOqK8z3SDK/J1Tv WCbWnSpEIO7a0/kbaCdMNWUusyG1vJgLTqNBNUHmHQoGl6wyNSIo7Lq8aBq2Eu01j+g0FSu5HWmR xU8odyXhq52CNVjI6uE10yO3BuEKa13QSdOx2HXCJPJnePX/dJU9cHTShEf/bXpVe3C40zsyXcaV L1B+vBOra0ihzjgr8NdepMjtWWdaSWv0+Nqsk+/tgg6SJSgmFG3fS0+/thPxCHj/BF1TpfbLOWBh I7F1omOtLpj9BfbC40ggn+pmkvSC9ss4kChLCZHX+NSh18EXXgwQWqj+0GFH00NbCWtPZqs7RhR+ h4Us4ySo7JGR0lCspaq12lf5NqgICELJZAhFhAlCeCffVrpJAtBprSlQPX11vgiF8KQ2brKUl2F8 EQckhB1/1uEKQ6dEfXwXXr9OuTYkjCOIuKYUgvKiTJQouvCqmRDIEeq/Vphk2KsuiOGlIktWmMsd kIRHRHS6guFyoDC+v8riqDZNtckAb0dnWiT4IoAgIRBkdlxPRBBzD9bIwNm1R3onuFwgbdnsIMue P2LcRa4QQh9EEHahPHOzklXwgbeXArI4fwtlWiUKRcKivhAh0F2vkpiPpnZxP6cNhxFKdhqt0H0I ohRwfoLQT0nmjUISQNog4/q8gRsTcgqOUOXDZBJIhJtMeERhEc/S0vCKHIEPSCbwwUIXlZZdEsZH SdyuKAQG2QMDlDnEsHpdmitd/QLXSiRHCXtJEUd4QOokxcRZHVIMHcgwp4egm8J0lp+gkIX97hW0 LCKHCTsmNAiOzGR1EhXO3GYZDZsQHIcyw/++o/67RFeinBEdkcyOgqeEGEMEK4iOLwgyChyhhSy5 F2O7Wm9B6uq19KIxBAhQ69oKQoe0CI+a0pW1hhiRnDtgnhlaWl661WgcL7EMo9eQ70EiLX4yOiPH ME20HyuFhtB11HVulWn6Yf6Q6dEDDynZHSSCkY+0RQ8Qi4It9FOU8GE5M1wfXp1pdw6rqNaGIpKm 6xe7NZBPQpgzjxwQO5BB9V66X03X6vg0EF1aQh2QwOYc/psiF03EGtPhA3a2q6CX2HV0lIMP+q1U 1B+XER0yOgoXsMkBoclhfTfT9+muG+ldu1Vr6Id0k20sQ4cPiU4e/fevpVTWsG69BENU77SC6T+E R010H15XWIdO+g316Ig6qEn7evYTr03CxWsIJDfsocPWt9/t68besjfqDf9hNBLoiD+v8JfZDhDc XDjq9hlCG2+l/HThuvyOD0R01gih1tL/9aqHT5XSrbJDx9d70tcP+xbQ9ghu9UkqSitbbIIP8N54 r1rpda6huv11JGCTDqq13XCKd6CD0gw+mwu/+/X+lSttdkdkcMrVdKklfjh7e/FL13Wl11/3/iK+ kF6QV62UP7qGrKfJdBU37+n+q373qwt+uqprpDq1dkzco6HeulXqlV/XYeqKWCs2lS0tUv8KHcrl SkQ3FXaX/ql/Ve/TIcf0EQ1bV+tr9LZOJvClcTyOZJkdga0+LSb191kJX+vDKHBBthVTh6UF6SX4 +YcPQISGBzjlIIbCQP0tTV+tfTShFD/cNCO3hEGpH8E9UvhEdKscNoRIuQntpdXZqVpVrhqrI5fC aobBEGmp/rpakhf8J6oW/eDMPUJ2aYLr30wTcViHG4bS34Ig4/CC7Nouh0LqvTRWQyrtIuw9lckq Vhl0CG6+9DUFjwiOkQUKPwzQCLwqVhDd0lflcrRcFQ7zLi9pBOMINdiKwgv/dLD8hHCdairjasju kgyC453C/iaBpCODxqqCWFpV9MIjqGRCC4igToGC8JqF0gRH7ppxhfK6WiOGcqSJg3VNUGuwVhBJ bCDBEdONoUsK43qupCPEdMR6uJ/CDCDVt1tVaYroRE1pqyGCbVPTC2oVb9fEKEG7YTREemkoNVXi yCDqmt2qapqFVewUIofqt0gtlO0qO1VO7KksisXw0yGzUIMENVCI6QOh+3J28NoJKxbCVDBKLXYa EMhgsCpghHDVC9JviQXHC6iEwmqa6ImEBkamCDCGEPpJt2CFE44aEGFTBJODO3GbV0+wnG3MiROy DEgKmKW/+RBzuFBdCGEVxH5bpaI6h9W05Q6ER2hKdHYRCtiMJf77CEevrbt7CSzI1VsrglVPpuVz O8eE7/8foodd+6ft0l/9O4RHSX91+THdf3X9dvxfq3XpN7X0C/1btuybjSh8uiCjfp9vH4VLPglu uqV5ZpJ49RCDI7JwYbpdJ3/6EU/63i9dK1rSTvu3CvW0ph9d8oDVI6bqjtWvEN3+yDAgYYWraS3r uSYdlDiulSb7q2H2qHS/022L10/7tsNDq1ZZVlem2wwuhx7tuPX9htul1tttfurbewsN3b8csmqX hhttuL9tvV6TDv2ibEnsMNtSqoEU7DmQTI6QfZBE9zCMI2jpkdGcR8EgkpHQmWoOmR1w3aEQxERE GUGLLWJhovsNwRBWHFlkNUW5dBTsDkrhkMHxDQZ2qIQSCb1DBkdAj31BEIyl6hrgxEV8GiGJ0quH Ddw0Quqzscvg4Mg2D0tBDX3DTLrKHFW0XUIiElvy3DBhxNeR0R8uKRwXI8VxCrSQQS0xhS3T5faE RE4h0g3T13ERETIGqO0pF0dqNLWrioitMravdS1hZcNRquWYXY+l9QnXS9lDyzNQn/0lCeqX+0l8 pEdkIj5Ha8XV3rCERXC+dlazIulFB0Qs7SCoVHQNVugSfSINSVyEVYRZA36wZHvIwZHRHXVeinF5 GOYcWSBCPqoWIduEvnQORtFEQvI74QnAMBCDI+R11EIjusF52H5tFw0JggyV0WRJL2hFn16EPsJd NMISC7rVDBBlJEd9yOlBhTCpJgiP3FPs7oopLCmuTIQOS6I4cqyI9neYdI6D8e5FP6D9BkERhFwa fWwprahCynBjHw4REc8ExxWqCb8PwoQihtQnIQeh50DZksRqyBIjp6dIR+qGv6ZFlUYVBJBQiIOw ihyDA8iGR2R0XjCJfoJmgUkQQsP8KRR0lS3LMqkDdSBBCE7uQzByZXColA0FUt8WR8EP+rwQYTCj xwghbrdNOSt7p2mal1KBK1paCDQIgQOEJDQRQ4i0DFVVJevVfSqG1VNdSP4YIUQcdhVCUhgnEUQf A4iRByh7ZEN+THOP1Spfp+tN+C6bZHVzDkEJeqFIJUQp+OoIhdrNYIQel4SX9cL/nTCeseLTCcKZ hs0kCI6TRQ4U12UPCfQ+F0qv09JJBvKmu1jXIY0FohR9MPSFYl2hEWgut6fpP1+tvXVEOOcfIQco dvuCKHWEKCCI6t0lBRZSP0tJVX9W+n9bUXt11io2U4Qw7rSOuK9Kx3+qvVJW/qIJa/6kF3iwneFw RdBBmaXSSkEj17WtOvt9Bf/tQqhBh9JYgmK+FS6Vb1u1W3ite+nSWkiRRg1XCe+EqtKt1qv77wqr X+F0D/pAkFtQl+uv+3SV+jTX69Kq7elcLWkEFX69r8Gt9UF9Vf1BEdLu30h14SS+vq70OvXX+kq4 10UJpIF0RuTHMOF4LXrpf77+EKWtdVC9vYepfLvoMIKItxCql2/1vpfrqnt7V/vhJCNIRtAu6WKq EHrhfS9J1WtKyNen5sM6INLlD64SVdbV9yzBnrZpeqS58Iqj5xGEX6C7xy3KyNJtwVf01BJ1CZN1 laVGwn3pKRwYa7kIODC4Sb9oIIQwlq4SSr4lSRHTVwo2fBLC1SSwoq6SYpMKEER1DCxjI3Oe03IV X6plDoRWqsUxqlWlX1BAs9fG1YRT4qFO1ew0RgarxqutV6Wl7W8Vlw8VIPyFLIHEeIKLYRYn6ZTo NHfxHwWqUJAvpDZAgcJJqmEMU0wpYvyrQIatgtdiIxFQ6UIIF1CkQdBkO6EP0NNA0PkQgQ0gyGPC 6aBqtMIIK34qYaBEdC7CYQ8MkA3ViE0IOyCDrpMEljWIcRkQmElEJQwRHQOLsF2CEEqGhcGUOfde oTCETJYRHQ8QloJghFKqO8BBHa+wlggRUIdLpDshmjhDV0Q8f8R4QVtaUEXR26hUsZFHWbSKggwO U0A3LMK8m5QoT44iDBAkPLMEBmigvO7WDKaBNyzAw1lrHGp2JItFIj5Oi6L5HBkQJPS4ghERHv/k Cccoc5yoVf9EFK1iR0I1/Rx6O5Bqgoc45QcIITT60o5aC1KQJCIiK9r7FRsV6r0tIp3SSv4rd16c P3XXoqaST7oFkFHYa6oHp+draeUPt+CnE/x0lTQkmSGP31Qb8K+nLHXTVHH1NyWQRk91CI6r48SM 3KziURG16sIK9JLVV931a3bI70rqp2UqNSDVB14vioNqv6tVrhEEIWtbIvLZNwJNKWUkXc1YIL9M JE3E8cz9MJJUlQKu/UK0faQ5EBnTx8NKRXSHtf+FO4IWqhf7SEcmwT9K9atDkmIpZUi9htJsmxms NaXsOEEyo+GCybVQ/QxccVMjoEq9dYrmH7XZVqivV9jetUzIdKoQXtuybBarO1pIHVr6fHaCCiHr WcdXfjF1CfH37ZBx2CNJMEqffoMEGR0C2lV6knekZVAXCENB1pXtU28Kmg1XhdAghD7kGHKHaIo7 Oz4Xrsw/oG6o7owiCQENrj0qVBBD1h+qi0hhfOw12JQ/3vunkE6djr001xuk+qoER1ohEFbHODIR 1giC+8B9eg31wQJCeaBF1CEUEZok0sGgfmHqr9uE9L0hE7SHoHdY3ppuuk3GjsNJEbS0RpEdoNBr e0mqslC6XDQl0kCITah4Qu0+vveQ8jwKnSiExSBPUFMnsIiw/vQ2lENddukDC6psgjtQ32lD/e7C C2d01CDXUF2U6SBtLuOvrSuw0FI7fkYGc71QTZGQVCQX6/CDzUqVNxpIMMnZQlUhojg3I2iWCBFD tRGFfv6vBNXWzvktNpnBkYiOwV0KCZF60Okg/9+Th6vfkdCkvQTi/pBoWF/63qlf+oY0qndp4STW FqqpflR+qYeu0FP847qheLBNBaBBQpL6+3xCfer6D1wQRHT9K+kQ6+EQKU62gwiCD6W0UPrv7qEt sIhX/32/oSN1sER0CoOHphBBeytIjqoUVW/Xp1j0NtKtQRQ/9hChgnobqI0w+1Xf4LULQJzs1SpE NLaGq7RxJKEkQz9pf+U/9NqoW3Vx1tZBx4LS9CFBFD6hEdLX/MhXb4aX6fCQpun+nSarM+tDQSjS 0v7UU3X5G7V9VWgtaXVUqIZx68JBa/WFkyAjCKH+m2kSVVSnZqtYpKPWxqsJWgutVuLkfNoxkUBo x1inoWqxqkq6/QJDhaqqXWIiNXqnCsKFRNER160iGIVJV/IRygiWsFfOO0vC1FPqN0qVQtUk4aCq hhJJUEuxtOmFqER0wT4Ip0mCnwx0gRHUVcGR0R4jqkoS12eRHBCPKQaLuk14JQrF6aaChBLWMiD+ Ii6kHHXCS4iccVmsPwZhyBIOUOeiWKpqoIjp8EKqtCF5HUKuQoRQRHSUSIPwguJ0RfLg5ci6EX+s OZpe8pwhgDFJL0HHQSCkF06Q+8F4iIiPCqENoY2CUJ2qS7qFhowiOkqXzgbLlnE1wqZF2VewQTCq qhNEQEI6qli36kFA4LBeNNNBrBKIUIg00qWItLsER1CVQcYhVuUOE00mFgmhF0uoScf8guJK+MEG hYphMJNhNNdBnHLBpJhMEgrptDUIMjWXiGqhC001R2DwlVocMIpFRdQhpoWtRCBdWmCGhUPi1nZK DTVwwgYLoRaaCIZg4K5aYIqDiGFQhwQIai7KHQ4oFw4nElC8IdLlqAaHrfSIo5xzj+PBCL2lHr+F 9v/T+13X9+vr/T///fpteEIYX6DGH5bQREdE2VF1FP5H1qI3ctMmibmSXQj0ymlWauWmGjoiyiRr 6CimsER/dViOhLcVl9hV+na8JwRHWW4WuFThJ9aI6W9BK9eqfCuiEHC1QdUhkx2p2nZHXSXqkLI3 5f2l9WScg0Id0lo7eI6TVD6aCK0vCEGdh6VhAgW6RJhApFzI6SwQZ34T0jsaR2PF0XDK6QLhDMgN agmCDtYRHR2TwkVg0Iyun+ggTTBR9ME+EoodhLtUFUzk1cEgtQShA4vhFD1XCDCxhENA4YS6oEDX xZZgTNhoJuJNBEdBVCDo7nIjHUg9qEqVUgYaflnVA5tGAVE6EkQXTCRHRFMjirGECEUQwOVYSkRK sNBHeiIKhtFnBQPFVUKaChEHHGRoFwmSSpAjXhEOOEI0CDyX0iOZ9MNkEHIQch9p7KXWE05Q9Q/a IW2SYaEmqSFAhwXCERBkhF0XyOjHLgPlD4SQ/GKpUGEqBNBEdHTFYSCwpUIjrs4iOVxFpGYLtbKc Jo7qWR1qQOBzh6hRSCwuIQSCWqCaF05HDxQRQ8NnRtCI6xmEUi3IMijUgQOFILxCIh4QRHS3hJAi OsLrSJjjiEagRehGxJWraJkExyGBzjd0KhMdKOmQ7hXrfBIocSC4LI+4V+hpFnKOEIitSEHMOcwt QiGgdpYJ5JtUGmEQwPXkG8yIOYcoddN7qNeukRukhhQtJUEggpFkcR5BSMD1ILgwglfgwXCEbDd9 HaxfH0hHhJIaphBkaFiKBOpDQnkdAgqpZCuFBAurVa1df/SWklCFaw4iEqvIxwhQoUg2ryh0d8jy JCGl+l1ogoHMPVQmCIEPCVMGiGynSca/3UUHDf05GHSSofuqIOO5Q6/13t1dcKJtQv+qXCqQUDsj mkFVERwQKMUiCDhJMHC6TVNLhXjnf3/oEv8dJILCEXfJC3gkt9vX+//2FpJdXoIocidQIjqqE+Gc 7Bg3hUktN16+PpaoK7pSGeKqhEm68QkEEaIJHYEC8JL6hqvqRPf2QQq7CCVcwoIbS/VKCjBFUwtd YeEtdN90ndOcB6YSe0umKXpGgZShvWvbpbCChAmRRCRda0yGfxVeLIlWvSVBBQk9UtkP01BLXsSn Q/zQTJuXV1h1YJKoIjqqBaCIMOt2vwRQ8jr8Lgih1pr9mdhAvdqxgh1SEJ0koIE9YZRddAhHh3CW EPCf8aCBY1BEdawnhUmCxCdaFcjqwQTumEFhJVQf9BduNdWvng2Qv1jwRFHBEdWCsM2DdhggvJQi OmER0Sj+kgq4KqrhJQwRBd5tIhsHXad1EYpGoNkQrOBnWiNrEj9kIv6Ve0HqqqohYQV8KoaWHkHH BEfojonQWogiOtYaYvf01S9hdC6pQRHUYwQrDStBRQ2NU40VCTuEGULe6X0QJO0PuMIjqFshR4QT SuwqrS4eqBEdfOkgvxEYSKHUFSsLYqhBEHHSYQTChEdepdUIggQj+0u3QSGwUUwt6CwWasjmR8j8 JxqNL/w0lrpBAzjnqkuiOrqlHERFgoVYsE/2zXpBVF8RhCOGkgQVQTIEOFtCOER1thCgQZ+yy1Ko RHT0GtNwZCiZEHBEdDS72GkCIo4jJsLoWqFc7FER08INCGhHYV8OhCcR2sRYXTKLAmqe2Eg7Y7Vj iwvtotwUhY+LIjxherSggyfope08LkjYUVNimcbiLRXRYw9BobDC3hbqhFd4fqHpbulp7/T1+iY7 wW3dN4eF0m8s6mnv7eL/SbUtAxf1bcTsDXrpuy0DECBC+9Jusf/D7hUZ9U3iOqtIMPLMMlYulbyy Gqyad+mG3iNVUHx/t5NzRX0nxr7/0mF/x/3+6/VZNzRFcsXWvHVjbKawItINIm9P524bCbmGJVUg i6t5JQ01EyVUR1jSyVgr53RCI+jyMI0ZdlwK6ybF19CGXA8OTcZn87dD+oy3KcREeK52Wq3iJkXR b1KpaCEGQLMK8rONxBkNQcwsvk2M0W5KMuiOMjsYTKairiIiIjUtgIiHw49QgTmaK4ouIiP5a6pk 3tVS4dBDCiTfloslUWYNrMLKHcIRGONLlsgiPexfjSLZEItyhcR5TGiuWvyLoeU6vPohFxG8jrLc UXbERM0PHqWvRJXEaKHlrqSJshWUPUrqf43x9jC93uJ2tLjW5ao0izSVcL20hhKFx/vUyJ9xp6/t wvvevtb1fdL8s6UDWRxl1os5KBPQZZwsCws0aXCIMDkNYcIrk8c48EQRQV5TklxV2yOwiEAoicxo aBD3QK6OPguxje/lnGq+m/f5Z5/97fi9/7+ZKa/Y9ytA/tdqS1kdJ2ce4Qv76cvuPsf6Jvf8FX8V /kOS79mrSUtML6KH9qkvj20klHKH7apd+6XLUWFT20kEeNEx3/btIjhaoft8Qkrzj9tJL4vt8KuF 40Cr+GmSr8J+K8Ph2vXj3v69+++He8tChQuiY70taT42/vLWU1XSDbZZDGW5BmAhHQzIUT9eJb2w QiTgoctmlQrq3lnLUfyciOydkdEcGQj/0ryzhMjhCOiOFQZHQIocRERf1byzho3REREOLI+R6/T4 IRHSZdVWvJspRb6MEUOIoIIe6TWTYECBCJA8NWb6pDwZXSwPBXJhF0Rw0d17RA8Nccoc5aVBUFDh dd8jqQ0xzDngociDnHIWDORWkU/8Q5DLHBCIiIiJ3WiOiOvoLsrhqhiL/rjILyUL9PBsiyGgRe+N yIODSj/vKHD7te2w9hEdb9MMMjrY6+0xD3u+5OGdeElotzHbKHIbF0n39Niwf/xo1gXaq19kuDfu 3vYMH3WyZojoK5SBoWF0Q6sqCsK8RIhsCwYPXsgwoKHEOyJAwR03kdVYi8i4YSb/hg7WrP5An9OG H3xJERwax26848SdF0R1kLBzoIZDHZLojqER1HLdWDAiOGGEHItFHZZx1CKiCDdsJ3gih/4+2UO4 bD1bxh08WHbbxXXwyhw5Nw70WPyyF3rxYlDiGS3I4OXReMI3sPfL6gnu8MWCERESDqbTiJKRqgtI t3F225BYHKLBrRZNAe4TrZBuOUOGhIovToFppswcswQC5vI9uIeQPEG92C9MaiJDuUtQZBxwocge GHO5/Ko08ErXlnWVEkq6ENoREX2F6eWdVOyOiBo5Ef9tpOER0TcDQS3tVEkg0CJFHdtkdEdF2eRH zAZB9lcYFBMpAaNWoxEdsRERGnYTUEFeRjlXWQccpyo19BB5EA1+reoQiRAHpBtJ2E7CXofyNAtL IFGpCWcfISOmd6JSGGr2vcGQ1sYaxE0A/SfRCuGg3BEGmAXFfIuCG0R4zQPyIOWOiFojgUJaCRGO m088DSR0PXUREQdNIWQ45DEFQCE4CnDe0FhvwQQ09Ww6VlGYQiJMwcjg1d+IbqJDMNqtLfC4idia JCI+R0bB61SDD5BqHKNhC9egkhERCr6t2ghyh634IIKtfV0gUdKuwkFS31cqVnEYRdBBf/CDSVe6 YYSQiIZHQJVOzJHZLhV3CFBP629RRDKHBV1S6wl9ur2CQRBQbFWKaCd8Igw+Qj+qoN5wM1ENBsCN lcHr/hAg1Vff2CIZm+KmvhUDr0qYXV6tsSBcdJ1StZBcQ/CCDQYXddNwhCfb0ob7YQRTgQR0P/tw XIUfRQ6tJh16CYIen+3sMJ72q/YIIpM39JavIe0QjbFYbsJP+EhF27s7JPeRZtfgrDoNj0EF69JW dE1Ug5X9JpEIH3QXginT+4/Dfo78JBndVYRB3S7qPf3fDtoIR8JD2v5Dr0ynevnHaXa7H04XTtb/ sVegX9++mnTX2vCC6etdqRIdNrfYXhBb16eqQOn/2t0ur3q7p/WtV6C4Xr7u3W9v/CSvp9ar+lcV 9IrW8Lf9rfvpBPbSHYVpfS/r7/CC2Crpf9aXQT7rgvXBFD6/+6IR/rhhGhL9/1v9NBW+vCv6of// q36Cx/S0mGuklw1Tfwu7tda4IjrWoRQ7VsyEhPVeutL0PX/CbLo7EoqYaNuv9LC2lC0utBY0wRBp aBLULyXMij9LS9Owl0LSbslQK27WTAImn+2l66Xeu0QUxymip9aSbDIO7SwglTXS7pB7CIEDiTaC EGmv+/XV9K16pbZGgXI6OgaiYhhb3kdVuk2l60l3pttISEBoLfgUF9xMkLf9NdLCC4q0v72gyJIj gXK60Ct/CI678NraXBYX6Tb2J4C5XBQJ7MjTEiq2NL9NKzAJ0xIQHq04bhkqBuVygFqhH7pL0mK2 Fb6Se53DBsriYZR7I6Lojhlf9kdJbYQUFwmq7TXRQCEEBgrmAyhESGjAXdpOkDUuttL5FG0/xDYn UIVIEK4MMsl0Ie+4S2o1ahp+CDW6O1UEthlUCFfUFBJoa+7i6thglBP48TutmGYBXskoshnWE+0t rTEiCSrYWiuLoqqI4HkGDPpuQ5mZuo/37hkhVVWGJQiRG8jxcDwbhoW5Pef8oLrpghtguVzAcTCI 4HgqhtuFb3aqmvQ41iLbDaVdXXIQegiOqYXpQ23963daGoYI7FF9EDw2rKcp33/etK6CwwmVe6IH g45Raw2G9X+uo8GZwQ+ceiB851omO9//TT6oR8YIkOQVrPuq23/1/X9Mj5dEcG5mi6G9/vtYX6fg hERFt7/67V1+Le3ZFS/9L96Tt32alXoNbS34O3v5OLfRJr6v+m3bt2u+NLSTrwlt3kpoKv9L9e7u ZEqNhOC+yoSa6W/e+GZFAZv/UPS6pa3t2dhYIRwaSOG2rmaXv+Gt72g3gp2ERIA8NZcwO9pjWur6 /ndYHgT1FemshH37rXcGzuAPFI4ZZGZHJKF769JKpSkfBgrJl2XGRzf3gpVGRwUyOiORHIuyrQ0l X9rqvklBsPRAwOPvZUwINojojokCEcCgjjEREbSrvQra+iWIjhkARX9CIiJDa2qUq/rUKnmoMgGR hEdd3kDwX2aTSNSSKEtOv8K1PBkAVsIKPu5BmlXsEKMyvXhdLxiN/BkoIZblYaQFbCmA0f/aXde0 gZOSW7BCQwO9/W1RGO4X3r7RHBBiIf+uK2lr6heIUFD/4T1bsgeGgcgeIOUOYc45Bxyx990ktqFH 1yHHXCI6VFD5A92UXKs45DMHIQckdDUocqYQyhwt9qGE2HZGH7ffvjkFocIRFl2VBIc0KU52cRT9 D0OurUJtpMjjkGqyDA52YK66VU0/20yhzoChM46RBuOdQUzCzf7sNL+wiOhdhWIsg8AhHS6WmL/T Q9cId0/p/0R0IsElBfWuTf/jwXDrpOk2remGCTqvrrf7bCbuv1dN38Ifuk6WFbr2Gwi6S9fdB/4R HX/1SpJvvcWCBR7/6Tf/Y/9fv8ND+qrSv9rhSukRJouiOi7PhglER8zRoa6UU/4/K6AaSOi4K5HR rRfMBtKvh7e/mRWDkcDwViOB5aVNV+TRFlqrnY2jtwyQqWl/rvyCA3OgZZBxVhkhiksb9xGyGbhT ljnHESCdVa/WhEREgeBIGqQUPd/IZIMDlgzuWOUOUOUUkMoc45nK0MRS+teyGQDIGQ+xMoypBKvf yB5DkMyCnBCINaVXf5FCEhyGMKrOOWOUNGHOOUOVoU5AwvdIJV/4QiIiIiIifB0kglVf1BlQUvrw klf9xFJIIJhf9fCCYVf9UgkLf96wS/fWoQRXBLf6aVBAlv/qkCC+/rSQIJA+u76hBMhVMHb1lD0k ggmQwLvyDuh6QQQZBQOUIlcrXoPh0kgQJiKvu7rpBAgwT5bkguv9QkDQ991dSNIEUPI6BS30BUI6 N3D/qkMQhCIO3CENJuFWDrXdJAgRbieYBO+3qoSI4MCOw+stzJapCQRoC7DXxukgRHWGO+unh7/S CcN99UQ0NC1Dr9BSC7QZXqqMOoKQ7OPeuZQoxZmekNaxDY5bnDOR0/0srpMgQKqe5brKrZXECk6I 4HmThmeN3BCIuuD6eR1yvoLmSWlj4fGv/wSwih3oL/VrDfGWYQ9ED8c45Q6+0EHogtKP0wT0Q0xy sOOU5GUEMDkh7f14QiIhlCP9N5HZ6HHK2k/f8REL/71r/pL30vWv9ZQkn+wvFEO8pF3hWoQVD3a+ vLcp4Vrelx8FrX1H6rv1/X0vu/S0WclX/8f9fRQ/6rx3pf/YXlcl4PW/v7xrHlmB339B6pX0/+qb 1/T/+vrW//ul/wjj69LoSIzHBe/YOF+tBkdBr0uCENr/hMf+CD/4T/4T/zuiog3h/mRPxhQwf/wi D2wb/t4QW3/rQKUPb68IofQUYb/iOgsN/Z2YBs6Cdv5B90IM45SCTqCSt/DK0B4KAih4ZTqEFsMy IPVkNhQIsR1Qe/DIZemErcdzsyDIBrhJ2HrIHgTuW7wg7+yB4NI5Q5Q5nP4IT2RwzISBFDqyzlJ7 sgeBccp0IiIiTxcEhBOG0HmShbOOWOQUhz2VSIifHSXu1xFlDlDnc45DOOU5FcoQxpMoe6/iIuyr JjlDlFDwntPFRERFaW3+nCTtow/4OEEC8dd/br08KnSXQfu4T6dBB3hfDhLeF6IYgOl2l2ob9bCp 1ekrY/Qb1eTcCXq9VxXUPp+uw1S275FHmvr9cKh197XXfcekt69JX3yzQ1+/hdJ11xpK/r9/6T6T /e216StK9V7f9XlpJR/fawmv0lbv+tqw9a1vdX/2G2/Saww1q+u3V+uwwf9W9v/1g2v0tww136eG GCf0nwyCOccqhQ5YW9f2Wksg8RESIOdzij/+WkNZfM0XRHA8HX9blpEwPBXI4gLvXstJOGQBf/5a SAyAaf/lpeB4ZhgD7fh9EFehxyVAROi8XRgCTUriShFDwih1lmi/IGLOOU5Q5xSIiUZcNfscVG9y BA5RLElw0fwfFghQLt8oeC7DQJqvG+WlUKECr6hPLSB5HStPlvC4fG0E6/pK6SrxpXikD/foFD/V 7CC/16COzVe/VyzQrCQ/17SQXXrxQXr/Sr/5ZyVQrv/ilX13he+iGl2v+Few1/0+h/9zj9f6Cr/6 TuRfX+4qx13XS/1sER1/U8nhDWlfStfpBdybgf/WFf++h7Hcl//futL/H7lAQjxHTqn9TaLgo3+k dwCvpP1JkB7LMJF1eiq5HA8KWYMB0+2qkFA8NgJ+vkO5WlPp+hGtkda/ti1fyB4ah6r/kDwaEi7/ yB4XiIK5EPf/IH2klZMJdb4ZBZLwwkE10/MjjLg3N7iwgS/4mgQZQ8QSrX1Flm2iOES/9IW7//I6 I9r/dCL//lmKq//4TZBx39KWaqrqCwS52sr3HuWQFRXEkEkRfKd49rVRsJMEP9PbW0hbq/1dhBNd eZKqq7aREgjf2N9NBEaCr/6bQRMQafv93UV9VSpsEE0/96DaSCr17bDCTCrv+2gSJrpd36sUP/2v +7Va9SbpE/v+H//de18oeLa1+LCKd/+gp5//hEfv/6FN//u6v3aCbV/4Vsj+tfQUX/qgjva392Te CQ3/7RNzUJTf+rBQr/7wTCT1/ybKgF1pf+Cwn9fgnQ//JsUhqQt3vgnX/ybCQFyOGeq1q5NgIMqQ 8Ik6l6upNlAZoIJwnCrvuCIZnIQRx2P+1JtWGYgkNf+EEEEC1/oEQMDlEBLv9QQIUgkTYWGVxuXy y8vZNsBugkQR1IPB9jmHKkGRLV/pwiBCQIIhTYsEi8QsFAYklBUEY5RMrDJyhynKshnHJDlDnHMO D1x6luaBn0EW5mHN5rA+Lo1IJl8jmbRHDKOgMEfMIvkdBCIiIiI/p4QQQSRl+SMujAQ1Mj5HiOjs vlPlw0zMDwwXZHA8ORwPDa+9BAiOqQR2tgQeQIpxEhhxESOy+MOYCPZRB7RHRfI+cDbI4LYbP+EC BIUqO8ikRHy7I8XiOBcEIuIMISPj2UOVYsjojgZhpP/CCFQgiSkR0Rw5HZQiOGQFI4GjX+ECqikz cXzAHhrkcIRwzSOB4QjgeBuRzOAejQDwVCgyOGZ/UJUkU4ZAbUhrOkQPBtcnaaJSDcjogwUHUG5e MBsNoSdGM5kd76wiGCxJEOCIZALuWOfhM5DYOVCeWOQPBpdCIkERHBxIkjmVAhdCZoj5chERH9ug qojouQISBQOQZRyQMoDM5To6oUYcIkBsLwzjmEEFHFDm8/FDluTHBCJ5CIiIj/wgWhESDKOScpBY 5BvJyrK8ymZlUb+klIbSwTZhbr4QWiGmzQv30C5MchoHKZqxf4S6DIVpGv6pVj/dBKuu7S/f6C0t a0wq772l1rtJLX9dfT69af7a6/vrX/Vdf9f8sk//64/Xp/2W9xHBzwX/+ZCeXzCLjJSzjI4Fdf/O zREcy6I6LgynUDwMX/87JQPByOB4aXhP+d6BS6I6IwMgDjotLQML8l8jiEcjCL5VhmEdkcMgM0jg 0eWaWxhE4NP81hqFzNoj5HDJ5Y5CDmH6lmjEbRHA+/IO4iIkMgG+EDDmE1uWYZovEcDwLv0JA8Ns chpQRCCnKggo8oSBEdQkvLMJEXA8NX7yFHO5Tm4rQIRJCI4yPCIiF8szXI6MIkRyI4HgrfkDwbjk Ucg8FDnHZdiIiIiNVlnKojhSORHDIDNSvIZQ5hyQ5IcnBWEFA4Qk+IsEP5ZxoMgDc3PqQbjhDKGi EsocIRH8s6eMQIhkASL66chXBAokdCIit2WhLi6I6I4ZBkcIXRHDULid2CERfzJIiyJwyAbmFNAQ nAbkeMIcruukn4REN9SlMochkAocEIidA5hCKjUW/MhgLk2MkRxkcC5HEOZwDwaSOiOKXZHBcjg3 I8YRHQKJKMfh9wgybKgZAcjojouiPmECWDK1KgSnNAQVocR9N0nZbjREdF0R4joiUU4ZAMEeBIRE REREz0CZ8CER93eFLdOGmXRxkciOHI4HgzEdEdEczgUwi+IiND8N+mVyvI4EEcFlCOQPBVc44QiI iIh/e6ILvBCIiQPDWN0r387WY2iPgrlcSDIDNI+R8j5HBgjjI+Rwv2wtnYsjeR8FBCNyuTDIBqER ZTIW6trneqPx5AhGRw27MiUIRwyAII4bC8R8vkdEdCV0ios6Wu353hWXQUjgeG+ZWiIRvPZHA8Fc j5fOZHBguKRxkcgyxyKOhEREyFkQiLoujCLo4jbLozxOInRHR9f33JKB4a1EIiOEL53rEdkcORwP DXMBnMR5iIgz4etkdCImRWi6BAhI6NoRFhYwhEREce3tmvPo1IwB4KlhCIZOjCKtG0VaI4HgUGal OCLoRFwYQiIiIiPpvzyI6I4HgUEcDEhcKwRIVzDiQ45XlOJA8FIuU5TlOCER+2+hEgeG2McRERES B4Kw5UBCIj7vuQPBQ5hyjB3KsSGSDccpnFd4fyB4Uc/BCIjIZIo5Fcw5kBD99tkFPehDIDMcgRCE RH7b2yDZtQQWLOOQPDQOgZhz1nHMOVBTM1Xb25ezIgpVEGwchpjoRFxEVpNvbcEQmXZHRfNGdYuC gR+3tvINQ5RwhERETpmPu23dyBdpLXd7FNPw3bUJat2Hr7fYYXdh23C+3bDDI2nmrOOG7Dgssg/c N2DdUPDDu8mwUr7dt41tg2ww7/B2wzCpbt2GHeW5JfDDti8Xqw5Ifv8MHth1W4Ybtt/ww7sP/DB9 h/4MG2GGHa+GHbbqvBkNE3Ye/YYix/X1wZQ/vYzj/4yDVHauHdyLa8zQOPr1JvpkcCNfiIYIjpRX iO//3+srSI+ZJd/CElJZf8INP24Qd+sJnZi6+iKOGF9+gj4ffuoQQe/7dA3V/0jaa/3pDr2q1a0t 3pbvr6pb/0P32kl6fKHS/8RrNCJT/tI7JvNhFruoQcUa679YVEGBjXOype6TIYaEglj4akEyBKGC CCp/9BgmgwQS6+qT9BJBB96VA9EooIKiQ7rTfDtWyOBBqkq735GtBpVXEJW66pd62GWOcdJJX+sU Th6TixoFTfWy0F8ujqtK7rfV/4iKqDdK/C771pN6Xqgm7qW4fdK7FaWv6u9J/6rS911aX1t+7VVd fVf09f+tbd7/CXS9+lp7yNB/ekv/dYLS++93f1WvX6r6hEWGEtLapL7buEFpf311fUEER1hKu9Pq 4nZJ9hR0n//97hKwkt1ut/uGCCYppd1S93UMIKur7V/2xVbD/Srk2JP2Ewml91+n8Lq/wlX8+Dl0 7CDBAwmmuwgn5XMkdiOsjwQvDCZIcENVxve07KA01YQj3sINU8lSBNTwa+DJbJw70PsiYq65XU0O wTCq9kCB06rw4jRkFrWQ8Jr1iGmEPewmvINclNiGsFeFTsMgXktQYVlDhd2a4JKCIccmuOEMR3RD GNtM/bJf/aCfRCvvHy1BQvoE3FV9a22K4S73aMzQi1vqvQ+E9d/3auvrXdaS1/0uqr/1cLS+u1Wr r//Su9dpWtdb6pbXC/bvhrgv9+PBfpJdRVpb+E9X97aCfd+va9dA06luWctxb3+ny3FVUIPF5EHT BB/Hu7FBlrijH4yK3tU3X4veui0gT37yuFXeMF35XAkt90DVrSmXpaXK8LKaFeEDsElcIhbKMFCG MyHD6/Eg45BoxVcEvQkNIdViCI/tRcLj60q23oiWklfwhOzho+9HdQKMNS7KdVQRFSxhCyrIdyhy 7Io/UK8REREM/GHVcgyI6Tyb+hEMF7QwuI0nBO6Oy652EjAu3Y6HCSpd0vrgl30wgSdc7NV0vyJh AmTn1fpBhMJ9Lewnp1Uod1wTwtpRIx/TXu/+6ffq3kBKtVkS3r13/hA3p/1jf0Oqrr/IMP12/q37 /r9611/df//e7rb9/09dVX7X//7/3a/1+n7te3pLrx/9revu/VQrq92klvUL62tMLaf6VJwrhUQE wNW19x6x6aWrhkTV21Srx+Ewu1+wiMcQq9osxaV0moJhNXk2OthKg41itiE0I/2mqsJgsbTBMKwh GwrCjlpgS8f//8s0wvHyAwkXjKwqxy2eUf/y0yfqP////5AXElH/////////4AIAIA1lbmRzdHJl YW0gDWVuZG9iag01IDAgb2JqDTMzMjgxDWVuZG9iag00IDAgb2JqDTw8IC9MZW5ndGggNiAwIFIg Pj4Nc3RyZWFtDXEgNjEyLjAwIDAgMCA3OTIuMDAgMC4wMCAwLjAwIGNtICAxIGcgL09iajMgRG8g UQ1lbmRzdHJlYW0NDWVuZG9iag02IDAgb2JqDTQ4DWVuZG9iag0yIDAgb2JqDTw8DS9UeXBlIC9Q YWdlcw0vS2lkcyBbIDEgMCBSXQ0vQ291bnQgMQ0+Pg1lbmRvYmoNNyAwIG9iag08PA0vVHlwZSAv Q2F0YWxvZyANL1BhZ2VzIDIgMCBSIA0+Pg1lbmRvYmoNOCAwIG9iag08PCAvQ3JlYXRvciAoSFAg OTEwMEMgRGlnaXRhbCBTZW5kZXIpDS9DcmVhdGlvbkRhdGUgKEQ6MjAwMTEyMTMyMTA0MDIpDS9B dXRob3IgKCkNL1Byb2R1Y2VyICgpDS9UaXRsZSAoKQ0vU3ViamVjdCAoU2NhbiBGcm9tIERpZ2l0 YWxTZW5kZXIpDT4+DQ1lbmRvYmoNeHJlZg0wIDkgDTAwMDAwMDAwMDAgNjU1MzUgZiANMDAwMDAw MDAxNiAwMDAwMCBuIA0wMDAwMDMzODk2IDAwMDAwIG4gDTAwMDAwMDAyMjkgMDAwMDAgbiANMDAw MDAzMzc3NiAwMDAwMCBuIA0wMDAwMDMzNzU1IDAwMDAwIG4gDTAwMDAwMzM4NzggMDAwMDAgbiAN MDAwMDAzMzk1NCAwMDAwMCBuIA0wMDAwMDM0MDA1IDAwMDAwIG4gDXRyYWlsZXINPDwNL1NpemUg OQovUm9vdCA3IDAgUg0vSW5mbyA4IDAgUg0+Pg1zdGFydHhyZWYNMzQxNjQNJSVFT0YN ------_=_NextPart_000_01C18455.48ADC980-- From owner-ips@ece.cmu.edu Fri Dec 14 00:04:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08791 for ; Fri, 14 Dec 2001 00:04:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE4VQG05284 for ips-outgoing; Thu, 13 Dec 2001 23:31:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12807.mail.yahoo.com (web12807.mail.yahoo.com [216.136.174.42]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBE4VNZ05279 for ; Thu, 13 Dec 2001 23:31:23 -0500 (EST) Message-ID: <20011214043122.51409.qmail@web12807.mail.yahoo.com> Received: from [24.42.134.59] by web12807.mail.yahoo.com via HTTP; Thu, 13 Dec 2001 20:31:22 PST Date: Thu, 13 Dec 2001 20:31:22 -0800 (PST) From: Luben Tuikov Subject: Re: found the constant for divide-only circuit! To: ips@ece.cmu.edu Cc: "'Paul Koning'" , "SHEEHY,DAVE \(A-Americas,unix1\)" , "THALER,PAT \(A-Roseville,ex1\)" , "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , "'Julian Satran'" In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED920CF76E@axcs13.cos.agilent.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-55293712-1008304282=:50062" Sender: owner-ips@ece.cmu.edu Precedence: bulk --0-55293712-1008304282=:50062 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here is the mathematical resoning (attached) which I arrived to early this afternoon, while playing with the math. This is along the other worksheet I posted yesterday. In this one I apply equivalence modulo G(x) and notice that x^nI(x) is equiv the Magic const. modulo G(x). This was communicatied with Vince earlier this afternoon. This is a copy for anyone else interested. Vince has also arrived at the same conclusion using circuit simulation. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com --0-55293712-1008304282=:50062 Content-Type: application/pdf; name="worksheet4.pdf" Content-Description: worksheet4.pdf Content-Disposition: attachment; filename="worksheet4.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKMyAwIG9iaiA8PAovTGVuZ3RoIDQgMCBSCi9GaWx0ZXIgL0Zs YXRlRGVjb2RlCj4+CnN0cmVhbQp42u1aS28jNxLO2bf8A93SQiIu348NfMgO NsEEmWQx8WGAzR7aVttuRI9ZqT3jyeO/p8giW2yJkh+jOBMkMGB1k8ViVfFj saqabEThj42sI0q5kVGGOMFHF/OTf52d/ONLpkaMEafU6OwyUJ5N/1t903Tj /519Db026+WUWBUpXmI/5yNgZ3yvI5S6kSRC2EBBI4ecPyfGqdFkQ/QDVbQw kwRReZzptsBHE933Aws2ngimq/PxhJuq8S+m6q4bbH0dWpezd4vlvK1nvlFV q+b1qlk3izF0dXXXLhfYvrzEQX50mFaIXHwmCVMmTjyvr9qLgnAC1ANDI9Gb sVJVPbuJwgB/ZCtzbYGrToalt+yCT5lrpiW9FRGUbRSn9Rr5touB3GBi5ohw bjQBkaXUYcDrGm3RrLzNyHginay+71Z1e3U95rbqgIfU1bR9067RIvCWftG4 y+4aXy+WN4swZv0ZNCge6UDXSF/fXM0bJAFVoMlU82a9rq8a7PfSz+p1nFOm SYD+XdescUC9apApRYELQNGMKJqM/WPBZJNEklui9RPwBBKuM9HgZdYsroKe PBoWKM9br+muAExxIkWCxKIgAKOwZjYSnHormmraXBV4CU6YjIRfFTg5wgGO 9K6NIx60cbixSSqYP6JzYEDOAHVcwIMl1rEw9j+r5gfK5G27uPpnaRpOeL8F Mlq0acnqpnrbJpsL7n9VxT5Zl9ZcUaKsBnE0kRTFebHjjRgnygiwhxP6bneU iI5mVSsZWLWwxIIYo7dYuV5qZLSRZ1FSn2jozYR+UQKdV1/ejZWHOVnOefVp aRNYL/99lfqxqBTjuU5HMs3zolqMive3jMgtg+hj+a5hsGs0ePUJM+AgVKD9 uHSowlYR9h7GMwfVNqi2OYwIcWREoN75WTYRmlANiwBaw5J6yl882cm/z06Y FsQ5WGdGIVgQbOQjkhEL5lk1o8sTFkMVZgRRMiNMwcpgqhSs/PxTPwElJrid fYy598We4CDDX6Pqul+FibCEwzsIRBRDbHkfPoGQ4XRnzeDolVRvHQkbZoD1 fsE/LSy4smZ4nmVuTRLN0wp8tMNZB8eIvay4fpwbsC5x3A6mH2xmSQy7PyD3 7GYYkQFyf7SYKO5wz+Z3hy1obVwRtoJC3OCXBLwcLGsBVgJiLSXvglUBp3s5 AoS01o8BqgnbfBeo+nFAdQeBqn8noDJw0tblSPVLP1+GGHRaOlcpcL4rdjry ebiB0oCNg/MlBfOl2AiiZXim/riDX47IPruufSSsLISmPqDW8LBoO8hX2p8w boIujJvg4dlLn7c88y8OUpmrdt01q0izxNZ6NsOG5SJE09AEQe9udMchpVAp o2j+f9O+GWsBoyF0F7zqSmYQxPJkSpzOVq+8QN+9nGzL6jCYg4YX359jA6ZA YAYOuwbWBONyPCDjKJoiw1LErcF19DnYU8U+IcnRKUYFAcsJooINpezd+aHp 070+P4wz1ItpP8ECny6W89c3XbQs3dho1czrdjHFlaeYuob+uoPcTlFdPf/k zThkxMHgzBqwnB0kQti/an2AHtI0n/J0+Hvu+97h83p52fnXt/4fpGU+eRSy ek78U5ZJmYBNG7AJL6c4+sUXfthXz2NrBAsG+Rjsa4+Pz/AJTYB5Qsy+1l29 6pA+ZaelVIXGHAUd+BfT6Z70xG9Ak0D/DMw7a+axFrCbpPQP3kardZfnKDrC 2mfGl+XkppjBgN9398pg5BEzGP4hZTDmXhmMeNIMhh01hdmXe/AjZ/C4t6kg 3MZkQ8ZSQ0FNOJy0/CssXraRtrX66GAocy+dH42QFBbrY67AEyJtJ8uFw0zJ O5NcwB3X7G/cfSC4O5SO/RFnDaOUbiJ8XYzwJSDMsj8mwgd8OwXHnnwqB/sh 1vcefDpuZYNsKxsslzzuZZEPDL+IEA5JPSR+PgLlai9AuK/x8z8pQB5W7ps4 X+YA/8UpcIJdsa8qN7GMcJoRPqCMop+02re3iGLeo9qnn7rat5leMMKc9SU/ J2WuQCZErkBZCDMUYggQACIMn4ggrKd6tSPFxJtQ+nxIEUcFfqHbmYkTa9PR fjqvb2E5jA3QpiW9eG+bz3d1ArS6w/5oa1EyOfJF2VMCUjC78lZVsa6xKlhV Q+a367AyqwB6wZHAzkof3dpSOgbWBaTj63t4Z34va7xPMbstocNpIrxT5oZQ J4b+A7JjCwD25QoDdhRwtAKQC/tcq8AvET7Qe+znKx1Azj7Cf2gWrlg8ogh7 DB8wgIclGtAjONFGHChJAoGRsE0VoMWgH/926Qs5b31Rhvp6XvhmTnk1b+pF fOywaklZqFFtF1ECQYMPoVwCdFgugYZQLtlQiOxbMLQWS5VCAtiUfGCtkkmT 1yqB+SuvV6xV4l0JasO1it1KJFfVurlYYkFKVed1d+EHX+MrlnxkrAXJoNz2 AsFhTwyT2b2YkquGVWI6vxeDrFUSQ+afylX/qVztKUMycKS8r9EeqEPKPikb 1CG5SkU41Rfh5KAOCa/9VRMBLClTg7piXpuUFtWRNtUmpXOpdChd1FHarHQI rad4BSTYVtpUHlSiOr/pErM4btHcxqZE7W9rbM8cibNLKLCQtZ8xFklxJN6Q aYKn8wXFTKlU5E6F0s2Nhb76ibYOhgOLymBR0gdE0EyECTEinECwrX1JljnY wOAF7VZQ5M3qfEmJO18w1r0XMrDr/ceOzAdFTFkIhZwW6Dakdv7Y1QwB/Z1f CgHbZY2/c6/MTQ/nvkfi5Rj/7ilAC13V7aw+nwVowEZrL7EflRb51hVqc3kG OhKnGRAgbwBAOkPYRliuNYSPdnjIZMo4Usjps/GCWKP2jrbg2szw/o3g+YWi gSs0sHW8zSEScRvb+uX7Dah+JShlbmRzdHJlYW0KZW5kb2JqCjQgMCBvYmoK MjE2MAplbmRvYmoKMiAwIG9iaiA8PAovVHlwZSAvUGFnZQovQ29udGVudHMg MyAwIFIKL1Jlc291cmNlcyAxIDAgUgovTWVkaWFCb3ggWzAgMCA1OTUuMjcz IDg0MS44ODddCi9QYXJlbnQgMTggMCBSCj4+IGVuZG9iagoxIDAgb2JqIDw8 Ci9Gb250IDw8IC9GMTUgNSAwIFIgL0YxOCA2IDAgUiAvRjIyIDcgMCBSIC9G MzMgOCAwIFIgL0YzNCA5IDAgUiAvRjM1IDEwIDAgUiAvRjE5IDExIDAgUiAv RjIxIDEyIDAgUiAvRjI0IDEzIDAgUiAvRjE2IDE0IDAgUiAvRjcgMTUgMCBS IC9GOCAxNiAwIFIgL0YxMSAxNyAwIFIgPj4KL1Byb2NTZXQgWyAvUERGIC9U ZXh0IF0KPj4gZW5kb2JqCjE3IDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0 eXBlIC9UeXBlMQovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhz IDE5IDAgUgovQmFzZUZvbnQgMjUgMCBSCi9Gb250RGVzY3JpcHRvciAyNiAw IFIKPj4gZW5kb2JqCjE5IDAgb2JqClsgNjE1IDgzMyA3NjMgNjk0IDc0MiA4 MzEgNzgwIDU4MyA2NjcgNjEyIDc3MiA2NDAgNTY2IDUxOCA0NDQgNDA2IDQz NyA0OTcgNDY5IDM1NCA1NzYgNTgzIDYwMyA0OTQgNDM3IDU3MCA1MTcgNTcx IDQzNyA1NDAgNTk2IDYyNiA2NTEgNjIyIDQ2NiA1OTEgODI4IDUxNyAzNjMg NjU0IDEwMDAgMTAwMCAxMDAwIDEwMDAgMjc4IDI3OCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNzggMjc4IDc3 OCA1MDAgNzc4IDUwMCA1MzEgNzUwIDc1OCA3MTUgODI4IDczOCA2NDMgNzg2 IDgzMSA0NDAgNTU0IDg0OSA2ODEgOTcwIDgwMyA3NjMgNjQyIDc5MSA3NTkg NjEzIDU4NCA2ODMgNTgzIDk0NCA4MjggNTgxIDY4MyAzODkgMzg5IDM4OSAx MDAwIDEwMDAgNDE3IDUyOSA0MjkgNDMzIDUyMCA0NjYgNDkwIDQ3NyA1NzYg MzQ0IDQxMiA1MjEgMjk4IDg3OCA2MDAgNDg1IDUwMyA0NDYgNDUxIDQ2OSAz NjEgNTcyIDQ4NSA3MTYgNTcyIDQ5MCA0NjUgMzIyIDM4NCA2MzYgNTAwIDI3 OCBdCmVuZG9iagoyMCAwIG9iaiA8PAovTGVuZ3RoIDIxIDAgUgovTGVuZ3Ro MSAyMiAwIFIKL0xlbmd0aDIgMjMgMCBSCi9MZW5ndGgzIDI0IDAgUgo+Pgpz dHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTU1JMTAgMS4xMDAKJSVDcmVh dGlvbkRhdGU6IDE5OTYgSnVsIDIzIDA3OjUzOjU3CiUgQ29weXJpZ2h0IChD KSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmln aHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2luCi9Gb250SW5mbyA3IGRpY3Qg ZHVwIGJlZ2luCi92ZXJzaW9uICgxLjEwMCkgcmVhZG9ubHkgZGVmCi9Ob3Rp Y2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwg U29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9G dWxsTmFtZSAoQ01NSTEwKSByZWFkb25seSBkZWYKL0ZhbWlseU5hbWUgKENv bXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9XZWlnaHQgKE1lZGl1bSkg cmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTQuMDQgZGVmCi9pc0ZpeGVk UGl0Y2ggZmFsc2UgZGVmCmVuZCByZWFkb25seSBkZWYKL0ZvbnROYW1lIC9L RUFBQUErQ01NSTEwIGRlZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250VHlwZSAx IGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9u bHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBpbmRleCBl eGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCAxMTAgL24gcHV0CnJlYWRvbmx5 IGRlZgovRm9udEJCb3h7LTMyIC0yNTAgMTA0OCA3NTB9cmVhZG9ubHkgZGVm Ci9VbmlxdWVJRCA1MDg3Mzg1IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVu dGZpbGUgZWV4ZWMK2dZvYzuEape2hql+RaPQqgUpcxyZp4TMvoW0mTsu6947 EtRyt89UZR7yEYURammrEJbtS60vZGY14Bm2QXzHe1MvhdgRxw0UKaGaUwfv Y+tcXgLIn8bCD22diefZH+Rwtyvv2iP133a+Ba9M6TE3ohntigSp19b9835r f83g2QuYZCPllgpdn7tMlWVW6N+Qy/rsR2+jb9mlyBdcmvUT/tkZwt3Sa9wN mTmLn00D1Zk9/AkwKXhm4c0KMZtrH9lYnjlKUzoIHDbUVqCZIAAaPSGZWD65 uEtN7gjj0Sk54yGZDNJJgn2WSFdJVfYbqqESY6kbbD1HpRkBZbDCWr9tPm7B h+SwUYISa7DQMj2UMXC3lSVSYPn9JfIkjQT0Xfv73vf/ixm/72N7IQAYrgJX KzibP3YoK+spzDAZBdOIxyFZYWiT53RBP0jeC0CLxm3OP+F8ufhNIFg51YAU 1qiII9kyCuk6+W2XoCxNWiuyuMeSXEV4ADlZxG484aLw6sS/i5syXkZDW95g vFTXK8istcCjRBOshwRdx7hGRqMkuAhv2ONCFyE+Exw7FRBBXORUIGiO2cHS eJDsaL18EjX6+R2rOjad0vw75c+WVce37ac2HX4F5YMba44u7FQqezjuA75L rGB50Diss8fJFieXZFR8LVGXa6upS6mGbXnxOQmVqjmw8DEDoHy99EG4xWaf cpAgryhLf/UqKcYlX8qs8XQQkFD7omAuclk/vL/CbnJu5K75e3YyvE9fNTtc Z/7SPqdSpKV7j3/v8dc0HYlfCjoL4djjORlwRXqWfv+E9thHdQsRRbjMW9lu 56qZ3cngaTnjg72kEXUjPVitJj6/Ga/Cfkp+B9CfsINV9up05TCwdDFD8qhx cy1i2A81sZ/Sx/3wgQWEfxPVCTRBmsZHy6cd909FMdwCu9oiruo/u7tAfgrM Ur3GDQGilAfMT5Pri/bUgT6bqFjVTziRisgnIElW1QKR8FRuUPyvptvQCZEj 9ezUqzONsxDbTK4RM3qJjtmbb0g5QMl1RPiI6vDL6xEJShPAc9AGGAhmKgSo K6CtNeh4L4VK9mwgwP7xjQ7N0WRjIbk9Mn5T2Iyg6CX6lQWqV71w/Qy9gkmY DUlPynxquPQR6iha7rT46RSpPUNChHP4hms3AXsX+s5apzt2ieKUJ21vgBsq u23k7Jn2MsFayx+42XVqeu4Fqk25LAapXP9XOqK+GnT9Hl85uHwb/2GjZJyr E5XlYlJn/KrHRVv4lnQfLsegY8s2EqBTiBR6XXYMWyZ+CG52ZNZ5KkudNUe5 o6vaRg/pz/j/JaV3DCMGQUjTmVANEKzjuBxfTAqD5tWyn1TouSYiUCsYs85b Nmo/LBUAeYARWcSNmhkFc20Kz48FYj/MqgMiMGNoglPTrJACvcQ56CJbpn29 k+GGmADwHG4r9u54+k6eIEoqANCshei3I6CjgB7gCCQLd26bxZXr9IBQHfns /aUeqkMX52shHn1aVrLTSUZ6mGa6PiqIoaaswBfB90DUE5QfJ5thKbdfUjnv eT7mqOPmbE70qxBNgrKNNSFYwSPOj0hCPlkMq8i00SA72ZKw/SWq9m1X1DY8 xAKClifcWKWpKZHMJ5tnMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAK MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNsZWFy dG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKMjEgMCBvYmoKMjUyMQplbmRvYmoK MjIgMCBvYmoKNzcxCmVuZG9iagoyMyAwIG9iagoxMjE4CmVuZG9iagoyNCAw IG9iago1MzIKZW5kb2JqCjI1IDAgb2JqCi9LRUFBQUErQ01NSTEwCmVuZG9i agoyNiAwIG9iaiA8PAovQXNjZW50IDY5NAovQ2FwSGVpZ2h0IDY4MwovRGVz Y2VudCAtMTk0Ci9Gb250TmFtZSAyNSAwIFIKL0l0YWxpY0FuZ2xlIC0xNAov U3RlbVYgNzIKL1hIZWlnaHQgNDMxCi9Gb250QkJveCBbIC0zMiAtMjUwIDEw NDggNzUwIF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9uKQovRm9udEZpbGUgMjAg MCBSCj4+IGVuZG9iagoxNiAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlw ZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyAy NyAwIFIKL0Jhc2VGb250IDMzIDAgUgovRm9udERlc2NyaXB0b3IgMzQgMCBS Cj4+IGVuZG9iagoyNyAwIG9iagpbIDYyNSA4MzMgNzc4IDY5NCA2NjcgNzUw IDcyMiA3NzggNzIyIDc3OCA3MjIgNTgzIDU1NiA1NTYgODMzIDgzMyAyNzgg MzA2IDUwMCA1MDAgNTAwIDUwMCA1MDAgNzUwIDQ0NCA1MDAgNzIyIDc3OCA1 MDAgOTAzIDEwMTQgNzc4IDI3OCAyNzggNTAwIDgzMyA1MDAgODMzIDc3OCAy NzggMzg5IDM4OSA1MDAgNzc4IDI3OCAzMzMgMjc4IDUwMCA1MDAgNTAwIDUw MCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCAyNzggNzc4 IDQ3MiA0NzIgNzc4IDc1MCA3MDggNzIyIDc2NCA2ODEgNjUzIDc4NSA3NTAg MzYxIDUxNCA3NzggNjI1IDkxNyA3NTAgNzc4IDY4MSA3NzggNzM2IDU1NiA3 MjIgNzUwIDc1MCAxMDI4IDc1MCA3NTAgNjExIDI3OCA1MDAgMjc4IDUwMCAy NzggMjc4IDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzA2IDUwMCA1NTYgMjc4IDMw NiA1MjggMjc4IDgzMyA1NTYgNTAwIDU1NiA1MjggMzkyIDM5NCAzODkgNTU2 IDUyOCA3MjIgNTI4IDUyOCA0NDQgNTAwIDEwMDAgNTAwIDUwMCA1MDAgXQpl bmRvYmoKMjggMCBvYmogPDwKL0xlbmd0aCAyOSAwIFIKL0xlbmd0aDEgMzAg MCBSCi9MZW5ndGgyIDMxIDAgUgovTGVuZ3RoMyAzMiAwIFIKPj4Kc3RyZWFt CiUhUFMtQWRvYmVGb250LTEuMTogQ01SMTAgMS4wMEIKJSVDcmVhdGlvbkRh dGU6IDE5OTIgRmViIDE5IDE5OjU0OjUyCiUgQ29weXJpZ2h0IChDKSAxOTk3 IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJl c2VydmVkLgoxMSBkaWN0IGJlZ2luCi9Gb250SW5mbyA3IGRpY3QgZHVwIGJl Z2luCi92ZXJzaW9uICgxLjAwQikgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENv cHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0 eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFt ZSAoQ01SMTApIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIg TW9kZXJuKSByZWFkb25seSBkZWYKL1dlaWdodCAoTWVkaXVtKSByZWFkb25s eSBkZWYKL0l0YWxpY0FuZ2xlIDAgZGVmCi9pc0ZpeGVkUGl0Y2ggZmFsc2Ug ZGVmCmVuZCByZWFkb25seSBkZWYKL0ZvbnROYW1lIC9HR0hMS1crQ01SMTAg ZGVmCi9QYWludFR5cGUgMCBkZWYKL0ZvbnRUeXBlIDEgZGVmCi9Gb250TWF0 cml4IFswLjAwMSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL0VuY29k aW5nIDI1NiBhcnJheQowIDEgMjU1IHsxIGluZGV4IGV4Y2ggLy5ub3RkZWYg cHV0fSBmb3IKZHVwIDQwIC9wYXJlbmxlZnQgcHV0CmR1cCA0MSAvcGFyZW5y aWdodCBwdXQKZHVwIDQ0IC9jb21tYSBwdXQKZHVwIDQ2IC9wZXJpb2QgcHV0 CmR1cCA1MCAvdHdvIHB1dApkdXAgNTEgL3RocmVlIHB1dApkdXAgNjEgL2Vx dWFsIHB1dApkdXAgNzkgL08gcHV0CmR1cCA5NyAvYSBwdXQKZHVwIDk4IC9i IHB1dApkdXAgOTkgL2MgcHV0CmR1cCAxMDEgL2UgcHV0CmR1cCAxMDIgL2Yg cHV0CmR1cCAxMDMgL2cgcHV0CmR1cCAxMDQgL2ggcHV0CmR1cCAxMDUgL2kg cHV0CmR1cCAxMDggL2wgcHV0CmR1cCAxMDkgL20gcHV0CmR1cCAxMTAgL24g cHV0CmR1cCAxMTQgL3IgcHV0CmR1cCAxMTUgL3MgcHV0CmR1cCAxMTYgL3Qg cHV0CmR1cCAxMTcgL3UgcHV0CmR1cCAxMTggL3YgcHV0CnJlYWRvbmx5IGRl ZgovRm9udEJCb3h7LTI1MSAtMjUwIDEwMDkgOTY5fXJlYWRvbmx5IGRlZgov VW5pcXVlSUQgNTAwMDc5MyBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRm aWxlIGVleGVjCtnWb2M7hGqXtoapfkWj0KoFKgFCZ7eQTrPA070Lg9iRAWym yktxKt6yWPqrmhMO5gXmH3f8G3OKvHxRzUbvgXGQmNX+5nZg5pp6uRtY8ppN eeVwIveD6w+7ttT07DUBT9Ley6mUWaTFnfDG66FQKERU5wfcIQDBW3a0wZuE NjdYRppsVYeFsiYzIVIQmHGpiDSH3XcQlJIE3c+DfmqHCLgr2/FvvHUS+qMI oJP+XPcVjxFjvB8zUuIqFFLnP+yopIcQD7H/xMivQJsgZ1NyIOYF2ghSykmD nhOGr516GkVf0fAXzkWITXbvLLm8WCH9JTZd3qbkXzMrX2ikStilMPCSo2+s jSf5CHr+6iCW+DmivEuTfyTggO98D5N0oY1WXClaBSENuWojF1rFmpvQFHox DvScVRpBfgoicD+U/3t1QJpdQX2mcwpp4xD6akIp/H5PYgsPxMY8UOmeF561 HkxLxFIXci8ejkDx4UKOeS6v4FxaUNOMUhFN/NJNVAJ8vyUS3RFvBGPeQFKn rVO2QaJ+geSBlHiEzjVmG0kVP6GeCiqGDHthVYZxMD3mrgaoDk5FDhcGdnbm u7QqmiSsvD6wynt6O/6oT+05zPttVFuyvMSeXhaXZAernZRVbNTwCCTvV5to ALbcOq+ECz/GgihyNo47QnTdBso2r49jRsEbQ8dyzCQvOyEsS9cBjXGhp0ya lO0Ak6X7ZVf04HUQR6/XIJjsowG4rmgRD5g3luWB8QYUSVHfW3UEMqIw/aO1 dVo4teeXKqvBIwagGpn8+Bidcbjb9JVQuuqc8bl8v8fMlkmOzJOLGhcQtnBl fekjplnbh1cUexQKSAZzKOfj+cN9GIiyhJBDAUUM4LwV7uoA5IzNY4jz/Dvv 2NnEAAFbZQ8vU20DViax/wpp1zLHoYNtY1wwwGvtQydzcCnlulgwueiKQCTD MmrS809HtUc5tIglrWaZ99EX6kxK7ERAv22qAJne/TJiNZZcY2R5IYKL8mns yHorHIytbHi25WGwB5e+K8fKMrRTQHX2SRvpWdH2NUY+cWeeUn9PRW93Syr4 /vPYxjsvi5n+D3O6RLPPFaYTRx6jx6HNeD0+tB9KzuUgdZtqTERm4tgO98eG a60G5d8ENNLGB/yCyevU2JAu5Ap2F8OurMt8zgAxnQZ3qm234CULUZCPlml3 vYyNB/299NBYRE59fZF4jeqZfL4FRZAuZxlLe6PNC/RU/KYLmiA+a7Um0tIf vW144hqTby4SPA9u9BqiJmz1G1E+v0nU2SwMk4IKNwEKTImQs9JVHu0vx0dH U6mDTI0XQFCfzAFFZOH1t9SRz59/Nd86DDoiImzYNfkcyLjpTS2L4S8dyuo1 cLyq/wA3/sxa1ZjyGELXOF00wcF0L8SrkMkrSfyq684euWMveOTqZZ9c3SXa ywlTccL6UD2sXcXz5UmKDEMIIa3lrCPhytS9vEXBfu0hmXxrWrULD2BmADzH 0uantyRUdBlQeLRD7fe34bcXwOdr9QSkjW658eDz94NLHEGYf45BWdFzcsao 7UYwpYosdPkdAJp1fKESE6SeYmsiXdjeZkxg+q0qw7B5ZK1OxeQp7FHJ98n5 AWyhnDEkppA/itPhu+hYgU4VpYjQCoBF0D4dxA5jGY2Lw2bV6J9WPc3/W21p R1U+TJLhZnFjz0QJBHSXmC4TrzInpy0S7DtwW50fzE2f9FLT0yu56hgXUyLR EfcjYnD0+OuvYDHUaTDys4XVehHgnunAgkOAsURdCX4rS1g+YLefvOzGb/7d FOwD95kZ+Dn7TihWJfrlVZkHv9gwSLw/7NOqfr4nWOhQjYpsoQv+K00Hf44G a9CzgnAo4xO56UmKLauO/mgUcZyuly7tuT1mFEty5raNhJAurxS4rHk8LD1s Mp6TzzCP6vnDwIm8AUa8bhpkj7C2r+y/24FRDzajXw+qGUDrc1BOnNGGqCbQ //ktoLHfJhJEpHIh24CQHcxPcF1/7BzxAgOK3CEmfJrKaI7uDl2WGdcX681E RJVfR0rSAElLpLgnFgftwZEujnoby0gqiSQUUV2EIgipjUEJBWXsgBgYAsDA hXSDA2DDW7CqdnYTMyab+a1nfWA1uZbqDGR6iCsDk/91xc4N6Vmej5+K5mMB HNvlwnbjpXDkb4c8mJFoFhosywQwGkVB4qEw3LIcizL17kw/5m74KJR3S324 270IeSGVTP+8sHDVImn0wtFO02fZFBWU+bA1eO/l7Y0Vw3xI2UW0zjXpIRh0 Lfelj8JvwdCZdCnPwM88cN4Zh0mBu3diYIv29JPLFQytlcJGrlbn0Lo9zKGH cWSnU3lIOu5cEKz33mlk+sX9ytnFC397jNDm3PVuaxatqbmDsIR1Fvl9ClgU vpFpXUHIWlQrSmQTDIeAb5h2O/1FSwcXxcx1vvUmwGeVTfFgaZhwu2rC3LOk VhxmyrMHH+FjW7fSGKBye9O+l21JY7yEDE1PUfvVzef+b8JUQVa7sYwurWZN G8uulzLVE9hNKIrRB3+jxyPax3tkpIQau/mbsgt9SPuvLqn+5oTD48vWegIQ 8/CDTRmHCV/KUWDrANQiDZ+Yama9OdhVpN4Ii3SyBwq9yscA85JT8y0u/XhF 7NF4wvSNog8a0jTinZro8986V3t3m1QcEBsyO5zCsdvO1l7hI+IcPSnoUrbZ Zp3Wyx10aG9qYKcTdit4JaLDVgbCwn/qQrzEtsundVhXYDIp+rvczGszZAAk vjY/YaaV3VRI4Ex2vMusmwdGfAhg0emSqkXeu1XhNOFBMKQJM0/tUfnfWRyw TzieesXpNp7ZPMYTWiQcThAKigj6mud62q+7JEVyPViQ7So7681srU+NsjLn 24DFmyUu0CP3PKFLcrEBORs8PDyAxGdHWJZzOnkx88JRzWwo9vN9R4osxajJ 0uLh6+wDY+Td17kBXkyLdJyx0EFlTUkbbvPNvnGieSMcJuEY1wVnm97GO3ag 9j29Z44ZcrHHN+XDrmzFCKftSh6VC+9aTnK12h3+ZAl1eylrz+2tQaIx9Xe4 JKwBSwKfvMSeFLkDawq/yjFdiZyDsmsYydYkVL2YYCnmuPA5Qk1wtCFbIQx8 v9/YyZ2dIY1tIJ1sqZ3OF/BnolrkymU9nOTpxoTsFLMPDeSpohXihuV5O1sb VEh1SPdHODubzYOytQdiBKYuMCLP57bxDJEzRzVS0JzR7jRQVZQOmxDcX7rk 8PVmypBYqRoUHwKSfI1Mqp/zYF8Xa+UiIuBzOTHqtThV0GEbqkEQf5uSSTV1 waphfdJnfYjsIrAYZtd+oSwmZwZ5Tl/TZ5Ym9aux7640BEN/ij90GN+6TTe6 glvu7zRKqvoUBm9id0aU0gQvxRs3nXDeAc2bn/9s5ANLQa2F5MNvXhHe7JdZ Om0B8tTE5fnH0seFBcPlCD8e26OU6OWZstCqbVX+5TrH4ePIFjTihep7MxSC 4eSmRfwBSzayNhC0sG9Ic5BNEKWWnpxhtJNgZ3fpOym5xytB02wjHLgL+7GQ uBT5f3H5vWtYZoeA6GQr8mjVVaY+MKoygA/yd81ESvsGmh6z40966rfT3Vj/ LkoiSmm94n1WD9jcngSu7mm5bFXNStdzwPOThL06rC2JtIzo+JiLIHHguYJL e96p5Dj3SPZ8fQoDnipIlGApBiXa5bwGZI+Rpmoo6rX05SVFx9ORBlhAYdpP n1UPUNfd/OU7IncpyVHeuxw7NYT2ZmFvTp4wqYJft1b7mlIBvGxSjOs9iFZo 5gj8AZBCN3uQ2O1QoZjfF75OEdXNtwphRST+EfyDSFBN402fe8RerUGJw3gU EiwIyPrRdk29vNCiEbWxRRL1UsKUMy0eKCasjzqVJX7xz5v02plTwOjY1tS9 CTWQ/CVCoJD5ljMtaN61PaKe2+3OHZ2+bJdetpQPU7p8eADMHMDYNRy3yLpH mIwfuitxvIsbaab2H/dh9BAhI8W7x27QG0MKmK3RtO60Ag2Y5HHsA47yZPqh a4lps/GTn4X8C4Q3i6jbNb4qCE9YlPglTabmlRb0BT7Mymzr6QebYGKiFQKY 06LU/s6GnPn9dPpP7J8PbgrppwSsFUXpH5NAHawqT3o+ByBCbVD+kDfIAKLj 8JiaRnlt02uby5ntTB8INzI6XPMv34ySYKBS0wmj1UnTokIuIpN50vMSJgbB CznYRkw4QiHURU08aYrlzRvTIIWH00oRRp5pU7FFtWfRlzZvFdF8H1D8B0YS 3lyf4ADEcQdFEslG7vX0G5v7K2RBNSkumtJ0NUhxZybfgCS475Isn/JT3DwQ Ep0HlQoQsgN5aaSgogOBU0lxtGX9rrS0EuRcliBae/BGULquxhCIQnS0Pati UGtYAHFst3qbMZw49IND+JLJ9wBJ35I/8kFvVwPRHPJkUow+lKal9QElUo6g l9134/CmfLuCfHuUwOIOYPw3wYsFZlWL9gvI+ajBlYmVYGtDVRDIGKeAMVBF TSXY/sgzIk86oXeWtTY/niC0j0XuVqzjRmr7hBGgPwv/Ntd9/eztS3tJ68ga EznrTLSMRIfLR+0Uiv0N7jjPrw8YntE78BwQW5bOpYIsL33P/EikvZrzUved I5Nu8xBTtnmxke4V8bzCWHMWAwxgMzG2orxStYPrSYym1yrsgFSFlvVlGW54 pHcExUQ9KfcRWoECgBNqFU8mcV9BSo0Nq7NOel/Tp2cxE8Np8jUVhiCl5SDm gDOapn7UCKdyTbynXDHAzT9+hceEGn3GQofHk6pQYR/++QYEr69cWDxzAaRb tLGC3eTS0ILbdHXVaA7GCqh3kRoPtu33Gpd4n6Y6dUKeMNYTwlQycSYG8uyw GvB0ZpEAMd8Pd3dh5o150Wm0wmX7JtH9DJZsjIcDjBhf3z5kpqVL3lbfkYr1 hp+bSw4177SKqcIg+WKWuRF/tqJ5pMg3pX3FJ2XOK6P9Uk02EZyj34ETwkml f/ZD5OEzQZCE5pZKWbvoWec9MoWMuf43L+KGNWGrNqSKm2ZdoOmA842SgR8Z Lo0Sgb9VinzGj+icUUv5mn+p0uSs6z/XiCvNiFVBwFRfamS4S/OvKccEHSkH byjpYU7YAd2L70orNZQW43hImcHeoFPUZvaG6gCOzTX3nlSAQ9LEK9QjIRhE xdxClJ+2ZQyv5OWyQp7O08JtZTKa1NdOKVRCWT6V9rfQCQ2z3FDTOgnq8aW2 8+gRXJKsOn0ro2t7qy1fiXvDkC6lv++HSbx9WWlRol1NbiER8B8qzNlouaLd htn+Fa4Or2LyHZRh9pJkm5tk/YPxkxMgQwLAs8Tj3d13gHNGWL+n6sFIjvMZ A0tP15A1YEO073Yt5hcK1TWLKM/YS7cYu+GOjyaJxV0aejiyYHhts55KCyfh lfoGXKj8M6gvuh08pmGnNwt4RNzXjfN3H4zt8ZPVG8fvjy31hoHez41840ju HQioiD0WAArW7V3KjJqP4J65hjQAlDz4VrEAMEHo+eTZvwcWFUtMHvFnqeM5 S1DO/xu1AGpYOdza17ScktkUZjAgfelViKtRl+30CPqOt6XmMaqLP0ZtwGzu SyjNW0tMIrhF0GGCnH++IhRueljeFjqegG1YhNwe8yNmD41smrPhjLAopfBA 0t+595OmiFr11SX4+ZOullV0dX4EZRH6HiAhr2ynHHIrxNz7xlCUsE0i10tl 8CILxpDQDwDw1HX/u9nUB94yyHgSfXn2uvM2p9ccVOErmvTQVbb9iefPWHiI h1tJg4Fzqln0Sa5Mg+wiI47W3MAnlhaWajO/f289ivbAFy8yM09LWwHCcbFc 4DWKR4rpu6QaQXtdDxzBFZDhP+r2RXhZ+suGsu0JbiMmGZgrdsapUOgBPNPT 3CdNO0dQnPU7HMSPWQRkjPzHApr3PEU2d/mnQwYVa6t2lfndLiwRqqIqnnii VK5vkTGySTvHchcyoTpCHEVf0nkcBbHm/94BpPUhpELspNkxNp4hrDEIeBHJ MZM85Pghyw9ODvifd9tEIQ/H4ModyWohjSUPt1hdGOE9GI7EjJC2fVmfN5xq 6Gpuuo21mVpvpRwQvR4GOn5nnD+dmStl4GlPNPXWxw2qdmu3eAHgOzm0zH6l gE0ls0+Aym6Svq3NlsFyYssw4OPgTIGdNpN7alHRj/io8xNVWppKFT2NAas6 lxRL8/wL15PoEmBYXe7Oa8hfYJdyXzm3fEy1mq7JWn6uvG31Xuw4Sh8pI0pe toldBgFYnEHsM9MvfnC42ioTDnShiNsmJyTAtYMzJnZ6DBfzrrh7BPpJxA9s gFXgHgP39Mfm0rnXb2gGmpp1LL7WJWHp9BVtEgbb1SGcVPYurzZ6cW8fWUcR 74MPLQfmpGr/PQ7aQDWDdtfYFwKJntwgiRAz1Xu87SZbvEYr44Bbf1kVuMhz j4/nDwb+PTZrm7f6TF68y0TonihJgkJUcq09Ip90xy4gGCphRVuy3NC2sGf3 cWQZQxIHHgQUO+E8C+N/iAGOhfbc1YGbL6nCylNliTtgragh2upWbrHJqEn3 hT8shtpJCqNZ7yf/1hkZtFdIG7Ub0nOVY4tpEYIpbWO4C3KSBs/SKWYTwqpL qBJaSNAFKoTKwN+HqerXlogYJ7FjyrgJRTf0IsrYr5RtxKdtwPRqrYtoyLo2 9Nm5pYWto50k+RWE/JSHDyjj1OoPlynhWjJo45X7pE4Co8/WXtIztj3sYfuA 9scB3ZBbAiK7iEq/oMSxiH4FNnxD7P1Q+JgdCVUxNqs3QSK/Z9+Ml3Ftfi/m tkUHP6AVS/rmhg87AvLfiDB8w3MekwRGA7IqMhQHpJptDY/fjoDyUjQNxnHr /PM6NbeatDXdPR+/QsBjLPj+EaT/4wK4IZ4pqbFvb5EfEuiPKGdZJtGi3Czt 32hdnxHfd+GfxmHS8AVMaODSv6dq8gWv8Fa/kH1XGd5124kmTcnOF5bQaZ2T HMKAjvRd/W5zdvU3oBBkJSMVgZ2q73j4dWTlsYWP7duPQ/k3ljtTcYz2K8Vv SEr5vfwOWlkimOAO0jHhXedSaV/rLOfvbyUWRvLa5aPLaASJ3DDloTycvY2i GmubahaQdKBxjrleyEn2Rkbh/88flEcCDdNYpH197lA2gp2maNWurxEuOAAV Q5jedqsfvPDQLCBdozaOaL5FFWyMzmeYjrMSDUQA1aLBpps7yczMcpnUJeIp F+EXsb2GNP5ltsD0XiibAO8GEfDTxrFHBjxr+HEczGeBlH/f7hpKnOvh7ePg 5iNgsm+Ltxm5hyydbQaRiFr7je/0czsF1BgXFGZKG1fHS8LiIyEsP//zHLec zKfrz9uZQs0vbihP4E9jKix2Djvdj/CeUJhMxQhmgq3Q77wc8rFti+UFj+WH GWg3J8wnGyJv78Xhinmq/3dUBljXNgkFk16Zi8z+KXv7O+mPuGlDTYj7yyOZ PUh1K0dkruSyBofm2EGTEPEquYYwFjzbI4DkYIvtu9KJG/1ZJnjLgB44dVx+ VSd/nzBqNMGTCR4GkaRenibjSjeJhqEPMtW033DIvIiI/xzcaq0OMfQhTVn0 mZJY3c9aGLUFU1PpVOWopfJwKuE1LVZXDHyxORE3vdy70yYvdj9zp93PMoa4 /Q/gzaOQ+TLv8Mu+hnP41PAPK/ZEXVz1EQapOQobBEXdRLMexl/6wbQHcrYY odNCnpCLULQqyr2pi+t2BV9zU6dEgJZaZ8c2xMtLM7mTL9khX5Js9oNP+0+A f0QvsjUQBGy8M98wcvHXTX4DTnJsrojGHXfTBQhCYEhTcvtUTf/k7+X9pT7H Rwr2Qat1had+8IYwhwTTmFlgfauk/Pl0JFiG1EV1cq4ZPj2vRKe/1RzydlY0 YwfyCE7uD2IYV08vtSgW6k2p/mDBYFFzOEU+edcWOC8shrokDhU3nXWEk+MR 8iHCAcC9A52qKPnPHNsRmNA0L9Fm0vHTG5bYotX184VGMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCmNsZWFydG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKMjkg MCBvYmoKNzYyOQplbmRvYmoKMzAgMCBvYmoKMTEzNAplbmRvYmoKMzEgMCBv YmoKNTk2MwplbmRvYmoKMzIgMCBvYmoKNTMyCmVuZG9iagozMyAwIG9iagov R0dITEtXK0NNUjEwCmVuZG9iagozNCAwIG9iaiA8PAovQXNjZW50IDY5NAov Q2FwSGVpZ2h0IDY4MwovRGVzY2VudCAtMTk0Ci9Gb250TmFtZSAzMyAwIFIK L0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY5Ci9YSGVpZ2h0IDQzMQovRm9udEJC b3ggWyAtMjUxIC0yNTAgMTAwOSA5NjkgXQovRmxhZ3MgNAovQ2hhclNldCAo L3BhcmVubGVmdC9wYXJlbnJpZ2h0L2NvbW1hL3BlcmlvZC90d28vdGhyZWUv ZXF1YWwvTy9hL2IvYy9lL2YvZy9oL2kvbC9tL24vci9zL3QvdS92KQovRm9u dEZpbGUgMjggMCBSCj4+IGVuZG9iagoxNSAwIG9iaiA8PAovVHlwZSAvRm9u dAovU3VidHlwZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcK L1dpZHRocyAzNSAwIFIKL0Jhc2VGb250IDQxIDAgUgovRm9udERlc2NyaXB0 b3IgNDIgMCBSCj4+IGVuZG9iagozNSAwIG9iagpbIDcwNiA5MzggODc3IDc4 MiA3NTQgODQzIDgxNSA4NzcgODE1IDg3NyA4MTUgNjc4IDY0NyA2NDcgOTcw IDk3MCAzMjMgMzU0IDU2OSA1NjkgNTY5IDU2OSA1NjkgODQzIDUwOCA1Njkg ODE1IDg3NyA1NjkgMTAxNCAxMTM3IDg3NyAzMjMgMzIzIDU2OSA5MzggNTY5 IDkzOCA4NzcgMzIzIDQ0NiA0NDYgNTY5IDg3NyAzMjMgMzg1IDMyMyA1Njkg NTY5IDU2OSA1NjkgNTY5IDU2OSA1NjkgNTY5IDU2OSA1NjkgNTY5IDMyMyAz MjMgMzIzIDg3NyA1MzkgNTM5IDg3NyA4NDMgNzk5IDgxNSA4NjAgNzY4IDcz NyA4ODQgODQzIDQxMyA1ODMgODc0IDcwNiAxMDI4IDg0MyA4NzcgNzY4IDg3 NyA4MjkgNjMxIDgxNSA4NDMgODQzIDExNTEgODQzIDg0MyA2OTIgMzIzIDU2 OSAzMjMgNTY5IDMyMyAzMjMgNTY5IDYzMSA1MDggNjMxIDUwOCAzNTQgNTY5 IDYzMSAzMjMgMzU0IDYwMCAzMjMgOTM4IDYzMSA1NjkgNjMxIDYwMCA0NDYg NDUzIDQ0NiA2MzEgNjAwIDgxNSA2MDAgNjAwIDUwOCA1NjkgMTEzOSA1Njkg NTY5IDU2OSBdCmVuZG9iagozNiAwIG9iaiA8PAovTGVuZ3RoIDM3IDAgUgov TGVuZ3RoMSAzOCAwIFIKL0xlbmd0aDIgMzkgMCBSCi9MZW5ndGgzIDQwIDAg Ugo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTVI3IDEuMAolJUNy ZWF0aW9uRGF0ZTogMTk5MSBBdWcgMjAgMTY6Mzk6MjEKJSBDb3B5cmlnaHQg KEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBS aWdodHMgUmVzZXJ2ZWQuCjExIGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcgZGlj dCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEuMCkgcmVhZG9ubHkgZGVmCi9Ob3Rp Y2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwg U29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9G dWxsTmFtZSAoQ01SNykgcmVhZG9ubHkgZGVmCi9GYW1pbHlOYW1lIChDb21w dXRlciBNb2Rlcm4pIHJlYWRvbmx5IGRlZgovV2VpZ2h0IChNZWRpdW0pIHJl YWRvbmx5IGRlZgovSXRhbGljQW5nbGUgMCBkZWYKL2lzRml4ZWRQaXRjaCBm YWxzZSBkZWYKZW5kIHJlYWRvbmx5IGRlZgovRm9udE5hbWUgL1lCQUFBQStD TVI3IGRlZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250VHlwZSAxIGRlZgovRm9u dE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9F bmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBpbmRleCBleGNoIC8ubm90 ZGVmIHB1dH0gZm9yCmR1cCA0OSAvb25lIHB1dApyZWFkb25seSBkZWYKL0Zv bnRCQm94ey0yNyAtMjUwIDExMjIgNzUwfXJlYWRvbmx5IGRlZgovVW5pcXVl SUQgNTAwMDc5MCBkZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRmaWxlIGVl eGVjCtnWb2M7hGqXtoapfkWj0KoFKgFCZ7eQTrPA070Lg9iRAWymyktxKt6y WPqrmhMO5gXmH3f8G3OKvHxRzUbvgXGQmNX+5nZg5pp6uRtY8ppNeeVwIveD 6w+7ttT07DUBT9Ley6mUWaTFnfDG66FQKERU5wfcIQDBW3a0wZuENjdYRpps VYeFsiYzIVIQmHGpiDSH3XcQlJIE3c+DfmqHCLgr2/FvvHUS+qMIoJP+XPW4 yruf/GzD8emuMvI062D+feNJlbGs/1JCjqIMjtT9c+OTXOvUDg6tcMCIekUe GxrIR67eQZHM24thNF/QcP0wxPN12EGN3UVHKaJRs/YdrnyIgjhCgv3WECro 7v7eZEdXavoYHyekghapytcwVhRp5HiyhvIjKPKuhO8YPeQRnEAncaJJqsH6 VDVpCijRtHSGEGDIAA0/4b9FEzz4R6JLT4RkpjzqAeyEqiL9AF50hH4BQmto kJUafdH1Cl8yheH5WPEfx/AO4m/ufGOZjqEyi8mEHFfICUbSwvyBNGJJpmTs +wiizgdQNs6nNZ/KHpDA9obDuyfu+kXVSPe9B0zmDmJqT4PGn+k6UyQTOng2 LzCOjcyA3QxJ4TfNyawIuuOSguJqek2MFZuV8ie9oqKBr6na6/MfUEOAsggS ohHPn+sRLsKaP7O9PoGAn8YpNIenRV6zuHnStL1GlCuxJDiWJkciy1kUbD9l vVm5anSxK7KaE1SvF0kyIQxuGf5YSxsUwA50YInLsX5ohF17PqBRBe7kYeNp f8+DXL5tRsdVI0eOdmgydRz22W7DOL2tV9U7UvU0D6yf4EVq0TEBgkI0smKs DKukO2Lr2jl5W65s/pdWOlCq4fGViIc58mdghqmBHlyaSn4L802hhbgWaDur Il8oV9Uaq9S+oZUerMV7+44zARquDdHnF5tq2IjWgp6wCUfLeY9mWLQqJOqj +qdg84oWcScymW+VcuRI8OAn6oN++tsv/RpwjwdqAw2OiE0xX1ZV2A81Fz64 Dqdotk44zYikPFTzCVrNL5Fysjv8ORk8cazsNN6IdfS12o7ua83UwYJXH4My tquoV02n3xaOeIFbvneXT5rKU4jpx3+AVgQoSsYEgRJLhAnOBT57V7d10hO9 y/PJMzUupqlTz48MIunZfdrRJWuSIm878XzhttXRIAoYXonu/WqtS7ml6d9r D6mOrxEAWWgmZd3lFQeatszzx2ZqV+QO55kV/YqAfD70vzshJTlovx56XXbW gIPJ+BSiS+VUpz6jGTxzEkoflDc+la/1LcofkOV0PBeChFXFtZE/RP/Q6ZD7 tmMzu4FmlwaI7y2zEPs5KfhV2mCm2J6xLh0ENiI5g6tNBYEMhOqH+7RSLJcj OAQSR2tTDCTuMXL4DgkEpHXu3k5mqr3uBTbwtwlNt87AqN+4giLr/+FM0Xtt GJ9RFesFYq9LWUuCdOfu8hfT4Xm+wS11GyKj7lYrvTB+nuLlkVb6Cb/Pk950 EkQ0frFotZI6WjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAK MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMApjbGVhcnRvbWFy awplbmRzdHJlYW0KZW5kb2JqCjM3IDAgb2JqCjI0MjAKZW5kb2JqCjM4IDAg b2JqCjc1NwplbmRvYmoKMzkgMCBvYmoKMTEzMQplbmRvYmoKNDAgMCBvYmoK NTMyCmVuZG9iago0MSAwIG9iagovWUJBQUFBK0NNUjcKZW5kb2JqCjQyIDAg b2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0x OTQKL0ZvbnROYW1lIDQxIDAgUgovSXRhbGljQW5nbGUgMAovU3RlbVYgNzkK L1hIZWlnaHQgNDMxCi9Gb250QkJveCBbIC0yNyAtMjUwIDExMjIgNzUwIF0K L0ZsYWdzIDQKL0NoYXJTZXQgKC9vbmUpCi9Gb250RmlsZSAzNiAwIFIKPj4g ZW5kb2JqCjE0IDAgb2JqIDw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBl MQovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEyNwovV2lkdGhzIDQzIDAgUgov QmFzZUZvbnQgNDkgMCBSCi9Gb250RGVzY3JpcHRvciA1MCAwIFIKPj4gZW5k b2JqCjQzIDAgb2JqClsgNjY0IDg4NSA4MjYgNzM3IDcwOCA3OTYgNzY3IDgy NiA3NjcgODI2IDc2NyA2MjAgNTkwIDU5MCA4ODUgODg1IDI5NSAzMjUgNTMx IDUzMSA1MzEgNTMxIDUzMSA3OTYgNDcyIDUzMSA3NjcgODI2IDUzMSA5NTkg MTA3NyA4MjYgMjk1IDI5NSA1MzEgODg1IDUzMSA4ODUgODI2IDI5NSA0MTMg NDEzIDUzMSA4MjYgMjk1IDM1NCAyOTUgNTMxIDUzMSA1MzEgNTMxIDUzMSA1 MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSAyOTUgMjk1IDI5NSA4MjYgNTAyIDUw MiA4MjYgNzk2IDc1MiA3NjcgODExIDcyMyA2OTMgODM0IDc5NiAzODMgNTQ1 IDgyNSA2NjQgOTczIDc5NiA4MjYgNzIzIDgyNiA3ODIgNTkwIDc2NyA3OTYg Nzk2IDEwOTEgNzk2IDc5NiA2NDkgMjk1IDUzMSAyOTUgNTMxIDI5NSAyOTUg NTMxIDU5MCA0NzIgNTkwIDQ3MiAzMjUgNTMxIDU5MCAyOTUgMzI1IDU2MSAy OTUgODg1IDU5MCA1MzEgNTkwIDU2MSA0MTQgNDE5IDQxMyA1OTAgNTYxIDc2 NyA1NjEgNTYxIDQ3MiA1MzEgMTA2MyA1MzEgNTMxIDUzMSBdCmVuZG9iago0 NCAwIG9iaiA8PAovTGVuZ3RoIDQ1IDAgUgovTGVuZ3RoMSA0NiAwIFIKL0xl bmd0aDIgNDcgMCBSCi9MZW5ndGgzIDQ4IDAgUgo+PgpzdHJlYW0KJSFQUy1B ZG9iZUZvbnQtMS4xOiBDTVI4IDEuMAolJUNyZWF0aW9uRGF0ZTogMTk5MSBB dWcgMjAgMTY6Mzk6NDAKJSBDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4g TWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjEx IGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNp b24gKDEuMCkgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykg MTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0 cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01SOCkgcmVh ZG9ubHkgZGVmCi9GYW1pbHlOYW1lIChDb21wdXRlciBNb2Rlcm4pIHJlYWRv bmx5IGRlZgovV2VpZ2h0IChNZWRpdW0pIHJlYWRvbmx5IGRlZgovSXRhbGlj QW5nbGUgMCBkZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYKZW5kIHJlYWRv bmx5IGRlZgovRm9udE5hbWUgL1ZLRUxBQStDTVI4IGRlZgovUGFpbnRUeXBl IDAgZGVmCi9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAw IDAuMDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkK MCAxIDI1NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCA0 MCAvcGFyZW5sZWZ0IHB1dApkdXAgNDEgL3BhcmVucmlnaHQgcHV0CmR1cCA0 MyAvcGx1cyBwdXQKZHVwIDQ4IC96ZXJvIHB1dApkdXAgNDkgL29uZSBwdXQK ZHVwIDYxIC9lcXVhbCBwdXQKZHVwIDk3IC9hIHB1dApkdXAgMTAwIC9kIHB1 dApkdXAgMTAxIC9lIHB1dApkdXAgMTAzIC9nIHB1dApkdXAgMTA5IC9tIHB1 dApkdXAgMTIwIC94IHB1dApyZWFkb25seSBkZWYKL0ZvbnRCQm94ey0zNiAt MjUwIDEwNzAgNzUwfXJlYWRvbmx5IGRlZgovVW5pcXVlSUQgNTAwMDc5MSBk ZWYKY3VycmVudGRpY3QgZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnWb2M7hGqX toapfkWj0KoFKgFCZ7eQTrPA070Lg9iRAWymyktxKt6yWPqrmhMO5gXmH3f8 G3OKvHxRzUbvgXGQmNX+5nZg5pp6uRtY8ppNeeVwIveD6w+7ttT07DUBT9Le y6mUWaTFnfDG66FQKERU5wfcIQDBW3a0wZuENjdYRppsVYeFsiYzIVIQmHGp iDSH3XcQlJIE3c+DfmqHCLgr2/FvvHUS+qMIoJP+XPTp0kBbFpzVNl1uztXX aNZtbGhhi4xIKzQfjKOOm7m6/PqtnC8/0DO2JpCYbtQ9nJNhNkW4I5LVyuEa fLSdfi6C3NSFy6F3LOQiux1yg61nW2VIp+oAaaiD7B2qPh+eznWG1s8KEozV V8fl16o+qX6605YZ0b/PSm1kdodB7eoKWw77vzR83L4uA9dWlnoWthPbD8Rf oqMxLgxGpf0EZqsJfFj/7sQGAbg5XlJ3XQr819uKsxczMRBTHlxEpMtLWs1X GhpglgsV5FCUil7qFN0zD+ogkmXbjhofyA3NOGAyP9JsETsEGojIiiFlWHho CkRm+hBAPSS7lxUqSbhCwYDk0ljJ1I8h0Fd4LZBiMRaDC6OZArPF8vLdAUM7 DXCZwH294mjQ/+1RabzQPUiy8FitYthnjGJtx6PzUhUsmbqWPvlfitEduLDT USEKF+TCxVrYnrZBcpNdPCCjmPPu7sMVUZZqdDjvP+5CLG1OBTN2INWsx7Ur 7ZhL+q02750gdIsF0HvkQUpjl1El0nL62D925hD/+DYwFL5SbVgIc8WkK3D6 kR7HuGkF8Tr+VesCc/WCgxWHk7jMKWuN4dzPElD9V8sOA1x+2jsAku2UDTeg VJMuxU4JuYT8pKt9LqGCvPEmOqJEsH7A6pL5rzSzTBxEuFatEMEY8DVi5owd Z+SoQU6U06oH2tEm14/ptvuaK4vCk6fEu5XJgrajpOE/F8zpwAzq7FxTZdBr 6ayB9uEXz2QY5IxWF/MHUHpqbVODDsisFt+kajst6DBAgBwzAHEeIcwsHmGQ ecgLLMoElg5geduqaahrtzkRa21vc3JB+359d+KH2ockxKR0uhnzr87ipnSX ruImcHg6C8zfSiwRi+xNhmWw8u4nAJbXRX9BIk4X80ySy/4/iGRGta9H26m9 U6ftH/pD/TtYB/ZulVHxoIdz/nR8YRjE4Jd1z84DXrGEaLHei8djCmgMwd3o lffI0eBnaVb8hCyPKeuBEM0C0FjzX4TPpIyqozMXT+Wl1eYtkCp4EpLi3Ytr kf48MeeuYyWIVM5vIlarTcgP3F0GlXfTwszOvgi0M8R5YRiwK9phgEZpBNiY 4hQt20CmWn8HjfPHoO9+4L6pzMkbHmnxz2lEzhw7QezrpYZFclbv4bPBQXyr Y/a0bJgCdjQCHncNn1SlFcxND0PGFoAboqfG9V4A8UjwtIzpJBv7Ishkv+tc 5udsA0cvP7acS7vRsRtPr4zC/+KC14kmYhCJF/CCi2880Y8lz7e0fEVRbzGF o6Hf8R/OA6dCJBVsn9dYLf7UlKwMpNDm8vSEq5S0TGpb+8VdZQtaOPxiuTf4 X/v/JPzwEyD3EwkyeAsNCeAaHP3Pb6f1xhOAjErccGAE5HXrcNvFpPDjYux7 OZCFQuHJ3vunZoCsTpHXqFTnYgdPdfkjBNNjpyCtZdgPS1aXYdsH3v8ZMjKA CL3YwX9mDioQ9Y/+qEjqD973PyZjmlfFbC9vyvl4U9DbDaK3AG0nGkaqT82f pYjHKacBJdj4QXNt+S0cc65d7yWcTehk836gATZ5hwfAT1wVGVe0xi/K9Gen cIijAsK1huKLbUURQIFjVAsPZtNO4hzakmrGDhclJCDqrg9QgoicxsUWJ9fs A3esqwBV4kxntSJLZk2lu9w1Xdya+MoVEq0msjJhdXzj3v8WVF3zJClWJrpx k08F8pm/rUNdcUpmopNhg1EPYe9yoacCy5KHCt76mGqJHxTZi6Lm/5QsWk+A NRntR5jFOkMdk+EOjZi4AAJieqPtpk+TZwubQqbNjRt0VVXazdwEuqInRra7 oGU0wmypptH6nNm+0+2rHmm3+UsmPkNikL92Gzc0P7zu50i75o1kWIKt4g9j Abzbyjz7VJTfnl6BNg5E6R3M17Zy2+grMoAigtJd/HgTwc+495eU8aHYMqW1 WXMhZOKikxFUKvvSRZ8wE7C2AFzyRv6QUSQ6E/CfBUq9CE1jYBRJvP0tD/Ol YWwtut0Mp9qejb1zaWLzJMWDTW4dAgOCuj7ApBC5LNiziwOAMMhdO9G1rBZL FhtmfVDASF3aMaXpj5Me4uZe2A7n6t4f6a++9aaMOyhPvlt4KwvQvqdiWJ1G XyZKni0mNe2yUTeFFJkeMjzAtZfQE/G6Ajps4K4/oDixbjrOVV+ncEzqOmn5 gHGTZ7f2/dbrHo/NZxXc6vo0YnDOqGBt9PvlVL1lXkQtJhlQhlJa3js7zg83 9b/hUz8qrKJq7dwGmKZAUy3tgS5cy44QS6HefqWwXeieQORxE+WKRbHuhMqi x4L9rnFykghvrcv5J1TWycgsuCLMsq3QBJBohc2LeNv/9bpnN/QemWH6BALl EsPW5WAhdTHYvEDSEW11y90CZ9IsEwuRQJWCqF7BQHUj6j0RWfe1yCPIbDHe YfUUuovIgdCIUZb99oWjgxxft1BqbVHRgtokwu+7PslImYNI28feFaD8WLx8 BZy1Wk4XOHytvrjNY4nWj1JOpiA6Ott6KW+bl1pQnT3T4GlRra/GWp22nmhG OFhkrVU0XXogJghzhp/7oiA4kn31X3fsDvLicLpzGzkWX0z65fGx3PNZKhzr CQmUxVapCK66+nbY1rkv43SVeWRFUVGEMJ4cYP2CtYg89DHS0ofhOc1Five7 fH6eWSpMMunMaYiDHwtnJDgr/wn9OOb8PqpRtGAWBsgA6jbJRB8zhPXkBrUn j7A2QUdX+H4ZGW+KJJum+TKsXreAp/UR+dEPnCNl/X9FFiaUrn1zuE7u6KcC 4b10vEELXBJ+Gvkk+EBlO8zvofB7HfbjOiNBplh/r8BjvC1HoLMdTf7xNKsR J7oCHRihgWiwRLephbdW+msaxDTKeRL+lqRhxQdXq9ApjEwud/qAQFetv3V5 o2Ii1zXcFhXWE/wnos1XGRa//wipj/z9JCrnYfZwTUtcN8DLZ6cGuOZ30ETB ZS4WvtJmSoOiYVMt9LI2WgTotNTOoPZ8jid5IQJ5UqNq9c2vcdmqxEApSt2k 6s50bIKmdg+pNN7HNu9XDxohyGbwQlkNJ404O/stviCfj5SwjGhXSFORb/ck PGKQ7CeVrFtdpo0oXe17llitTr+QruxR8oD8/Y/9SyWpUIVFQp+4eAKZGbRb LmhhA0o8vVBD/2ELxID3sjidlxths8oyJwYWlBvjhGXjGfDoC2xsqxe/y/KF gz1Lqa0BYriLki7JOeM6WvPFe3mlPsO/uyaTcERPURHa8t33W/keHHPaQPB2 gPebD2iujSC7zyzakjeLQJnvWpHGRVJomEEpR4mJa8oyAeqkF/K1lhh6o0HS hezjzb+mKLKuJkuQTlvNmzUGjTsN3x65VD87yyeH2yGgn5wRJpTs/lrEDuln +ktTpERiVMOkA4S7jXeG9Gdy7wI3wSDF9AcTK+dbMr4dkJIIJk4ipsiaKPq8 3drZVnzC6gNwtT6Q+eM7F+GBHvguodjPUvXHyVoSGrKW/eSHkdIhnWRe608q 7GOoew1RZQQXg5WiWCbTBMfbqLwU2n7jgtzYpr/3e6LaWFV3jk7h4cKTNskr cmA4OHL0doYZUA0L6KBcpQD4K6+zxfBXpXGtzQLlKKbeabwe+2XpnCFGLCL6 DnsLgajGLPiDCh2exRscaFWH2215mDXOE6vVqkzfjXaymfNjLyQ6GPvxvbaU R+DoMVYnnZZepC7kTYO3Vs80aTyBEEhvfnzJRHhXZ816NIR0Gz8+LL+vzTAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMApjbGVhcnRvbWFyawplbmRzdHJlYW0K ZW5kb2JqCjQ1IDAgb2JqCjQ0NTEKZW5kb2JqCjQ2IDAgb2JqCjk0MwplbmRv YmoKNDcgMCBvYmoKMjk3NgplbmRvYmoKNDggMCBvYmoKNTMyCmVuZG9iago0 OSAwIG9iagovVktFTEFBK0NNUjgKZW5kb2JqCjUwIDAgb2JqIDw8Ci9Bc2Nl bnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnROYW1l IDQ5IDAgUgovSXRhbGljQW5nbGUgMAovU3RlbVYgNzYKL1hIZWlnaHQgNDMx Ci9Gb250QkJveCBbIC0zNiAtMjUwIDEwNzAgNzUwIF0KL0ZsYWdzIDQKL0No YXJTZXQgKC9wYXJlbmxlZnQvcGFyZW5yaWdodC9wbHVzL3plcm8vb25lL2Vx dWFsL2EvZC9lL2cvbS94KQovRm9udEZpbGUgNDQgMCBSCj4+IGVuZG9iagox MyAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL0ZpcnN0 Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyA1MSAwIFIKL0Jhc2VGb250 IDU3IDAgUgovRm9udERlc2NyaXB0b3IgNTggMCBSCj4+IGVuZG9iago1MSAw IG9iagpbIDQ1OCA0NTggNDE3IDQxNyA0NzIgNDcyIDQ3MiA0NzIgNTgzIDU4 MyA0NzIgNDcyIDMzMyA1NTYgNTc4IDU3OCA1OTcgNTk3IDczNiA3MzYgNTI4 IDUyOCA1ODMgNTgzIDU4MyA1ODMgNzUwIDc1MCA3NTAgNzUwIDEwNDQgMTA0 NCA3OTIgNzkyIDU4MyA1ODMgNjM5IDYzOSA2MzkgNjM5IDgwNiA4MDYgODA2 IDgwNiAxMjc4IDEyNzggODExIDgxMSA4NzUgODc1IDY2NyA2NjcgNjY3IDY2 NyA2NjcgNjY3IDg4OSA4ODkgODg5IDg4OSA4ODkgODg5IDg4OSA2NjcgODc1 IDg3NSA4NzUgODc1IDYxMSA2MTEgODMzIDExMTEgNDcyIDU1NiAxMTExIDE1 MTEgMTExMSAxNTExIDExMTEgMTUxMSAxMDU2IDk0NCA0NzIgODMzIDgzMyA4 MzMgODMzIDgzMyAxNDQ0IDEyNzggNTU2IDExMTEgMTExMSAxMTExIDExMTEg MTExMSA5NDQgMTI3OCA1NTYgMTAwMCAxNDQ0IDU1NiAxMDAwIDE0NDQgNDcy IDQ3MiA1MjggNTI4IDUyOCA1MjggNjY3IDY2NyAxMDAwIDEwMDAgMTAwMCAx MDAwIDEwNTYgMTA1NiAxMDU2IDc3OCA2NjcgNjY3IDQ1MCA0NTAgNDUwIDQ1 MCA3NzggNzc4IF0KZW5kb2JqCjUyIDAgb2JqIDw8Ci9MZW5ndGggNTMgMCBS Ci9MZW5ndGgxIDU0IDAgUgovTGVuZ3RoMiA1NSAwIFIKL0xlbmd0aDMgNTYg MCBSCj4+CnN0cmVhbQolIVBTLUFkb2JlRm9udC0xLjE6IENNRVgxMCAxLjAw CiUlQ3JlYXRpb25EYXRlOiAxOTkyIEp1bCAyMyAyMToyMjo0OAolIENvcHly aWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4g QWxsIFJpZ2h0cyBSZXNlcnZlZC4KMTEgZGljdCBiZWdpbgovRm9udEluZm8g NyBkaWN0IGR1cCBiZWdpbgovdmVyc2lvbiAoMS4wMCkgcmVhZG9ubHkgZGVm Ci9Ob3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1h dGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkg ZGVmCi9GdWxsTmFtZSAoQ01FWDEwKSByZWFkb25seSBkZWYKL0ZhbWlseU5h bWUgKENvbXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9XZWlnaHQgKE1l ZGl1bSkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAwIGRlZgovaXNGaXhl ZFBpdGNoIGZhbHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFtZSAv WUVGQUFBK0NNRVgxMCBkZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udFR5cGUg MSBkZWYKL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdIHJlYWRv bmx5IGRlZgovRW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5kZXgg ZXhjaCAvLm5vdGRlZiBwdXR9IGZvcgpkdXAgODggL3N1bW1hdGlvbmRpc3Bs YXkgcHV0CmR1cCAxMjIgL2JyYWNlaHRpcGRvd25sZWZ0IHB1dApkdXAgMTIz IC9icmFjZWh0aXBkb3ducmlnaHQgcHV0CmR1cCAxMjQgL2JyYWNlaHRpcHVw bGVmdCBwdXQKZHVwIDEyNSAvYnJhY2VodGlwdXByaWdodCBwdXQKcmVhZG9u bHkgZGVmCi9Gb250QkJveHstMjQgLTI5NjAgMTQ1NCA3NzJ9cmVhZG9ubHkg ZGVmCi9VbmlxdWVJRCA1MDAwNzc0IGRlZgpjdXJyZW50ZGljdCBlbmQKY3Vy cmVudGZpbGUgZWV4ZWMK2dZvYzuEape2hql+RaPQqgUqAUJnt5BOs8DTvQuD 2JEBbKbKS3Eq3rJY+quaEw7mBeYfd/wbc4q8fFHNRu+BcZCY1f7mdmDmmnq5 G1jymk155XAi94PrD7u21PTsNQFP0t7LqZRZpMWd8MbroVAoRFTnB9whAMFb drTBm4Q2N1hGmmxVh4WyJjMhUhCYcamINIfddxCUkgTdz4N+aocIuCvb8W+8 dRL6owigk/5c9bjKxqe+tdAiduUR/68q4RkQ3gdvJDEdlNB8rMMj82CIfx6h G92nkn/zMlmG/bCr38iOS0DnmIkh1VHsCGfrykTAVlfw3JE+ezAEpfPhM3tp h/68RfmJyNxtwK1XfpA/BdDVQgigrn8oxzTxMMEztIQivtSGOaK3TkwI8ucQ 4kqZ80fg9DlM5k6stUlXbokETlLqvllbyWQVbZ2MK6sPSWZOlR18Gj0XicR/ A8cFGmPV6N8E+qxHNR6CyuB5SqlpLGRSaIp0p6anrQm4qXg8I17B6iFWJhuP szGCcUXeMVtuwbPYtnszI/dh6vTCI7shTExrBi0bKB9QQdBoMZ9JEQWDdtjv ulmIS6MxjFvJVoTygeBZG8DRsqRZKhN/8wFhABm4rEaubki8CR6IjkSHaINQ 6a1QdO5ISCcc5KzDjYy8jz2zKBPd1bNBr5pmASgaujhKl4uYSDpj/MRY0OO8 5v2DDn4JsNuYemtjt0Y4/J8hpYxoR54ahSJWcNec3eWsC3f1qZTKcAtfD/H5 f8Y+/eAjgTXwSp0gwxmYsSrgZnbDYhQaqqOVze8KSeAUHTNZZfL7QZhJl5nO zMiqXSVSZHhM0wo+gpWIjvvCBgrd17rEWu7vm4b5NDfXlQvBd6eY5rtxzPJj PoV5EIg2mtE2w3wE0OiHCmDU8M7/BQotCkU+6GALUBrPwjVAWL8IkG145eAx YkBDFkSs1kQEeDNyC810GsxL+TCFo8Vu9CM1fqyuQACdBrO13HLo8tzfUya9 hoOzFWCmWYtDbCE7/VS6/9+eAnuhPk1Yi4sHpyJffLsjF3h3e71VSsBDvDMx 8IuRSfuy0KwToKUzlc1+s+gbmgs85yBQvGbBg9PpaY8feskAGhA5qLNpjuV5 gBtiwWqNEVguFn/VpuFiAaFg5pMSNwkG4K0v1EFg0EiBX/nOnGWGrTWuWCMZ gxrSIYU3VKaUVatygBARs3x1uzKrJo0I8H5uR1VcRPqmKDCxFKW/ZW2kXEJz bUuwCkZmW6QuYOPVYHWgBjSfET2/Z8J/AgyALNViARVOPL15BrlK3Z8WIaFK a/3gEIUkJ6MGxln4mFpsuvXYqZcWckuZs05ORmTC6HAn9l3BPlXToCzAMJ9D giCnr1SSidf6B9UInx5lMu+W/rM8zdI/k9leJI4WruCM30WNxkcnNsWOuVxk /BkbaumzCpFkrjg/yXOC6T23kmzAmd/xDHh6ZlYO3mMku56mw9n6i9JeJaMs YUz0ihZ75jnO+Rlyl9yG6OyXJ/4mcBL1RNdf6XGjedfbugdvw1rHkXar6fsz edzB2v1Gf2Qz54ucRKmeFIXoY04PBErqeXPBtN6ZSF6r9CQ0EyYJ1WXSqVVR g67OpLJyWw8PrJgwhKZ3KelRDLy0EVAIA0+zxQrdU6kDSZkWIVxQro28cJVl GIM2b5sqi8lv/tovf3wtvPCTf2GgdxllfHzkkwTB9C3Iwbh0ynukiq8CNAW8 A0n/2t5+1K154WQTrElJVvF62GNzd49tOM57z3ZPxvxiyC9JE1xKLKOZhRKG aWp6HWzTVP57Ri0sxbDvFC6Cdv/JIzIHzgn+AyOvs/X0/rkz7HXYCsOS/xtP ILn15rYKv5nEP3ErmXORZQymMQBlHueqmOLLHTXCc9FtebUrTWsCLYDLI/Z5 p2JaFhpk2S6Oy/aPtykGJSig3JQUkRS7eeuFu9jEqamukiDPO57o6UhGTWeG 2C29OUN3q89HyRZoanHywp4WyhUsFCPtCoQoOsVfRX7ie/UTS6SZNCjVh+wV VWWBST6s5MVb+Whthi9/0eh8yxQFSAaoOUJgMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwCmNsZWFydG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoK Mjk3NQplbmRvYmoKNTQgMCBvYmoKOTAxCmVuZG9iago1NSAwIG9iagoxNTQy CmVuZG9iago1NiAwIG9iago1MzIKZW5kb2JqCjU3IDAgb2JqCi9ZRUZBQUEr Q01FWDEwCmVuZG9iago1OCAwIG9iaiA8PAovQXNjZW50IDQwCi9DYXBIZWln aHQgMAovRGVzY2VudCAtMTc2MAovRm9udE5hbWUgNTcgMCBSCi9JdGFsaWNB bmdsZSAwCi9TdGVtViA0NwovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTI0 IC0yOTYwIDE0NTQgNzcyIF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9zdW1tYXRp b25kaXNwbGF5L2JyYWNlaHRpcGRvd25sZWZ0L2JyYWNlaHRpcGRvd25yaWdo dC9icmFjZWh0aXB1cGxlZnQvYnJhY2VodGlwdXByaWdodCkKL0ZvbnRGaWxl IDUyIDAgUgo+PiBlbmRvYmoKMTIgMCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1 YnR5cGUgL1R5cGUxCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMTI3Ci9XaWR0 aHMgNTkgMCBSCi9CYXNlRm9udCA2NSAwIFIKL0ZvbnREZXNjcmlwdG9yIDY2 IDAgUgo+PiBlbmRvYmoKNTkgMCBvYmoKWyA3NzggMjc4IDc3OCA1MDAgNzc4 IDUwMCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggMTAwMCA1MDAgNTAw IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDc3OCA3Nzgg Nzc4IDEwMDAgMTAwMCA3NzggNzc4IDEwMDAgMTAwMCA1MDAgNTAwIDEwMDAg MTAwMCAxMDAwIDc3OCAxMDAwIDEwMDAgNjExIDYxMSAxMDAwIDEwMDAgMTAw MCA3NzggMjc1IDEwMDAgNjY3IDY2NyA4ODkgODg5IDAgMCA1NTYgNTU2IDY2 NyA1MDAgNzIyIDcyMiA3NzggNzc4IDYxMSA3OTggNjU3IDUyNyA3NzEgNTI4 IDcxOSA1OTUgODQ1IDU0NSA2NzggNzYyIDY5MCAxMjAxIDgyMCA3OTYgNjk2 IDgxNyA4NDggNjA2IDU0NSA2MjYgNjEzIDk4OCA3MTMgNjY4IDcyNSA2Njcg NjY3IDY2NyA2NjcgNjY3IDYxMSA2MTEgNDQ0IDQ0NCA0NDQgNDQ0IDUwMCA1 MDAgMzg5IDM4OSAyNzggNTAwIDUwMCA2MTEgNTAwIDI3OCA4MzMgNzUwIDgz MyA0MTcgNjY3IDY2NyA3NzggNzc4IDQ0NCA0NDQgNDQ0IDYxMSA3NzggNzc4 IDc3OCA3NzggXQplbmRvYmoKNjAgMCBvYmogPDwKL0xlbmd0aCA2MSAwIFIK L0xlbmd0aDEgNjIgMCBSCi9MZW5ndGgyIDYzIDAgUgovTGVuZ3RoMyA2NCAw IFIKPj4Kc3RyZWFtCiUhUFMtQWRvYmVGb250LTEuMTogQ01TWTEwIDEuMAol JUNyZWF0aW9uRGF0ZTogMTk5MSBBdWcgMTUgMDc6MjA6NTcKJSBDb3B5cmln aHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFs bCBSaWdodHMgUmVzZXJ2ZWQuCjExIGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcg ZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEuMCkgcmVhZG9ubHkgZGVmCi9O b3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGlj YWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVm Ci9GdWxsTmFtZSAoQ01TWTEwKSByZWFkb25seSBkZWYKL0ZhbWlseU5hbWUg KENvbXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9XZWlnaHQgKE1lZGl1 bSkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTQuMDM1IGRlZgovaXNG aXhlZFBpdGNoIGZhbHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFt ZSAvUkFBQUFBK0NNU1kxMCBkZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udFR5 cGUgMSBkZWYKL0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdIHJl YWRvbmx5IGRlZgovRW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5k ZXggZXhjaCAvLm5vdGRlZiBwdXR9IGZvcgpkdXAgMTcgL2VxdWl2YWxlbmNl IHB1dApyZWFkb25seSBkZWYKL0ZvbnRCQm94ey0yOSAtOTYwIDExMTYgNzc1 fXJlYWRvbmx5IGRlZgovVW5pcXVlSUQgNTAwMDgyMCBkZWYKY3VycmVudGRp Y3QgZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnWb2M7hGqXtoapfkWj0KoFLwn5 yK3p2QfAWLh+m2lkfVM1nlEhZ3Sk6qHitY7DF2vRGEpjO5UTcrQZjU6MXvSi E6y1iqCmWJCANb8u2FMXeYOKlg3+KyfqScNxVpicheIbOr9y45qJIyzZ9CN/ yAyeZOhCWqO+997WCxIqUpIqIho32agH3QEWF3nd59Mf8rh/l8c9Y+7N2kxJ UBdzRoon0WY+C2L0YfbkCl1mdtHRK1HmQcHU6OJ3GGT8EE+Mv1t47B2IIocl 8cRTpnj1in4be9fKcAcX0ojrjaH1fE8JCr8dQsXd0MOEx+Ivj4BHvh1MHMjj M2j7GsgrTpYUZzDeMwKy5rgZy2rkVbGvMYf/6AcapX74pmFrnLeUHUTsenGn uz33VReNfS5LtphZ76S7wwvWuxUxEz/U2UOP+Z8JTswGijJNdbX2lrhojusv F+XtNMzW0Eek44BtABESJnYYqIiV/A8unvBkrwHLxCkTJVyJ6dC+GiDzwC6v dZoI4f8JgRUYqxQWMzk6yNIPBziNmip2hoEwehNdBJgJyLibgihYEPci3YbC jOeCJfnVBzTmNmGS443HdwSpedEYAGpch9oOLXv0L40ubBEq68/tI0GncDxN OtccC/nPQel4bTAmHbgWfGyQ3bVnQLRdwrB6TA+0H3G30mXoSPb4URouyOTk +kvGRVynLRXKUXGmfOgYQkKdO85S04rTT48Delz5/98eM3/dMYFL8Hkrcxvy ZjFXsyDtR94yixLLM+9L+VD4rjc9Lzcr1AFqKJW4RJQrJ6OamJ1KQT2ZWUi1 oRsI9kjaYaQE5QPFno8bIOj4dH2/D90KbJryt1pg/+6MKzW3iF5NlcxUrctx u3+IEIwyX0mgGlkURCPtzasKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNs ZWFydG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKNjEgMCBvYmoKMTk3NwplbmRv YmoKNjIgMCBvYmoKNzc3CmVuZG9iago2MyAwIG9iago2NjgKZW5kb2JqCjY0 IDAgb2JqCjUzMgplbmRvYmoKNjUgMCBvYmoKL1JBQUFBQStDTVNZMTAKZW5k b2JqCjY2IDAgb2JqIDw8Ci9Bc2NlbnQgNzUwCi9DYXBIZWlnaHQgNjgzCi9E ZXNjZW50IDAKL0ZvbnROYW1lIDY1IDAgUgovSXRhbGljQW5nbGUgLTE0Ci9T dGVtViA4NQovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTI5IC05NjAgMTEx NiA3NzUgXQovRmxhZ3MgNAovQ2hhclNldCAoL2VxdWl2YWxlbmNlKQovRm9u dEZpbGUgNjAgMCBSCj4+IGVuZG9iagoxMSAwIG9iaiA8PAovVHlwZSAvRm9u dAovU3VidHlwZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcK L1dpZHRocyA2NyAwIFIKL0Jhc2VGb250IDczIDAgUgovRm9udERlc2NyaXB0 b3IgNzQgMCBSCj4+IGVuZG9iago2NyAwIG9iagpbIDY0MyA4ODUgODA2IDcz NyA3ODMgODczIDgyMyA2MjAgNzA4IDY1NSA4MTcgNjgyIDU5NiA1NDcgNDcw IDQzMCA0NjcgNTMzIDQ5NiAzNzYgNjEyIDYyMCA2MzkgNTIyIDQ2NyA2MTAg NTQ0IDYwNyA0NzIgNTc2IDYzMiA2NjAgNjk0IDY2MSA0OTEgNjMyIDg4MiA1 NDQgMzg5IDY5MiAxMDYzIDEwNjMgMTA2MyAxMDYzIDI5NSAyOTUgNTMxIDUz MSA1MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSA1MzEgNTMxIDUzMSA1MzEgMjk1 IDI5NSA4MjYgNTMxIDgyNiA1MzEgNTYwIDc5NiA4MDEgNzU3IDg3MiA3Nzkg NjcyIDgyOCA4NzMgNDYxIDU4MCA4OTYgNzIzIDEwMjAgODQzIDgwNiA2NzQg ODM2IDgwMCA2NDYgNjE5IDcxOSA2MTkgMTAwMiA4NzQgNjE2IDcyMCA0MTMg NDEzIDQxMyAxMDYzIDEwNjMgNDM0IDU2NCA0NTUgNDYwIDU0NyA0OTMgNTEw IDUwNiA2MTIgMzYyIDQzMCA1NTMgMzE3IDk0MCA2NDUgNTE0IDUzNSA0NzQg NDc5IDQ5MSAzODQgNjE1IDUxNyA3NjIgNTk4IDUyNSA0OTQgMzUwIDQwMCA2 NzMgNTMxIDI5NSBdCmVuZG9iago2OCAwIG9iaiA8PAovTGVuZ3RoIDY5IDAg UgovTGVuZ3RoMSA3MCAwIFIKL0xlbmd0aDIgNzEgMCBSCi9MZW5ndGgzIDcy IDAgUgo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTU1JOCAxLjEw MAolJUNyZWF0aW9uRGF0ZTogMTk5NiBKdWwgMjMgMDc6NTM6NTQKJSBDb3B5 cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHku IEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjExIGRpY3QgYmVnaW4KL0ZvbnRJbmZv IDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEuMTAwKSByZWFkb25seSBk ZWYKL05vdGljZSAoQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhl bWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkKSByZWFkb25s eSBkZWYKL0Z1bGxOYW1lIChDTU1JOCkgcmVhZG9ubHkgZGVmCi9GYW1pbHlO YW1lIChDb21wdXRlciBNb2Rlcm4pIHJlYWRvbmx5IGRlZgovV2VpZ2h0IChN ZWRpdW0pIHJlYWRvbmx5IGRlZgovSXRhbGljQW5nbGUgLTE0LjA0IGRlZgov aXNGaXhlZFBpdGNoIGZhbHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250 TmFtZSAvUVhCQUFBK0NNTUk4IGRlZgovUGFpbnRUeXBlIDAgZGVmCi9Gb250 VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAxIDAgMF0g cmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1NSB7MSBp bmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCA1OSAvY29tbWEgcHV0 CmR1cCAxMDUgL2kgcHV0CmR1cCAxMDcgL2sgcHV0CmR1cCAxMTAgL24gcHV0 CnJlYWRvbmx5IGRlZgovRm9udEJCb3h7LTI0IC0yNTAgMTExMCA3NTB9cmVh ZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDg3MzgzIGRlZgpjdXJyZW50ZGljdCBl bmQKY3VycmVudGZpbGUgZWV4ZWMK2dZvYzuEape2hql+RaPQqgUpcxyZp4TM voW0mTsu6947EtRyt89UZR7yEYURammrEJbtS60vZGY14Bm2QXzHe1MvhdgR xw0UKaGaUwfvY+tcXgLIn8bCD22diefZH+Rwtyvv2iP133a+Ba9M6TE3ohnt igSp19b9835rf83g2QuYZCPllgpdn7tMlWVW6N+Qy/rsR2+jb9mlyBdcmvUT /tkZwt3Sa9wNmTmLn00D1qjwW0evle8oqcVh29yYxHz1UlABHRnpNm62/RU9 OhAMqmIS49XZOZBzf40ybTR7ftxDkcnfRAKFuPwVnQ6Y1CWPxXiS3fdTZCzV JqlqztpBIHiPIrHQnxSXlOZt0awsKzvG/sWdYm9CfNWunFTH949iw29Js8Ll 5ir7Vtzuh0RaEqlCwUrmGNH+GxGpz5+qHzJhe1mM5QWHFe8wUeIo9y9lEECt madB8kfGgAfmjITp0dC/mapdd32Ip9PO0upn9K5h6LwElefaOC6C3bKwCd1j Uyx0475exVWgFLy7arMbgobXcS4Okm+GloMGcrghTptdB0DBat8K/UfEk483 NXXGypHkbYjeJOaC3sRLV+qK+E5X1FZGBzJQ2CxLUMu7CzaZMmGDAfPUGGJ3 EDtTs8nm20LWswEV9nudB4Ig1XUmRJMGQ735+s9oTr4T45tlBV6xvQVMMkli Al7Hnh0VWTb+MtnyIkNT8qRsNVjvIW9rsqMEuvdSvuw2xEQLVWrv7PRUuny7 p1N7yxDrwhBHMzqJiTZBnYV82fWeuiCwo9m6Sg0zlTNrTNpLpkUbbk0TcPrZ vau38nG8HGxI2d8eWm+ueI9WCd48SNR6Zwl8VH2YF604n9JElNNl1iAXGCq+ vMeecSesQXGXthCTAe/v1g+jlCmM2KDPqIYb44FOBTaLTN1O2QH0zKoUXQx6 WmCAYYqW1bI/+p9w3KO8DAyblGmpb1ARfVf6+s3J8FnP2BtQuaFlRZPl/6Lp BvPAtoYbyFzrq4NGTybASewNcPJdyeOZ/LqZxOAmlTlJAoprfpLgqfki09vb vQfaGxx2vR0FraKjCRmajCeLbOdqo07KX6wDcEaWJsARSt4bh1wUg517ALu5 E1TGZOq98IhtqsxV1U24C+Hj9ZdPub5C99w/8ogeTHdarU6MrBO3CdmB74hV b1eqNWHFG0VGzTzfdgp3Ydhrc5IITVwuai+a3hCelV5ggVj3eEUz095l+UuR MaOxPoEwqVWM+PBeIyLJLeMo1tL8lpeTFWXzGrHLIDbTZ45KlcsoWg48pmW5 Vi5Cx40929NP5VYJaKSIzx20e/yVVf/36TI6mQ4LtwKSiQiYLdbRm5G9kk8+ xH4ywPcKqAAxsAsYU3SFRUpYLk7FzJZ16DCSjv6JLHPQ5CB6OxcOf6ftzyUm 22Q8LJuWNRgHnWUTq9Et8P99WmEbjAGPuoZA/Uxi1RkX9IlWlTkDPCeWtp+X Yx2JL/SmZGsHACUGxKJNoJfyqomgBHNoSwmsMLlfcSD0dC7zSWP6G8AK3CyI I6pGv2SO2FFrbCppbMxPdkHNJMBQeHa6qaULQy8KKXz+DQkJYndkKDG/1xoC miycdhcFp8YHeMcG7MsSiquwIciJqJ9i76mIRpoRovJ9fu42ZcVdk+d3AoG/ 5+Lnk1I7+xdj47gLZGUgZTaxK6z/Cy7kp6mmfqxHsPcY4RmQ9aGFzPcgm2f9 VdipRhf5lHIp+UHKBNbHZDTf8NwiJhNXXQh84vvOfUzTfB5gaBQpwTUPSlU7 Isu/g7eJ9Rxha7qB3WDtI2LLGjdTYTUaIHAYJvQ1OXyRt2qtpU8fIFgpzgnv PSDDkIMiiDDmukMPVaJFTts0NDbTIDUEvGv5lRBa/DGtiiFVQMrLhkCd8Shm 97CTBe9UeQ7b0roQmHjJeigVsITrFKJC9MeIoEAKgOSQHcVke6pkQVwR1rQ6 NV1do2yCSi3nKfSzMCLvLtorvh1mJndKFqMASboXcJ+adigqx1czF0Gvd7bB osYm2ojbHUXuoLQfvwIFXkXwnxy4WpszF2ZlkQmKevZ8Fjm6Tcmg1mr8xl/M nV8bPSMLao6a4AJKQpE3IWjOonZsU51rVigH0RhoqCCABxY1aGbvlNlGb4R+ 3F7ztu8Bl2v2RGYJeNBrjk2y5VPqMVjw6RHOfyD2PP2Avbo3t/rGlOtCU8cM 7R2B6kBkLQDF9nQhS+kRX9dahu0AMy9DspB/89GmRqJPKHm7ZhNk1vQ7t97s xZEHC8oliQ8LMC8bRd+OQVHA73UZQCtXR5fueHNoXpeJjCiBbMmXBkGDIZXF qbUxLrhG7XxQe0vQ2M15P0mBAWGrvW/LS+UvC7ivjbelC9zM8ovvZoaht1Ee clPPX/KSs7E/ABfi4QUfMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAK MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNsZWFy dG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKNjkgMCBvYmoKMzE0MgplbmRvYmoK NzAgMCBvYmoKODE2CmVuZG9iago3MSAwIG9iagoxNzk0CmVuZG9iago3MiAw IG9iago1MzIKZW5kb2JqCjczIDAgb2JqCi9RWEJBQUErQ01NSTgKZW5kb2Jq Cjc0IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9DYXBIZWlnaHQgNjgzCi9EZXNj ZW50IC0xOTQKL0ZvbnROYW1lIDczIDAgUgovSXRhbGljQW5nbGUgLTE0Ci9T dGVtViA3OAovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTI0IC0yNTAgMTEx MCA3NTAgXQovRmxhZ3MgNAovQ2hhclNldCAoL2NvbW1hL2kvay9uKQovRm9u dEZpbGUgNjggMCBSCj4+IGVuZG9iagoxMCAwIG9iaiA8PAovVHlwZSAvRm9u dAovU3VidHlwZSAvVHlwZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcK L1dpZHRocyA3NSAwIFIKL0Jhc2VGb250IDgxIDAgUgovRm9udERlc2NyaXB0 b3IgODIgMCBSCj4+IGVuZG9iago3NSAwIG9iagpbIDY3NiA5MzggODc1IDc4 NyA3NTAgODgwIDgxMyA4NzUgODEzIDg3NSA4MTMgNjU2IDYyNSA2MjUgOTM4 IDkzOCAzMTMgMzQ0IDU2MyA1NjMgNTYzIDU2MyA1NjMgODUwIDUwMCA1NzQg ODEzIDg3NSA1NjMgMTAxOSAxMTQ0IDg3NSAzMTMgMzQzIDU4MSA5MzggNTYz IDkzOCA4NzUgMzEzIDQzOCA0MzggNTYzIDg3NSAzMTMgMzc1IDMxMyA1NjMg NTYzIDU2MyA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1NjMgNTYzIDMxMyAz MTMgMzQzIDg3NSA1MzEgNTMxIDg3NSA4NTAgODAwIDgxMyA4NjIgNzM4IDcw NyA4ODQgODgwIDQxOSA1ODEgODgxIDY3NiAxMDY3IDg4MCA4NDUgNzY5IDg0 NSA4MzkgNjI1IDc4MiA4NjUgODUwIDExNjIgODUwIDg1MCA2ODggMzEzIDU4 MSAzMTMgNTYzIDMxMyAzMTMgNTQ3IDYyNSA1MDAgNjI1IDUxMyAzNDQgNTYz IDYyNSAzMTMgMzQ0IDU5NCAzMTMgOTM4IDYyNSA1NjMgNjI1IDU5NCA0NTkg NDQ0IDQzOCA2MjUgNTk0IDgxMyA1OTQgNTk0IDUwMCA1NjMgMTEyNSA1NjMg NTYzIDU2MyBdCmVuZG9iago3NiAwIG9iaiA8PAovTGVuZ3RoIDc3IDAgUgov TGVuZ3RoMSA3OCAwIFIKL0xlbmd0aDIgNzkgMCBSCi9MZW5ndGgzIDgwIDAg Ugo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTUJYMTIgMS4wCiUl Q3JlYXRpb25EYXRlOiAxOTkxIEF1ZyAyMCAxNjozNDo1NAolIENvcHlyaWdo dCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxs IFJpZ2h0cyBSZXNlcnZlZC4KMTEgZGljdCBiZWdpbgovRm9udEluZm8gNyBk aWN0IGR1cCBiZWdpbgovdmVyc2lvbiAoMS4wKSByZWFkb25seSBkZWYKL05v dGljZSAoQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNh bCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkKSByZWFkb25seSBkZWYK L0Z1bGxOYW1lIChDTUJYMTIpIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAo Q29tcHV0ZXIgTW9kZXJuKSByZWFkb25seSBkZWYKL1dlaWdodCAoQm9sZCkg cmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAwIGRlZgovaXNGaXhlZFBpdGNo IGZhbHNlIGRlZgplbmQgcmVhZG9ubHkgZGVmCi9Gb250TmFtZSAvRVVDSk5B K0NNQlgxMiBkZWYKL1BhaW50VHlwZSAwIGRlZgovRm9udFR5cGUgMSBkZWYK L0ZvbnRNYXRyaXggWzAuMDAxIDAgMCAwLjAwMSAwIDBdIHJlYWRvbmx5IGRl ZgovRW5jb2RpbmcgMjU2IGFycmF5CjAgMSAyNTUgezEgaW5kZXggZXhjaCAv Lm5vdGRlZiBwdXR9IGZvcgpkdXAgMTIgL2ZpIHB1dApkdXAgNTggL2NvbG9u IHB1dApkdXAgNjUgL0EgcHV0CmR1cCA4MCAvUCBwdXQKZHVwIDk3IC9hIHB1 dApkdXAgMTAwIC9kIHB1dApkdXAgMTAxIC9lIHB1dApkdXAgMTAzIC9nIHB1 dApkdXAgMTA1IC9pIHB1dApkdXAgMTA4IC9sIHB1dApkdXAgMTEwIC9uIHB1 dApkdXAgMTEzIC9xIHB1dApkdXAgMTE0IC9yIHB1dApkdXAgMTE2IC90IHB1 dApkdXAgMTE3IC91IHB1dApkdXAgMTE4IC92IHB1dApkdXAgMTIwIC94IHB1 dApyZWFkb25seSBkZWYKL0ZvbnRCQm94ey01MyAtMjUxIDExMzkgNzUwfXJl YWRvbmx5IGRlZgovVW5pcXVlSUQgNTAwMDc2OSBkZWYKY3VycmVudGRpY3Qg ZW5kCmN1cnJlbnRmaWxlIGVleGVjCtnWb2M7hGqXtoapfkWj0KoFKgFCZ7eQ TrPA070Lg9iRAWymyktxKt6yWPqrmhMO5gXmH3f8G3OKvHxRzUbvgXGQmNX+ 5nZg5pp6uRtY8ppNeeVwIveD6w+7ttT07DUBT9Ley6mUWaTFnfDG66FQKERU 5wfcIQDBW3a0wZuENjdYRppsVYeFsiYzIVIQmHGpiDSH3XcQlJIE3c+DfmqH CLgr2/FvvHUS+qMIoJP+XwNkzVZg90vulnkN41r6kMz3ErGAXaiK43WgTZlZ jq38YlvcH5wxW2zyjJvUJ/MsdFyZrr5w2q7UnqRa+U8IGTSqR4lKNw1pirq9 pCFVALGQryZ/z7fdorxoYFpO9h7Mo9YcaEtH/7WIejvt4LTTDo66vyCYDCMx JhjrDq8omykk/0ozS4XZj9aFRf2ttH+ZHnOQsQ7oakalr4hmwBAiUCTV5YYt Sd612OzLldlCg8UKNj1opJBxRFYQ8DzjYAlFEYprwLOqRZMQTnJyYcaMSkf4 Cdd+TPJ7NoH2tvOsSY5FNhv54B+vVSf148x5DTCEZ0s+JilvPgMyG1xVXSRY V4qJ5y0xZqPF10Czq7Enz0IMMW35V4c9oEzw2yWnNXSk3i5PLV1OjgtDBlTP fzQaG9s+JnfBlHZOrVjFhfSe8QhD/gIPn9/ZAI1mDeULm9eiqHKZvDGeZteB EBu5VuMGQ6Gbk8iWfhrkcZ8wC/5YZvDW2l7FXhcaJNO3B++jJdR/Rzdk6ZvI sRCNgVzyrK36bEZj6DCFXWc86Yq3j1+Cn3+iJqtX8Hs+fU584w7Tt+sNMDXF FI2o2fo0SDQU/ajj3J5sR54+7poRoFR/yQhfpGMa0ZzpNuBZjjGXIH+nu25V z9Xvcq7BLZqWdSQceaNms83ST8+Dubs0bo5BAHmS2LpJTnoAKzoX086Dq7XO gw/Qj/7qfRQ9zHweHnpgx3bZKwGZRHsu9DtGAFeRTEVjNs7F5W8d6Cwezxb9 CCBlJtj2jtu6gUjqf+AAlh3Q7c7XFaqlBb4lJmWHtSvaIG89lxLnzQC6J6gB Yec5sNyuOxotz3NnfbZsM7RLP8tTgI4ORWhBcjuy+6F9NdmgvNj165W3FYGO N18XS9+UWrTBiW4rgL21GZ/nC0vODnepJBtaiGTr8h521Kx8zWTJFS2qh7o0 zcsGN1047zOlTXDW5PkvcXpODRlojfSzcXidcSYpjtxvbNVyQzQUbPr7/KHJ TJmJdstuELvUcXhwk/LsfyI6N33K2udKqq39OvoXryJ3Vovk6OQUKuXqUUjN IVt/12HnKg6x1gfXoCHRFqpQafkso+lWljxXzqeE7536WRzz75zSiA9YolZ3 Y3Std9EL3wOiVqAB7ikrLIrPDFVdA0fxt3YkLZi1NdMXftr+YkLLCD1PZ28O OJ2ytL/N/YgxWCxqDt0fSiWAgWK1cn1AAzClaUhL3eWOMSFrE116vjuXonLz /sMYC7QaQFRFK70AcxhY5ZIOQjS2g/1SY0FKzIXt/sd2esgRw3TEtzbWl6DB iXK3+4GOnB91cVUBOodeboIaQRs4ae8rZw3jxtTMarU67V2fSADDLPxiJvXI zbmpa3AlSryIBoZlApzTC7eS2g4mVrhkO/LQPuMbU80Tp1INHlXLBF7waLO8 GjhLCWuYU/yhuNpSfEfS0Z3mK5U3jW4JsPRLp6pfaYPxt/eqX8E4b7ry6+1R XSOsqlU0okJBw4yuJceorZxBzsAjmrzZhFgp0bQZiPBdZaYHKN4f1/UtrTTu wteGy2j7tIc6c9venrmm2kY0c+iKmc+Q6pIqPmGR5pfvr8FKhoPbOl16mBg0 +JOlPYswkw0891U+/kkc4QL69xYSkaXaoWDnCZdVQAyoYatuv/TdjC/YQW4d OswRcAbqmlU0+TQChGULDoNrlCkxoT0MzPGFuQevlQXptdpWPrksGKqiM+c2 sVtLC7hw40JKyeW904ZqNkE5lrDd5RNwc6uZ0jScqf8v0OR8NcEyVZs87T7O Y4I7ZjheZvrdHoHvGKv7usles5oQYemuZj2nmAVqxm+L1wduAL5w6ffsaEKW cDZN7O+1+ZCsi4HSX6qAb7ltnEmvHH0rZ+TexQ3Vsh/WP8Pi7S4EKkjg3VMW OzmajEBBmywt55hIyh5UVdAIHw+FC+fDoJZ66T0BbPKJyXEb6MuMgQ8qQqaV wMtsSfGFO9G6REjn6eMPxbGx+1iWRhGTRRRf3gdUA1RKYI/MJNYVrTcd135P xqV8ZxaA6KGHEpj2ELFQyouAVJ5riiLPSqHUNcwR0d6iWsmUm2aJK4z9exvU 10YQg11rc4CJ+QAcpdiCQY2AmMhlisqJAay6zsPsvAiY615rMfaWM+4KhRR9 MLo+DRzxRQmr/uZEiI/sCR/muv/lXSJxa3zKTevNy1q3VW0XwdWBkOz20F+u 9zY4uPZiRBFANc5u7mETz0kU5CC/UwDLH0488Xjw/ImA5gtpMVlGDwpa7En7 vFZ6UwUR6QTfoEJUlc70wGSrDrrdm5cj5IHBwSVP2AJcP69c5PfQE2iPfB6R Zgu91avyScfMTTGHT3d592jJ1PNu2ns5yhfyBucc4fOX7UXHFtCk/Bbn4V34 ruyKP1oIv9ngg5EPBHjpTtbyRiD8XIJ5LiSGiFgiERT2SyQXG4kureEgi13M hB4N84It4y8k5C8U2M78YS0rmGZAAxbbvsK+e5qIA1bOHa+s0iW5+LIGp91e rdYPIwg+Uwy5MsO5UQKcBT3xaEaTeCjXC/bS/99jD0BqX7QfL1INgZNmbVGi NH7logchrAMTMYVpZjzhKg2iNdevExOmO8D4bdhYjCss/a/5VmZfTqnXXvCD KX2DS7TrcN5HFWOzqpBdIOUVG2LUNb8UYX4mwJPRO0MSTBcjFm+eVYOQlOAi /wmUYPsXWcR1vSvemo75Zal5+ylBft8qLUlHCyTWj7xPXh2mXnJkkq6MxLRn 43SteirCySLZYoulhktPTC2oTO+xQ/LqoHVj/4v29euzF5ue94MiQh+h6ZQN 6taP+yGHTlB0mRMA19MZBXuPHRcBvbzRycLqFxf9k8Klimhzu8PottTYwCo8 t4p3RI5+//BAeYikO3MzHvDGERNCsMRiB48L5fvm7d+NkXBiqS+HOoXMdlJp f9lesSzlLEg+n/8+FZ4ySalgqNbTz7OXsiXEvgrhtITII7jhmPD+lzLlY+DT FseAu+QnHQLDU59Z9Gb4WJ4lM8rAqVs7iGfQ7wEnnzB11FZ5Txrxzqp88U4I Ji+Ckwe7jtq+cgJ9YxeEIcjiHyeXTkPeqrCmtwkGHPsoTytzFSPHGuWcuxh8 nJH35ZXY4HYCgt2QMpCtBfhaBiniSOsUpDKBMGN1cLHGXVX9GRNVENYFd9Qd MSls9orz+1M/0Y1aWsTeHxNywF46le7DgFw3KWepBgEfZ8d6WiexEtCiOL1U 2Wx8aDqRMEQUfQRKjeMT8Yalkfky1QXAbWCF3zZtY/zCtHUJ+Esj33mHRJVL zdbeXpeZV08P+gmitIgVTGXa8VgWx3zOvi4Sjl6aMHgQn5qzpfwgKHL1UOKp m//X7ZQ0qpW9yQsWiBOW8C7ijSgCCzLBLmfi9zkgpdctV/mJNY9M0eQOIiwq RlSKPDQVOsEXzbBD8Ubg5paq2KccvGx+PTZm5UHCVlIUza6mGrEJndLCa4Ea 16Dll6ZA6RvXB8/pw0uI8G8/A954oR3YDa0nB1ukrx2R6ATj263x6GHMn55c q0AmofdZmM969dwrLBI1Z3kMZmDNqA+k59MCODlBqAU7hYmYi2ZF6YikcKyW JdsiDN0RBLVV4URVo0t+5CZEgj+iaNkJR4g+xef2e/lR54arxQHTDHF7mYoF qc881xlWu2Eo3dTQtqRXz75vXW6ZVUwNKcyV6heKfmFmz1YKoKtJvwVHWjST /o5QV5BgRDkQ8JE0wVfZH1Vgk+l+Urgm4tfCY2ZPKpfXq7T4+GmWqCNePXdL chuKabyDoTuwLU354b/L2p4EYeBUMAQhZdJfFbSRkhOZLXNz0+BpZYuHImWQ EjbopAnQTHOcdWv6B9HwyS2mMGwpouhn2e3H2+wB6jt81VgPC9F6xp8phLHt PuycyKZzZpMeEwb3LJNP19edJJQ408/uke/+n+bz3kMCiHYkF/YqMgyQ7jpO e5JjpA8BXZJ2mxBHxxP6tp4w96Xg5aSoQoBWPitTaR16ul7YnbUyuTNr11/2 SAVzDprZ2NbA3zfy1OZzYDxPsNNccg6fBUhkSITJWvjDeaLjbWAQtUG/annY 7z1y+IvCctBAx0QHoyXN7nMBxs93+EfuA0SRBY+ZsAa/Mio5iHg7szTPmcj2 aiqVrNbzY0MpSeuzYHHUliM5I5jtOMsnZ5mpBFjuy9c2qkoYi1qZ2EcmDW+i rkPacuc32fTxiLSKNe72sAKUGGtA62X2znZJ7yAkJgjMFs0j3sQBnWIJlBeX 4YcKnDQvSHUK9P6eeZC7DrinKNW1n8ytH6whSJe5smCoSJIrc/uU3twT48gs yh1paknD9MeXMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAow MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNsZWFydG9tYXJr CmVuZHN0cmVhbQplbmRvYmoKNzcgMCBvYmoKNDkzOQplbmRvYmoKNzggMCBv YmoKMTAwMAplbmRvYmoKNzkgMCBvYmoKMzQwNwplbmRvYmoKODAgMCBvYmoK NTMyCmVuZG9iago4MSAwIG9iagovRVVDSk5BK0NNQlgxMgplbmRvYmoKODIg MCBvYmogPDwKL0FzY2VudCA2OTQKL0NhcEhlaWdodCA2ODYKL0Rlc2NlbnQg LTE5NAovRm9udE5hbWUgODEgMCBSCi9JdGFsaWNBbmdsZSAwCi9TdGVtViAx MDkKL1hIZWlnaHQgNDQ0Ci9Gb250QkJveCBbIC01MyAtMjUxIDExMzkgNzUw IF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9maS9jb2xvbi9BL1AvYS9kL2UvZy9p L2wvbi9xL3IvdC91L3YveCkKL0ZvbnRGaWxlIDc2IDAgUgo+PiBlbmRvYmoK OSAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL0ZpcnN0 Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyA4MyAwIFIKL0Jhc2VGb250 IDg5IDAgUgovRm9udERlc2NyaXB0b3IgOTAgMCBSCj4+IGVuZG9iago4MyAw IG9iagpbIDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUx NSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1 IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUg NTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1 MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUx NSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1 IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUg NTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1 MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUx NSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1 IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUg NTE1IDUxNSA1MTUgNTE1IDUxNSA1MTUgXQplbmRvYmoKODQgMCBvYmogPDwK L0xlbmd0aCA4NSAwIFIKL0xlbmd0aDEgODYgMCBSCi9MZW5ndGgyIDg3IDAg UgovTGVuZ3RoMyA4OCAwIFIKPj4Kc3RyZWFtCiUhUFMtQWRvYmVGb250LTEu MTogQ01UVDEyIDEuMAolJUNyZWF0aW9uRGF0ZTogMTk5MSBBdWcgMjAgMTY6 NDU6NDYKJSBDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmljYW4gTWF0aGVtYXRp Y2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCjExIGRpY3QgYmVn aW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVnaW4KL3ZlcnNpb24gKDEuMCkg cmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVy aWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZl ZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01UVDEyKSByZWFkb25seSBk ZWYKL0ZhbWlseU5hbWUgKENvbXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVm Ci9XZWlnaHQgKE1lZGl1bSkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAw IGRlZgovaXNGaXhlZFBpdGNoIHRydWUgZGVmCmVuZCByZWFkb25seSBkZWYK L0ZvbnROYW1lIC9HSFZBQUErQ01UVDEyIGRlZgovUGFpbnRUeXBlIDAgZGVm Ci9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAuMDAx IDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAxIDI1 NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCA0OCAvemVy byBwdXQKZHVwIDQ5IC9vbmUgcHV0CmR1cCA1MCAvdHdvIHB1dApkdXAgNTcg L25pbmUgcHV0CmR1cCA5OSAvYyBwdXQKZHVwIDEwMCAvZCBwdXQKZHVwIDEw MSAvZSBwdXQKZHVwIDEyMCAveCBwdXQKcmVhZG9ubHkgZGVmCi9Gb250QkJv eHstMSAtMjM0IDUyNCA2OTV9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDAw ODMzIGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK2dZv YzuEape2hql+RaPQqgUqAUJnt5BOs8DTvQuD2JEBbKbKS3Eq3rJY+quaEw7m BeYfd/wbc4q8fFHNRu+BcZCY1f7mdmDmmnq5G1jymk155XAi94PrD7u21PTs NQFP0t7LqZRZpMWd8MbroVAoRFTnB9whAMFbdrTBm4Q2N1hGmmxVh4WyJjMh UhCYcamINIfddxCUkgTdz4N+aocIuCvb8W+8dRL6owigk/5fA2TNVmD+E/8B vCAUj5xIC80OyB1b/GbwSZPdc/C+CrE/U7G6ef5fYYpPZysWwGvjJR47y1mb +g5gQfvVWEdTcNaTqVklmiaZum6Xz0BDW46KS0JjQ+FF3xTlkCjU4JQatTfj QCTmzeDqmvgDijJgoDWN1bHbU1gvDat63inPjboJktWpRnLf+RVz842b/RpX 4WHlLaG0FDPIImHkf3mZffYDk10qGHqV96JdFI+zwraqMmuYLDLGslhnhx7X s44VADGj3laMjTcxp3nqrwmsXObFoSnEFH5WiCuAaN83yXx2FpTxMWr5PjP/ fgsvHyUnNc4Nn3vOE2sG7pZ6vgyN8k3Lv5mHRwLtJStnf0B8s5Z4zIXd/C9F xVK6ln5BWBZe0W/sxOMqxNOz64BG3N03yS/f8fNxC7jvXKNYq6yjPH5ayta/ XcWL38PPCboqOCkdRaTBX/GRb+LsR/3ICRHrnGH101W+38nbF1iFR3Y6xfCx zBLS/7MuCAPTfjKB2pzjbFQzZVUmrPs6MBxW+rCd8HtdBItHaHNI3rlvP5xT zlbd0xK5PTkYzZKvU/uUYYZNEbgBOJGNCxJwxUhzxAEs3m+IbbEbzqBLAj67 Q+DQoGvnJXQdCLnbaIcxpstlaPmJQEQWnxW5L7cd+BIRITBl0c6oh8gZNLzq dP7ezmDdXQnLULS0vigZ/vNoy/prvtDxq8XqkDT44j5yXKv3PiuQ4Y7Ccq8c /gLluFldUTrY/E4inUY1SKtGePGaJtm+99YF65J1qfW5YjmCnqRUY19SSGIO 4wWklQz57xLVUrv/y6zj/6e57AmZnHq/NKyRGCb0gtvkE9ApHm+oSJUOZtwN rF1Dv2N1RgYS2tUsUD3CcDlRZ/L5dB6VIP31fcwkopkkROueMEPZzJWq4j4S CPZtorRKwfWVLvnSB3XF6wZ8OuxNQwWzscNEUER4I581r2C+kmXqzzZIr30l nM8o1L75QMGcd99TQ20BVIxaGbFSG3SMSCKEwbGKD2LC9DfUdtC1JdvW0FSg iOIt0iop0X7LRf+JA0neJ596ktuIgMBR+JyFcHqXrTz18klCjsXVuZ2HzEOG eK1ek8BtOosmPib5XKldIzxeiSdjstEAbA8sxSaKQtg7TxlYhAfACBofuHn8 6YPseLRObtw6Ymz8NQWLdvIDafIPUo844qozaAVNSIFRKihdBpq6J57EXZeF HoCTnFh93X+iJstIYsPlXnSAMcTJOZtbTNalScd2WaT++Weo8n/Ngk9V+f77 FiY8WFu+jgZmooYpuOUntiwN6bVVwW3DVyWAyQ6a+d5hlkvWRsbgvSKZBalE nYryHc5wDpREknD+0gYBYavi3unSMhwrUExp08Ij8UG7JlYLQAmR3Q5FE2d7 NC8WvB294mH4EnD/ZRpDkT5NBwN5xYYTHIbAna5o9e5jNhxE6q8paxnIirkc sEsEuUpFLSWFzjJkYeocK7Ondt6FJrRT2SCptX4w/uIiyov8cB6LDJb9xzfI 5Pcx2Jnpa9xANufmbKBeeXGnSISL+yK9Iuygr3lJBwXsR7a5DQ3gEFgVvEiz St4BiawCJw51sRDVftKD5Nk+YFrNTxLDyHkSXQJTXlQQHtT+1DBpe4XRPo7r MWLgp+cLIh4mDw11mLS9JzV2BObHWbhTaBgs6pVr9M6MLGNpNCDwKE0Av4EE gDFCAr4h6p5TiIDtfmJw2hAdLuC5XFpR71guCpxJ1hjjTOSJAaewBEVvurQ1 ZXfttYM3YBhmt9QpxJhbsdT/uutJo8afdrEUQI4fG0S4LPwW42KE5nlwhlAT +OskwyZGXY7Mn73JDnwzi8UigT2LrTnUTuGNPxe2+mQB2+p+PupOexRyOeR5 1zTafEYhU9CUQCHDuUUkzRbGCkkyB7ONHepmsZVpQqc4TS+8uN5ZyczRZjEj KWpWQR0lNcQos1oolgdKRMhUewQMB+FrMcWohZDu6KH1zpMAGCe88zbD2e+N w0DZNbyJ6Dw4XD1FkjJ7OsUwAarAun8O5RW851xHwhLUIVjeN6iq1v8UD7E6 eitqnkOgMSOo6icpzBXWt1A129nfwbMkEFaihVPq5Z3WJLve6cstRVt0j7Wg 0/Kq0BgnCFOX+jtL9MX4fz4ZRdD0t0pSpm7O+M6HawJtKH2fYtYd+7xJeoEV g7/LPouD0F2kHo44w3eRtFJJsfhwV9ZpiPMhZMDUt4gNdSflSI2rO8KK8pp7 uzKSQfwcFRTE2Fq6oQnzacFdVa9FFBn0wQGGPgME/+OJPI6qateNTYweIc8H TwR0OwWGmLDXR5GtdCI0lvj2ONTWDviJhCLN4NzqdnM063n8thbObnBBWbLp IqqKV93ztK0v+YYnNXKHxWI93/iTJu4Yf4Y6to7OS+SXDRLD/Reuc0SWYvGD xJvxa9lMI7g2sv4UAmu+XzY1Y8fwtSCBJEhSf4P0VOBQkIFhcmHTWwwFiRrB EcaI2Rz/C7jsj5blPPff/eGzTJZWQuAXQ329eqe8hRmJ569nhldmI/fYy2F1 LzMCJRQ22dUHqkBvVZRAVKqOiuFFpsfpPLoPE8iWcCyBRblIuJe/qoMPE2P4 WlEjvon8Wi/BJwdl5oUhu3s702ucQ38eMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAow MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwCmNsZWFydG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKODUgMCBvYmoKMzU0 MwplbmRvYmoKODYgMCBvYmoKODY5CmVuZG9iago4NyAwIG9iagoyMTQyCmVu ZG9iago4OCAwIG9iago1MzIKZW5kb2JqCjg5IDAgb2JqCi9HSFZBQUErQ01U VDEyCmVuZG9iago5MCAwIG9iaiA8PAovQXNjZW50IDYxMQovQ2FwSGVpZ2h0 IDYxMQovRGVzY2VudCAtMjIyCi9Gb250TmFtZSA4OSAwIFIKL0l0YWxpY0Fu Z2xlIDAKL1N0ZW1WIDY1Ci9YSGVpZ2h0IDQzMQovRm9udEJCb3ggWyAtMSAt MjM0IDUyNCA2OTUgXQovRmxhZ3MgNAovQ2hhclNldCAoL3plcm8vb25lL3R3 by9uaW5lL2MvZC9lL3gpCi9Gb250RmlsZSA4NCAwIFIKPj4gZW5kb2JqCjgg MCBvYmogPDwKL1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUxCi9GaXJzdENo YXIgMAovTGFzdENoYXIgMTI3Ci9XaWR0aHMgOTEgMCBSCi9CYXNlRm9udCA5 NyAwIFIKL0ZvbnREZXNjcmlwdG9yIDk4IDAgUgo+PiBlbmRvYmoKOTEgMCBv YmoKWyA2MTMgODAwIDc1MCA2NzcgNjUwIDcyNyA3MDAgNzUwIDcwMCA3NTAg NzAwIDYwMCA1NTAgNTc1IDg2MyA4NzUgMzAwIDMyNSA1MDAgNTAwIDUwMCA1 MDAgNTAwIDgxNSA0NTAgNTI1IDcwMCA3MDAgNTAwIDg2MyA5NjMgNzUwIDI1 MCAzMDAgNTAwIDgwMCA3NTUgODAwIDc1MCAzMDAgNDAwIDQwMCA1MDAgNzUw IDMwMCAzNTAgMzAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAg NTAwIDUwMCA1MDAgMzAwIDMwMCAzMDAgNzUwIDUwMCA1MDAgNzUwIDcyNyA2 ODggNzAwIDczOCA2NjMgNjM4IDc1NyA3MjcgMzc3IDUxMyA3NTIgNjEzIDg3 NyA3MjcgNzUwIDY2MyA3NTAgNzEzIDU1MCA3MDAgNzI3IDcyNyA5NzcgNzI3 IDcyNyA2MDAgMzAwIDUwMCAzMDAgNTAwIDMwMCAzMDAgNTAwIDQ1MCA0NTAg NTAwIDQ1MCAzMDAgNDUwIDUwMCAzMDAgMzAwIDQ1MCAyNTAgODAwIDU1MCA1 MDAgNTAwIDQ1MCA0MTMgNDAwIDMyNSA1MjUgNDUwIDY1MCA0NTAgNDc1IDQw MCA1MDAgMTAwMCA1MDAgNTAwIDUwMCBdCmVuZG9iago5MiAwIG9iaiA8PAov TGVuZ3RoIDkzIDAgUgovTGVuZ3RoMSA5NCAwIFIKL0xlbmd0aDIgOTUgMCBS Ci9MZW5ndGgzIDk2IDAgUgo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4x OiBDTVRJMTIgMS4wCiUlQ3JlYXRpb25EYXRlOiAxOTkxIEF1ZyAxOCAyMTow Njo1MwolIENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGlj YWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4KMTEgZGljdCBiZWdp bgovRm9udEluZm8gNyBkaWN0IGR1cCBiZWdpbgovdmVyc2lvbiAoMS4wKSBy ZWFkb25seSBkZWYKL05vdGljZSAoQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJp Y2FuIE1hdGhlbWF0aWNhbCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVk KSByZWFkb25seSBkZWYKL0Z1bGxOYW1lIChDTVRJMTIpIHJlYWRvbmx5IGRl ZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIgTW9kZXJuKSByZWFkb25seSBkZWYK L1dlaWdodCAoTWVkaXVtKSByZWFkb25seSBkZWYKL0l0YWxpY0FuZ2xlIC0x NC4wNCBkZWYKL2lzRml4ZWRQaXRjaCBmYWxzZSBkZWYKZW5kIHJlYWRvbmx5 IGRlZgovRm9udE5hbWUgL0FYRUFBQStDTVRJMTIgZGVmCi9QYWludFR5cGUg MCBkZWYKL0ZvbnRUeXBlIDEgZGVmCi9Gb250TWF0cml4IFswLjAwMSAwIDAg MC4wMDEgMCAwXSByZWFkb25seSBkZWYKL0VuY29kaW5nIDI1NiBhcnJheQow IDEgMjU1IHsxIGluZGV4IGV4Y2ggLy5ub3RkZWYgcHV0fSBmb3IKZHVwIDk3 IC9hIHB1dApkdXAgOTkgL2MgcHV0CmR1cCAxMDMgL2cgcHV0CmR1cCAxMDUg L2kgcHV0CmR1cCAxMDkgL20gcHV0CnJlYWRvbmx5IGRlZgovRm9udEJCb3h7 LTM2IC0yNTEgMTEwMyA3NTB9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDAw ODI5IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK2dZv YzuEape2hql+RaPQqgUpcxyZp4TMvoW0mTsu6947EtRyt89UZR7yEYURammr EJbtS60vZGY14Bm2QXzHe1MvhdgRxw0UKaGaUwfvY+tcXgLIn8bCD22diefZ H+Rwtyvv2iP133a+Ba9M6TE3ohntigSp19b9835rf83g2QuYZCPllgpdn7tM lWVW6N+Qy/rsR2+jb9mlyBdcmvUT/tkZwt3Sa9wNmTmLn00D1qjwW0evle8o qcVh29yYxHz1UlAD89vlvwey6D5mt/l93Xzg7rdaeL2SJ781nQAratuKxXoz /tTvAhpwhbHiuTPeYC8P9xRn7NUBdErjOK8poCb302isbyXMuILbe3NDVmGS vWh+E0kiWYKCMCfTtmcDOw23p+aApoK5gCPTnH+ugaXVuGegpmyKoNvIOxWW qE8ENqxqeQC3Z73M4AYKSBEAPHn9zHHXP38tCmZ16TrSGla0zY73Xu096MCh i+v3udG+clBIctVu2ycvHpf8cmy2aMhccTBZ2hn2wuDz4ScQpZtvxGma6IPe jIYVtykqwlzVcUts+xTvDvEesTAJvrpPNFpdPW2ZJqvCutfbEyhlHkN7+zxG 2ntiIZZg/DaM89NwTa06tGHCj3EWZb9IS/YcBSCT0jHKZWGOpGPWPkBuzoWN GApsBYmy/twyE3HCjnfel01lXfX/fUHtAf5xfZKKiF9vps/k0sCAf45/k3kW 4Jbt0aO6Z4ArH0pJEA51YTugNW2dy7rU2rPFnnCkcFj1IWPRcw8O5NH4fDpK 5yOiPP15hvxPvTmTR+n1lGNU4BPYYPxEav8LB0T12ifMd3yWrbOI0eg13cvh I/tRdnm5t+5aPd3NOSQVr1jOIupVt/RwMROMbyd5i0D34Y/dMVkSvpnzOt4P 3VOKij5d5Yr2ilRzKuafGI8/fgRY2EggVkjL6CDCh63COUUg8Du7l9uJP2oS FUsbf4Ym01zmtw+FJMsSjeh4IaDjLx6CX2xQrotL43+qMYO6TWeOiWzH5hzJ 0CJvw4ucrgk50ZFJ2YeXm5aobraaEFgHq0JmOSkv9fvv8IF/z9XlFT3QMV3r acT3TaA43nIklPJLuVpuLL/hrAtCaPUoimOgOpYsN1FGuSYdqVvO/PKBtrBT zVBoAm7zI6LFvYni1auihsGDbKs82kNYzsqF6jUSCu7g/DeRInebdfzysX02 pkCBS1uHBkaMcK0jSEihNxiMW4cYZ/CCFka1nsy/sSXf4veqKJdOr1IfYyMB pA1fMUyhYDBgoU/Z0pk+Wx96Z4CoZst1ZwrsheNjScECOjs1D6SUseUprvTR y6vP2rrytYVPD5georw9mbCgGgEGVd7SdLiDu4v/1mtQ3NeLWuhA94B5dcA4 8E9ZI1AvnfOFYLha7AGW+DJiy0IRr+KIDcM23gIlO4fEV7dKFRQwR4rgLCWR mTMoG47VKLd3ThDTwpAoKZWzY6fyCZMsHNELylVyS9N49QAnWB31AcMJwOPe Sig6Xx9CPHOzS9DdfYTn9KBVHK5kT+8rpm2CVunJ0AA/7Z9WOj/UBEHj54cx 86Z7zIN14CLkujQpT62usToVMmQm87OxZiBbssVgwJOjvEsuR4+GxVdTaJYi ceZVdQpe+4+J9ZQRamaVIYvN0USvKm+RKwfbqYW8fD06B4UH/lWf1tj1NYRR HAngxSHI+vdevOCrTHOnGTyjg5kuza05rFSTC9LE3pPLsHqWhnRLYqGDV2Q+ Kw+QURYZHVk3YNeFUVEQzw4a24OgbjkR59E/0TkZuhmVvQ1tI042rf4W226p kjsY3WP1LK3NcusZAl511wAteWiSAoBGaZcc1RjxsToxuururpWciWA++rhl ss1N5UrGiC2xMN9LI1say3JhlfpUicujEAIIrLvJh14kDGDQZi19Qo+k1gu5 DZLdJ8Hm+B8MgItnQ7h5g6PiKLC3hqj5w+plI8tvO0kpxPdNSSBXjQUym0l1 x11nfAX2PR5Rgb+UHTuKOiabIt9bJ1HfUXRj1GSdBDZP19WtDN2WA6S6n1E2 azT3zSbxkcAhjl0Lb/q+Ny9+sJEjxtqNQkUVprx8xTgDc8eZNQKCZp0+MfK0 Y4IZ0lC3GCaQDu45hnSk2TgAPXwHipWmjf9PaoWeJDf+36Fa/hRqXfTNNstn sP39MX1Bskpn+vNp5QAgbtUG1xPqwIk+xsPwjIinOjqkhEkRsN+ZRbxDgVye Nqohpr3zYY+fo84cOs4ZsbnzwC/4saT/GONzvS72K73oRPZzMV5ZkNg4IEWA voTPV2LBhRr3ZFlMBCUOpbi5HgD+2MMxX9K6K96PiafrX50AIo2uAkGI3dfc 2Jlz3SUav93IEMbqJJhzJ1Pt2MSv68kBw4x3JyM6zr1yjpstas73DxPd1HNZ o44lHxgwRgYw6aeWEWNOy1tt4J7fw4q/053/C4bQMIUJvND9yCB4lXU6gvtb ROwW6wLvGN5H+LTroqpGJ0js5/qJw+ht/eqYFdirzAvEZ55s3Qp55mKIR/1o nGBo3Bk9fbKurin2hxoxXo39MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCmNs ZWFydG9tYXJrCmVuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoKMzI2OAplbmRv YmoKOTQgMCBvYmoKODI1CmVuZG9iago5NSAwIG9iagoxOTExCmVuZG9iago5 NiAwIG9iago1MzIKZW5kb2JqCjk3IDAgb2JqCi9BWEVBQUErQ01USTEyCmVu ZG9iago5OCAwIG9iaiA8PAovQXNjZW50IDY5NAovQ2FwSGVpZ2h0IDY4Mwov RGVzY2VudCAtMTk0Ci9Gb250TmFtZSA5NyAwIFIKL0l0YWxpY0FuZ2xlIC0x NAovU3RlbVYgNjMKL1hIZWlnaHQgNDMxCi9Gb250QkJveCBbIC0zNiAtMjUx IDExMDMgNzUwIF0KL0ZsYWdzIDQKL0NoYXJTZXQgKC9hL2MvZy9pL20pCi9G b250RmlsZSA5MiAwIFIKPj4gZW5kb2JqCjcgMCBvYmogPDwKL1R5cGUgL0Zv bnQKL1N1YnR5cGUgL1R5cGUxCi9GaXJzdENoYXIgMAovTGFzdENoYXIgMTI3 Ci9XaWR0aHMgOTkgMCBSCi9CYXNlRm9udCAxMDUgMCBSCi9Gb250RGVzY3Jp cHRvciAxMDYgMCBSCj4+IGVuZG9iago5OSAwIG9iagpbIDgyNiAyOTUgODI2 IDUzMSA4MjYgNTMxIDgyNiA4MjYgODI2IDgyNiA4MjYgODI2IDgyNiAxMDYz IDUzMSA1MzEgODI2IDgyNiA4MjYgODI2IDgyNiA4MjYgODI2IDgyNiA4MjYg ODI2IDgyNiA4MjYgMTA2MyAxMDYzIDgyNiA4MjYgMTA2MyAxMDYzIDUzMSA1 MzEgMTA2MyAxMDYzIDEwNjMgODI2IDEwNjMgMTA2MyA2NDkgNjQ5IDEwNjMg MTA2MyAxMDYzIDgyNiAyODggMTA2MyA3MDggNzA4IDk0NCA5NDQgMCAwIDU5 MCA1OTAgNzA4IDUzMSA3NjcgNzY3IDgyNiA4MjYgNjQ5IDg0OSA2OTUgNTYz IDgyMiA1NjEgNzU4IDYzMSA5MDQgNTg1IDcyMCA4MDcgNzMxIDEyNjUgODY5 IDg0MiA3NDMgODY4IDkwNyA2NDMgNTg2IDY2MyA2NTYgMTA1NSA3NTYgNzA2 IDc2NCA3MDggNzA4IDcwOCA3MDggNzA4IDY0OSA2NDkgNDcyIDQ3MiA0NzIg NDcyIDUzMSA1MzEgNDEzIDQxMyAyOTUgNTMxIDUzMSA2NDkgNTMxIDI5NSA4 ODUgNzk2IDg4NSA0NDQgNzA4IDcwOCA4MjYgODI2IDQ3MiA0NzIgNDcyIDY0 OSA4MjYgODI2IDgyNiA4MjYgXQplbmRvYmoKMTAwIDAgb2JqIDw8Ci9MZW5n dGggMTAxIDAgUgovTGVuZ3RoMSAxMDIgMCBSCi9MZW5ndGgyIDEwMyAwIFIK L0xlbmd0aDMgMTA0IDAgUgo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4x OiBDTVNZOCAxLjAKJSVDcmVhdGlvbkRhdGU6IDE5OTEgQXVnIDE1IDA3OjIy OjEwCiUgQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNh bCBTb2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2lu Ci9Gb250SW5mbyA3IGRpY3QgZHVwIGJlZ2luCi92ZXJzaW9uICgxLjApIHJl YWRvbmx5IGRlZgovTm90aWNlIChDb3B5cmlnaHQgKEMpIDE5OTcgQW1lcmlj YW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQp IHJlYWRvbmx5IGRlZgovRnVsbE5hbWUgKENNU1k4KSByZWFkb25seSBkZWYK L0ZhbWlseU5hbWUgKENvbXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9X ZWlnaHQgKE1lZGl1bSkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTQu MDM1IGRlZgovaXNGaXhlZFBpdGNoIGZhbHNlIGRlZgplbmQgcmVhZG9ubHkg ZGVmCi9Gb250TmFtZSAvWEJBQUFBK0NNU1k4IGRlZgovUGFpbnRUeXBlIDAg ZGVmCi9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAu MDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAx IDI1NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCAwIC9t aW51cyBwdXQKZHVwIDQ4IC9wcmltZSBwdXQKcmVhZG9ubHkgZGVmCi9Gb250 QkJveHstMzAgLTk1NSAxMTg1IDc3OX1yZWFkb25seSBkZWYKL1VuaXF1ZUlE IDUwMDA4MTggZGVmCmN1cnJlbnRkaWN0IGVuZApjdXJyZW50ZmlsZSBlZXhl YwrZ1m9jO4Rql7aGqX5Fo9CqBS8J+cit6dkHwFi4fptpZH1TNZ5RIWd0pOqh 4rWOwxdr0RhKYzuVE3K0GY1OjF70ohOstYqgpliQgDW/LthTF3mDipYN/isn 6knDcVaYnIXiGzq/cuOaiSMs2fQjf8gMnmToQlqjvvfe1gsSKlKSKiIaN9mo B90BFhd53efV/BshCYOeW1Lfuyp8G12OfoqgWxDqQ9ao7WGvWyPUmSDY952r alkGITTYSsAQAYemzR+A9d3Z0iKsscIzJqdlamNcSiQczTLL/fg2Mga4qjbh BxR39UlhEeBVx0kQAq/ycuRuzEZCLwOA0JMoSHACJSP72hcWzE8uLMrV8XP8 vm7duHStJVzV5cD4YhQ5P8tfXCCcPCu1iG42/DzMIUg8OsGTSFpG6dIr1yAY lOTUWt2b8cxc9qUBC1ZUrAvg2pA9tWOxOEC6MBX3LlHjvIAVfj4FBWav9gtT EP2mZvGrL91AHc0KrZI2m/qKTd8rihwcRV5vqCHUR4nHLI9WvslXj4ryZAKc nQcgtCHbkk/RSavf9H6j/U0QVLvCtrFpiRotBkRKYZMFYq8om+Oo7xG0ahnd oK1ADpVYMlhALAdUf9K7hcHqtcZyWOtBTQ+nhyDjZxbDKMch0quHwbQ6pPhU Ioi/W7n4RKHbcz/hSoWtGh3uMJTWosPe+DB7s3IQyASOLjwE0zaQaWweBfUG OPSMZR7tl6yym69hK9dapeejK7XNFHnvg8SWg1Wgh48C8ZHsB924rKgPX+hQ UnYLKnomoSkY2xlihSa7SDyZ7IHYeyxZxHN2P5W2mBReEzJcIOMGW3bEZcRA dmr4hk2N7Z72juoEXZWQG8iwW9QUYhrUOs5MSQ7yasOfJ1q1huK9DLfpKdj+ iUuN4F9xjLFoUN9HfwOF9dAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xl YXJ0b21hcmsKZW5kc3RyZWFtCmVuZG9iagoxMDEgMCBvYmoKMjAwNwplbmRv YmoKMTAyIDAgb2JqCjc4NQplbmRvYmoKMTAzIDAgb2JqCjY5MAplbmRvYmoK MTA0IDAgb2JqCjUzMgplbmRvYmoKMTA1IDAgb2JqCi9YQkFBQUErQ01TWTgK ZW5kb2JqCjEwNiAwIG9iaiA8PAovQXNjZW50IDc1MAovQ2FwSGVpZ2h0IDY4 MwovRGVzY2VudCAwCi9Gb250TmFtZSAxMDUgMCBSCi9JdGFsaWNBbmdsZSAt MTQKL1N0ZW1WIDg5Ci9YSGVpZ2h0IDQzMQovRm9udEJCb3ggWyAtMzAgLTk1 NSAxMTg1IDc3OSBdCi9GbGFncyA0Ci9DaGFyU2V0ICgvbWludXMvcHJpbWUp Ci9Gb250RmlsZSAxMDAgMCBSCj4+IGVuZG9iago2IDAgb2JqIDw8Ci9UeXBl IC9Gb250Ci9TdWJ0eXBlIC9UeXBlMQovRmlyc3RDaGFyIDAKL0xhc3RDaGFy IDEyNwovV2lkdGhzIDEwNyAwIFIKL0Jhc2VGb250IDExMyAwIFIKL0ZvbnRE ZXNjcmlwdG9yIDExNCAwIFIKPj4gZW5kb2JqCjEwNyAwIG9iagpbIDYwNyA4 MTYgNzQ4IDY4MCA3MjkgODExIDc2NiA1NzEgNjUzIDU5OCA3NTggNjIzIDU1 MyA1MDggNDM0IDM5NSA0MjggNDgzIDQ1NiAzNDYgNTY0IDU3MSA1ODkgNDg0 IDQyOCA1NTUgNTA1IDU1NyA0MjUgNTI4IDU4MCA2MTMgNjM3IDYxMCA0NTgg NTc3IDgwOSA1MDUgMzU0IDY0MSA5NzkgOTc5IDk3OSA5NzkgMjcyIDI3MiA0 OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5 MCAyNzIgMjcyIDc2MiA0OTAgNzYyIDQ5MCA1MTcgNzM0IDc0NCA3MDEgODEz IDcyNSA2MzQgNzcyIDgxMSA0MzIgNTQxIDgzMyA2NjYgOTQ3IDc4NCA3NDgg NjMxIDc3NiA3NDUgNjAyIDU3NCA2NjUgNTcxIDkyNCA4MTMgNTY4IDY3MCAz ODEgMzgxIDM4MSA5NzkgOTc5IDQxMSA1MTQgNDE2IDQyMSA1MDkgNDU0IDQ4 MyA0NjkgNTY0IDMzNCA0MDUgNTA5IDI5MiA4NTYgNTg0IDQ3MSA0OTEgNDM0 IDQ0MSA0NjEgMzU0IDU1NyA0NzMgNzAwIDU1NiA0NzcgNDU1IDMxMiAzNzgg NjIzIDQ5MCAyNzIgXQplbmRvYmoKMTA4IDAgb2JqIDw8Ci9MZW5ndGggMTA5 IDAgUgovTGVuZ3RoMSAxMTAgMCBSCi9MZW5ndGgyIDExMSAwIFIKL0xlbmd0 aDMgMTEyIDAgUgo+PgpzdHJlYW0KJSFQUy1BZG9iZUZvbnQtMS4xOiBDTU1J MTIgMS4xMDAKJSVDcmVhdGlvbkRhdGU6IDE5OTYgSnVsIDI3IDA4OjU3OjU1 CiUgQ29weXJpZ2h0IChDKSAxOTk3IEFtZXJpY2FuIE1hdGhlbWF0aWNhbCBT b2NpZXR5LiBBbGwgUmlnaHRzIFJlc2VydmVkLgoxMSBkaWN0IGJlZ2luCi9G b250SW5mbyA3IGRpY3QgZHVwIGJlZ2luCi92ZXJzaW9uICgxLjEwMCkgcmVh ZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHlyaWdodCAoQykgMTk5NyBBbWVyaWNh biBNYXRoZW1hdGljYWwgU29jaWV0eS4gQWxsIFJpZ2h0cyBSZXNlcnZlZCkg cmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAoQ01NSTEyKSByZWFkb25seSBkZWYK L0ZhbWlseU5hbWUgKENvbXB1dGVyIE1vZGVybikgcmVhZG9ubHkgZGVmCi9X ZWlnaHQgKE1lZGl1bSkgcmVhZG9ubHkgZGVmCi9JdGFsaWNBbmdsZSAtMTQu MDQgZGVmCi9pc0ZpeGVkUGl0Y2ggZmFsc2UgZGVmCmVuZCByZWFkb25seSBk ZWYKL0ZvbnROYW1lIC9ETEVDQUErQ01NSTEyIGRlZgovUGFpbnRUeXBlIDAg ZGVmCi9Gb250VHlwZSAxIGRlZgovRm9udE1hdHJpeCBbMC4wMDEgMCAwIDAu MDAxIDAgMF0gcmVhZG9ubHkgZGVmCi9FbmNvZGluZyAyNTYgYXJyYXkKMCAx IDI1NSB7MSBpbmRleCBleGNoIC8ubm90ZGVmIHB1dH0gZm9yCmR1cCA1OCAv cGVyaW9kIHB1dApkdXAgNzEgL0cgcHV0CmR1cCA3MyAvSSBwdXQKZHVwIDc3 IC9NIHB1dApkdXAgODIgL1IgcHV0CmR1cCAxMDcgL2sgcHV0CmR1cCAxMTAg L24gcHV0CmR1cCAxMTQgL3IgcHV0CmR1cCAxMjAgL3ggcHV0CnJlYWRvbmx5 IGRlZgovRm9udEJCb3h7LTMwIC0yNTAgMTAyNiA3NTB9cmVhZG9ubHkgZGVm Ci9VbmlxdWVJRCA1MDg3Mzg2IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVu dGZpbGUgZWV4ZWMK2dZvYzuEape2hql+RaPQqgUpcxyZp4TMvoW0mTsu6947 EtRyt89UZR7yEYURammrEJbtS60vZGY14Bm2QXzHe1MvhdgRxw0UKaGaUwfv Y+tcXgLIn8bCD22diefZH+Rwtyvv2iP133a+Ba9M6TE3ohntigSp19b9835r f83g2QuYZCPllgpdn7tMlWVW6N+Qy/rsR2+jb9mlyBdcmvUT/tkZwt3Sa9wN mTmLn00D1qjwW0evle8oqcVh29yYxHz1UlABHRnpNm62/RU9OhAMqmIS49XZ OZBzf40ybTR7ftxDkcnfRAKFuPwVnQ6Y1CWPxXiS3MV/eQNEngeRT76eZzwV whU8Bh61QfZsEefud9XXfAsR4axVEB2pdsysq2mT7tFAb7t/8w6snpC5Cyr0 7HwnPKMvEaXBQm/2QbSi+y9OaGNck9uDVzdWf6+EccvAUHjc1OQOJaL05a9G wjTPWSoc6POeG6GypZQ1VjfkdBZ+rU2X1RrwqJm0Q4fh/ZM6Mjr9prp0BTSl ELRwXAoVZHr78+U6gr8yDdlnU2Ob5JwveaGYiGPvl3uADJ21tCA5wj64aVNx P3MOA+oi/3uywdl9M/13sb3MKmCxLPeAXPyQxbkUwPMKZz35WH+T5HzqWTLd GTBWDE8Nl1R7zYBdbYVEVbE6TXOCoi9WLXxVBB8P0pS9qhg0gg+JQmWmZ+XJ fZX/FSUx75clj1Y3RQKGXaHnwMX7fG+308Q/6zQxCVpZ+/b2HOxtbe4J9OsP 1w13KosKSYTGEgKT9rlHlEviMln262QwPWJzUxY7ZQX8imAAaB96OWi2y7Se BCCmkSWPXnsHtBcVeAP8vpufsfgP2MoKJ2l7XQQm5eENOWM8DNjpVZD0NmME rLTr3o+2KPHTPk/BgzGZc2IRyT5IykHSnvIjQdfNh9hpGDu8eVofWbTrkUmz RyCiCfkGMuVvz2cjIbTlf1xT4VI4qT9T0u6oVEfxQSft8BCU3PgKpTsljmHx EQnM3CXZOcAbOLKP2a6m+p8oC9jD4DVFnKX3Peb4IMdXIjLrYt4n2iuKfesa wrsqiAGiPyli0FUHh8JFNUq9Aw5oDYkJA0WMvi7NpaLmccEMrL9Y6fEdWhSd r/VVZ4oU7vP2VF66AZwu4dC4YN993G8+LMjbZZyCLHloW2ePCiCVMlp6wW6Y AFujb3KgjhA8/Y5pRB/hH1brdoLJKu3e9/HiNl8uxdUqzZbKkxikAJjPSxPj KQkcdgQr6bLt6jZsRqlr3doUEU+nIgif0MYj+0mNuxNqxuNpgAogp2HFysKo XbdCm8JCon24/rp4npSdoI3VbI0Xc0sFLEMitnIfl0YaSgFms64GcCdkx9q+ vIM/GrqEKOe/UDLG0zh+Emi4/o+Bi+1FgRwAsUbS6PeUwVRvY3O+hHZ9r5dZ qrnRc1VDBkVqLwDre9GZpsghdrlkJ043tFX7irDHg9XbXOenpB4X+qSNpTz+ k4y8FDYJPl8htl2HKGyIsvTvuJ/FrY4bPd59OjhAfPzUXG3D2/Rsypvc77Rv PM+STQ1mAFnAAO1+Q06PfwAIGgyRHx7tsIBZ+KhaGrQYdEjpizxljZuiRdi7 3dz/25YOxTzE6+DUIdeGPG81lSfSrQ8TZGAKQwVkdt6aF6NxvHsUH8H2mZi0 aH2lqAIeOEap4AZwNoBeIPAVhG28ssaQFh6Hc5uHvSOzVtDkT5nl7HlsQsqa zSMz0G7sWbr0oBFlRqnZYsF8yinbdc+TZ+sVfIlj0RGHnaJHB0Flp5RKrt+V 9IBTFgGGx304GKrotutwzrOvxc7oajk79z+zmJUtzOHwu6pRCpxZytOoyj2V rjbC1rp9oSVRXtzuBXRUPSamLTe6plQazGoxdZWjg0GckJgW3ezDXw/VnQzs xrWJ/HYG2nEmnWR1lzO4tvN4aVta7ZO3QwVC8Iuj2clEalJgryuJeR6YT/K6 Q8jqOxD2iD/mT+rn/WSnvSvYRNM9ZnlazF3LJWALxc33usFu5wEkr8yvmzKX DqN5YURwCt5yXr8UKo2rbZTizVCDHMZq6jDqOe9YwvJRo6dS+/gMAJ2vEvAh jXy65pI3PMoUGdJJmYlUW0xS7ylR4qawAoJNSKlB0igke+fOfnIGxPBEEqlw Ad4pmN/0lc7Ykz6Y9f92xBhNTGnzhLcsnzm9hbX1+pGGITzIii4JE/06pVDL 3t1hlQ9VSFEqeGEfQMw9w8xRAtp3aFx9pVxeC58Bbo7w8M+bJPFFaba6kmqY /FyfaY40C+YjFMdV3cRkCJd1cB1krR9x1sxv8FRpudrogIxN1G5lMhYu7KTc HB+YH163UP7VLYRWdrQA0A7r4xZJxfPID/PLwqwQ4PkCn2gpyCYRxdyAWC1P iv74BmlVcBdtqBX1iB3unabHJmMTQkumP4VCbZRDhNHAAxMPvRdXJ07MqpDd 9Qku1Vjhaht4lkTKyGIutVT33kxMANbaeqEJr8bLf6En9OvLdj/S6rHbVSEY UCBEFkaPIu1e9lpfjWarrZHdqgYDcqHItTQE+d71ga97tEHBjgWGX/chWvAN xqSAnvMqVMVFGLvIDDSyqHGYgr0Qfg/NWslgJGpAU7RQxyYXqiS2gjaxhtZR /lRPO6DP6z+P0QUhep1daGytvtKuHpgSaTLTTf+hDRlBOgz4DWGKm22QZOcb EXEu60BFUJxEmJ/VUCN5PDAfTdkRHvb+G76qa1phPvZAM5k7Pd/9MzlXcA82 WdAkKdcYnd6bVswGUvNM1cAt/6JdiDx+OSvHq2PonNaNbAyYrLoWEcj61IQc z1+cUf4LwJifnvRJXc8UCmRwvSWPnZmpDpDswQCkUF/Y9ksodeoyerKcUX0I Cza1+qcLWM8GuJ6trSYhE4Xsle/825J7B7r4Z6K6wpX7OjIajdsRWdmASoSz MZnUCqkqelQAHhC0BY2yo+9XhEj1QHt5we/ESKqnAyiYG0Ab55Zg3PAwxRJb EX/j++2AHSwYaqGrdklQ3aBcblmQNIe24lLkKtDxmVT4DUafRH9yOxrm14HL Kt6JSYtop16hNk8P2/0FXqPzdLD3wru1Zni9y0wzU9cmnCPDMvEqVxBYpqN4 hiheLb4p4Ktj/F8oTIt/w7sAU7R/l8ekLwBlfTv1HDNRv3Y/ThRmNOsjkgH2 vY6/0fT1cXYvVw3p3MTvHlk3boMZMWsy3P/nSFVtUj0QcUzVAFMjav3AUcjN U9vyjaJs+jYwYBTn1cd/yzYaaIbi+MmkiZv53kkuWhJ5O3Xumun/he/zjABT e6+YbvVceNAEofTNITYhjw+WndQpHu8rxK/QHWcsJSEiuZdQeTGpxDfX50DQ +EO6lO1a8uP9OUbDYPa7Z8yjx5G7+28WAdcuDRkziZVGbYg8t2tX5A34cI2Y W6eV/s0zbvUfbSuCh0zAeyeGIXJp7NcfyHyRZqOmBrSnErjRhF6RWH8Ju4Dh gNS7u3zwBrPJkIjcdFYf4l2r6Z6k8HdM4HhtlF/vGx7kioFi4ePH15MrFcIe 2asTAfMapDzobvvbhh0CltYk85OVFU9ZHPHrkWN7c57RumFny1/KVq39EUWd c/TIjHnsgNC39XTKD93BQselFq7JtMqkWW8BJuO4HtwYX10SxdOVXPNxboLY KmlsKuKPhSo9zSomV030+WeyZEss1BNR8VXSr+qWzB90VHhqu12MpMl5d+Pn 0lqE+L7NkMQB0FyJLztOBBYdPXw8EquN9ugwSXjp7P8sDECUBKzk9w2M1qMG WCTdB8lUOCtgjlr9hJmPpto0v+4KKfpPlCr485oLYRyLGW695vIlAW72rCeh AVJSF3Pbpb+iXyQrKVv7NqEF+WfAhaoin6F877LXpwpNth50hrhG50gm6tgd p6T8+wzvR8yIBwlBc8ScycXhivTvqWluvnoldoBfS4ghBgjteptpyd0jm8hv 3hXua+DkycuAevhgXQ2l/QUvE5bYOuaddlxM66l+ThFTt8hS+xBHEYHD+eDo xecUVLXrBlsLqC9qve/hVAJUBhM86Wl2yNK2VsRfrNpq4+uGryJka4aDrbD6 SXSh9uREGOPZrkqTLSeRnuSfKg0aeMl8A5QRtjWBIVzfrljHQkih6qfxVknk Pf0MFcfCpxB4sSMfRuyvDgcpJRjLiCP4gc0L6IIUJ0I0DhnMKZQG2QzgjuKt 50YjTXkrlg6ZC+ecxxhBZWBacVAyFCkVEMP1zMtOV5Ii9ZVnhV3vJkdaqfHU SDAAOAvRSPLIWqiCJBjkL9zUdF5iYbbRlDJwHRte8q/IqypkHgJ/5nJF2rbU VW+ZvtjXcVpZvvOaxUzjaghYRrfRBudZmtSovY61LJuCq3Oxlw6unjZJ/jzE ZaLj/NQGj+bi9uz6YWKgrOM/5QZZPT1gq5q9P7S/F7yTgED4zRuNLCJJIOw+ ZCyEDW9Dbp0lSwHHSpeoCXChaSsOCFhCY0vKwtuo9rzJRIFUsWedaMUDehdn omeP/A6J0lXwp1VX0Tdo2LhzaKgjsvz4UOzdjdzpKZCteUGudLl67k5upHMb tg621YCtVijcOJxvbHGoNnH5LWm2bzLPxdVl3yr1aDe0dVoRVo8X/zxmu4VY DwyX1OAZvK31uvj8pPhPJtInH6GuNCh7rQKOOosTena8geousTDNasqQBuN4 MpYNhGGtPDFD8WJEKGmOS53D7ag8YbbJtnwCh3JhkW83s8RZWzZbPIxidrxw v+4zSLRhsglWuDHHy8LC47J1hRP205nJ3IV0857bp9mWKc5dSw/UedK0NwlD wCueuZ+1yZMgHLkKKpZhDHZJr8wz2rxF54F5/q1PPQyZfMzQgB+MvMTl2DtK 7Sq+jYi5hAyrt06zwvJjBEPCJFD981g4K4uvHRLdcDrfrl4u+bZgkknFK4/S F+WbLKfhg2rlydTi0UXFW3Hm+Ez5kopvR7zG/tITjiCODJphbc9tHh94NCV7 4tErtZy8WnbafA0Zhgy0YUCuJ60biqk2M/1Gfb/ATP1TklHeUvKFYHNOETKq MDyWRxKh9Pc2kPaehNUi87zJwigLRv42LvwxmHJFR2McjpKcxs1649ciXkun qUOEWlnfGLZfY50+n8ebEXK4F3uMEjujrw79s17mu/Byzh9HshIRIg/Fla7G Rl/P5+DZqX/p4lzHn0uQQRRBVEOK8mNYqU33yrF+TdKaYasB9dL/XEa2Z0Pe eXTAwPUU2gacHjCs6q/Z8wXEvvP8y3qN6UPhN5vagK27pTdnDYLYlo3Lrns1 bNJkDqkQDZs9w5cEzHcNMK0FvLV5M62KQeIwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw CjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAKY2xlYXJ0b21hcmsKZW5kc3RyZWFtCmVuZG9iagoxMDkgMCBvYmoK NTM5NwplbmRvYmoKMTEwIDAgb2JqCjg5MQplbmRvYmoKMTExIDAgb2JqCjM5 NzQKZW5kb2JqCjExMiAwIG9iago1MzIKZW5kb2JqCjExMyAwIG9iagovRExF Q0FBK0NNTUkxMgplbmRvYmoKMTE0IDAgb2JqIDw8Ci9Bc2NlbnQgNjk0Ci9D YXBIZWlnaHQgNjgzCi9EZXNjZW50IC0xOTQKL0ZvbnROYW1lIDExMyAwIFIK L0l0YWxpY0FuZ2xlIC0xNAovU3RlbVYgNjUKL1hIZWlnaHQgNDMxCi9Gb250 QkJveCBbIC0zMCAtMjUwIDEwMjYgNzUwIF0KL0ZsYWdzIDQKL0NoYXJTZXQg KC9wZXJpb2QvRy9JL00vUi9rL24vci94KQovRm9udEZpbGUgMTA4IDAgUgo+ PiBlbmRvYmoKNSAwIG9iaiA8PAovVHlwZSAvRm9udAovU3VidHlwZSAvVHlw ZTEKL0ZpcnN0Q2hhciAwCi9MYXN0Q2hhciAxMjcKL1dpZHRocyAxMTUgMCBS Ci9CYXNlRm9udCAxMjEgMCBSCi9Gb250RGVzY3JpcHRvciAxMjIgMCBSCj4+ IGVuZG9iagoxMTUgMCBvYmoKWyA2MTIgODE2IDc2MiA2ODAgNjUzIDczNCA3 MDcgNzYyIDcwNyA3NjIgNzA3IDU3MSA1NDQgNTQ0IDgxNiA4MTYgMjcyIDI5 OSA0OTAgNDkwIDQ5MCA0OTAgNDkwIDczNCA0MzUgNDkwIDcwNyA3NjIgNDkw IDg4NCA5OTMgNzYyIDI3MiAyNzIgNDkwIDgxNiA0OTAgODE2IDc2MiAyNzIg MzgxIDM4MSA0OTAgNzYyIDI3MiAzMjYgMjcyIDQ5MCA0OTAgNDkwIDQ5MCA0 OTAgNDkwIDQ5MCA0OTAgNDkwIDQ5MCA0OTAgMjcyIDI3MiAyNzIgNzYyIDQ2 MiA0NjIgNzYyIDczNCA2OTMgNzA3IDc0OCA2NjYgNjM5IDc2OCA3MzQgMzUz IDUwMyA3NjEgNjEyIDg5NyA3MzQgNzYyIDY2NiA3NjIgNzIxIDU0NCA3MDcg NzM0IDczNCAxMDA2IDczNCA3MzQgNTk4IDI3MiA0OTAgMjcyIDQ5MCAyNzIg MjcyIDQ5MCA1NDQgNDM1IDU0NCA0MzUgMjk5IDQ5MCA1NDQgMjcyIDI5OSA1 MTcgMjcyIDgxNiA1NDQgNDkwIDU0NCA1MTcgMzgxIDM4NiAzODEgNTQ0IDUx NyA3MDcgNTE3IDUxNyA0MzUgNDkwIDk3OSA0OTAgNDkwIDQ5MCBdCmVuZG9i agoxMTYgMCBvYmogPDwKL0xlbmd0aCAxMTcgMCBSCi9MZW5ndGgxIDExOCAw IFIKL0xlbmd0aDIgMTE5IDAgUgovTGVuZ3RoMyAxMjAgMCBSCj4+CnN0cmVh bQolIVBTLUFkb2JlRm9udC0xLjE6IENNUjEyIDEuMAolJUNyZWF0aW9uRGF0 ZTogMTk5MSBBdWcgMjAgMTY6Mzg6MDUKJSBDb3B5cmlnaHQgKEMpIDE5OTcg QW1lcmljYW4gTWF0aGVtYXRpY2FsIFNvY2lldHkuIEFsbCBSaWdodHMgUmVz ZXJ2ZWQuCjExIGRpY3QgYmVnaW4KL0ZvbnRJbmZvIDcgZGljdCBkdXAgYmVn aW4KL3ZlcnNpb24gKDEuMCkgcmVhZG9ubHkgZGVmCi9Ob3RpY2UgKENvcHly aWdodCAoQykgMTk5NyBBbWVyaWNhbiBNYXRoZW1hdGljYWwgU29jaWV0eS4g QWxsIFJpZ2h0cyBSZXNlcnZlZCkgcmVhZG9ubHkgZGVmCi9GdWxsTmFtZSAo Q01SMTIpIHJlYWRvbmx5IGRlZgovRmFtaWx5TmFtZSAoQ29tcHV0ZXIgTW9k ZXJuKSByZWFkb25seSBkZWYKL1dlaWdodCAoTWVkaXVtKSByZWFkb25seSBk ZWYKL0l0YWxpY0FuZ2xlIDAgZGVmCi9pc0ZpeGVkUGl0Y2ggZmFsc2UgZGVm CmVuZCByZWFkb25seSBkZWYKL0ZvbnROYW1lIC9WRkdJVEErQ01SMTIgZGVm Ci9QYWludFR5cGUgMCBkZWYKL0ZvbnRUeXBlIDEgZGVmCi9Gb250TWF0cml4 IFswLjAwMSAwIDAgMC4wMDEgMCAwXSByZWFkb25seSBkZWYKL0VuY29kaW5n IDI1NiBhcnJheQowIDEgMjU1IHsxIGluZGV4IGV4Y2ggLy5ub3RkZWYgcHV0 fSBmb3IKZHVwIDEyIC9maSBwdXQKZHVwIDM5IC9xdW90ZXJpZ2h0IHB1dApk dXAgNDAgL3BhcmVubGVmdCBwdXQKZHVwIDQxIC9wYXJlbnJpZ2h0IHB1dApk dXAgNDMgL3BsdXMgcHV0CmR1cCA0NCAvY29tbWEgcHV0CmR1cCA0NSAvaHlw aGVuIHB1dApkdXAgNDYgL3BlcmlvZCBwdXQKZHVwIDQ4IC96ZXJvIHB1dApk dXAgNDkgL29uZSBwdXQKZHVwIDUwIC90d28gcHV0CmR1cCA1MSAvdGhyZWUg cHV0CmR1cCA1MiAvZm91ciBwdXQKZHVwIDYxIC9lcXVhbCBwdXQKZHVwIDY1 IC9BIHB1dApkdXAgNjcgL0MgcHV0CmR1cCA3MSAvRyBwdXQKZHVwIDczIC9J IHB1dApkdXAgNzYgL0wgcHV0CmR1cCA3NyAvTSBwdXQKZHVwIDc4IC9OIHB1 dApkdXAgNzkgL08gcHV0CmR1cCA4MCAvUCBwdXQKZHVwIDgyIC9SIHB1dApk dXAgODMgL1MgcHV0CmR1cCA4NCAvVCBwdXQKZHVwIDg4IC9YIHB1dApkdXAg OTcgL2EgcHV0CmR1cCA5OCAvYiBwdXQKZHVwIDk5IC9jIHB1dApkdXAgMTAw IC9kIHB1dApkdXAgMTAxIC9lIHB1dApkdXAgMTAyIC9mIHB1dApkdXAgMTAz IC9nIHB1dApkdXAgMTA0IC9oIHB1dApkdXAgMTA1IC9pIHB1dApkdXAgMTA4 IC9sIHB1dApkdXAgMTA5IC9tIHB1dApkdXAgMTEwIC9uIHB1dApkdXAgMTEx IC9vIHB1dApkdXAgMTEyIC9wIHB1dApkdXAgMTE0IC9yIHB1dApkdXAgMTE1 IC9zIHB1dApkdXAgMTE2IC90IHB1dApkdXAgMTE3IC91IHB1dApkdXAgMTE4 IC92IHB1dApkdXAgMTE5IC93IHB1dApkdXAgMTIwIC94IHB1dApkdXAgMTIx IC95IHB1dApkdXAgMTIyIC96IHB1dApyZWFkb25seSBkZWYKL0ZvbnRCQm94 ey0zNCAtMjUxIDk4OCA3NTB9cmVhZG9ubHkgZGVmCi9VbmlxdWVJRCA1MDAw Nzk0IGRlZgpjdXJyZW50ZGljdCBlbmQKY3VycmVudGZpbGUgZWV4ZWMK2dZv YzuEape2hql+RaPQqgUqAUJnt5BOs8DTvQuD2JEBbKbKS3Eq3rJY+quaEw7m BeYfd/wbc4q8fFHNRu+BcZCY1f7mdmDmmnq5G1jymk155XAi94PrD7u21PTs NQFP0t7LqZRZpMWd8MbroVAoRFTnB9whAMFbdrTBm4Q2N1hGmmxVh4WyJjMh UhCYcamINIfddxCUkgTdz4N+aocIuCvb8W+8dRL6owigk/5c9OnSQFsWnNU2 XW7O1ddo1m1saGGLjEgrNB+Mo46bubr8+q2cLz/QM7YmkJhu1D2ck2E2Rbgj ktXK4Rp8tJ1+LoLc1IXLoEx3Mi6y5qedc9wZTlnBIKLau5v3LizyVt1utU7s uliBAavZM7V86KOg0WsoUddJT3MJbfU73Ga7+Ja1h9+WQzF9X2EM2QiPmEkS byPd4DD3snfdmQVcixGcrpyZFYrE4VDN/Cxm7ZLrtMwJKqoHjOFiR6EzWtMy 2qlQ0gOVpzhMM/9y6qMaW4l2bmNfRcTAaK1+6Gc5jwOBsHy5TSn/CX1Z/5lh 0ZWpSOPYfDGCHpKVpW0hh1tBmI96FqFYcFDDxxtOQ1W7N/JV1rI3zpbyVGf3 D6GeD4V4X/SQaJSczHny+K5X1febucXPXu1dmFe5ln2bls3Pc9XWX/da+rtm c0AYuuJkWXIgyJ/Rc3kmdkqTAtB4tOsOKReMh4/WEAfuot2xGa6IxX7P70tx 5BQKNJUd3DVoqEzJI3GniQIaEDoaNHBQ/abs95A/Z9ITHQx8R0qQU4ZunIjm XmkyuoenNobqsAGTifhNFZgJxJgeejDtlC6yEbANv/W8xyD04nbDM5sxtuq7 sHhDDmoJuzd9MGGiCx65h5a4YH7svGmUReqoZsOOAEILBHdTOtsT/Ds5bAZb CXadrwhxB2+3/Q3CKM8+4RVEbHFZsD8ZvGuP2pG68orTA+JviF7iOIdLEf7o TEevN+hxq1qFsEMZDuhgtkQ8Q+J+oSLx5JJByg07nxJJWwlE2rViqF0IQxKs il+3xNrbcMjR0Dhws45hQGwoHO6kwtYGFeYTL6wtd1ETg33fLe12ifTQ1PWn tjjNy1BE/eIZfOgzjbDB9ZzyVQII+QHhHaBlbWT3JVaaZ13Gq4t6cVL45f3z E4FIp4DxOdc6YYgQ/nj+52BT9UkmSQpTuV+zKEJxKN4Lu8ajh6BxQB9/zuF/ wT3lS1iaBJVMlaU8zumqdHnlkYnaDt+blnkeITP5QFAdPRn7ZD2/+m1Q3kcO 9kVOJPYpDEmiu/h2HE9mACe8MqQ/WLzRjD8vpuU0V5kv43pfwWKPZ3a0zVDG HErYjrAol7g6QNfmdrlRHbINgWw5geqB/j1iTd2A+taIneb3ep70mcYUdegH Zy2rx0ztK/aPOTrRhFQSoJCnurTK5R5Yr5gFGzXPir6n1O5c+88C3S2YgvHd MAQcumaleKobgeT1dlnqzfkY/99Geildn1RTZSrU4Sh37IemdbCQK+ocXLvr T3WJGLTKxNvfhSIUha52FYOUkdGSkCQJ68lqcVLn8Gn3tgtTZV+x5pkgZggs LV2XwHxdEH6EcFaFzSxBW/x7Mnt2r8m0JEfHr0HQgroCcObWyI0IsYjbFFrd 9cXdv7p8fgLPPzHsBVLiz7C8s71/FN85m2naF1Oa9gQ/+sT8NyMMFmoxUm2/ nAiE41NEUdy4L0eE0zq35BHY/44OdxnYqu/8B7YlTmDFGJMsmw5haIbfMukG nOxrot6ldUFN3HMS1soOJW7Xd1/iV3pT/7t85GiV+GSOlZqaz+yhdSYiE3fr wwgfv7XSNrBDbtBmztcnKUyVaUbT8iAyxm2FDLdo3kSvdig09EIMnVvskgTO abdReWl/agR0MCexfQ5P2tMMY7OfOXCrEY9iF6xNkkXvoMD9VktmN/ym5K4b P4S6KzAJfExG/T5OUqmWcj8dWVPpkPynnngFOLNubjJ624Wcjg12dWx3Ezwf 5zDvO8JRmFj2HJSEYM7WuDfMqm1fHSV4jZnWgEbabHcJxTlIh68cpcXmEe/r dXAU5gcDje8UzdG4mSss4oHW3fMPsRVkQa84GO/YhbMsdxKQXIZzSR6UTaz4 MLwSEM7SIWSnignzXW5bYA0cSFmUULRjVKDaTd13zWgjaWTR9x5pPa1BGiSr W81QtS0VBzjnvMcel2cWb5K2G9POQpJ+ooipjPpjKHWFf1PBkqw/lik5F+s7 PYnJBeibmUUsNEKs2o27HmjQGKyA6O4Qclso3lUDvLfgbS7h4oeFM6tLuina WNImXicKzDtwfodID/E7musNxU2R2Wdl1I5YKVZHylKO0fHP3aFLLHUdJnzb 3wmTxekCImyz2iABpPBCQ3J5WgPBE9By2yQrybVXyP7/mPPdUwTLileWZxG9 0l3JGY7eE/D5DDzXR+bCQi7+01ct0QpGdH2cC3+fuwpXFHwTHcK9yI4rjGlb z7Bbp1GQoKrT4VkzfMFr00ii3fhG9uS6TePuwuzBMu9Ku8xeLv4CIiILMVAM bUPsrX/5/AmuuW41tuuaBxkwBqo7gc2ArpSFzT/55AM2JS/JBKC5qsghTxnz irL8LTpL93UfX1AdksygMz5Oqvd7ovglH5pYr0FnBaSEjAImc8EYk6O72eqS hidkzM2pVY1fb1pEhKxIygal8IYzSyJUNkfd0hA6i1GDfEM8DID7cCCHQP5Q cSuZS6qJ0wY6dEZyN/ReEKJf+i321CuQzrw73RePoCDmB9TQUrZYOLSW4rNB c/Z8EyPm0fMzn6wYB3FmbiVJSj5TAol87tfA+AZD1D+L9gVgoxnoG/va/2wJ 2cWchnvgd9ShLP0UGCmMkqPhBoGUwpAe0ys/6uD5JP6U7dJwK/3i2poJiw3l CP/Uh3/nx5kDiowYqObdipvKN3lbscM77gxjBsXmWtYAUJ+jmurUM4gNCd+8 alNowIfodLbvZcYveV8owC80zwYlSFkD+BpckMwyey4BAL5mpVPTV95n6D6F cCvo/ftmIgeM6mtDi/Xcv6AaxzcoAKzQj9NvcfML0InhsCU0Wr/mZ2kx5rgq K1QysI+MLArxTLvIUm7SnJTf3nrR13NwE9YP6/+zU9BIkye9SAQ6VmrdW9XA PlfsBAuu6lx9XMBEBPtO4j/ADEJJogzmTov0MhDXgL3IXlsnIs/fJz5qwykb Hco0epS7/ycSTKqa3Fqj1D4DqsxtrFei09CcJ8cIYheQR1mvHsQ0wt7NfRAz 12eUePLuMKjuFl/s2ku8MJMdrf1msb+OVvMoL6ArnP6/9re5rZ+Ywe3tjnUU mS8vYUSqGZShQ5SlUzGoD6eDyIlcyXoFmMrBh5QnIGudhCJLKOyg+ioUgv4u +IbHulB2Lbw87Oxw09J8NNHCoTApjh3mm1sJ6gnslco7rpImfQmVrh65pVbW V85xwItehtxlpNMA3vz/r5h7Hy8pEv4jjj9fIeJlvCGng8RE0m81KyqANH6c xyJ4Rjt1ybTVRzM6++uWiebIOLSReyrhE37vizj9lbDfHmhF8wq2ofDULKdZ ulSDtr56xRmcSgUFOyMD/yGYyY5I/AxQbV2lBzrCDZJHEbqfl/CzMvT3oCnw L6K8PudFYWopR5795V/9fpvIeGfTFRXORCOWGPMNO3qixdukPug+Ga2rQ0rB MY38VdPeCynd6EgGzmRHssPN9ySOQJlf05c+eshoeA68s0lUsoCARk9IAizC OfxMdqF+0OEjc1sR47HtERen0onxT5ymujMQ22gqNooLID9hRJGavxwdbKQi GFOI880HgGtUAfochnQG4HYdF/yHIcgYb3E5eRGJo+LqdHzwfTX7mFz2iaXS 5Pv/lWZ1DqbkRYDEvB3qWHUnQ9ccdUc94gTnCFu031U5GgzJty4dDB7zEAyE 1y79ltyKl6D9GzQazYiM6sHOupEjCrYFB5CCOdVW2G6c0v8TUlbwbYDr8/Hh HySstHm+VHfvpoxGuMOsmyCyiQ/a5ghrXJWGf0iU0lQdMykjPCbLwFIsTG9y Ti2COcOVb+hB1OgKwaQn79/Fm6szxmteuIvDxYl4Lq3Qovo0VjIIm4kWFz8s +3oN1ERffSO9rKbbl03pIPiMaBJsC9mFzL8fVz7Ujo0/SLQMSX4fj0tq23MI /P/N2znDa0fM2Y7Q0+9KBhEN5h9S0F4hdfRXWEDlCqntumg2GvOrTF58ZIc5 muYIE0+HO9gM6pNHtCEVE4PEHGqRGJXi0pbdzkWMZPfGHlyS2l5RBUhKXnke rZbk3OsoD9ZOUcRY3rFKCQoT0MlMyztel0y/lmKIUtjp5o4rDjdAPijJ9MxQ kehyX22joKAo+Bw84DHnL+fyxGOMRwqQ5BOAV4bU+xI4r6uJWyqNsNAUM3ZJ 7bwVB/B43d2MxU0N23ztr1FXWsNdl74iz8Ql5HYrj56U1nky6hl17cLcVwFq oKMr2zQbiaVSvd/gs3L/doV3kldcEOVsfx7YTtndPJg2oVdcV8oDh/rV8M8r 5gM6o3hYKidYrzBgad3+Itpd8VRg9j4VlB2X08tf3XPB4rLoN0aavWpNoPVI P68rucuJxXPvH6HkFoGK3IbmsCQOpDpwKhgAcJ88CTyonKqJNdTP433mdRxy tc//sFL2rHRn7XgqJo2tp0jBIKU3okyjOhDq92rsF4DqwZHX15n33c4HONhZ Ya8WVpurtr3BLKshH1rN8kmhGCJwGG+fZxI7jFdHcXFLyEN38xwE3MDCeX6s T0ayg+E/bdzDO4GgBu3FsMQLbFMCsWQDiCBLF3hhTVgCELpWX7pt1gerOH2S V+bNaw6uif6cyOskV5r4rSrdrj+3KjcpJMUg7Fo2AOVC9OVprzD0t5Hin3ky 1FrujrnGFHQWL6ek8I1CV3LqcIl4a56XuQpBgMwMQ4nMGBNosZrWiRYeoGpl zpwqKj3j5vuXgU6OZHp+KCTsjhqsoXlB8+SEKI+vTQRn8E8x9FcemqiXlTUJ Zy+3aDVZX/LYzo8RJBk5nUKbldcJtsLyr/qE28xW82nLddUQnIabCcozrLbV HCuhCWUn30GxqzZbASfDNgYGfkag2uVT1D1NMM6I+zbFCt+BDX0xXU6vRyrx +MmZXpy9za7iV0vOPtUh/put0f1dotJYhPuIIY/1NfiCsQGI7IyY24mPngbS o2K1vO1WGu6I4N76LQt2Qt5zTMbSt0FKRwK1DOjeqmrhNrobfcGrT6f7MWN+ JhXeLr6ha/wJ3x8Xm+aVmveFdaGamVqOetWdMCM0c9jtpknneTtsw2YSpqi/ fM4pHxG9xAUc7dWwjLaSdvSpnDgqaQAHOZkO+zmugtp/wnvK4BoQdg5VJUFT zxlDLZ0Y1s968jPDwnlPwwxo6ga3E66i/I+FX5mhm0yVOirZWm0g8G3EixRq qjWF4Uc/prTImalh2cGNfrF7B9lPjQ1romZakML35vI2IAZfPwF2Ope8VdhG kia4MyIp5Pu3/WLe8s+rOyzwQx9ARK6PrIxWQct9y3GlTCui4FQ/CycLypbw XrVlRWgfA06XuTSkhrBL/9rju5sNVx4wgfrAnqSG2Hsowl26WyYFpr8zch0Q Fnh7rGzOXnmO4+CX9bRe8GXghTSMzknFJZ2jZOce3lKwE1aicP7lPAP559zz uTc6Q7JRPhQYoHqqA5nMr7ZQHQwWHPiiOB1mrs2hzcY55XA4ITJnNkp3Udjl hyA+sx0s+Xxmgnpd29/lzrODac5+YM24+chi5pUnE1sOXN4vDZ+lCmlq1HXG x55aorjLejRVhtW3SNxxY0yf06DnSek4ubhGgpS2pbMxR/dQQbtgZd5w+Avs kT3AXP+gVTJi8x4CWknUQokAxkA+jLCeOxVjt5uTudS48EEzw/60ck+eW8DW JXO4gacNqCtHT5R/M2bLNdHlQ+iMM87xFLXOWzp6ptMkvZZePdU/ERhMVcd/ YFc82qJHDlFpVmnqU2sy4sqpzYoklL34MNtEBQaAc83pYpwrnljR7A5zrdzl wl9U55iDN1trLYEdUHXd2uD+DzHjAZo1Q2+dtVKjxRGQ3WRMPzqWYhw1jBEM nqNE9Md6YN0BfCvsGxo5TUcTqQuIV9nvbCEuIlz8PNAjzAhvgy5kej5fsCcw YHBC6/GVzfx3vr9ouVoHkAbxOVHoPVuOT6QthCROnsQCkk7VtSehqiirc4a+ GVWO7KeqUv4LBpH3k0gCnmXzkd2wveqxCh8qTQKjqPCipL36oTk8fgYdkRXj UwQ4q33H4FBOrq5mhyzsBa++35VlWDqqvAoK/joEmzLdJERn+yZJkiN+5y6l CxidEPSoUE4WziW/WQA/XXl+IRcE7UvSFDy5rzvmlPusg/CZeHn2hHQsThU5 1AeoVOK+kVMD85Q952yLolLlJh/DQVOWg3GcB3sYd5Sw8mJeXr/Z948+ASCR nQwnWyGVpCp9oe//jpWnVQxUWTgf1ByYF/CrR/6USED/cGk3i1omGZZtRDTj EMKu+ddQJBHNCymHW3LEDbFPa6Dpzwcqq7zrMe2aomaZByyjq7WMsQ/Le+DL aSRox/DfJuaWL8peKxMWo+91QLYOXTGzR9XE/Veybw3ggHxHCn7u61pCElIo wvDmkeAMWnoVvLjAUIFVGiQr+rggLWAN+tUAQQbwfOj0eEPItnLKTfXZGjNl OdMNrlzyDskpU7Ydz3KcPTYtzmqf6pPsiv5G7fof5ZVS58qDZbyq4vdaIeV+ agPJ9QjeCZ324DWyAweMobn8rI6/aiLwmbI62s4qhvduT8uB4MSYPNtCSxoS yJ9O3/UMPcobSeVkg4sjFAHP/YXccXxAi3iIr1XxpoxxFKBVQOMswtdnf2G2 H5eL3E1RVmAmV45OcGdNo6pvgY4Ayujo8hO23DnR0dUKxPKIBI5C00qQ8qvI 4xYeQkAHB0LLMIPn5rKMWkpYyChFVOb+40PIGO92uZD2arktshh4DEplB8DG N6LJcRQU2HpCpMV7/osESiccp6LWxx5IgBmFt5oNj0ZQXTBHrjNyWErq48jq 7wJ3rzsshSreThJuiXrslYj57FfIRDnT9Jcs0irK4Rg726L0qKeLypH6EIvJ vs9bwofFvfK7plGEvvRFfiNY+yd9m6RBig7UDb61BSVV7TBXUMeBEdCqvdH7 yK0ogFMD0LK4asckh0qZuoLTo+fFxbk4Oqjicw9NBG1hIO1/Aog61gKghvP6 cFGaVs8WOg0ODUPalNZAkvd393YzHckZYd9kPYTIDHwUdi9iK+rvIROeBKhR X5r3Y8iy/RpSs1MSEfCKMTYxuUtyFSkwH+IIJgKc65ebgYkccfCXvpS4HbxF A/+gZUXPb8CeTyf3g20Zl9RRbh1L/fBoEHTNiJXVK1YOIgFf8jibHFUHTArt 4lHz6k7Fpup/TIabMQojaDC3sW4qSXYOMsmE+m4oAdV1qqvxCwbuETJCu6HD PztTUJAWISD2/LOyXdMoHYOCH1nbbcT2J1r97QOXsuntwQdCpfyvWjKXkfYs XCmbLJLG1zrYMuJc3cPx+SAxDKv5C1aZHmIF+cWaOmY/+A3MZwUnv1fZvxps SbvBcmjcf8vajcRxOQiWrqvWEMh5S7U/ZFll4Afhxbrrzp9BYgWVhtJaT0j9 AKQabeVf1GnWi4c3cbBWauApw7VpmNSNG3q70uAiDP7CXDkBAvACDn/tYdTO T7OWJTx9MZt6WA1gPGXTDbSnbxGBkDQ0Zq9LIp3PKtCyIKYuv6WboJspuDXC Qyiv10NlTEsH1UqymloEC1m1kWQa8/Yq2j1Zue3XvWhiqAlSCkwEk8dFHGNP hnDfCE8HU32nKGOCTYLnsDTnOAxwZ3KVWnZGxPSlm+zSUbi2GKAadfq8ApYf xUcT0efIetASF2UHfHPPwDuQzqWr6hLEUH5xs9H+p39ZTFu+Dob3PEwJTALD 7pdP6/C64kK28gCSqj4soUG0TIBKJazCtzjTooScT8FUZbUBdxmDCWUZJXsJ 5VKNeZVjHDZLyEbRKCsvi35nb+JnsV4GRBbpl8HsqGvdcoLkFZXzvTppXvfq dYsPKCVopT4qv4MTtA5rCZwYo4IG3PoruzJMkEi+hxiwun92JghKF0cr8NjO oNk2FRTt2eT8GMNpD7aTKzBWinSXPSfuAMKKXhKvmMob2VTuJrHRFVQmoHVd dtP6oSNFhfMQLiIydQr8kUQ8nkcXVpH501dk9g3vJWwg8KVBWedWMgGdlzZK 2I4VBIztFqnkBquDJ3QsjTUsHUKE+WvACr8szamDvt7uvAuOqlZEHeO/Ws5N JmBKn03Oaz4oozPAUB2iNXX5VzRWtK4pZDWc8dSCXTu6t3aGa08+gm0JpeSF b5Ck4VxR64eZiBwJFAFyD1gYqBgImR1aDl9KwNnzYXx5cs0hEyY6OJDmWEnq d4iaQITBDRUsJZSAid6D4weLogxF71EktFtFRacPy6soQZyw1fKQhE56ICKB 3pRW8NKAAr/llH6XnRqJxvV9ZmeA5nQXV7Xtewh5s22lVWFB4VCJW39Blq7i lAv/u/CSaL82DObowpqRo2ax0uayhV5af6+dYzy1Hq5KI4xvnL3HhhVOpZJn dCg9bTHf7zys0m8ACm1AQsbIw6OXSpKYwWKtsK12r4tFYbS1v/VuPkkKOWSu mO6c0KHDs786nL2G68e0luyDfVK5f+yshA+zuLkc9d5w6q9fyLlZ0sv8WUwF hbg+oI3QeMwuMqnpozAcq5d+tSSkIYIH3kb8xh72QFlF18U+2csMtqa494g8 /dn+lNOkzkxBsxHM0hUHWwb4p54pnjzxgt/lZ1kEjgr8+WUKVtYeJKeuoPtq TPIrsxBMKTn+Tfb1GU79oq4A84djCwlm8jqPBeaI3ernL7BiU3c5onsmk2Xo 5NjY9cxWtVjJmlVDqLhE57Ig34Lx6antCLAaGmnr8vMhQYaQuoavQqyFQMGr gxeZb+E7o0eVwkqH/9jI2gaC8QtqjYO3E9smfa1gPzyeYOAEi4L/R/ZHwGTM IISK1jmX2Frhc3zJuJT697VcC17P4FIMymQ2WNgqp9GLu2buWWRt7pHy2tyA IOmxSJUTLwBKsT7TyyW1zmyWVR7WXkjh85rYeBAJVUA0bIVsfbVHI8GBcF/q 6WcODefrq808bcEl32zxt9N+dSi6gHhs6igkeAv13WAP0abCmBo8Y2NdceqF zpNP233IoVFw13Hh+wtZiybhVRQ6803PDF/jPH87jqlWob8OW7QmddVii8cG Ndi0XPCuoSt9LpbEJCC28zR5MfPCWdyW0tMq8TUSB2/5mX8K9sWbcM7Nl4Hr xdXGj7JomeS/CinlnCEi7sjMmbv8zAR+17pqdTsOZQ49BnRRmG6xVqt2yu0y NmYRYRsZsNmYILVghdPrhA0gK+UC48dW0NLrzQscJ6WLVekijnxNT4qosbao NxG8HZeCDi59dxNU2aKCqNWYw1gWdK/jHUbULGE/IoHVpt9+bHjfZiWm4P82 L9+39eL6sCQIhCLbwcHiEyQ57yRk2fEq/GnvlWiRLyspRClUp6qMLs507OnY cChtt08dTt6W7+fPsSYeIzWRFCKV8GzR3xj1zHjVO5Od9I1HJpeyZmJ4Q97s 1F4NQqS+mM+p1KLu1Bwl7IdvtNB/NWS2KGhOYu4xIhYPVBtt0L0AIamOs+jo cbSuTzNiIjxgdOC7uap2PwaFuEjPW9QS1Lt/jw8k6XTgIGwom55vLkUCh7TG MZva8nGHIM7UmHI2P5FDRcQgx4ZLlnJR2RAHsNQmeK3W1RXdcToSXKomwzEU RMy6hhtCaQ8mPuZeFGIDKAKlNPd1XsE1ROe+2NkskLx3EDbNn5u+T2w/sABz PNQFJE+YGY69bjPKXXsGlXtTUwGr8aNASu9DY4a17s3midJyEW6fw3jDwJRE LwKAoI8YYPZJERpDPKASWro7DnGoQi4ch66EZ4UiAPwyP2vYwJsfOx22aZlQ Aq4SVTkfMF9iiD3PryaHeaEs0HzOdJLkSyfcfPXISfj8xDqESFxzUCDbujl6 x+PIRRz2rH0oN/t/1RfD+er7m4uTQaVhYwnI5TJ0lGLX21zsbp2xX6kjcUk/ EBs2LOQJpv75M+tZsYxhqpfs/BH74hklvP586t9dejy0dit1LgxNo2XO5ijI SobzaFGZOLpAn+TMWp5G2lNoYsgCO0E9NQCWu6SFJFpVedK4qHL+TRggufVX GCap7ZaMNm5x5NgN2OVTt2QdogkOZFvjmujOBGHfwTm7DqrvT59+LN3XpMrk I5YhjN7B+ePQ9OkmrP71Q8wZK1SH1y2H/GzcfwYdCyUfgSwuTEdHu8W/GQnn obJf8Ih29+H5YFS5J4vLea5oRFkUAQHAQR6qvMaUTlTpe1AP6aAbS/0mMSeQ 89QspIq9hOHEyEbQhXzUaAKiXlxyN/KlpNEj/3z7Cjy7yHyCH3lek934HpwX ZO/fUZ1j3vTxtNHBLRJb9wRNt6RxMHZIM0oDcuFwzlc4bXyqVcHa2UW/13PR jQDmgzAcT4VMPjrvqVTYCfmB3foTxXsyJW7YV/KmkPCGJqpTbcOR3VCY69IC CqhwK1oFB1e1MTF/MssRco/F/BcNFN/MYzQoZ1pysOXj/Rjc7E5uQ3dfFKKC LHyNx5586SLZp5nU0xs6efjDxCM+pRWaF0MCmW6zftrpOC+EpV6oHvWd3/5/ 6pI/if1SR6Hwdm8qcTXXN1cFxeKVaVPfAdtX73o1BatuOK0q6G63Vpq8W0sn WPHiZLK1HKsWQaY26LUsCVnxUSurHWqYyYK2o7Smw6LS99racPF8dyPgYcj+ xhwg4q6CttIgAerVpAyeuYbKd5zYsPFaXx/gn5vG6+NnJGQUxx0WgCFUoYaa k5JVUizvb69/+iEVb864M0hzI29XOC/5AguQJWHEhxeHmug2z8bnCrGNsVZ6 8s5Aa64sJPaekx+F75AwxFpS7Usw96CPFAEq/OEzGCpQOevF5EC5ivMRJy3E THFsRrju3F5/aPeKtjXFBGh+ojkc1n1EflgZhhtWpLXTz/Il96kvnYbGA1Xi K95Honc81p30Qz3GRtHdNKv+zgNJG0vFsvxzUZw6evmK6BiA5n7z2JaB1sAL 5Ueu1qVBoNr7bUpSV0K0fMT3aJn7YkFmNa+tp3nbSWl+FFDZu4ns90CVTcF4 Ayx3xUxZFEOan+IFVOYt/ca1dHVKIXKo39NzU+VhPNqR4gwtTfI1fcWdO9KT tpgwMdSiD7MWwdOCVpkSVD1iofdg8wkUoO5TcCTP8SZ8w1wAWQXuBP7EYoGs DQCzm3hAxYr5rGuAHb0vpUOreDU4u4LpADdYg9sT1A/12/iv5P8dJxg0NMUd G8IrGOn7amiZlzGYxohwk0qGiuhfJAhOrvAIGxvRO9Xth3pVmRHfWiZQ8Ccn ufZMJPV8Vwgqs1srktZxx8xH0mr0S7QvGKT3XGmD/pfzBmHtoPhNmVw3Xi+T ngq0VmIMSoVPITFWN/uQHIUd4nbl8n+SoNV3pL+UVc7daxuwrXCUX6PCzOqV oOF6f8pXqR6cmKPWdesOMqfvAt2VLr6lwOhs/igRYYJS2uxcsnLgzyVMKsVO HE6e2XZ5LwmfQmlAFZGXsjWQPQRTcjlVLv6t1llqgqDUQn+3s8ZbKCkFwcs1 TWwbXQtLnYdPiQkOXjdkadgwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAowMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MAowMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwCjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAKY2xl YXJ0b21hcmsKZW5kc3RyZWFtCmVuZG9iagoxMTcgMCBvYmoKMTA4MDcKZW5k b2JqCjExOCAwIG9iagoxNTI1CmVuZG9iagoxMTkgMCBvYmoKODc1MAplbmRv YmoKMTIwIDAgb2JqCjUzMgplbmRvYmoKMTIxIDAgb2JqCi9WRkdJVEErQ01S MTIKZW5kb2JqCjEyMiAwIG9iaiA8PAovQXNjZW50IDY5NAovQ2FwSGVpZ2h0 IDY4MwovRGVzY2VudCAtMTk0Ci9Gb250TmFtZSAxMjEgMCBSCi9JdGFsaWNB bmdsZSAwCi9TdGVtViA2NQovWEhlaWdodCA0MzEKL0ZvbnRCQm94IFsgLTM0 IC0yNTEgOTg4IDc1MCBdCi9GbGFncyA0Ci9DaGFyU2V0ICgvZmkvcXVvdGVy aWdodC9wYXJlbmxlZnQvcGFyZW5yaWdodC9wbHVzL2NvbW1hL2h5cGhlbi9w ZXJpb2QvemVyby9vbmUvdHdvL3RocmVlL2ZvdXIvZXF1YWwvQS9DL0cvSS9M L00vTi9PL1AvUi9TL1QvWC9hL2IvYy9kL2UvZi9nL2gvaS9sL20vbi9vL3Av ci9zL3QvdS92L3cveC95L3opCi9Gb250RmlsZSAxMTYgMCBSCj4+IGVuZG9i agoxOCAwIG9iaiA8PAovVHlwZSAvUGFnZXMKL0NvdW50IDEKL0tpZHMgWzIg MCBSXQo+PiBlbmRvYmoKMTIzIDAgb2JqIDw8Ci9UeXBlIC9DYXRhbG9nCi9Q YWdlcyAxOCAwIFIKPj4gZW5kb2JqCjEyNCAwIG9iaiA8PAovQ3JlYXRvciAo VGVYKQovUHJvZHVjZXIgKHBkZlRlWC0wLjEzZCkKL0NyZWF0aW9uRGF0ZSAo RDoyMDAxMTIxMzE3MTQwMCkKPj4gZW5kb2JqCnhyZWYKMCAxMjUKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDAyMzc1IDAwMDAwIG4gCjAwMDAwMDIyNjIg MDAwMDAgbiAKMDAwMDAwMDAwOSAwMDAwMCBuIAowMDAwMDAyMjQyIDAwMDAw IG4gCjAwMDAwNjAxMjkgMDAwMDAgbiAKMDAwMDA1MzYyNCAwMDAwMCBuIAow MDAwMDUwNTE1IDAwMDAwIG4gCjAwMDAwNDYxNjggMDAwMDAgbiAKMDAwMDA0 MTUzNSAwMDAwMCBuIAowMDAwMDM1NDgzIDAwMDAwIG4gCjAwMDAwMzEyNTMg MDAwMDAgbiAKMDAwMDAyODE4OCAwMDAwMCBuIAowMDAwMDI0MDI5IDAwMDAw IG4gCjAwMDAwMTg0NTcgMDAwMDAgbiAKMDAwMDAxNDk2MyAwMDAwMCBuIAow MDAwMDA2MTc5IDAwMDAwIG4gCjAwMDAwMDI1ODEgMDAwMDAgbiAKMDAwMDA3 MjE4MiAwMDAwMCBuIAowMDAwMDAyNzEzIDAwMDAwIG4gCjAwMDAwMDMyNTEg MDAwMDAgbiAKMDAwMDAwNTg3NCAwMDAwMCBuIAowMDAwMDA1ODk1IDAwMDAw IG4gCjAwMDAwMDU5MTUgMDAwMDAgbiAKMDAwMDAwNTkzNiAwMDAwMCBuIAow MDAwMDA1OTU2IDAwMDAwIG4gCjAwMDAwMDU5ODcgMDAwMDAgbiAKMDAwMDAw NjMxMSAwMDAwMCBuIAowMDAwMDA2ODQ2IDAwMDAwIG4gCjAwMDAwMTQ1Nzcg MDAwMDAgbiAKMDAwMDAxNDU5OCAwMDAwMCBuIAowMDAwMDE0NjE5IDAwMDAw IG4gCjAwMDAwMTQ2NDAgMDAwMDAgbiAKMDAwMDAxNDY2MCAwMDAwMCBuIAow MDAwMDE0NjkwIDAwMDAwIG4gCjAwMDAwMTUwOTUgMDAwMDAgbiAKMDAwMDAx NTYzMiAwMDAwMCBuIAowMDAwMDE4MTU0IDAwMDAwIG4gCjAwMDAwMTgxNzUg MDAwMDAgbiAKMDAwMDAxODE5NSAwMDAwMCBuIAowMDAwMDE4MjE2IDAwMDAw IG4gCjAwMDAwMTgyMzYgMDAwMDAgbiAKMDAwMDAxODI2NSAwMDAwMCBuIAow MDAwMDE4NTg5IDAwMDAwIG4gCjAwMDAwMTkxMjQgMDAwMDAgbiAKMDAwMDAy MzY3NyAwMDAwMCBuIAowMDAwMDIzNjk4IDAwMDAwIG4gCjAwMDAwMjM3MTgg MDAwMDAgbiAKMDAwMDAyMzczOSAwMDAwMCBuIAowMDAwMDIzNzU5IDAwMDAw IG4gCjAwMDAwMjM3ODggMDAwMDAgbiAKMDAwMDAyNDE2MSAwMDAwMCBuIAow MDAwMDI0NzI0IDAwMDAwIG4gCjAwMDAwMjc4MDEgMDAwMDAgbiAKMDAwMDAy NzgyMiAwMDAwMCBuIAowMDAwMDI3ODQyIDAwMDAwIG4gCjAwMDAwMjc4NjMg MDAwMDAgbiAKMDAwMDAyNzg4MyAwMDAwMCBuIAowMDAwMDI3OTE0IDAwMDAw IG4gCjAwMDAwMjgzMjAgMDAwMDAgbiAKMDAwMDAyODg2MyAwMDAwMCBuIAow MDAwMDMwOTQyIDAwMDAwIG4gCjAwMDAwMzA5NjMgMDAwMDAgbiAKMDAwMDAz MDk4MyAwMDAwMCBuIAowMDAwMDMxMDAzIDAwMDAwIG4gCjAwMDAwMzEwMjMg MDAwMDAgbiAKMDAwMDAzMTA1NCAwMDAwMCBuIAowMDAwMDMxMzg1IDAwMDAw IG4gCjAwMDAwMzE5MjUgMDAwMDAgbiAKMDAwMDAzNTE2OSAwMDAwMCBuIAow MDAwMDM1MTkwIDAwMDAwIG4gCjAwMDAwMzUyMTAgMDAwMDAgbiAKMDAwMDAz NTIzMSAwMDAwMCBuIAowMDAwMDM1MjUxIDAwMDAwIG4gCjAwMDAwMzUyODEg MDAwMDAgbiAKMDAwMDAzNTYxNSAwMDAwMCBuIAowMDAwMDM2MTUyIDAwMDAw IG4gCjAwMDAwNDExOTMgMDAwMDAgbiAKMDAwMDA0MTIxNCAwMDAwMCBuIAow MDAwMDQxMjM1IDAwMDAwIG4gCjAwMDAwNDEyNTYgMDAwMDAgbiAKMDAwMDA0 MTI3NiAwMDAwMCBuIAowMDAwMDQxMzA3IDAwMDAwIG4gCjAwMDAwNDE2NjYg MDAwMDAgbiAKMDAwMDA0MjE5OCAwMDAwMCBuIAowMDAwMDQ1ODQzIDAwMDAw IG4gCjAwMDAwNDU4NjQgMDAwMDAgbiAKMDAwMDA0NTg4NCAwMDAwMCBuIAow MDAwMDQ1OTA1IDAwMDAwIG4gCjAwMDAwNDU5MjUgMDAwMDAgbiAKMDAwMDA0 NTk1NiAwMDAwMCBuIAowMDAwMDQ2Mjk5IDAwMDAwIG4gCjAwMDAwNDY4MzIg MDAwMDAgbiAKMDAwMDA1MDIwMiAwMDAwMCBuIAowMDAwMDUwMjIzIDAwMDAw IG4gCjAwMDAwNTAyNDMgMDAwMDAgbiAKMDAwMDA1MDI2NCAwMDAwMCBuIAow MDAwMDUwMjg0IDAwMDAwIG4gCjAwMDAwNTAzMTUgMDAwMDAgbiAKMDAwMDA1 MDY0OCAwMDAwMCBuIAowMDAwMDUxMTkyIDAwMDAwIG4gCjAwMDAwNTMzMDYg MDAwMDAgbiAKMDAwMDA1MzMyOCAwMDAwMCBuIAowMDAwMDUzMzQ5IDAwMDAw IG4gCjAwMDAwNTMzNzAgMDAwMDAgbiAKMDAwMDA1MzM5MSAwMDAwMCBuIAow MDAwMDUzNDIyIDAwMDAwIG4gCjAwMDAwNTM3NTggMDAwMDAgbiAKMDAwMDA1 NDI5MSAwMDAwMCBuIAowMDAwMDU5Nzk1IDAwMDAwIG4gCjAwMDAwNTk4MTcg MDAwMDAgbiAKMDAwMDA1OTgzOCAwMDAwMCBuIAowMDAwMDU5ODYwIDAwMDAw IG4gCjAwMDAwNTk4ODEgMDAwMDAgbiAKMDAwMDA1OTkxMyAwMDAwMCBuIAow MDAwMDYwMjYzIDAwMDAwIG4gCjAwMDAwNjA3OTcgMDAwMDAgbiAKMDAwMDA3 MTcxMSAwMDAwMCBuIAowMDAwMDcxNzM0IDAwMDAwIG4gCjAwMDAwNzE3NTYg MDAwMDAgbiAKMDAwMDA3MTc3OCAwMDAwMCBuIAowMDAwMDcxNzk5IDAwMDAw IG4gCjAwMDAwNzE4MzAgMDAwMDAgbiAKMDAwMDA3MjI0MCAwMDAwMCBuIAow MDAwMDcyMjkyIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgMTI1Ci9Sb290 IDEyMyAwIFIKL0luZm8gMTI0IDAgUgo+PgpzdGFydHhyZWYKNzIzODgKJSVF T0YK --0-55293712-1008304282=:50062-- From owner-ips@ece.cmu.edu Fri Dec 14 03:59:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27119 for ; Fri, 14 Dec 2001 03:59:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE8CR417648 for ips-outgoing; Fri, 14 Dec 2001 03:12:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from bramg1.net.external.hp.com (bramg1.net.external.hp.com [192.6.126.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE8CPZ17644 for ; Fri, 14 Dec 2001 03:12:26 -0500 (EST) Received: from fowey.BR.ITC.HP.COM (fowey.br.itc.hp.com [15.145.8.186]) by bramg1.net.external.hp.com (Postfix) with SMTP id D10892ED; Fri, 14 Dec 2001 09:12:24 +0100 (MET) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Fri, 14 Dec 2001 08:12:24 -0000 (GMT Standard Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 08:12:24 -0000 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1D2B@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Dave Francheski'" , ips@ece.cmu.edu Subject: RE: iSCSI Text Request Date: Fri, 14 Dec 2001 08:12:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18477.0C689640" Sender: owner-ips@ece.cmu.edu 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_01C18477.0C689640 Content-Type: text/plain; charset="iso-8859-1" Dave, You are correct: only Login Requests and Login Responses are allowed during the login phase. Until FFP, any other PDU is protocol? error. The use of Text PDUs were removed when we revised the login procedure as there were no benefits for using different PDUs (i.e. Text PDUs). Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- -----Original Message----- From: Dave Francheski [mailto:davef@seven-systems.com] Sent: Thursday, December 13, 2001 7:23 PM To: ips@ece.cmu.edu Subject: iSCSI Text Request Before full feature phase is entered, is it valid for an initiator to send a Text Request PDU for parameter negotiation purposes? In other words, are only Login Request PDUs and Login Response PDUs allowed during the login phase? I believe iSCSI draft 9 only permits Login Request/Response PDUs during the login phase, but we've noticed that some initiators violate this restriction. Regards, David Francheski Seven Systems Technologies 575 Menlo Drive Suite 2 Rocklin CA 916-577-1281 davef@seven-systems.com ------_=_NextPart_001_01C18477.0C689640 Content-Type: text/html; charset="iso-8859-1"
Dave,
 
You are correct: only Login Requests and Login Responses are allowed during the login phase.  Until FFP, any other PDU is protocol? error.  The use of Text PDUs were removed when we revised the login procedure as there were no benefits for using different PDUs (i.e. Text PDUs).
 
Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com
-----Original Message-----
-----Original Message-----
From: Dave Francheski [mailto:davef@seven-systems.com]
Sent: Thursday, December 13, 2001 7:23 PM
To: ips@ece.cmu.edu
Subject: iSCSI Text Request

Before full feature phase is entered, is it valid for an initiator to send a
Text Request PDU for parameter negotiation purposes?   In other words,
are only Login Request PDUs and Login Response PDUs allowed during
the login phase?
 
I believe iSCSI draft 9 only permits Login Request/Response PDUs
during the login phase, but we've noticed that some initiators violate
this restriction.
 
Regards,
 
David Francheski    
Seven Systems Technologies
575 Menlo Drive Suite 2
Rocklin CA
916-577-1281
davef@seven-systems.com
 
 
      
------_=_NextPart_001_01C18477.0C689640-- From owner-ips@ece.cmu.edu Fri Dec 14 05:03:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27566 for ; Fri, 14 Dec 2001 05:03:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE9FbB20762 for ips-outgoing; Fri, 14 Dec 2001 04:15:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE9FZZ20756 for ; Fri, 14 Dec 2001 04:15:35 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA92058 for ; Fri, 14 Dec 2001 04:12:45 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBE9FXr214088 for ; Fri, 14 Dec 2001 02:15:33 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Byte1 Bit 7 Seems Not to be reserved To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 14 Dec 2001 00:24:26 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/14/2001 02:15:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1. Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved. We should probably make those consistent. I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Dec 14 05:07:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27595 for ; Fri, 14 Dec 2001 05:07:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBE9FaS20757 for ips-outgoing; Fri, 14 Dec 2001 04:15:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE9FYZ20749 for ; Fri, 14 Dec 2001 04:15:34 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA59536; Fri, 14 Dec 2001 04:12:43 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBE9FWr39806; Fri, 14 Dec 2001 02:15:32 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Checking the I bit To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 13 Dec 2001 23:55:27 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/14/2001 02:15:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBE9FYZ20751 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, Technically, the In coming PDUs all have Byte 0, Bit 6, set to one. It is not identified as the I (Immediate) bit. And it is NOT reserved. So the Statement from the UNH Plugfest does not apply. I think your point is that if all the incoming PDUs have that bit set, why do we need to set the bit, and why do we need to check it. I think this bit has evolved over time, and perhaps up to now no one has noticed. If every incoming PDU has the bit set, we may not need the bit to be set, and perhaps it should be reserved, thereby not requiring the check. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/13/2001 03:26:18 AM Sent by: owner-ips@ece.cmu.edu To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: Checking the I bit Is it necessary for the initiator to check the I bit in every response? If an initiator does not need it, then I don't want to take the extra time to check it. I think this is consistent with the thinking of all attendees of the UNH Plug Fest because the report from UNH IOL was that "all companies failed that test". I would like to propose adding some wording to 3.2.1.1 similar to "It is not necessary to check this bit for 1 if the implementation in the initiator does not need its use". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Dec 14 10:24:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00964 for ; Fri, 14 Dec 2001 10:24:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEEWhJ19035 for ips-outgoing; Fri, 14 Dec 2001 09:32:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lucy.trebia.com ([65.192.191.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEEWfZ19030 for ; Fri, 14 Dec 2001 09:32:41 -0500 (EST) Received: from trebiaachadda (140.186.40.85 [140.186.40.85]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X6ZM4667; Fri, 14 Dec 2001 09:32:08 -0500 Message-ID: <005501c184ac$19294160$9a7fa8c0@trebiaachadda> From: "Anshul Chadda" To: References: Subject: Re: iSCSI: Checking the I bit Date: Fri, 14 Dec 2001 09:31:58 -0500 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 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: The question of checking bits will be relevant whether a bit/field is set to 1 or 0(means reserved). The point being does the initiator/target has to check the bits/fields if it is not affected by those. It (initiator/target) might not want to check for it as these checks are costly. I know this issue was discussed before, but I don't know the outcome of it??? Anshul ----- Original Message ----- From: "John Hufferd" To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu (E-mail)" Sent: Friday, December 14, 2001 2:55 AM Subject: Re: iSCSI: Checking the I bit > > Eddy, > Technically, the In coming PDUs all have Byte 0, Bit 6, set to one. It is > not identified as the I (Immediate) bit. And it is NOT reserved. > > So the Statement from the UNH Plugfest does not apply. I think your point > is that if all the incoming PDUs have that bit set, why do we need to set > the bit, and why do we need to check it. I think this bit has evolved over > time, and perhaps up to now no one has noticed. > > If every incoming PDU has the bit set, we may not need the bit to be set, > and perhaps it should be reserved, thereby not requiring the check. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" @ece.cmu.edu on 12/13/2001 03:26:18 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: "ips@ece. cmu. edu \(E-mail\)" > cc: > Subject: iSCSI: Checking the I bit > > > > > Is it necessary for the initiator to check the I bit in every response? > > If an initiator does not need it, then I don't want to take the extra time > to check it. I think this is consistent with the thinking of all attendees > of the UNH Plug Fest because the report from UNH IOL was that "all > companies failed that test". > > I would like to propose adding some wording to 3.2.1.1 similar to "It is > not necessary to check this bit for 1 if the implementation in the > initiator does not need its use". > > Eddy_Quicksall@iVivity.com > > > From owner-ips@ece.cmu.edu Fri Dec 14 11:26:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02114 for ; Fri, 14 Dec 2001 11:26:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEFXkW23366 for ips-outgoing; Fri, 14 Dec 2001 10:33:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBEFXgZ23356 for ; Fri, 14 Dec 2001 10:33:42 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBEFXXt11464; Fri, 14 Dec 2001 10:33:33 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id fBEFXWS26179; Fri, 14 Dec 2001 10:33:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15386.7116.843000.993216@gargle.gargle.HOWL> Date: Fri, 14 Dec 2001 10:33:32 -0500 From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu, ltuikov@yahoo.com, dave_sheehy@agilent.com, pat_thaler@agilent.com, Julian_Satran@il.ibm.com Subject: RE: found the constant for divide-only circuit! References: <01A7DAF31F93D511AEE300D0B706ED920CF76F@axcs13.cos.agilent.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 13 December 2001) by CAVANNA,VICENTE V (A-Roseville,ex1): > I have modified the preferred implementation (simultaneous multiply-divide > circuit) to include the control logic as Paul suggested (similar to ethernet > spec). By showing this circuit the iSCSI spec becomes less ambiguous and, > just maybe, Luben and Paul will be happy men :-). This is good. I have one comment: I'd call this an "example" implementation rather than "preferred". In fact, it is quite likely not the preferred implementation if you have to go flying along at several gigabits per second... And, since it's an example, I'd put it in some appendix. There are other example implementations one might point to, for example the 4 bits at a time table driven approach documented in the VAX architecture manual, or the 8 bits at a time approach documented in a paper by Stuart Wecker from sometime before 1980. I should have the former somewhere; the latter I don't have but I can probably come up with a reference to it. paul From owner-ips@ece.cmu.edu Fri Dec 14 12:47:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03959 for ; Fri, 14 Dec 2001 12:47:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEH47i29910 for ips-outgoing; Fri, 14 Dec 2001 12:04:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEH45Z29906 for ; Fri, 14 Dec 2001 12:04:05 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA27166 for ; Fri, 14 Dec 2001 18:03:54 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEH4MO136480 for ; Fri, 14 Dec 2001 18:04:22 +0100 To: ips@ece.cmu.edu Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 19:04:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 19:04:18, Serialize complete at 14/12/2001 19:04:18 Content-Type: multipart/alternative; boundary="=_alternative 005D9E6AC2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005D9E6AC2256B22_= Content-Type: text/plain; charset="US-ASCII" John, If you are referring to the fact that a reserved bit has to be 0 - that is not so. The statement about reserved is that they are 0 unless explicitly said otherwise. There are some other reserved positions that are set to 1. Julo John Hufferd@IBMUS 14-12-01 10:24 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu Subject: iSCSI: Byte1 Bit 7 Seems Not to be reserved Julian, in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1. Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved. We should probably make those consistent. I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 005D9E6AC2256B22_= Content-Type: text/html; charset="US-ASCII"
John,

If you are referring to the fact that a reserved bit has to be 0 - that is not so.
The statement about reserved is that they are 0 unless explicitly said otherwise.
There are some other reserved positions that are set to 1.  

Julo


John Hufferd@IBMUS

14-12-01 10:24

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: Byte1 Bit 7 Seems Not to be reserved


Julian,
in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1.  Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved.  We should probably make those consistent.   I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 005D9E6AC2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 12:50:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04032 for ; Fri, 14 Dec 2001 12:50:42 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEH3d129866 for ips-outgoing; Fri, 14 Dec 2001 12:03:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-68.crossroads.com [65.68.235.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEH38Z29837 for ; Fri, 14 Dec 2001 12:03:35 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPSEC: IKE preshared keys, ID payload, and DHCP Date: Fri, 14 Dec 2001 11:02:40 -0600 Message-ID: Thread-Topic: IPSEC: IKE preshared keys, ID payload, and DHCP Thread-Index: AcGCnpQ2ssPhFbqmSsOHbpqCy9ydJwCIlojg From: "Michael Klock" To: "Ips Reflector (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBEH3ZZ29861 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit If someone could address my question, I'd be most grateful. Thanks. > -----Original Message----- > From: Michael Klock > Sent: Tuesday, December 11, 2001 5:50 PM > To: Ips Reflector (E-mail) > Subject: IPSEC: IKE preshared keys, ID payload, and DHCP > > > I searched the archives, but couldn't find a discussion directly related to this topic. Apologies if I missed one. > > If only the required IKE mode of preshared keys is supported and ID payloads must contain a single IP address (ips-security-06, last paragraph, page 12), how are DHCP-enabled ports handled? When setting up the preshared key, an administrator needs to know the IP address since this is what the ID payload will identify (and what is used to select the preshared key). But can't the IP address change for a DHCP-enabled port on a power cycle, or lease expiration, etc.? Is there an assumption that only ports with static IP addresses are being used? > > In a related vein, will the IPSec DOI definition be updated to include iSCSI names for ID payload types? I think this would remove the problem with DHCP (at least for IKE Aggressive Mode). > > Thanks for the help, > Mike. > > Michael M. Klock > Crossroads Systems, Inc. > (512) 928-7292 > From owner-ips@ece.cmu.edu Fri Dec 14 12:51:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04074 for ; Fri, 14 Dec 2001 12:51:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEHWVs02077 for ips-outgoing; Fri, 14 Dec 2001 12:32:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEHWTZ02071 for ; Fri, 14 Dec 2001 12:32:29 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 8A88C34D6; Fri, 14 Dec 2001 10:32:28 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 482DD1F7; Fri, 14 Dec 2001 10:32:28 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 10:32:28 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A00955A99A@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Paul Koning , vince_cavanna@agilent.com Cc: ips@ece.cmu.edu, pat_thaler@agilent.com, dave_sheehy@agilent.com Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? Date: Fri, 14 Dec 2001 10:32:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I agree that we should use the mathematical description of the CRC as the spec. Equivalent ways of obtaining the effect of inverting the first bits or checking the result (magic number) are implementation details. I'm not convinced that we need to show an implementation example in the annex. Given the misleading information that Vince has found in some of the literature if we show an implementation example, we need to point out that the technique of initializing the register to 1's applies specifically to that implementation and may not work for other implementations. Regards, Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Thursday, December 13, 2001 8:40 AM To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu; pat_thaler@agilent.com; dave_sheehy@agilent.com Subject: Re: effect of initializing CRC reg to 1's depends on implementation? >>>>> "vince" == vince cavanna writes: vince> In working with Luben Tuikov to document the math behind the vince> CRC I discovered something that surprised me. I intend to vince> study this further but hope someone can save me work by vince> pointing out that I am wrong (or right) and offering some vince> proof. vince> Consider two ways to implement the iSCSI CRC with a serial vince> divider (see PDF file): vince> 1. divide the message directly using a serial circuit that, vince> when its stages are initialized to zeroes, simultaneously vince> multiplies by x^32 and divides by G(x). vince> 2. pre-multiply message by x^32 and then divide the results by vince> G(x) using a serial circuit that, when its stages are vince> initialized to zeroes performs a division by G(x). vince> The two circuits, of course, produce the same results when vince> they are initialized to 0's. vince> In the approach in (1) initializing the register to 1's vince> appears equivalent (produces the same quotient; same vince> remainder) to initializing the register to 0's and vince> complementing the most significant 32 bits of the message vince> prior to processing. vince> In the approach of (2) such an equivalence does not appear vince> true! vince> This means to me that it is meaningless to specify that the vince> CRC must be initialized to 1's unless we refer to a specific vince> implementation which we did not do in the iSCSI spec! What is vince> troublesome is that I have seen claims in the literature (and vince> in one textbook on data communications) that initializing the vince> CRc to 1's is equivalent to complementing the most significant vince> n bits of the dividend for both implementations. I have also vince> seen the same claim with no reference to an implementation vince> (e.g. iSCSI) which would imply that the implementation does vince> not matter. I must be sounding like a broken record at this point, but I believe the answer is to use the Ethernet spec as an example. The Ethernet spec has the mathematical definition of the CRC in the body of the spec. In other words, it talks about complementing the message, multiplying by x^32. dividing by G(x), and so forth. That definition is unambiguous. In addition, the Ethernet spec gives an EXAMPLE implementation in appendix C. That is not normative; it merely shows one way to translate the math into gates. In that example implementation -- and NOT in the mathematical definition in the normative part -- it is meaningful to talk about initializing the shift register to all 1's. I would recommend using the same descriptive approach in the iSCSI spec. It may be possible simply to copy the description as it appears there (with suitable alteration to the placement of the LFSR taps, of course, for the sample implementation); I see no copyright claims on the document that prevent doing so. paul From owner-ips@ece.cmu.edu Fri Dec 14 12:51:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04085 for ; Fri, 14 Dec 2001 12:51:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEGfVB28302 for ips-outgoing; Fri, 14 Dec 2001 11:41:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEGfQZ28284; Fri, 14 Dec 2001 11:41:26 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA22254; Fri, 14 Dec 2001 17:41:14 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEGfgs56080; Fri, 14 Dec 2001 17:41:42 +0100 To: pratima Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Few basic doubts MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 18:41:36 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 18:41:40, Serialize complete at 14/12/2001 18:41:40 Content-Type: multipart/alternative; boundary="=_alternative 005B5ECDC2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005B5ECDC2256B22_= Content-Type: text/plain; charset="US-ASCII" owner-ips@ece.cmu.edu wrote on 13-12-2001 22:42:41: > Hi all, > I am just a beginner in iSCSI. I have gone through > draft-ietf-ips-iscsi-09.txt. > I have few basic doubts. I am very thankful if some one clarifies those. > I am listing them. > > 1) Data segment length in the BHS is not including the padding > bytes how to reach the end of PDU. > is it only padded to the nearest integer multiple of 4? > Can we assume like pad can be maximum of 3? > @3.2.1.5 > > 2) Digests are not included in data or header length fields > How do we know Digest is present or not? > @3.2.3 > During Login Negotiation PDU where Digest is negotiated What will be the > digest? > pad bytes are not included in the length (there must be a way to convey the real length) and there are maximum 3 bytes of padding (minimum neede to reach a multiple of 4) > 3) In ISCSI Command format both W and F setting to 0 > is an error. +++ yes it is an error +++ > Read command(R=1) but further reads can follow is not valid? > @ 3.3.1 ??? what is the question ??? > > 4) If the Initiator Sent less than FirstBurstSize( negotiated > maximum amount of unsolicated Data the target will accept) > Why it is an error? > Sending Maximum than allowed can be an error but sending lesser > than allowed how it can be an error? > @ 3.3.5 It may negatively affect performance of targets that send R2T immediately after seeing the command an not waiting to see the F=1 for unsolicited - to "beat" the turnaround time. > > 5) Residual overflow error why it has kept target can read more > and give only what the initiator is requesting. > @ 3.4.1 > > > Pratima > > > > > > > > > > > > > > > > > > > > > > > > > > > --=_alternative 005B5ECDC2256B22_= Content-Type: text/html; charset="US-ASCII"

owner-ips@ece.cmu.edu wrote on 13-12-2001 22:42:41:

> Hi all,
> I am just a beginner in iSCSI. I have gone through
> draft-ietf-ips-iscsi-09.txt.
> I have few basic doubts. I am very thankful if some one clarifies those.
> I am listing them.
>
> 1) Data segment length in the BHS is not including the padding
>    bytes how to reach the end of PDU.
>    is it only padded to the nearest integer multiple of 4?
>    Can we assume like pad can be maximum of 3?
>    @3.2.1.5
>
> 2) Digests are not included in data or header length fields
>    How do we know Digest is present or not?
>    @3.2.3
>    During Login Negotiation PDU where Digest is negotiated What will be the
> digest?
>
pad bytes are not included in the length (there must be a way to convey the real length) and there are maximum 3 bytes of padding (minimum neede to reach a multiple of 4)
 
> 3) In ISCSI Command format both W and F setting to 0
>    is an error.

+++ yes it is an error +++
>    Read command(R=1) but further reads can follow is not valid?
>    @ 3.3.1
??? what is the question ???
>
> 4) If the Initiator Sent less than FirstBurstSize( negotiated
>    maximum amount of unsolicated Data the target will accept)
>    Why it is an error?
>    Sending Maximum than allowed can be an error but sending lesser
>    than allowed how it can be an error?
>    @ 3.3.5

It may negatively affect performance of targets that send R2T immediately after seeing the command an not waiting to see the F=1 for unsolicited - to "beat" the turnaround time.
>
> 5) Residual overflow error why it has kept target can read more
>    and give only what the initiator is requesting.
>    @ 3.4.1
>
>
> Pratima
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>  
>
--=_alternative 005B5ECDC2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 12:55:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04131 for ; Fri, 14 Dec 2001 12:55:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEHFjL00788 for ips-outgoing; Fri, 14 Dec 2001 12:15:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEHFeZ00776 for ; Fri, 14 Dec 2001 12:15:40 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA20586 for ; Fri, 14 Dec 2001 18:15:32 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEHFbO151476 for ; Fri, 14 Dec 2001 18:15:37 +0100 To: ips@ece.cmu.edu Subject: Re: iSCSI: Checking the I bit MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 19:15:29 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 19:15:33, Serialize complete at 14/12/2001 19:15:33 Content-Type: multipart/alternative; boundary="=_alternative 005DEB00C2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005DEB00C2256B22_= Content-Type: text/plain; charset="US-ASCII" I think that Eddy's suggestion to state that parties have to check only what they have to check is valuable and we may want to include a general statement about that. Julo John Hufferd Sent by: owner-ips@ece.cmu.edu 14-12-01 09:55 To: "Eddy Quicksall" cc: "ips@ece. cmu. edu \(E-mail\)" Subject: Re: iSCSI: Checking the I bit Eddy, Technically, the In coming PDUs all have Byte 0, Bit 6, set to one. It is not identified as the I (Immediate) bit. And it is NOT reserved. So the Statement from the UNH Plugfest does not apply. I think your point is that if all the incoming PDUs have that bit set, why do we need to set the bit, and why do we need to check it. I think this bit has evolved over time, and perhaps up to now no one has noticed. If every incoming PDU has the bit set, we may not need the bit to be set, and perhaps it should be reserved, thereby not requiring the check. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/13/2001 03:26:18 AM Sent by: owner-ips@ece.cmu.edu To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: Checking the I bit Is it necessary for the initiator to check the I bit in every response? If an initiator does not need it, then I don't want to take the extra time to check it. I think this is consistent with the thinking of all attendees of the UNH Plug Fest because the report from UNH IOL was that "all companies failed that test". I would like to propose adding some wording to 3.2.1.1 similar to "It is not necessary to check this bit for 1 if the implementation in the initiator does not need its use". Eddy_Quicksall@iVivity.com --=_alternative 005DEB00C2256B22_= Content-Type: text/html; charset="US-ASCII"
I think that Eddy's suggestion to state that parties have to check only what they have to check is valuable and we may want to include a general statement about that.

Julo


John Hufferd
Sent by: owner-ips@ece.cmu.edu

14-12-01 09:55

       
        To:        "Eddy Quicksall" <Eddy@Quicksall.com>
        cc:        "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
        Subject:        Re: iSCSI: Checking the I bit




Eddy,
Technically, the In coming PDUs all have Byte 0, Bit 6, set to one.  It is
not identified as the I (Immediate) bit.  And it is NOT reserved.

So the Statement from the UNH Plugfest does not apply.  I think your point
is that if all the incoming PDUs have that bit set, why do we need to set
the bit, and why do we need to check it.  I think this bit has evolved over
time, and perhaps up to now no one has noticed.

If every incoming PDU has the bit set, we may not need the bit to be set,
and perhaps it should be reserved, thereby not requiring the check.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


"Eddy Quicksall" <Eddy@Quicksall.com>@ece.cmu.edu on 12/13/2001 03:26:18 AM

Sent by:  owner-ips@ece.cmu.edu


To:   "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Checking the I bit




Is it necessary for  the initiator to check the I bit in every response?

If an initiator does  not need it, then I don't want to take the extra time
to check it. I think this  is consistent with the thinking of all attendees
of the UNH Plug Fest because  the report from UNH IOL was that "all
companies failed that  test".

I would like to  propose adding some wording to 3.2.1.1 similar to "It is
not necessary to check  this bit for 1 if the implementation in the
initiator does not need its  use".

Eddy_Quicksall@iVivity.com

--=_alternative 005DEB00C2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 13:34:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04777 for ; Fri, 14 Dec 2001 13:34:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEHej002632 for ips-outgoing; Fri, 14 Dec 2001 12:40:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEHecZ02607 for ; Fri, 14 Dec 2001 12:40:38 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.00) id A8273FCC00CE; Fri, 14 Dec 2001 11:34:31 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A965847010E; Fri, 14 Dec 2001 11:39:49 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: markers explanation Date: Fri, 14 Dec 2001 12:12:05 -0500 Message-ID: <001a01c184c6$4b14a600$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C1849C.623E9E00" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C1849C.623E9E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Julian, The explanation of markers says: Anything counted in the TCP sequence-number is counted for the offset. Specifically this includes any bytes "inserted" in the TCP stream by an UFL and it excludes any other markers inserted between the one we are examining and the next PDU header. The part that says “specifically” seems to contradict the previous sentence because the markers are counted in the TCP sequence-number. May I suggest changing it to: With one exception, anything counted in the TCP sequence-number is counted for the offset. Specifically this includes any bytes "inserted" in the TCP stream by an UFL. The exception excludes any other markers inserted between the one we are examining and the next PDU header. Eddy ------=_NextPart_000_001B_01C1849C.623E9E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Julian,

 

The explanation of markers says:

 

 Anything counted in the TCP sequence-number is

 counted for the offset. = Specifically this includes any bytes

 "inserted" in the TCP = stream by an UFL and it excludes any other

 markers inserted between the = one we are examining and the next PDU

 header.

 

The part that says “specifically” seems to contradict the = previous sentence because the markers are counted in the TCP sequence-number. May I suggest = changing it to:

 

 With one exception, anything = counted in the TCP sequence-number is

 counted for the offset. = Specifically this includes any bytes

 "inserted" in the TCP = stream by an UFL. The exception excludes any other

 markers inserted between the = one we are examining and the next PDU

 header.

 

Eddy

 

 

 

 <= /p>

------=_NextPart_000_001B_01C1849C.623E9E00-- From owner-ips@ece.cmu.edu Fri Dec 14 13:34:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04788 for ; Fri, 14 Dec 2001 13:34:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEHmmB03298 for ips-outgoing; Fri, 14 Dec 2001 12:48:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEHmgZ03292; Fri, 14 Dec 2001 12:48:42 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id SAA06576; Fri, 14 Dec 2001 18:48:30 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEHmms99190; Fri, 14 Dec 2001 18:48:57 +0100 To: "Ted Kuo" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu Subject: Re: ESP tunnel mode or transport mode MUST be implemented? MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 19:48:43 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 19:48:55, Serialize complete at 14/12/2001 19:48:55 Content-Type: multipart/alternative; boundary="=_alternative 00617C7BC2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00617C7BC2256B22_= Content-Type: text/plain; charset="US-ASCII" This is subject to debate and will be solved up-to/at the interim meeting in February. Julo owner-ips@ece.cmu.edu wrote on 14-12-2001 03:34:41: > While I am reading iscsi drafts, I found the following potential conflict > > between drafts. > > > > In Section 2.3 of the latest securing iscsi, ifcp, fcip draft (06),it states > > compliant iscsi implementation "MUST support ESP transport mode" while > > in Section 10.3.1 of the latest iSCSI draft (09), it states ESP tunnel mode > > must be implemented. > > > > I am new to the list and would appreciate a private email if this issue has > > been resovled in the list already. > > > > Thanks, > > Ted --=_alternative 00617C7BC2256B22_= Content-Type: text/html; charset="US-ASCII"
This is subject to debate and will be solved up-to/at the interim meeting in February.

Julo

owner-ips@ece.cmu.edu wrote on 14-12-2001 03:34:41:

> While I am reading iscsi drafts, I found the following potential conflict
>
> between drafts.
>
>  
>
> In Section  2.3 of the latest securing iscsi, ifcp, fcip draft (06),it states
>
> compliant iscsi implementation "MUST support ESP transport mode" while
>
> in Section 10.3.1 of the latest iSCSI draft (09), it states ESP tunnel mode
>
> must be implemented.
>
>  
>
> I am new to the list and would appreciate a private email if this issue has
>
> been resovled in the list already.
>
>  
>
> Thanks,
>
> Ted   --=_alternative 00617C7BC2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 14:29:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05746 for ; Fri, 14 Dec 2001 14:29:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEICPJ04963 for ips-outgoing; Fri, 14 Dec 2001 13:12:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.com (040.dsl6660175.bstatic.surewest.net [66.60.175.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEICJZ04940 for ; Fri, 14 Dec 2001 13:12:19 -0500 (EST) Received: by homer.lmg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 10:10:53 -0800 Message-ID: From: Dean Scoville To: "ips@ece. cmu. edu (E-mail)" Subject: RE: Re: iSCSI Marker questions Date: Fri, 14 Dec 2001 10:10:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C184CA.A7E94F30" Sender: owner-ips@ece.cmu.edu 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_01C184CA.A7E94F30 Content-Type: text/plain; charset="iso-8859-1" Julian, Thanks for the response. Some examples would be very helpful. Your response shows a parameter negotiation with SFMarkInt=1,512 but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt. Is a range also being allowed for SFMarkInt? > > I assume a normal dialogue may go like: > > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 > Section 2.2.4 of the draft currently requires all integer parameter negotiations to have a response . (Responses are optional only with boolean negotiations where the offered value allows only a single outcome -- such as an "OR" boolean function with a "Yes" offer). Are responses always required for RFMarkInt and SFMarkInt, or is the following acceptable? I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4 Would it also be allowed to respond with the following and, if so, is one preferred over the other? (I'm not sure about the current state of using "0" as a "don't care" value, but is that also permitted in cases where the response would be irrelevant?) I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant With the following exchange, is the target required to respond with any RFMarkInt or SFMarkInt values, since there is no real choice of values? Agreeing to send markers implies that the interval is 512, and not agreeing to receive markers implies that there is no receive interval. Is the following allowed, or should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned by the target? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=send Is the following acceptable, even though it doesn't reply to RFMarkInt and SFMarkInt? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=no It would also be helpful to explain what happens if the login phase goes beyond the negotiated first marker interval. Assume, for example, the following: SYN - at TCP sequence num 1000. SYN-ACK - at TCP sequence num 2000. negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100. If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404, full-feature phase starts in the middle of what would have been a marker. Is a partial marker inserted? What would be the TCP seqNum of the first and second marker? If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810, what would be the TCP seqNum of the first and second marker? thanks, Dean -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 11, 2001 4:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questions Link Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. ------_=_NextPart_001_01C184CA.A7E94F30 Content-Type: text/html; charset="iso-8859-1"
Julian,
Thanks for the response. Some examples would be very helpful.
Your response shows a parameter negotiation with SFMarkInt=1,512
but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt.
Is a range also being allowed for SFMarkInt?
 
>
> I assume a normal dialogue may go like:
>
> I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
>
Section 2.2.4 of the draft currently requires all integer parameter
negotiations to have a response . (Responses are optional only
with boolean negotiations where the offered value allows only a
single outcome -- such as an "OR" boolean function with a "Yes"
offer). Are responses always required for RFMarkInt and SFMarkInt,
or is the following acceptable?
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4
 
Would it also be allowed to respond with the following and, if so,
is one preferred over the other? (I'm not sure about the current
state of using "0" as a "don't care" value, but is that also
permitted in cases where the response would be irrelevant?)
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant
 
With the following exchange, is the target required to respond
with any RFMarkInt or SFMarkInt values, since there is no
real choice of values? Agreeing to send markers implies that
the interval is 512, and not agreeing to receive markers implies
that there is no receive interval. Is the following allowed, or
should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned
by the target?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=send
 
Is the following acceptable, even though it doesn't reply to
RFMarkInt and SFMarkInt?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=no
 
It would also be helpful to explain what happens if the login
phase goes beyond the negotiated first marker interval.
Assume, for example, the following:
 
  SYN - at TCP sequence num 1000.
  SYN-ACK - at TCP sequence num 2000.
  negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100.
 
If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404,
full-feature phase starts in the middle of what would have been a marker.
Is a partial marker inserted? What would be the TCP seqNum of the first and
second marker?
 
If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810,
what would be the TCP seqNum of the first and second marker?
 
thanks,
Dean
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 11, 2001 4:54 PM
To: ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker questions


----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


        To:        IPS List
        cc:        
        Subject:        Re: iSCSI Marker questionsLink


Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 
 
> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).


 
> Thanks,
> Dean Scoville
> QLogic Corp.

------_=_NextPart_001_01C184CA.A7E94F30-- From owner-ips@ece.cmu.edu Fri Dec 14 14:31:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05808 for ; Fri, 14 Dec 2001 14:31:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEJ8MK09132 for ips-outgoing; Fri, 14 Dec 2001 14:08:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEJ8KZ09127 for ; Fri, 14 Dec 2001 14:08:20 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id E5BF53586; Fri, 14 Dec 2001 12:08:19 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 4A9C815E; Fri, 14 Dec 2001 12:08:19 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Dec 2001 12:08:19 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 12:08:19 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF771@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Paul Koning'" Cc: ips@ece.cmu.edu, ltuikov@yahoo.com, "SHEEHY,DAVE (A-Americas,unix1)" , "THALER,PAT (A-Roseville,ex1)" , Julian_Satran@il.ibm.com, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: ISCSI: found the constant for divide-only circuit! Date: Fri, 14 Dec 2001 12:08:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Added iSCSI prefix to subject line. Actually both "example" and "preferred" seem inappropriate. How about "reference" or "assumed" implementation? For the claims and examples in the iSCSI spec to be correct we must refer to an implementation that performs the following transformations (responses), after n input bits are applied, on an initial state I(x) and an input M(x): 1. when I(x) is zero, multiplies the input, M(x), by x^32 and divides by G(x). 2. when M(x) is zero, multiplies the initial state, I(x), by x^n and divides by G(x). I have previously provided a serial implementation (the simultaneous multiply-divide circuit) that performs the above tranformations. Any parallel implementation properly derived from such a serial implementation should produce the same transformation and could therefore also be used as references. In contrast, the divide-only serial circuit that I have also provided performs the following transformations on an initial state I(x) and an input M(x) and iSCSI should not refer to it unless it changed some of its claims and examples: 1. when I(x) is zero, divides the input, M(x), by G(x) 2. when M(x) is zero, multiplies the initial state, I(x), by x^n and divides by G(x) Note that, by linearity of the CRC circuit, the overall response or transformation when both I(x) and M(x) are non-zero is the sum of the individual responses to the input and the initial state. Vince -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Friday, December 14, 2001 7:34 AM To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu; ltuikov@yahoo.com; dave_sheehy@agilent.com; pat_thaler@agilent.com; Julian_Satran@il.ibm.com Subject: RE: found the constant for divide-only circuit! Excerpt of message (sent 13 December 2001) by CAVANNA,VICENTE V (A-Roseville,ex1): > I have modified the preferred implementation (simultaneous multiply-divide > circuit) to include the control logic as Paul suggested (similar to ethernet > spec). By showing this circuit the iSCSI spec becomes less ambiguous and, > just maybe, Luben and Paul will be happy men :-). This is good. I have one comment: I'd call this an "example" implementation rather than "preferred". In fact, it is quite likely not the preferred implementation if you have to go flying along at several gigabits per second... And, since it's an example, I'd put it in some appendix. There are other example implementations one might point to, for example the 4 bits at a time table driven approach documented in the VAX architecture manual, or the 8 bits at a time approach documented in a paper by Stuart Wecker from sometime before 1980. I should have the former somewhere; the latter I don't have but I can probably come up with a reference to it. paul From owner-ips@ece.cmu.edu Fri Dec 14 14:31:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05819 for ; Fri, 14 Dec 2001 14:31:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEIw1r08348 for ips-outgoing; Fri, 14 Dec 2001 13:58:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEIvxZ08343 for ; Fri, 14 Dec 2001 13:58:00 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.00) id AA3442ED00CE; Fri, 14 Dec 2001 12:51:32 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id AB7A6910128; Fri, 14 Dec 2001 12:56:58 -0600 From: "Eddy Quicksall" To: "'Julian Satran'" , Subject: RE: iSCSI: Byte1 Bit 7 Seems Not to be reserved Date: Fri, 14 Dec 2001 13:57:20 -0500 Message-ID: <003301c184d1$2971ce00$0102a8c0@eddydesktop> 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit If it is reserved then that means "today I don't know the meaning" but if that is the case, why not make it 0? If it is a "1" for a reason, then it would not fit the meaning of "reserved" (would it?). Draft 7 said bit 7 is a 1 and bits 5-6 were reserved. Wouldn't that be less controversial than saying a "1" is a reserved bit? Maybe I am missing something. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 12:04 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved John, If you are referring to the fact that a reserved bit has to be 0 - that is not so. The statement about reserved is that they are 0 unless explicitly said otherwise. There are some other reserved positions that are set to 1. Julo John Hufferd@IBMUS 14-12-01 10:24 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu Subject: iSCSI: Byte1 Bit 7 Seems Not to be reserved Julian, in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1. Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved. We should probably make those consistent. I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Dec 14 14:33:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05856 for ; Fri, 14 Dec 2001 14:33:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEIC8704913 for ips-outgoing; Fri, 14 Dec 2001 13:12:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEIC6Z04908 for ; Fri, 14 Dec 2001 13:12:06 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA12716 for ; Fri, 14 Dec 2001 19:12:00 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEIBAs59326 for ; Fri, 14 Dec 2001 19:11:10 +0100 To: ips@ece.cmu.edu Subject: Re: iSCSI: markers explanation MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 20:11:05 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 20:11:08, Serialize complete at 14/12/2001 20:11:08 Content-Type: multipart/alternative; boundary="=_alternative 00634DD7C2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00634DD7C2256B22_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable OK The reason for this design is to keep the marker content independent of=20 the marker interval. Please note also that in calculating where to place markers you should=20 assume that markers have been inserted everywhere (including Login)=20 although they are not inserted during login. This will allow parties not=20 to remember where login ended. Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 19:12 =20 To: "ips@ece. cmu. edu \(E-mail\)" cc:=20 Subject: iSCSI: markers explanation Julian, =20 The explanation of markers says: =20 Anything counted in the TCP sequence-number is=20 counted for the offset. Specifically this includes any bytes=20 "inserted" in the TCP stream by an UFL and it excludes any other=20 markers inserted between the one we are examining and the next PDU=20 header. =20 The part that says ?specifically? seems to contradict the previous=20 sentence because the markers are counted in the TCP sequence-number. May I = suggest changing it to: =20 With one exception, anything counted in the TCP sequence-number is=20 counted for the offset. Specifically this includes any bytes=20 "inserted" in the TCP stream by an UFL. The exception excludes any other=20 markers inserted between the one we are examining and the next PDU=20 header. =20 Eddy =20 =20 =20 =20 --=_alternative 00634DD7C2256B22_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
OK

The reason for this design is to kee= p the marker content independent of the marker interval.

Please note also that in calculating= where to place markers you should assume that markers have been inserted e= verywhere (including Login) although they are not inserted during login. &n= bsp;This will allow parties not to remember where login ended.

Julo


"Eddy Quic= ksall" <Eddy=5FQuicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

14-12-01 19:12

      &n= bsp;
        To: &nbs= p;      "ips@ece. cmu. edu \(E-mail\)" <ips@ece= .cmu.edu>
        cc: &nbs= p;      
        Subject:=        iSCSI: markers explanation



Julian,

 

The explanation of markers says:

 
 Anything counted in the TCP s= equence-number is
 counted for the offset. Speci= fically this includes any bytes
 "inserted" in the T= CP stream by an UFL and it excludes any other
 markers inserted between the = one we are examining and the next PDU
 header.
 
The part that says “specifica= lly” seems to contradict the previous sentence because the markers ar= e counted in the TCP sequence-number. May I suggest changing it to:
 
 With one exception, anything = counted in the TCP sequence-number is
 counted for the offset. Speci= fically this includes any bytes
 "inserted" in the T= CP stream by an UFL. The exception excludes any other
 markers inserted between the = one we are examining and the next PDU
 header.
 
Eddy
 
 
 
 

--=_alternative 00634DD7C2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 15:13:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06697 for ; Fri, 14 Dec 2001 15:13:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEJQeY10593 for ips-outgoing; Fri, 14 Dec 2001 14:26:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12805.mail.yahoo.com (web12805.mail.yahoo.com [216.136.174.40]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBEJQbZ10580 for ; Fri, 14 Dec 2001 14:26:37 -0500 (EST) Message-ID: <20011214192636.87447.qmail@web12805.mail.yahoo.com> Received: from [207.219.118.250] by web12805.mail.yahoo.com via HTTP; Fri, 14 Dec 2001 11:26:36 PST Date: Fri, 14 Dec 2001 11:26:36 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "THALER,PAT \(A-Roseville,ex1\)" , Paul Koning , vince_cavanna@agilent.com Cc: ips@ece.cmu.edu, dave_sheehy@agilent.com In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A00955A99A@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "THALER,PAT (A-Roseville,ex1)" wrote: > Paul, > > I agree that we should use the mathematical description > of the CRC as the > spec. I've been trying to convince ppl this since I started to work on iSCSI. Pure math is much clearer, and simple than an implementation. And it woudn't be more than a few lines to describe the algorithm. (A treatment of why it works, would of course be longer than that.) Please note that the draft makes no mention of the Ethernet CRC algo, and I assume there is a reason for it. Else why not say: ``Ethernet CRC algo, with the generator poly be ...''. > Equivalent ways of obtaining the effect of > inverting the first bits or > checking the result (magic number) are implementation > details. I guess that would be true, but one thing needs mentioning: ====================================================== The start point of all those algoritms and circuits is a message premultiplied by x^n (n=degG(x)), e.g. AUGMENTED, and PREFIXED. And then division is done on that, I.e. x^nM(x) + Prefix. ====================================================== Setting an initial value of the CRC register will result in a constant apperaing here and there. Now you want to object to this, and rightly so. Why? Well after analysis, the above said can be so much transformed that it doesn't look like that statement anymore. E.g. Prefixing can be done away with, by adding a constant value to the n MSb of the message; as well as augmentation, by changing the div algo to include mult on the fly. As an exampe of this ``compilation'' is the circuits that Vince has provided. But we need a mathematical description, and by analogy, reading source code makes understanding a lot easier than reading compiled binary code. > I'm not > convinced that we need to show an implementation example > in the annex. Yes we should stick with the way it currently is in the draft: mathematical steps, but make them clearer. > Given > the misleading information that Vince has found in some > of the literature if > we show an implementation example, we need to point out > that the technique > of initializing the register to 1's applies specifically > to that > implementation and may not work for other > implementations. It was I who first brought this up using pure analysis. Maybe you should take a look at the iSCSI archives. When I started work on iSCSI -- the CRC thead was quiet and by word of mouth ppl were implementing Ethernet using the CRC32/4 generator poly. But the description of the draft had some inconsistencies and here we are. > Regards, > Pat Regards, Luben ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Fri Dec 14 15:19:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06786 for ; Fri, 14 Dec 2001 15:19:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEIsLP08072 for ips-outgoing; Fri, 14 Dec 2001 13:54:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEIsIZ08068 for ; Fri, 14 Dec 2001 13:54:18 -0500 (EST) Received: from somesh (sdsl-66-80-0-42.dsl.sca.megapath.net [66.80.0.42]) by eumenes.hosting.pacbell.net id NAA20986; Fri, 14 Dec 2001 13:53:32 -0500 (EST) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Julian Satran" , Subject: RE: iSCSI: abort task & abort task set Date: Fri, 14 Dec 2001 10:52:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01C1848D.5E459C40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0066_01C1848D.5E459C40 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Julian, I like the proposal made at the IETF. I had two follow up questions 1. For targets that only support single connection per session, and do not support error recovery, would it be ok to send the status for the task management command without having to wait for the status ack for all previously sent statuses? 2. I have to analyze in more detail, but there is an interesting case where let us say that the status sent prior to the task management status suffers from a digest error, or a connection failure. The initiator retries the command on another connection. I have not fully figured out the implications of this. Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, December 03, 2001 10:51 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: abort task & abort task set Dear all, On a phone conversation we have agreed to change the required behaviour along those lines enabling the initiator to drop all outstanding commands after a response from a the task management abort/clear-task-set is received. The iSCSI target will carry the burden for waiting for all outstanding statuses on all connections to be acknowledged after receiving the abort confirmation from the SCSI target and sending all statuses before returning the task management response. Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 12-03-01 07:53 PM Please respond to cbm To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: abort task & abort task set Resolution of this certainly requires an offline discussion - which we two plan to have. But one comment to make my proposal clear to the list. > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ That is not possible since as I said above, the 'abort task set' TMF response is sent only after all StatSN "snapshots" are ack'ed on all connections. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 Julian Satran wrote: > > Mallikarjun, > > Comments in text - Julo > > PS - I would like also to point out that we may want to consider a > very simple alternative to the barrier scheme outlined in 9.4 > - that will require less cooperation between initiator and will be > simpler to read and implement. > I will outline such a scheme soon. > > "Mallikarjun C." > To: "ips" > Sent by: owner-ips@ece.cmu.edu > cc: > 12/03/2001 01:33 AM Subject: iSCSI: > abort task & abort task set > > > > Julian, > > iSCSI currently requires two responses to be returned for an aborted > task - > one for the original task with a "good" status, and the second for the > task > management function (TMF) itself. So, the following legal behaviors > are > required of a target - > a) plug the CmdSN gap if the command was not received, > b) send a SCSI response and TMF response if the task still is > active, > c) send a TMF response if the task isn't active (if already > complete). > > I would like to suggest that we reconsider our approach for case (b) > for > a variety of reasons, to change it to: > b) send a TMF response signalling that the abort is complete, if > the > task > still is active. > > Here are my reasons - > > 1. Target iSCSI layer would need to make a SCSI response up on > an abort of an active task. It then follows that the iSCSI > layer > may have to make up several SCSI responses on an 'abort task > set'. > > 2. The current approach also creates a side effect that isn't > readily > apparent for 'abort task set'. Initiators would need to stall > processing > 'abort task set' TMF response till task responses (to account > for > all > the tasks in the task set) on multiple TCP connections > (possibly on > different NICs) are received - which I am afraid would > tantamount to > an initiator scoreboard. > +++ That is not entirely correct. The whole purpose of requiring the > target to send a "good status" is to allow the initiator to send the > response immediately and have the initiator mark its internal data > structures as aborted - but avoid reusing ITT untill it gets the good > answer. > This way initiator can make progress and it can be sure that it won't > be surprised by an "old" answer after it has reused the ITT > +++ > 3. The current approach complicates initiator implementations that > want > to process a successful SCSI completion even after they > initiated > timeout processing since on an 'abort task set', initiators can > never > be sure if the response was pre-abort, or post-abort (made up > "good" > status). I believe it is worth preserving this implementation > choice. > +++ see above +++ > 4. I am further concerned that iSCSI is possibly in violation of > the > spirit of > SAM-2, rev20. > - clause 5.6.2 that states - > "When an initiator causes its own task(s) to be aborted, no > notification > that the task(s) have been aborted shall be > returned to the initiator other than the completion response for the > command > or task management function action > that caused the task(s) to be aborted and notification(s) associated > with > related effects of the action (e.g., a target > reset unit attention condition)." > +++ I did say explicitly that the good status is a "good-will" message > between iSCSI target and initiator. It does not have to reach SCSI. > SAM also allows statuses that have been sent before an abort was > executed but received after the TM response to be delivered or not at > initiators will +++ > - clause 5.3.1 that states - > "GOOD. This status indicates that the device server has successfully > completed the task." > > I propose that the target deliver only the TMF response on an abort of > an active task on an 'abort task' TMF, and not transmit an 'abort task > set' > TMF response until all the current StatSN's on all connections (as on > the > completion of "abort task set') in the session are ack'ed. This ack > may be > solicited by way of a NOP-IN with valid TTT. > > +++ that may result in an initiator reusing prematurely an ITT and > being hit by a late arriving status > for a "former" task - i.e. non-deterministic behavior +++ > > This gives the determinism to initiators that (a) abort task set TMF > response > signifies that the entire task set had been dealt with, and (b) every > task > response > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > doing > away with SCSI-response code in the target iSCSI layer. > > Comments? Did I miss any corner cases? > > +++ see above +++ > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 ------=_NextPart_000_0066_01C1848D.5E459C40 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Julian,
 
I like=20 the proposal made at the IETF. I had two follow up = questions
 
1. For=20 targets that only support single connection per session, and=20 do
not=20 support error recovery, would it be ok to send the status for=20 the
task=20 management command without having to wait for the status = ack
for=20 all previously sent statuses?
 
2. I=20 have to analyze in more detail, but there is an interesting=20 case
where=20 let us say that the status sent prior to the
task=20 management status suffers from a digest error, or a=20 connection
failure. The initiator retries the = command on another=20 connection. I
have=20 not fully figured out the implications of this.
 
Somesh
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Monday, December 03, 2001 10:51 = PM
To:=20 ips@ece.cmu.edu
Subject: Re: iSCSI: abort task & abort = task=20 set


Dear = all,=20

On a phone conversation we = have agreed to=20 change the required behaviour along those lines enabling the initiator = to drop=20 all
outstanding commands = after a=20 response from a the task management abort/clear-task-set is = received.=20
The iSCSI target will carry the = burden for=20 waiting for all outstanding statuses on all connections to be = acknowledged=20 after receiving the abort confirmation from the SCSI target and = sending all=20 statuses before returning the task management response. =

Julo


"Mallikarjun C."=20 <cbm@rose.hp.com>
Sent=20 by: owner-ips@ece.cmu.edu=20

12-03-01 07:53 PM =
Please respond to cbm

        =
        To: =    =20    ips@ece.cmu.edu
        cc:      =20  
    =  =20   Subject:        Re: iSCSI: abort task = &=20 abort task set

  =  =20    


Resolution of this certainly requires an offline discussion = -
which=20 we two plan to have.  But one comment to make my = proposal
clear to the=20 list.

> I propose that the target deliver only the TMF = response on=20 an abort of
> an active task on an 'abort task' TMF, and not = transmit an=20 'abort task
> set'
> TMF response until all the current = StatSN's=20 on all connections (as on
> the
> completion of "abort = task set')=20 in the session are ack'ed.  This ack
> may be
> = solicited by=20 way of a NOP-IN with valid TTT.
>
> +++ that may result = in an=20 initiator reusing prematurely an ITT and
> being hit by a late = arriving=20 status
> for a "former" task - i.e. non-deterministic behavior=20 +++

That is not possible since as I said above, the 'abort task = set'
TMF response is sent only after all StatSN "snapshots" are = ack'ed=20
on all connections.
--
Mallikarjun

Mallikarjun=20 Chadalapaka
Networked Storage Architecture
Network Storage = Solutions=20 Organization
Hewlett-Packard MS 5668
Roseville CA=20 95747


Julian Satran wrote:
>
> = Mallikarjun,
>=20
> Comments in text - Julo
>
> PS - I would like = also to=20 point out that we may want to consider a
> very simple = alternative to=20 the barrier scheme outlined in 9.4
> - that will require less=20 cooperation between initiator and will be
> simpler to read and=20 implement.
> I will outline such a scheme soon.
>
> =  =20 "Mallikarjun C."
>   <cbm@rose.hp.com>     =  =20                 To:   =  =20    "ips"
>   Sent by: owner-ips@ece.cmu.edu=20  <ips@ece.cmu.edu>
>         =  =20                     =  =20           cc:
>   12/03/2001 01:33 = AM=20                     = Subject:=20        iSCSI:
>         =  =20                     =  =20   abort task & abort task set
>
>
> =
>=20 Julian,
>
> iSCSI currently requires two responses to be = returned=20 for an aborted
> task -
> one for the original task with a = "good"=20 status, and the second for the
> task
> management = function (TMF)=20 itself.  So, the following legal behaviors
> are
> = required=20 of a target -
>    a) plug the CmdSN gap if the = command was=20 not received,
>    b) send a SCSI response and TMF = response if=20 the task still is
> active,
>    c) send a TMF = response=20 if the task isn't active (if already
> complete).
> =
> I=20 would like to suggest that we reconsider our approach for case = (b)
>=20 for
> a variety of reasons, to change it to:
>   =  b)=20 send a TMF response signalling that the abort is complete, if
>=20 the
> task
>        still is = active.
>=20
> Here are my reasons -
>
>    1. Target = iSCSI=20 layer would need to make a SCSI response up on
>     =  =20  an abort of an active task.  It then follows that the = iSCSI
>=20 layer
>        may have to make up several = SCSI=20 responses on an 'abort task
> set'.
>
>   2. =  The=20 current approach also creates a side effect that isn't
> = readily
>=20        apparent for 'abort task set'. =  Initiators=20 would need to stall
> processing
>      =20  'abort task set' TMF response till task responses (to = account
>=20 for
> all
> =    =20    the tasks in the task set) on multiple TCP = connections
>=20 (possibly on
>        different NICs) are = received -=20 which I am afraid would
> tantamount to
>     =  =20  an initiator scoreboard.
> +++ That is not entirely = correct. The=20 whole purpose of requiring the
> target to send a "good status" = is to=20 allow the initiator to send the
> response immediately and have = the=20 initiator mark its internal data
> structures as aborted - but = avoid=20 reusing ITT untill it gets the good
> answer.
> This way = initiator=20 can make progress and it can be sure that it won't
> be = surprised by an=20 "old" answer after it has reused the ITT
> +++
>   =  3.=20 The current approach complicates initiator implementations = that
>=20 want
>        to process a successful SCSI=20 completion even after they
> initiated
>     =  =20  timeout processing since on an 'abort task set', initiators = can
>=20 never
>        be sure if the response was=20 pre-abort, or post-abort (made up
> "good"
>     =  =20  status).  I believe it is worth preserving this=20 implementation
> choice.
> +++ see above +++
> =   4.=20  I am further concerned that iSCSI is possibly in violation = of
>=20 the
> spirit of
>        SAM-2, = rev20.
>=20         - clause 5.6.2 that states -
> "When = an=20 initiator causes its own task(s) to be aborted, no
>=20 notification
> that the task(s) have been aborted shall = be
>=20 returned to the initiator other than the completion response for = the
>=20 command
> or task management function action
> that caused = the=20 task(s) to be aborted and notification(s) associated
> = with
>=20 related effects of the action (e.g., a target
> reset unit = attention=20 condition)."
> +++ I did say explicitly that the good status is = a=20 "good-will" message
> between iSCSI target and initiator. It = does not=20 have to reach SCSI.
> SAM also allows statuses that have been = sent=20 before an abort was
> executed but received after the TM = response to be=20 delivered or not at
> initiators will +++
>     =  =20   - clause 5.3.1 that states -
> "GOOD. This status = indicates that=20 the device server has successfully
> completed the = task."
>=20
> I propose that the target deliver only the TMF response on an = abort=20 of
> an active task on an 'abort task' TMF, and not transmit an = 'abort=20 task
> set'
> TMF response until all the current StatSN's = on all=20 connections (as on
> the
> completion of "abort task set') = in the=20 session are ack'ed.  This ack
> may be
> solicited by = way of=20 a NOP-IN with valid TTT.
>
> +++ that may result in an = initiator=20 reusing prematurely an ITT and
> being hit by a late arriving=20 status
> for a "former" task - i.e. non-deterministic behavior=20 +++
>
> This gives the determinism to initiators that =  (a)=20 abort task set TMF
> response
> signifies that the entire = task set=20 had been dealt with, and (b) every
> task
> = response
> is a=20 true SCSI end-to-end reponse (not generated by iSCSI), besides
> = doing
> away with SCSI-response code in the target iSCSI = layer.
>=20
> Comments?  Did I miss any corner cases?
>
> = +++ see=20 above +++
>
> Regards.
> --
> = Mallikarjun
>=20
> Mallikarjun Chadalapaka
> Networked Storage=20 Architecture
> Network Storage Solutions Organization
>=20 Hewlett-Packard MS 5668
> Roseville CA=20 95747


------=_NextPart_000_0066_01C1848D.5E459C40-- From owner-ips@ece.cmu.edu Fri Dec 14 15:19:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06799 for ; Fri, 14 Dec 2001 15:19:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEJXtQ11194 for ips-outgoing; Fri, 14 Dec 2001 14:33:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBEJXrZ11187 for ; Fri, 14 Dec 2001 14:33:53 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBEJXkM13764; Fri, 14 Dec 2001 14:33:46 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBEJXjc09676; Fri, 14 Dec 2001 14:33:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15386.21529.595765.200040@pkoning.dev.equallogic.com> Date: Fri, 14 Dec 2001 14:33:45 -0500 (EST) From: Paul Koning To: vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: RE: ISCSI: found the constant for divide-only circuit! References: <01A7DAF31F93D511AEE300D0B706ED920CF771@axcs13.cos.agilent.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Vince" == A-Roseville,ex1 writes: Vince> Added iSCSI prefix to subject line. Actually both "example" Vince> and "preferred" seem inappropriate. How about "reference" or Vince> "assumed" implementation? That suggest you have to do it (or at least SHOULD do it) the way that is being described, which is not the right thing to say. The thing that has to be stated is the mathematical statement of the CRC value, and the rules of bit order. That and only that is required for interoperability. All else is implementation detail that can certainly be helpful but is in no way normative, and anyone is entirely free to do something completely different so long as the PDUs come out the same. Vince> For the claims and examples in the Vince> iSCSI spec to be correct we must refer to an implementation Vince> that performs the following transformations (responses), after Vince> n input bits are applied, on an initial state I(x) and an Vince> input M(x): Vince> 1. when I(x) is zero, multiplies the input, M(x), by x^32 and Vince> divides by G(x). 2. when M(x) is zero, multiplies the initial Vince> state, I(x), by x^n and divides by G(x). Vince> ... In contrast, the divide-only serial circuit that I have also Vince> provided performs the following transformations on an initial Vince> state I(x) and an input M(x) and iSCSI should not refer to it Vince> unless it changed some of its claims and examples: Vince> 1. when I(x) is zero, divides the input, M(x), by G(x) 2. when Vince> M(x) is zero, multiplies the initial state, I(x), by x^n and Vince> divides by G(x) Those are four example implementations, I think. I'm not sure if giving four examples is better than giving just one, or more confusing. (Perhaps the right answer is to give no examples, as Pat suggested, retaining only the formal mathematical definition; that would match the practice of all other datacomm specs other than Ethernet that I know of.) paul From owner-ips@ece.cmu.edu Fri Dec 14 16:03:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07671 for ; Fri, 14 Dec 2001 16:03:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKZDq16182 for ips-outgoing; Fri, 14 Dec 2001 15:35:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEKZBZ16177 for ; Fri, 14 Dec 2001 15:35:11 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 48BCA1F6EE for ; Fri, 14 Dec 2001 15:35:05 -0500 (EST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA22229 for ; Fri, 14 Dec 2001 12:36:36 -0800 (PST) Message-Id: <200112142036.MAA22229@core.rose.hp.com> Date: Fri, 14 Dec 2001 12:48:11 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: iSCSI: AHS drop bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Section 3.2.2.1 says the following on the AHS drop bit - bit 7 - Drop Bit - if set to 1 this AHS may be ignored if not understood; if set to 0 this AHS must be rejected if not understood. - I suspect it is the entire command that was meant to be failed, not just the AHS... - If it is a SCSI operation that is being failed, I suggest that the target should end the command with an appropriate SCSI CHECK CONDITION - so the command sequence window can advance at the transport level (and the inability of the target to support say extended CDB is known end-to-end, to prevent fruitless SCSI retries). - This bit may be useful for AHS code "Non-iSCSI extensions", but I could not see how it can be used for the defined iSCSI operations. If it is indeed so, I would actually suggest dropping this feature. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Fri Dec 14 16:05:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07693 for ; Fri, 14 Dec 2001 16:05:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKD5G14377 for ips-outgoing; Fri, 14 Dec 2001 15:13:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEKD3Z14371 for ; Fri, 14 Dec 2001 15:13:03 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.00) id ABDE3F6A0100; Fri, 14 Dec 2001 14:06:54 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id AD20218007A; Fri, 14 Dec 2001 14:12:16 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: scope of keys Date: Fri, 14 Dec 2001 15:12:12 -0500 Message-ID: <004001c184db$9ec6fdb0$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C184B1.B5F0F5B0" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C184B1.B5F0F5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Would it make sense to add a “scope” to each key definition? The IO and LO “use:” labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy ------=_NextPart_000_0041_01C184B1.B5F0F5B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Would it make sense to add a “scope” to each key definition? The = IO and LO “use:” labels almost do that but not in all cases. For = example:

 

 SW =3D Session wide =

 CO =3D Connection = only

 

 Use: = IO

 Who can send: = Initiator

 Scope: = SW

 

 Key=3D<value>

 

Eddy<= /span>

------=_NextPart_000_0041_01C184B1.B5F0F5B0-- From owner-ips@ece.cmu.edu Fri Dec 14 16:06:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07718 for ; Fri, 14 Dec 2001 16:06:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKIYP14788 for ips-outgoing; Fri, 14 Dec 2001 15:18:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBEKIVZ14783 for ; Fri, 14 Dec 2001 15:18:32 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBEKID414107; Fri, 14 Dec 2001 15:18:13 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBEKIC916469; Fri, 14 Dec 2001 15:18:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15386.24195.879416.67590@pkoning.dev.equallogic.com> Date: Fri, 14 Dec 2001 15:18:11 -0500 (EST) From: Paul Koning To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: <1BEBA5E8600DD4119A50009027AF54A00955A99A@axcs04.cos.agilent.com> <20011214192636.87447.qmail@web12805.mail.yahoo.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I guess the problem with the spec is that it is a confusing mix of pieces of the mathematical definition and pieces of description from a specific (and unstated) implementation. Ok, so let me propose specific replacement text. This is for Appendix D, starting at the top of page 193 in the -09 rev of the spec. ---------------- The generator polynomial for the CRC is x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + x^18 +x^14 + x+13 + x+11 + x^10 + x^9 + x^8 +x^6 + 1. The CRC value for a PDU is defined mathematically as follows: 1. The first 32 bits of the PDU are complemented. 2. The N bits of the PDU are then considered to be coefficients of a polynomial M(x) of degree N-1. Bit 0 of byte 0, i.e., the low order bit of the high order byte of the first word of the PDU, corresponds to the X^(N-1) term of this polynomial, and the high order bit of the last byte of the PDU corresponds to the x^0 term. Note that any pad bytes for the PDU are included. 3. M(x) is multiplied by x^32, and divided by G(x), producing a remainder R(x) of degree < 32. 4. The coefficients of R(x) are considered to be a 32-bit sequence. 5. This bit sequence is complemented and the result is the CRC. The CRC is trannsmitted with the high order bit (corresponding to the x^31 term of R(x)) in the low order bit of the first byte transmitted, and the low order bit (corresponding to the x^0 term of R(x)) in the high order bit of the fourth byte transmitted. ---------------- This text is inspired by the text in the Ethernet spec, with some wording changes needed for the iSCSI context. I believe this is a precise definition of what is needed. For additional information, more text could be included. For example: ---------------- The above algorithm is exactly that used in the Ethernet/802.3 LAN, with the exception of the choice of generator polynomial. ---------------- And perhaps a note on implementation: ---------------- The above algorithm may be efficiently implemented in a variety of ways, such as linear feedback shift registers, table lookup, etc. ---------------- Finally, we could capture the "magic constant" receive algorithm as follows: ---------------- Implementation of the CRC32C checking for PDU reception can be done in several ways. One approach is to calculate the CRC over the PDU not including the CRC field, and compare that with the received CRC. If the two values are equal, the digest is considered valid. Another approach is to perform the above algorithm over the entire received PDU, including the CRC field. With that approach, a valid digest results in R(x) having the value x^28 + x^27 + x^26 + x^21 + x^19 + x^18 +x^16 + x^12 + x^11 + x^8 + x^7 + x^6 + x^5 + x^3 + x^2 + 1, i.e., the value of the 32-bit sequence obtained in step 4 is 0x1c2d19ed. ---------------- Following Pat Thaler's comments, I am not proposing any more text on implementation approaches. Both the table based approaches and the LFSR approach can be covered by references to literature, though admittedly some of the references may not be all that easy to acquire. So my proposal is to replace the text on page 193 up to the "Proprietary algorithms MAY also..." with the four pieces given above. If people don't like the later pieces, then I'll fall back to proposing just the first chunk of text (the formal definition of the CRC) as replacement for the current text. paul From owner-ips@ece.cmu.edu Fri Dec 14 16:09:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07766 for ; Fri, 14 Dec 2001 16:09:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKO0b15260 for ips-outgoing; Fri, 14 Dec 2001 15:24:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEKNrZ15250 for ; Fri, 14 Dec 2001 15:23:53 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 3F5B83131; Fri, 14 Dec 2001 13:23:52 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id CC99E4CE; Fri, 14 Dec 2001 13:23:51 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 13:23:51 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF774@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Paul Koning'" Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: ISCSI: found the constant for divide-only circuit! Date: Fri, 14 Dec 2001 13:23:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I have to agree that a mathematical description is the best. I had it all worked out months ago until I realized about the bit reversal within each byte which broke my math. At that time I argued against the bit reversal and lost - including my interest. Luben and you rekindled my interest. Luben and I have now pretty much developed the necessary math to unambiguously show the steps but we still have some disagreements on how to present it. In the process we discovered the need to specify the reference circuit. In the meantime I was trying to get the iSCSI spec fixed because, as it stands, it makes an implicit assumption about the implementation without which its claims are wrong. Either the claims must be fixed or the assumed circuit must be specified. One way to specify the circuit is to show the reference implementation and to say that any circuit that performs the same function, ie. has the exact same response to initial state and to the input is also acceptable. Another way is to describe the response of the implied circuit after the application of n input bits is: 1. when I(x) is zero, multiplies the input, M(x), by x^32 and divides by G(x). 2. when M(x) is zero, multiplies the initial state, I(x), by x^n and divides by G(x). where I(x) represents the initial state of the CRC register and M(x) represents the input. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Friday, December 14, 2001 11:34 AM |To: vince_cavanna@agilent.com |Cc: ips@ece.cmu.edu |Subject: RE: ISCSI: found the constant for divide-only circuit! | | |>>>>> "Vince" == A-Roseville,ex1 writes: | | Vince> Added iSCSI prefix to subject line. Actually both "example" | Vince> and "preferred" seem inappropriate. How about "reference" or | Vince> "assumed" implementation? | |That suggest you have to do it (or at least SHOULD do it) the way that |is being described, which is not the right thing to say. The thing |that has to be stated is the mathematical statement of the CRC value, |and the rules of bit order. That and only that is required for |interoperability. | |All else is implementation detail that can certainly be helpful but is |in no way normative, and anyone is entirely free to do something |completely different so long as the PDUs come out the same. | | Vince> For the claims and examples in the | Vince> iSCSI spec to be correct we must refer to an implementation | Vince> that performs the following transformations (responses), after | Vince> n input bits are applied, on an initial state I(x) and an | Vince> input M(x): | | Vince> 1. when I(x) is zero, multiplies the input, M(x), by x^32 and | Vince> divides by G(x). 2. when M(x) is zero, multiplies the initial | Vince> state, I(x), by x^n and divides by G(x). | | Vince> ... In contrast, the divide-only serial circuit that I |have also | Vince> provided performs the following transformations on an initial | Vince> state I(x) and an input M(x) and iSCSI should not refer to it | Vince> unless it changed some of its claims and examples: | | Vince> 1. when I(x) is zero, divides the input, M(x), by G(x) 2. when | Vince> M(x) is zero, multiplies the initial state, I(x), by x^n and | Vince> divides by G(x) | |Those are four example implementations, I think. I'm not sure if |giving four examples is better than giving just one, or more |confusing. (Perhaps the right answer is to give no examples, as Pat |suggested, retaining only the formal mathematical definition; that |would match the practice of all other datacomm specs other than |Ethernet that I know of.) | | paul | From owner-ips@ece.cmu.edu Fri Dec 14 16:47:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08288 for ; Fri, 14 Dec 2001 16:47:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBELGZq19370 for ips-outgoing; Fri, 14 Dec 2001 16:16:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBELGXZ19365 for ; Fri, 14 Dec 2001 16:16:33 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id AED0D400642; Fri, 14 Dec 2001 13:16:27 -0800 (PST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA28318; Fri, 14 Dec 2001 13:17:58 -0800 (PST) Message-ID: <001e01c184e4$9622fd90$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: Cc: "ips" References: Subject: Re: iSCSI: abort task & abort task set Date: Fri, 14 Dec 2001 13:16:24 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh, One comment. > 1. For targets that only support single connection per session, and do > not support error recovery, would it be ok to send the status for the > task management command without having to wait for the status ack > for all previously sent statuses? I think it's okay. (There are other subtle areas here even for ErrorRecoveryLevel=0 - how quickly should a connection/command be failed after the first error that requires recovery? If there are posted good statuses after the lost status, initiator in general can process those - except it should not in this case of 'abort task set'.) OTOH, This approach breaks even for single connection sessions if status recovery is eventually supported. That makes me believe that this choice is an optimization for a specific deployment scenario. IMO, the draft would be generally better off not describing specific scenarios. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Somesh Gupta" To: "Julian Satran" ; Sent: Friday, December 14, 2001 10:52 AM Subject: RE: iSCSI: abort task & abort task set > Julian, > > I like the proposal made at the IETF. I had two follow up questions > > 1. For targets that only support single connection per session, and do > not support error recovery, would it be ok to send the status for the > task management command without having to wait for the status ack > for all previously sent statuses? > > 2. I have to analyze in more detail, but there is an interesting case > where let us say that the status sent prior to the > task management status suffers from a digest error, or a connection > failure. The initiator retries the command on another connection. I > have not fully figured out the implications of this. > > Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, December 03, 2001 10:51 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: abort task & abort task set > > > > Dear all, > > On a phone conversation we have agreed to change the required behaviour > along those lines enabling the initiator to drop all > outstanding commands after a response from a the task management > abort/clear-task-set is received. > The iSCSI target will carry the burden for waiting for all outstanding > statuses on all connections to be acknowledged after receiving the abort > confirmation from the SCSI target and sending all statuses before returning > the task management response. > > Julo > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > 12-03-01 07:53 PM > Please respond to cbm > > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: abort task & abort task set > > > > > Resolution of this certainly requires an offline discussion - > which we two plan to have. But one comment to make my proposal > clear to the list. > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > That is not possible since as I said above, the 'abort task set' > TMF response is sent only after all StatSN "snapshots" are ack'ed > on all connections. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > > Julian Satran wrote: > > > > Mallikarjun, > > > > Comments in text - Julo > > > > PS - I would like also to point out that we may want to consider a > > very simple alternative to the barrier scheme outlined in 9.4 > > - that will require less cooperation between initiator and will be > > simpler to read and implement. > > I will outline such a scheme soon. > > > > "Mallikarjun C." > > To: "ips" > > Sent by: owner-ips@ece.cmu.edu > > cc: > > 12/03/2001 01:33 AM Subject: iSCSI: > > abort task & abort task set > > > > > > > > Julian, > > > > iSCSI currently requires two responses to be returned for an aborted > > task - > > one for the original task with a "good" status, and the second for the > > task > > management function (TMF) itself. So, the following legal behaviors > > are > > required of a target - > > a) plug the CmdSN gap if the command was not received, > > b) send a SCSI response and TMF response if the task still is > > active, > > c) send a TMF response if the task isn't active (if already > > complete). > > > > I would like to suggest that we reconsider our approach for case (b) > > for > > a variety of reasons, to change it to: > > b) send a TMF response signalling that the abort is complete, if > > the > > task > > still is active. > > > > Here are my reasons - > > > > 1. Target iSCSI layer would need to make a SCSI response up on > > an abort of an active task. It then follows that the iSCSI > > layer > > may have to make up several SCSI responses on an 'abort task > > set'. > > > > 2. The current approach also creates a side effect that isn't > > readily > > apparent for 'abort task set'. Initiators would need to stall > > processing > > 'abort task set' TMF response till task responses (to account > > for > > all > > the tasks in the task set) on multiple TCP connections > > (possibly on > > different NICs) are received - which I am afraid would > > tantamount to > > an initiator scoreboard. > > +++ That is not entirely correct. The whole purpose of requiring the > > target to send a "good status" is to allow the initiator to send the > > response immediately and have the initiator mark its internal data > > structures as aborted - but avoid reusing ITT untill it gets the good > > answer. > > This way initiator can make progress and it can be sure that it won't > > be surprised by an "old" answer after it has reused the ITT > > +++ > > 3. The current approach complicates initiator implementations that > > want > > to process a successful SCSI completion even after they > > initiated > > timeout processing since on an 'abort task set', initiators can > > never > > be sure if the response was pre-abort, or post-abort (made up > > "good" > > status). I believe it is worth preserving this implementation > > choice. > > +++ see above +++ > > 4. I am further concerned that iSCSI is possibly in violation of > > the > > spirit of > > SAM-2, rev20. > > - clause 5.6.2 that states - > > "When an initiator causes its own task(s) to be aborted, no > > notification > > that the task(s) have been aborted shall be > > returned to the initiator other than the completion response for the > > command > > or task management function action > > that caused the task(s) to be aborted and notification(s) associated > > with > > related effects of the action (e.g., a target > > reset unit attention condition)." > > +++ I did say explicitly that the good status is a "good-will" message > > between iSCSI target and initiator. It does not have to reach SCSI. > > SAM also allows statuses that have been sent before an abort was > > executed but received after the TM response to be delivered or not at > > initiators will +++ > > - clause 5.3.1 that states - > > "GOOD. This status indicates that the device server has successfully > > completed the task." > > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > > > This gives the determinism to initiators that (a) abort task set TMF > > response > > signifies that the entire task set had been dealt with, and (b) every > > task > > response > > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > > doing > > away with SCSI-response code in the target iSCSI layer. > > > > Comments? Did I miss any corner cases? > > > > +++ see above +++ > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > From owner-ips@ece.cmu.edu Fri Dec 14 16:48:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08306 for ; Fri, 14 Dec 2001 16:48:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEL3mu18416 for ips-outgoing; Fri, 14 Dec 2001 16:03:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-68.crossroads.com [65.68.235.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEL3iZ18409 for ; Fri, 14 Dec 2001 16:03:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: iSCSI: Security (SRP) Disposition-Notification-To: "Lee Xing" Date: Fri, 14 Dec 2001 15:03:44 -0600 Message-ID: Thread-Topic: iSCSI: Security (SRP) Thread-Index: AcGE4tDUkGUIiDBcS8+2M/PuPFrWMg== From: "Lee Xing" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBEL3jZ18411 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I got a question on iSCSI security-SRP, and would appreciate it if someone could help. Based on iSCSI v.09, several key=value pairs are used to exchange SRP parameters and keys. Such as: SRP_N= SRP_g= SRP_s= SRP_A= SRP_B= SRP_M= SRP_HM= The question is what types of data formats should be used for each key=value pair? Should decimal, hex, base64 or something else be used? It seems iSCSI v.09 or RTF2945 don't specify it. Thanks. Lee Xing Crossroads Systems, Inc. From owner-ips@ece.cmu.edu Fri Dec 14 16:49:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08317 for ; Fri, 14 Dec 2001 16:49:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKvcA17923 for ips-outgoing; Fri, 14 Dec 2001 15:57:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEKvbZ17919 for ; Fri, 14 Dec 2001 15:57:37 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA83600 for ; Fri, 14 Dec 2001 21:55:23 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEKoNO199196 for ; Fri, 14 Dec 2001 21:50:24 +0100 To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 22:50:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 22:50:19, Serialize complete at 14/12/2001 22:50:19 Content-Type: multipart/alternative; boundary="=_alternative 007234A5C2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007234A5C2256B22_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, I think the text says it - but if people love headers better I can add it=20 (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 =20 To: "ips@ece. cmu. edu \(E-mail\)" cc:=20 Subject: iSCSI: scope of keys =20 Would it make sense to add a ?scope? to each key definition? The IO and LO = ?use:? labels almost do that but not in all cases. For example: =20 SW =3D Session wide=20 CO =3D Connection only =20 Use: IO Who can send: Initiator Scope: SW =20 Key=3D =20 Eddy --=_alternative 007234A5C2256B22_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eddy,

I think the text says it - but if pe= ople love headers better I can add it (some voices needed).

Julo


"Eddy Quic= ksall" <Eddy=5FQuicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

14-12-01 22:12

      &n= bsp;
        To: &nbs= p;      "ips@ece. cmu. edu \(E-mail\)" <ips@ece= .cmu.edu>
        cc: &nbs= p;      
        Subject:=        iSCSI: scope of keys



 

Would it make sense to add a “scope&= #8221; to each key definition? The IO and LO “use:” labels almo= st do that but not in all cases. For example:

 

 SW =3D Session wide

 CO =3D Connection only

 

 Use: IO

 Who can send: Initiator

 Scope: SW

 

 Key=3D<value>

 

Eddy

--=_alternative 007234A5C2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 16:49:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08328 for ; Fri, 14 Dec 2001 16:49:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEKvPm17908 for ips-outgoing; Fri, 14 Dec 2001 15:57:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEKv5Z17875 for ; Fri, 14 Dec 2001 15:57:05 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id VAA65276; Fri, 14 Dec 2001 21:50:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBEKoFs131354; Fri, 14 Dec 2001 21:50:20 +0100 To: Cc: ips@ece.cmu.edu Subject: RE: iSCSI: abort task & abort task set MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Fri, 14 Dec 2001 22:49:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/12/2001 22:50:12, Serialize complete at 14/12/2001 22:50:12 Content-Type: multipart/alternative; boundary="=_alternative 0071BE92C2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0071BE92C2256B22_= Content-Type: text/plain; charset="US-ASCII" Somesh, "Somesh Gupta" wrote on 14-12-2001 20:52:04: > Julian, > > > > I like the proposal made at the IETF. I had two follow up questions > > > > 1. For targets that only support single connection per session, and do > > not support error recovery, would it be ok to send the status for the > > task management command without having to wait for the status ack > > for all previously sent statuses? > > I assume that you are on safe ground as the target is doing it and no one could be wiser (no way to observe extrnally any difference) and there is no need to specify this behavior. Or is it? > > 2. I have to analyze in more detail, but there is an interesting case > > where let us say that the status sent prior to the > > task management status suffers from a digest error, or a connection > > failure. The initiator retries the command on another connection. I > > have not fully figured out the implications of this. > > Statuses are recovered by SNACK. I doubt initiators will retry abborted commands! > > Somesh > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, December 03, 2001 10:51 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: abort task & abort task set > > > Dear all, > > On a phone conversation we have agreed to change the required > behaviour along those lines enabling the initiator to drop all > outstanding commands after a response from a the task management > abort/clear-task-set is received. > The iSCSI target will carry the burden for waiting for all > outstanding statuses on all connections to be acknowledged after > receiving the abort confirmation from the SCSI target and sending > all statuses before returning the task management response. > > Julo > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > > 12-03-01 07:53 PM > Please respond to cbm > > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: abort task & abort task set > > > > > > Resolution of this certainly requires an offline discussion - > which we two plan to have. But one comment to make my proposal > clear to the list. > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > That is not possible since as I said above, the 'abort task set' > TMF response is sent only after all StatSN "snapshots" are ack'ed > on all connections. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > > Julian Satran wrote: > > > > Mallikarjun, > > > > Comments in text - Julo > > > > PS - I would like also to point out that we may want to consider a > > very simple alternative to the barrier scheme outlined in 9.4 > > - that will require less cooperation between initiator and will be > > simpler to read and implement. > > I will outline such a scheme soon. > > > > "Mallikarjun C." > > To: "ips" > > Sent by: owner-ips@ece.cmu.edu > > cc: > > 12/03/2001 01:33 AM Subject: iSCSI: > > abort task & abort task set > > > > > > > > Julian, > > > > iSCSI currently requires two responses to be returned for an aborted > > task - > > one for the original task with a "good" status, and the second for the > > task > > management function (TMF) itself. So, the following legal behaviors > > are > > required of a target - > > a) plug the CmdSN gap if the command was not received, > > b) send a SCSI response and TMF response if the task still is > > active, > > c) send a TMF response if the task isn't active (if already > > complete). > > > > I would like to suggest that we reconsider our approach for case (b) > > for > > a variety of reasons, to change it to: > > b) send a TMF response signalling that the abort is complete, if > > the > > task > > still is active. > > > > Here are my reasons - > > > > 1. Target iSCSI layer would need to make a SCSI response up on > > an abort of an active task. It then follows that the iSCSI > > layer > > may have to make up several SCSI responses on an 'abort task > > set'. > > > > 2. The current approach also creates a side effect that isn't > > readily > > apparent for 'abort task set'. Initiators would need to stall > > processing > > 'abort task set' TMF response till task responses (to account > > for > > all > > the tasks in the task set) on multiple TCP connections > > (possibly on > > different NICs) are received - which I am afraid would > > tantamount to > > an initiator scoreboard. > > +++ That is not entirely correct. The whole purpose of requiring the > > target to send a "good status" is to allow the initiator to send the > > response immediately and have the initiator mark its internal data > > structures as aborted - but avoid reusing ITT untill it gets the good > > answer. > > This way initiator can make progress and it can be sure that it won't > > be surprised by an "old" answer after it has reused the ITT > > +++ > > 3. The current approach complicates initiator implementations that > > want > > to process a successful SCSI completion even after they > > initiated > > timeout processing since on an 'abort task set', initiators can > > never > > be sure if the response was pre-abort, or post-abort (made up > > "good" > > status). I believe it is worth preserving this implementation > > choice. > > +++ see above +++ > > 4. I am further concerned that iSCSI is possibly in violation of > > the > > spirit of > > SAM-2, rev20. > > - clause 5.6.2 that states - > > "When an initiator causes its own task(s) to be aborted, no > > notification > > that the task(s) have been aborted shall be > > returned to the initiator other than the completion response for the > > command > > or task management function action > > that caused the task(s) to be aborted and notification(s) associated > > with > > related effects of the action (e.g., a target > > reset unit attention condition)." > > +++ I did say explicitly that the good status is a "good-will" message > > between iSCSI target and initiator. It does not have to reach SCSI. > > SAM also allows statuses that have been sent before an abort was > > executed but received after the TM response to be delivered or not at > > initiators will +++ > > - clause 5.3.1 that states - > > "GOOD. This status indicates that the device server has successfully > > completed the task." > > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > > > This gives the determinism to initiators that (a) abort task set TMF > > response > > signifies that the entire task set had been dealt with, and (b) every > > task > > response > > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > > doing > > away with SCSI-response code in the target iSCSI layer. > > > > Comments? Did I miss any corner cases? > > > > +++ see above +++ > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > --=_alternative 0071BE92C2256B22_= Content-Type: text/html; charset="US-ASCII"
Somesh,

"Somesh Gupta" <somesh_gupta@silverbacksystems.com> wrote on 14-12-2001 20:52:04:

> Julian,
>
>  
>
> I like the proposal made at the IETF. I had two follow up questions
>
>  
>
> 1. For targets that only support single connection per session, and do
>
> not support error recovery, would it be ok to send the status for the
>
> task management command without having to wait for the status ack
>
> for all previously sent statuses?
>
>
I assume that you are on safe ground as the target is doing it and no one could be wiser
(no way to observe extrnally any difference) and there is no need to specify this behavior. Or is it?
 
>
> 2. I have to analyze in more detail, but there is an interesting case
>
> where let us say that the status sent prior to the
>
> task management status suffers from a digest error, or a connection
>
> failure. The initiator retries the command on another connection. I
>
> have not fully figured out the implications of this.
>
>
Statuses are recovered by SNACK. I doubt initiators will retry abborted commands!

>
> Somesh
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Monday, December 03, 2001 10:51 PM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: abort task & abort task set
>
>
> Dear all,
>
> On a phone conversation we have agreed to change the required
> behaviour along those lines enabling the initiator to drop all
> outstanding commands after a response from a the task management
> abort/clear-task-set is received.
> The iSCSI target will carry the burden for waiting for all
> outstanding statuses on all connections to be acknowledged after
> receiving the abort confirmation from the SCSI target and sending
> all statuses before returning the task management response.
>
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>
> Sent by: owner-ips@ece.cmu.edu
>
> 12-03-01 07:53 PM
> Please respond to cbm
>
>        
>         To:        ips@ece.cmu.edu
>         cc:        
>         Subject:        Re: iSCSI: abort task & abort task set
>
>        
>
>
>
> Resolution of this certainly requires an offline discussion -
> which we two plan to have.  But one comment to make my proposal
> clear to the list.
>
> > I propose that the target deliver only the TMF response on an abort of
> > an active task on an 'abort task' TMF, and not transmit an 'abort task
> > set'
> > TMF response until all the current StatSN's on all connections (as on
> > the
> > completion of "abort task set') in the session are ack'ed.  This ack
> > may be
> > solicited by way of a NOP-IN with valid TTT.
> >
> > +++ that may result in an initiator reusing prematurely an ITT and
> > being hit by a late arriving status
> > for a "former" task - i.e. non-deterministic behavior +++
>
> That is not possible since as I said above, the 'abort task set'
> TMF response is sent only after all StatSN "snapshots" are ack'ed
> on all connections.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
>
>
> Julian Satran wrote:
> >
> > Mallikarjun,
> >
> > Comments in text - Julo
> >
> > PS - I would like also to point out that we may want to consider a
> > very simple alternative to the barrier scheme outlined in 9.4
> > - that will require less cooperation between initiator and will be
> > simpler to read and implement.
> > I will outline such a scheme soon.
> >
> >   "Mallikarjun C."
> >   <cbm@rose.hp.com>                       To:        "ips"
> >   Sent by: owner-ips@ece.cmu.edu  <ips@ece.cmu.edu>
> >                                           cc:
> >   12/03/2001 01:33 AM                     Subject:        iSCSI:
> >                                   abort task & abort task set
> >
> >
> >
> > Julian,
> >
> > iSCSI currently requires two responses to be returned for an aborted
> > task -
> > one for the original task with a "good" status, and the second for the
> > task
> > management function (TMF) itself.  So, the following legal behaviors
> > are
> > required of a target -
> >    a) plug the CmdSN gap if the command was not received,
> >    b) send a SCSI response and TMF response if the task still is
> > active,
> >    c) send a TMF response if the task isn't active (if already
> > complete).
> >
> > I would like to suggest that we reconsider our approach for case (b)
> > for
> > a variety of reasons, to change it to:
> >    b) send a TMF response signalling that the abort is complete, if
> > the
> > task
> >        still is active.
> >
> > Here are my reasons -
> >
> >    1. Target iSCSI layer would need to make a SCSI response up on
> >        an abort of an active task.  It then follows that the iSCSI
> > layer
> >        may have to make up several SCSI responses on an 'abort task
> > set'.
> >
> >   2.  The current approach also creates a side effect that isn't
> > readily
> >        apparent for 'abort task set'.  Initiators would need to stall
> > processing
> >        'abort task set' TMF response till task responses (to account
> > for
> > all
> >        the tasks in the task set) on multiple TCP connections
> > (possibly on
> >        different NICs) are received - which I am afraid would
> > tantamount to
> >        an initiator scoreboard.
> > +++ That is not entirely correct. The whole purpose of requiring the
> > target to send a "good status" is to allow the initiator to send the
> > response immediately and have the initiator mark its internal data
> > structures as aborted - but avoid reusing ITT untill it gets the good
> > answer.
> > This way initiator can make progress and it can be sure that it won't
> > be surprised by an "old" answer after it has reused the ITT
> > +++
> >    3. The current approach complicates initiator implementations that
> > want
> >        to process a successful SCSI completion even after they
> > initiated
> >        timeout processing since on an 'abort task set', initiators can
> > never
> >        be sure if the response was pre-abort, or post-abort (made up
> > "good"
> >        status).  I believe it is worth preserving this implementation
> > choice.
> > +++ see above +++
> >   4.  I am further concerned that iSCSI is possibly in violation of
> > the
> > spirit of
> >        SAM-2, rev20.
> >         - clause 5.6.2 that states -
> > "When an initiator causes its own task(s) to be aborted, no
> > notification
> > that the task(s) have been aborted shall be
> > returned to the initiator other than the completion response for the
> > command
> > or task management function action
> > that caused the task(s) to be aborted and notification(s) associated
> > with
> > related effects of the action (e.g., a target
> > reset unit attention condition)."
> > +++ I did say explicitly that the good status is a "good-will" message
> > between iSCSI target and initiator. It does not have to reach SCSI.
> > SAM also allows statuses that have been sent before an abort was
> > executed but received after the TM response to be delivered or not at
> > initiators will +++
> >         - clause 5.3.1 that states -
> > "GOOD. This status indicates that the device server has successfully
> > completed the task."
> >
> > I propose that the target deliver only the TMF response on an abort of
> > an active task on an 'abort task' TMF, and not transmit an 'abort task
> > set'
> > TMF response until all the current StatSN's on all connections (as on
> > the
> > completion of "abort task set') in the session are ack'ed.  This ack
> > may be
> > solicited by way of a NOP-IN with valid TTT.
> >
> > +++ that may result in an initiator reusing prematurely an ITT and
> > being hit by a late arriving status
> > for a "former" task - i.e. non-deterministic behavior +++
> >
> > This gives the determinism to initiators that  (a) abort task set TMF
> > response
> > signifies that the entire task set had been dealt with, and (b) every
> > task
> > response
> > is a true SCSI end-to-end reponse (not generated by iSCSI), besides
> > doing
> > away with SCSI-response code in the target iSCSI layer.
> >
> > Comments?  Did I miss any corner cases?
> >
> > +++ see above +++
> >
> > Regards.
> > --
> > Mallikarjun
> >
> > Mallikarjun Chadalapaka
> > Networked Storage Architecture
> > Network Storage Solutions Organization
> > Hewlett-Packard MS 5668
> > Roseville CA 95747
>
--=_alternative 0071BE92C2256B22_=-- From owner-ips@ece.cmu.edu Fri Dec 14 16:50:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08339 for ; Fri, 14 Dec 2001 16:50:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBEL96w18812 for ips-outgoing; Fri, 14 Dec 2001 16:09:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBEL94Z18806 for ; Fri, 14 Dec 2001 16:09:04 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 2764634B3; Fri, 14 Dec 2001 14:09:04 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 093B115E; Fri, 14 Dec 2001 14:09:04 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 14:09:03 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF464D@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Paul Koning'" , ltuikov@yahoo.com Cc: ips@ece.cmu.edu, "CAVANNA,VICENTE V (A-Roseville,ex1)" Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Fri, 14 Dec 2001 14:09:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, Looks fine as long as one realizes that: 1. If someone choses to use the divide-only circuit that is commonly found in texts they cannot initialize the registers to 1's and hope to achieve the same effect as complementing the first 32 bits of the PDU. 2. If someone choses to use the multiply-divide circuit as in ethernet spec they can initialize the registers to 1's and achieve the same effect as complementing the first 32 bits of the PDU. I am pretty sure the intent in predecessors to the ethernet spec (FDDI, HDLC) was to initialize the registers of the implementation to ones. The effect, for the referenced implementation which was a multiply-divide implementation, could be obtained by complementing the most significant bits of the message. Vince |-----Original Message----- |From: Paul Koning [mailto:ni1d@arrl.net] |Sent: Friday, December 14, 2001 12:18 PM |To: ltuikov@yahoo.com |Cc: ips@ece.cmu.edu |Subject: RE: effect of initializing CRC reg to 1's depends on |implementati on? iSCSI | | |I guess the problem with the spec is that it is a confusing mix of |pieces of the mathematical definition and pieces of description from a |specific (and unstated) implementation. | |Ok, so let me propose specific replacement text. | |This is for Appendix D, starting at the top of page 193 in the -09 rev |of the spec. | |---------------- |The generator polynomial for the CRC is x^32 + x^28 + x^27 + x^26 + |x^25 + x^23 + x^22 + x^20 + x^19 + x^18 +x^14 + x+13 + x+11 + x^10 + |x^9 + x^8 +x^6 + 1. | |The CRC value for a PDU is defined mathematically as follows: | |1. The first 32 bits of the PDU are complemented. | |2. The N bits of the PDU are then considered to be coefficients of a |polynomial M(x) of degree N-1. Bit 0 of byte 0, i.e., the low order |bit of the high order byte of the first word of the PDU, corresponds |to the X^(N-1) term of this polynomial, and the high order bit of the |last byte of the PDU corresponds to the x^0 term. Note that any pad |bytes for the PDU are included. | |3. M(x) is multiplied by x^32, and divided by G(x), producing a |remainder R(x) of degree < 32. | |4. The coefficients of R(x) are considered to be a 32-bit sequence. | |5. This bit sequence is complemented and the result is the CRC. | |The CRC is trannsmitted with the high order bit (corresponding to the |x^31 term of R(x)) in the low order bit of the first byte transmitted, |and the low order bit (corresponding to the x^0 term of R(x)) in the |high order bit of the fourth byte transmitted. |---------------- | |This text is inspired by the text in the Ethernet spec, with some |wording changes needed for the iSCSI context. I believe this is a |precise definition of what is needed. | |For additional information, more text could be included. For example: | |---------------- |The above algorithm is exactly that used in the Ethernet/802.3 LAN, |with the exception of the choice of generator polynomial. |---------------- | |And perhaps a note on implementation: | |---------------- |The above algorithm may be efficiently implemented in a variety of |ways, such as linear feedback shift registers, table lookup, etc. |---------------- | |Finally, we could capture the "magic constant" receive algorithm as |follows: | |---------------- |Implementation of the CRC32C checking for PDU reception can be done in |several ways. | |One approach is to calculate the CRC over the PDU not including the |CRC field, and compare that with the received CRC. If the two values |are equal, the digest is considered valid. | |Another approach is to perform the above algorithm over the entire |received PDU, including the CRC field. With that approach, a valid |digest results in R(x) having the value x^28 + x^27 + x^26 + x^21 + |x^19 + x^18 +x^16 + x^12 + x^11 + x^8 + x^7 + x^6 + x^5 + x^3 |+ x^2 + 1, |i.e., the value of the 32-bit sequence obtained in step 4 is |0x1c2d19ed. |---------------- | |Following Pat Thaler's comments, I am not proposing any more text on |implementation approaches. Both the table based approaches and the |LFSR approach can be covered by references to literature, though |admittedly some of the references may not be all that easy to |acquire. | |So my proposal is to replace the text on page 193 up to the |"Proprietary algorithms MAY also..." with the four pieces given |above. If people don't like the later pieces, then I'll fall back to |proposing just the first chunk of text (the formal definition of the |CRC) as replacement for the current text. | | paul | From owner-ips@ece.cmu.edu Fri Dec 14 19:21:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09835 for ; Fri, 14 Dec 2001 19:21:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBENdcT29902 for ips-outgoing; Fri, 14 Dec 2001 18:39:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBE7oIZ16512; Fri, 14 Dec 2001 02:50:19 -0500 (EST) Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.48 2001/12/13 16:27:50 root Exp $) with SMTP id HAA09769; Fri, 14 Dec 2001 07:50:18 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2001121323512502893 ; Thu, 13 Dec 2001 23:51:25 -0800 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 23:50:18 -0800 Message-ID: From: "Mesnier, Michael" To: "'ips@ece.cmu.edu'" , "'ips_source@ece.cmu.edu'" Subject: Intel Labs iSCSI v8 Available Date: Thu, 13 Dec 2001 23:50:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Intel Lab's reference implementation of iSCSI v8 is now available on SourceForge. Host and target mode drivers are included in this distribution. See http://www.sourceforge.net/projects/intel-iscsi for download. -- Mike Mesnier Intel Labs michael.mesnier@intel.com From owner-ips@ece.cmu.edu Fri Dec 14 19:32:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10019 for ; Fri, 14 Dec 2001 19:32:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBENtDe00922 for ips-outgoing; Fri, 14 Dec 2001 18:55:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBENtBZ00917 for ; Fri, 14 Dec 2001 18:55:11 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA90214 for ; Fri, 14 Dec 2001 18:52:20 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBENt9J175038 for ; Fri, 14 Dec 2001 16:55:09 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 14 Dec 2001 15:54:15 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/14/2001 04:55:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBENtBZ00919 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit But, this is the only place that we say a bit setting is set to 1 and is also marked as reserved. I think it would be easier, to just update the documentation to not say it is reserved. We have lots of other bits set to 1 always, that we do not call reserved. I think the only other place we have ones in a reserved field is the places where we set word fields to 0xFFFFFFFF. And this is where the filed is so marked because a setting of zero has another semantic. I do not think that applies to this bit, best to just update the document and not claim it to be reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 12/14/2001 09:04:15 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved John, If you are referring to the fact that a reserved bit has to be 0 - that is not so. The statement about reserved is that they are 0 unless explicitly said otherwise. There are some other reserved positions that are set to 1. Julo John Hufferd@IBMUS         To: Julian 14-12-01 10:24 Satran/Haifa/IB M@IBMIL@IBMDE         cc: ips@ece.cmu.edu Subject: iSCSI: Byte1 Bit 7 Seems Not to be reserved Julian, in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1.  Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved.  We should probably make those consistent.   I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Fri Dec 14 20:12:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10285 for ; Fri, 14 Dec 2001 20:12:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF0jeh03867 for ips-outgoing; Fri, 14 Dec 2001 19:45:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12801.mail.yahoo.com (web12801.mail.yahoo.com [216.136.174.36]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBF0jcZ03862 for ; Fri, 14 Dec 2001 19:45:38 -0500 (EST) Message-ID: <20011215004534.11545.qmail@web12801.mail.yahoo.com> Received: from [207.219.118.250] by web12801.mail.yahoo.com via HTTP; Fri, 14 Dec 2001 16:45:34 PST Date: Fri, 14 Dec 2001 16:45:34 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: Paul Koning Cc: ips@ece.cmu.edu In-Reply-To: <15386.24195.879416.67590@pkoning.dev.equallogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello Paul, I like the current description of CRC32C of iSCSI, except for one small little thing: page 194 of v9, dash 2: - the CRC register is initialized with all 1s (equivalent to complementing the first 32 bits of the message) This is actually equivalent to XORing the first 32 bits of the message with the magic constant as Vince and I have shown. If this is changed, then the message in its form: M'(x) = x^32 M(x) + x^(32+n) I(x) yields to better optimizations as Vince and I have shown. (see his circuits and worksheet4.pdf, which I posted yesterday) I.e. the message is augmented (mult by x^32, aka postfixed) and prefixed by 32 1's (aka CRC=32 1's). From this M'(x) one can derive the Simultaneous Multiply and Divide alogirthm (SMD), get the constants to which the CRC has to be set or the first 32 MSb of the PDU, etc. In an SMD, one would have to set the CRC to the magic constant and then proceed as the algorithm indicates, (this is identical to what you'd find in Ethernet, and is derived from M'(x), as Williams [1] shows) In a simple divide, one would have to Magic XOR 32 MSb of PDU, CRC = 0 and then proceed. Williams [1], shows how this is possible, in his paper, but he doesn't use math to show how/why as the title of the paper indicates (``Painless guide...''), and most derivations are omitted. Regarding examples: I like examples, we should have the examples as they are in the draft, but fix the CRCs for ones, decs and incs. ``A picture's worth a thousand words.'' -l P.S. I've just got the math on the SMD, and will be communicating it with Vince. A worksheet5.pdf will follow with the math. [1] Williams, Ross, Painless guide to CRC error detection algorithms. Rocksoft. ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Fri Dec 14 20:17:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10315 for ; Fri, 14 Dec 2001 20:17:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF0HRY02278 for ips-outgoing; Fri, 14 Dec 2001 19:17:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBF0HPZ02273 for ; Fri, 14 Dec 2001 19:17:25 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA59822 for ; Fri, 14 Dec 2001 19:14:34 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBF0HNJ234684 for ; Fri, 14 Dec 2001 17:17:23 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Checking the I bit To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 14 Dec 2001 16:16:45 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/14/2001 05:17:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBF0HPZ02275 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit OK, Except for the fact that Eddy pointed out to me 3.2.1.1 does call it the I bit that is always set to 1 for responses (and Async Msgs by the way), I think my basic statement is still true -- It is not a reserved bit. So the UNH statements really does not apply. And if it is a bit that is always set to one but does not need to be checked, why is it set to one? Why not set it to zero and mark it reserved, so that the UNH statement does apply, and then we can use it for something else in the future. The bit seems redundant, why do we need it to be set? Does this have something to do about with expediting the handling of responses in a target which is working on extended copy commands? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 12/14/2001 09:15:29 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Checking the I bit I think that Eddy's suggestion to state that parties have to check only what they have to check is valuable and we may want to include a general statement about that. Julo John Hufferd Sent by:         To: owner-ips@ece.c "Eddy mu.edu Quicksall"         cc: "ips@ece. cmu. edu \(E-mail\)" Subject: Re: iSCSI: Checking the I bit Eddy, Technically, the In coming PDUs all have Byte 0, Bit 6, set to one.  It is not identified as the I (Immediate) bit.  And it is NOT reserved. So the Statement from the UNH Plugfest does not apply.  I think your point is that if all the incoming PDUs have that bit set, why do we need to set the bit, and why do we need to check it.  I think this bit has evolved over time, and perhaps up to now no one has noticed. If every incoming PDU has the bit set, we may not need the bit to be set, and perhaps it should be reserved, thereby not requiring the check. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/13/2001 03:26:18 AM Sent by:  owner-ips@ece.cmu.edu To:   "ips@ece. cmu. edu \(E-mail\)" cc: Subject:  iSCSI: Checking the I bit Is it necessary for  the initiator to check the I bit in every response? If an initiator does  not need it, then I don't want to take the extra time to check it. I think this  is consistent with the thinking of all attendees of the UNH Plug Fest because  the report from UNH IOL was that "all companies failed that  test". I would like to  propose adding some wording to 3.2.1.1 similar to "It is not necessary to check  this bit for 1 if the implementation in the initiator does not need its  use". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Dec 14 20:18:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10331 for ; Fri, 14 Dec 2001 20:18:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF0iuD03813 for ips-outgoing; Fri, 14 Dec 2001 19:44:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBF0itZ03809 for ; Fri, 14 Dec 2001 19:44:55 -0500 (EST) Received: from core.rose.hp.com (unknown [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 5A48020668 for ; Fri, 14 Dec 2001 19:44:49 -0500 (EST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id QAA04612 for ; Fri, 14 Dec 2001 16:46:20 -0800 (PST) Message-ID: <004901c18501$b164cf80$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "ips" References: Subject: Re: iSCSI: scope of keys Date: Fri, 14 Dec 2001 16:44:45 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I actually suggest something along the following lines at the beginning of Appendix D, than labelling each key. This would also allow us to not specifically call out each "IO" key as we currently do. All keys with LO or FFPO, or qualified as Declarative use have session-wide applicability. All keys with IO or ALL usage have connection-wide applicability. With that said, some general comments on keys - - InitiatorAlias, TargetAlias and TargetAddress keys should be qualified with the "Declarative" label. - I recommend changing InitialR2T, BidiInitialR2T and ImmediateData as IO, fom the current ALL (with the one-time change restrictions). This makes it simple, and besides I can not quite picture a scenario the current allowance could be useful in. - InitiatorAlias and TargetAlias are keys that merely report an alias set in a different management domain (hence declarative), with the currently specified usage as ALL. I assume it is so because the alias could be changed while the session is in progress outside of iSCSI. iSCSI does not however require this key to be sent everytime the alias is changed during a session. We should either require this to avoid stale values, or much better, drop aliases altogether from iSCSI (can be asynchronously set in a different domain, and not useful for iSCSI protocol interactions).... - Editorial: MaxRecvPDULength - s/b "Use: All" with "Use: ALL". -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Julian Satran" To: Sent: Friday, December 14, 2001 12:50 PM Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a ?scope? to each key definition? The IO and LO ?use:? labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Sat Dec 15 00:09:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15128 for ; Sat, 15 Dec 2001 00:09:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF3wXp14686 for ips-outgoing; Fri, 14 Dec 2001 22:58:33 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBF3wTZ14679; Fri, 14 Dec 2001 22:58:29 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id EAA15900; Sat, 15 Dec 2001 04:58:13 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBF3vkO117320; Sat, 15 Dec 2001 04:57:54 +0100 To: Dean Scoville Cc: "ips@ece. cmu. edu (E-mail)" , owner-ips@ece.cmu.edu Subject: RE: Re: iSCSI Marker questions MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Dec 2001 05:57:32 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/12/2001 05:57:50, Serialize complete at 15/12/2001 05:57:50 Content-Type: multipart/alternative; boundary="=_alternative 00764B3AC2256B22_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00764B3AC2256B22_= Content-Type: text/plain; charset="US-ASCII" You are right there is no range today for SFMarkint - we may want to change this to enable a one-shot negotiation. Julo Dean Scoville Sent by: owner-ips@ece.cmu.edu 14-12-01 20:10 To: "ips@ece. cmu. edu (E-mail)" cc: Subject: RE: Re: iSCSI Marker questions Julian, Thanks for the response. Some examples would be very helpful. Your response shows a parameter negotiation with SFMarkInt=1,512 but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt. Is a range also being allowed for SFMarkInt? > > I assume a normal dialogue may go like: > > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 > Section 2.2.4 of the draft currently requires all integer parameter negotiations to have a response . (Responses are optional only with boolean negotiations where the offered value allows only a single outcome -- such as an "OR" boolean function with a "Yes" offer). Are responses always required for RFMarkInt and SFMarkInt, or is the following acceptable? I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4 Would it also be allowed to respond with the following and, if so, is one preferred over the other? (I'm not sure about the current state of using "0" as a "don't care" value, but is that also permitted in cases where the response would be irrelevant?) I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant With the following exchange, is the target required to respond with any RFMarkInt or SFMarkInt values, since there is no real choice of values? Agreeing to send markers implies that the interval is 512, and not agreeing to receive markers implies that there is no receive interval. Is the following allowed, or should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned by the target? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=send Is the following acceptable, even though it doesn't reply to RFMarkInt and SFMarkInt? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=no It would also be helpful to explain what happens if the login phase goes beyond the negotiated first marker interval. Assume, for example, the following: SYN - at TCP sequence num 1000. SYN-ACK - at TCP sequence num 2000. negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100. If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404, full-feature phase starts in the middle of what would have been a marker. Is a partial marker inserted? What would be the TCP seqNum of the first and second marker? If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810, what would be the TCP seqNum of the first and second marker? thanks, Dean -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 11, 2001 4:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questionsLink Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. --=_alternative 00764B3AC2256B22_= Content-Type: text/html; charset="US-ASCII"
You are right there is no range today for SFMarkint - we may want to change this to enable a one-shot negotiation.

Julo


Dean Scoville <Dean.Scoville@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-12-01 20:10

       
        To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: Re: iSCSI Marker questions



Julian,
Thanks for the response. Some examples would be very helpful.
Your response shows a parameter negotiation with SFMarkInt=1,512
but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt.
Is a range also being allowed for SFMarkInt?
 
>
> I assume a normal dialogue may go like:
>
> I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
>
Section 2.2.4 of the draft currently requires all integer parameter
negotiations to have a response . (Responses are optional only
with boolean negotiations where the offered value allows only a
single outcome -- such as an "OR" boolean function with a "Yes"
offer). Are responses always required for RFMarkInt and SFMarkInt,
or is the following acceptable?
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4
 
Would it also be allowed to respond with the following and, if so,
is one preferred over the other? (I'm not sure about the current
state of using "0" as a "don't care" value, but is that also
permitted in cases where the response would be irrelevant?)
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant
 
With the following exchange, is the target required to respond
with any RFMarkInt or SFMarkInt values, since there is no
real choice of values? Agreeing to send markers implies that
the interval is 512, and not agreeing to receive markers implies
that there is no receive interval. Is the following allowed, or
should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned
by the target?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=send
 
Is the following acceptable, even though it doesn't reply to
RFMarkInt and SFMarkInt?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=no
 
It would also be helpful to explain what happens if the login
phase goes beyond the negotiated first marker interval.
Assume, for example, the following:
 
  SYN - at TCP sequence num 1000.
  SYN-ACK - at TCP sequence num 2000.
  negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100.
 
If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404,
full-feature phase starts in the middle of what would have been a marker.
Is a partial marker inserted? What would be the TCP seqNum of the first and
second marker?
 
If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810,
what would be the TCP seqNum of the first and second marker?
 
thanks,
Dean
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 11, 2001 4:54 PM
To: ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker questions

----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


       To:        IPS List
       cc:        
       Subject:        Re: iSCSI Marker questionsLink



Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 

> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).



> Thanks,
> Dean Scoville
> QLogic Corp.

--=_alternative 00764B3AC2256B22_=-- From owner-ips@ece.cmu.edu Sat Dec 15 00:34:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15293 for ; Sat, 15 Dec 2001 00:34:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF4jdq17200 for ips-outgoing; Fri, 14 Dec 2001 23:45:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBF4jaZ17195 for ; Fri, 14 Dec 2001 23:45:37 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id FAA71678 for ; Sat, 15 Dec 2001 05:45:30 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBF4jus88594 for ; Sat, 15 Dec 2001 05:45:58 +0100 To: "John Hufferd" Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 15 Dec 2001 06:45:49 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/12/2001 06:45:55, Serialize complete at 15/12/2001 06:45:55 Content-Type: multipart/alternative; boundary="=_alternative 0019DFA2C2256B23_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0019DFA2C2256B23_= Content-Type: text/plain; charset="US-ASCII" OK - to the todo bucket - julo John Hufferd@IBMUS 15-12-01 01:54 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved But, this is the only place that we say a bit setting is set to 1 and is also marked as reserved. I think it would be easier, to just update the documentation to not say it is reserved. We have lots of other bits set to 1 always, that we do not call reserved. I think the only other place we have ones in a reserved field is the places where we set word fields to 0xFFFFFFFF. And this is where the filed is so marked because a setting of zero has another semantic. I do not think that applies to this bit, best to just update the document and not claim it to be reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved John, If you are referring to the fact that a reserved bit has to be 0 - that is not so. The statement about reserved is that they are 0 unless explicitly said otherwise. There are some other reserved positions that are set to 1. Julo John Hufferd@IBMUS 14-12-01 10:24 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu Subject: iSCSI: Byte1 Bit 7 Seems Not to be reserved Julian, in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1. Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved. We should probably make those consistent. I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 0019DFA2C2256B23_= Content-Type: text/html; charset="US-ASCII"
OK - to the todo bucket - julo


John Hufferd@IBMUS

15-12-01 01:54


        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI: Byte1 Bit 7 Seems Not to be reservedLink


But, this is the only place that we say a bit setting is set to 1 and is also marked as reserved.  I think it would be easier, to just update the documentation to not say it is reserved.  We have lots of other bits set to 1 always, that we do not call reserved.  

I think the only other place we have ones in a reserved field is the places where we set word fields to 0xFFFFFFFF.  And this is where the filed is so marked because a setting of zero has another semantic.  I do not think that applies to this bit, best to just update the document and not claim it to be reserved.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

Sent by:        owner-ips@ece.cmu.edu

To:        ips@ece.cmu.edu
cc:        
Subject:        Re: iSCSI: Byte1 Bit 7 Seems Not to be reserved




John,

If you are referring to the fact that a reserved bit has to be 0 - that is not so.
The statement about reserved is that they are 0 unless explicitly said otherwise.
There are some other reserved positions that are set to 1.  

Julo


John Hufferd@IBMUS

14-12-01 10:24
       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: Byte1 Bit 7 Seems Not to be reserved


Julian,
in Draft 9, the SCSI Response PDU picture shows Byte 1 Bit 7 (normally the Final Flag) to be set to 1.  Yet the Text that follows the picture says that Byte 1 Bit 7 -5 is reserved.  We should probably make those consistent.   I think you meant to indicate that the Response was the only PDU associated with this action, so I think you need to mark only Byte 1 bit 6-5 as reserved.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com





--=_alternative 0019DFA2C2256B23_=-- From owner-ips@ece.cmu.edu Sat Dec 15 04:44:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03502 for ; Sat, 15 Dec 2001 04:44:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBF8YkG28880 for ips-outgoing; Sat, 15 Dec 2001 03:34:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-68.crossroads.com [65.68.235.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBF8YhZ28869 for ; Sat, 15 Dec 2001 03:34:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI: abort task & abort task set Date: Sat, 15 Dec 2001 02:34:41 -0600 Message-ID: Thread-Topic: iSCSI: abort task & abort task set Thread-Index: AcGE5VIuY3OR61liSh+2edvUXY+FxgAEE+Cw From: "Buck Landry" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBF8YiZ28873 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit One barely-related comment, since this section is apparently in flux. The Task Management Function Request is supposed to be applicable to both iSCSI and SCSI tasks, according to the v9 draft, section 3.5.1. I take it that ABORT TASK SET, CLEAR TASK SET, and LOGICAL UNIT RESET do affect *iSCSI* tasks that have a LUN field set? AFAICT this includes only earlier instances of these same aborts and ABORT TASK .. still, it feels slightly weird to abort aborts.. This seems to happen, for example, if an immediate abort-task-set with CmdSN 'i+1' was sent ahead of a non-immediate abort-task-set with CmdSN 'i'. In this case the non-immediate abort is aborted, and a response is returned for the immediate abort. I don't need additional comment on this (unless I'm wrong, of course) I understand that TARGET WARM RESET blows away *all* pending iSCSI tasks (logout PDUs, etc) from all initiators? That seems like a little bit of overkill, inducing extra unneeded errors, but I'm assuming there's a decent reason for it, like consistency or something. --Buck -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Friday, December 14, 2001 3:16 PM To: somesh_gupta@silverbacksystems.com Cc: ips Subject: Re: iSCSI: abort task & abort task set Somesh, One comment. > 1. For targets that only support single connection per session, and do > not support error recovery, would it be ok to send the status for the > task management command without having to wait for the status ack > for all previously sent statuses? I think it's okay. (There are other subtle areas here even for ErrorRecoveryLevel=0 - how quickly should a connection/command be failed after the first error that requires recovery? If there are posted good statuses after the lost status, initiator in general can process those - except it should not in this case of 'abort task set'.) OTOH, This approach breaks even for single connection sessions if status recovery is eventually supported. That makes me believe that this choice is an optimization for a specific deployment scenario. IMO, the draft would be generally better off not describing specific scenarios. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Somesh Gupta" To: "Julian Satran" ; Sent: Friday, December 14, 2001 10:52 AM Subject: RE: iSCSI: abort task & abort task set > Julian, > > I like the proposal made at the IETF. I had two follow up questions > > 1. For targets that only support single connection per session, and do > not support error recovery, would it be ok to send the status for the > task management command without having to wait for the status ack > for all previously sent statuses? > > 2. I have to analyze in more detail, but there is an interesting case > where let us say that the status sent prior to the > task management status suffers from a digest error, or a connection > failure. The initiator retries the command on another connection. I > have not fully figured out the implications of this. > > Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, December 03, 2001 10:51 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: abort task & abort task set > > > > Dear all, > > On a phone conversation we have agreed to change the required behaviour > along those lines enabling the initiator to drop all > outstanding commands after a response from a the task management > abort/clear-task-set is received. > The iSCSI target will carry the burden for waiting for all outstanding > statuses on all connections to be acknowledged after receiving the abort > confirmation from the SCSI target and sending all statuses before returning > the task management response. > > Julo > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > 12-03-01 07:53 PM > Please respond to cbm > > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: abort task & abort task set > > > > > Resolution of this certainly requires an offline discussion - > which we two plan to have. But one comment to make my proposal > clear to the list. > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > That is not possible since as I said above, the 'abort task set' > TMF response is sent only after all StatSN "snapshots" are ack'ed > on all connections. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > > Julian Satran wrote: > > > > Mallikarjun, > > > > Comments in text - Julo > > > > PS - I would like also to point out that we may want to consider a > > very simple alternative to the barrier scheme outlined in 9.4 > > - that will require less cooperation between initiator and will be > > simpler to read and implement. > > I will outline such a scheme soon. > > > > "Mallikarjun C." > > To: "ips" > > Sent by: owner-ips@ece.cmu.edu > > cc: > > 12/03/2001 01:33 AM Subject: iSCSI: > > abort task & abort task set > > > > > > > > Julian, > > > > iSCSI currently requires two responses to be returned for an aborted > > task - > > one for the original task with a "good" status, and the second for the > > task > > management function (TMF) itself. So, the following legal behaviors > > are > > required of a target - > > a) plug the CmdSN gap if the command was not received, > > b) send a SCSI response and TMF response if the task still is > > active, > > c) send a TMF response if the task isn't active (if already > > complete). > > > > I would like to suggest that we reconsider our approach for case (b) > > for > > a variety of reasons, to change it to: > > b) send a TMF response signalling that the abort is complete, if > > the > > task > > still is active. > > > > Here are my reasons - > > > > 1. Target iSCSI layer would need to make a SCSI response up on > > an abort of an active task. It then follows that the iSCSI > > layer > > may have to make up several SCSI responses on an 'abort task > > set'. > > > > 2. The current approach also creates a side effect that isn't > > readily > > apparent for 'abort task set'. Initiators would need to stall > > processing > > 'abort task set' TMF response till task responses (to account > > for > > all > > the tasks in the task set) on multiple TCP connections > > (possibly on > > different NICs) are received - which I am afraid would > > tantamount to > > an initiator scoreboard. > > +++ That is not entirely correct. The whole purpose of requiring the > > target to send a "good status" is to allow the initiator to send the > > response immediately and have the initiator mark its internal data > > structures as aborted - but avoid reusing ITT untill it gets the good > > answer. > > This way initiator can make progress and it can be sure that it won't > > be surprised by an "old" answer after it has reused the ITT > > +++ > > 3. The current approach complicates initiator implementations that > > want > > to process a successful SCSI completion even after they > > initiated > > timeout processing since on an 'abort task set', initiators can > > never > > be sure if the response was pre-abort, or post-abort (made up > > "good" > > status). I believe it is worth preserving this implementation > > choice. > > +++ see above +++ > > 4. I am further concerned that iSCSI is possibly in violation of > > the > > spirit of > > SAM-2, rev20. > > - clause 5.6.2 that states - > > "When an initiator causes its own task(s) to be aborted, no > > notification > > that the task(s) have been aborted shall be > > returned to the initiator other than the completion response for the > > command > > or task management function action > > that caused the task(s) to be aborted and notification(s) associated > > with > > related effects of the action (e.g., a target > > reset unit attention condition)." > > +++ I did say explicitly that the good status is a "good-will" message > > between iSCSI target and initiator. It does not have to reach SCSI. > > SAM also allows statuses that have been sent before an abort was > > executed but received after the TM response to be delivered or not at > > initiators will +++ > > - clause 5.3.1 that states - > > "GOOD. This status indicates that the device server has successfully > > completed the task." > > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > > > This gives the determinism to initiators that (a) abort task set TMF > > response > > signifies that the entire task set had been dealt with, and (b) every > > task > > response > > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > > doing > > away with SCSI-response code in the target iSCSI layer. > > > > Comments? Did I miss any corner cases? > > > > +++ see above +++ > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > > > > From owner-ips@ece.cmu.edu Sat Dec 15 16:39:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07880 for ; Sat, 15 Dec 2001 16:39:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBFKn1T17027 for ips-outgoing; Sat, 15 Dec 2001 15:49:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBFKmxZ17022 for ; Sat, 15 Dec 2001 15:48:59 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBFKmat17807; Sat, 15 Dec 2001 15:48:36 -0500 Received: from PKONING.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with ESMTP id fBFKmYr11916; Sat, 15 Dec 2001 15:48:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15387.46883.407000.525991@gargle.gargle.HOWL> Date: Sat, 15 Dec 2001 15:48:35 -0500 From: Paul Koning To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: <15386.24195.879416.67590@pkoning.dev.equallogic.com> <20011215004534.11545.qmail@web12801.mail.yahoo.com> X-Mailer: VM 6.95 under 21.4 (patch 3) "Academic Rigor" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Excerpt of message (sent 14 December 2001) by Luben Tuikov: > Hello Paul, > > I like the current description of CRC32C of iSCSI, except > for one small little thing: page 194 of v9, dash 2: > > - the CRC register is initialized with all 1s (equivalent > to complementing the first 32 bits of the message) > > This is actually equivalent to XORing the first > 32 bits of the message with the magic constant as Vince > and I have shown. Are you saying that you believe the intent of the current spec is NOT the same as the Ethernet CRC, i.e., complement the first 32 bits, multiply by x^32, then divide by G(x)? If that is your interpretation, then we absolutely MUST fix the spec, I'm quite sure that the intent of the spec is as I wrote it, i.e., Ethernet except for the generator. > If this is changed, then the message in its form: > M'(x) = x^32 M(x) + x^(32+n) I(x) > > yields to better optimizations as Vince and I have shown. > (see his circuits and worksheet4.pdf, which I posted > yesterday) > > I.e. the message is augmented (mult by x^32, aka postfixed) > and prefixed by 32 1's (aka CRC=32 1's). But that is NOT what the spec currently says. What you describe may be a fine CRC but it is not the one that's in the spec. Initializing the CRC register to all 1 is not the same as prefixing 32 1 bits onto the message. What does "better optimizations" mean? > In an SMD, one would have to set the CRC to the magic > constant and then proceed as the algorithm indicates, > (this is identical to what you'd find in Ethernet, ... No it isn't. The Ethernet spec appendix C, and, more importantly, the formal definition of the CRC in the body of the spec, makes it quite clear that it isn't. I don't understand how you arrive at any other conclusion. paul From owner-ips@ece.cmu.edu Sun Dec 16 06:39:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01128 for ; Sun, 16 Dec 2001 06:39:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBGAhkc07979 for ips-outgoing; Sun, 16 Dec 2001 05:43:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12808.mail.yahoo.com (web12808.mail.yahoo.com [216.136.174.43]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBGAhiZ07974 for ; Sun, 16 Dec 2001 05:43:44 -0500 (EST) Message-ID: <20011216104343.69064.qmail@web12808.mail.yahoo.com> Received: from [24.42.134.59] by web12808.mail.yahoo.com via HTTP; Sun, 16 Dec 2001 02:43:43 PST Date: Sun, 16 Dec 2001 02:43:43 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: Paul Koning , VICENTE V CAVANNA Cc: ips@ece.cmu.edu In-Reply-To: <15387.46883.407000.525991@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Paul Koning wrote: > Excerpt of message (sent 14 December 2001) by Luben > > This is actually equivalent to XORing the first > > 32 bits of the message with the magic constant as Vince > > and I have shown. > > Are you saying that you believe the intent of the current > spec is NOT > the same as the Ethernet CRC, i.e., complement the first > 32 bits, > multiply by x^32, then divide by G(x)? In our profession we cannot talk about beliefs and intentions, more so for documents, rfc, etc. If you show the current description of the CRC of the draft to a mathematician, they will object to the same thing I've objected. The reason is that they don't have the preconception about what circuit is being used, and any such higher level notions. All they would have and all I had was long division in Z_2. (Actually Z_2[x] since we deal with polynomials.) Then I started from first principles of CRC, polydivision, etc, etc. -- similarly to how Williams proceeds in his paper, but my treatment was purely algebraic. The same applies to anyone looking at a description of an algorithm. (An ``algorithm'' has a precise definition in Computer Science.) In its current form the description of the algorithm to compute the CRC in the iSCSI draft is not consistent, just because there is an unspoken assumption that a SMD circuit will be used. We cannot afford to do this in a definition document, unless we refer explicitly to it. We cannot even assume that a circuit will be used... Please also note that the Ethernet spec CRC algorithm, is an optimized version of a basic prefix-postfix-initialize-the- CRC-register-to-some-constant algoritm. BUT as SMD it operates on NON-AUGMENTED messages. FOR THAT REASON you cannot say that we have to multiply M(x) by x^32!!! I.e. SMD algoritms like the one in the Ethernet spec, operate on non-augmented messages, while simple Division (D) algorithms operate on augmented messages. Any D can be optimized to SMD, but the constant has to be changed. Also, prefixing a message is equivalent to loading the CRC register with that prefix (WLG), but this is not so for SMD. (elaborated below) Further more for any SMD there is an equivalent D, including for the Ethernet spec SMD; and for any D there is an equivalent SMD. > If that is your interpretation, then we absolutely MUST > fix the spec, > I'm quite sure that the intent of the spec is as I wrote > it, i.e., > Ethernet except for the generator. Probably it is. But lets not hasten here. We can further generalize the explanation of the algorithm. > > If this is changed, then the message in its form: > > M'(x) = x^32 M(x) + x^(32+n) I(x) > > > > yields to better optimizations as Vince and I have > shown. > > (see his circuits and worksheet4.pdf, which I posted > > yesterday) > > > > I.e. the message is augmented (mult by x^32, aka > postfixed) > > and prefixed by 32 1's (aka CRC=32 1's). > > But that is NOT what the spec currently says. What you > describe may > be a fine CRC but it is not the one that's in the spec. > Initializing > the CRC register to all 1 is not the same as prefixing 32 > 1 bits onto > the message. It is, in a simple division, e.g. in D. This is clearly and simply explained in the Williams paper. It is an equivalent to a long division. Now, in D, if I initialize the CRC to all 1's and then do division of M(x) by G(x), so that I catch 0's at the beginning of the message, (which is equivalent to prefixing the message by 1's of the number of the width of the CRC, and then do just simple division,(CRC=0), since after so many clicks the CRC will be loaded with the prefixing bits, and also 0/G(x) = 0) then I can find a constant which I can XOR to the first 32 bits of the message and then perform the division, still in D, with the same effect. In this particular case that constant is the magic constant. (We are one step closer to SMD...) (Now we jump to SMD, by means of worksheet4.pdf, Prefixing part.) Now, in the Ethernet CRC spec, that constant is 32 1's, and XORing 32 1's with the 32 MSb of the message is equivalent to complementing them. BUT the Ethernet spec uses SMD, not D, so I claim that there is an equivalent D, which for a suitable initial CRC (also equivalent to prefixing the message with it) value will yield IDENTICAL results as Ethernet SMD. Now using a bit of algebra similar to worksheet4.pdf which I posted a couple of days ago and numerical methods (solving a linear system of 33 unknowns) I have found such a constant: 0x2a26f826 which in simple division, D, will yield results identical to SMD of Ethernet. So, here is an abstractization of the Ethernet CRC SMD, explained in a simple, simple, simple division only way: TX: 1. Mutliply the message, M(x), by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. 4. Complement that remainder and add it to the result of 1. 5. Send the result of 4. to the recipient. RX: (same as steps 1-3 in TX) 1. Mutliply the message by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. The result of 3 should be 0x1c2d19ed (the magic constant). Of course I've ommitted the mirroring of bytes for clarity and brevity. It can be mentioned on the side, e.g. How to build the message: mirror the bytes == to swapping the bits inside the bytes, .... Also note that step 4 in TX, adding means exactly that, since we already mult. by x^32, so the remainder will nicely fit in the last 32 0 bits. Also note that step 2, can be made clearer: let C(x), be the polynomial representation of 0x2a26f826. Let n = deg G(x), k-1 = deg M(x) (there are k bits), then step 2 is: 2. Add x^n x^k C(x) to the message M(x). Or we can swap step 1 and 2: 1. Add x^k C(x) to M(x). 2. Multiply the result of 1. by x^n. I hope this makes things a bit clearer. So from this D specification above, I can derive SMD exaclty as it is in the Ethernet spec. I'll include this derivation in the paper -- it will be pure math, but in english it goes like this: First we notice that after 32 clicks the CRC register will contain only 32 1's XOR-ed with the message, then we see that we can just load the crc with ones and then kick one byte off the left xor it with the next message bit... The above equivalence I've tested empirically. > What does "better optimizations" mean? See above. > > In an SMD, one would have to set the CRC to the magic > > constant and then proceed as the algorithm indicates, > > (this is identical to what you'd find in Ethernet, ... > > No it isn't. The Ethernet spec appendix C, and, more > importantly, the > formal definition of the CRC in the body of the spec, > makes it quite > clear that it isn't. I don't understand how you arrive > at any other > conclusion. I didn't mean identical as in the constant. I meant identical in a way of equivalence of algorithms, that one can be derived from the other, etc. See above. Or simpler answer: Math. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Sun Dec 16 13:16:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03398 for ; Sun, 16 Dec 2001 13:16:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBGHm0Z27880 for ips-outgoing; Sun, 16 Dec 2001 12:48:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBGHZIZ27143; Sun, 16 Dec 2001 12:35:18 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id SAA98472; Sun, 16 Dec 2001 18:35:11 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBGHZeC15434; Sun, 16 Dec 2001 18:35:40 +0100 Received: from PS180-18 ([32.226.99.175]) by d10hubm1.telaviv.ibm.com (Lotus Domino Release 5.0.8) with ESMTP id 2001121619353063:1551 ; Sun, 16 Dec 2001 19:35:30 +0200 From: Julian_Satran/Haifa/IBM%IBMIL@telaviv.ibm.com To: ips@ece.cmu.edu Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Questions about implementation of Multiple connections MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: Date: Mon, 10 Dec 2001 20:05:23 +0200 X-MIMETrack: Serialize by Notes Client on Julian Satran/Haifa/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 16-12-2001 19:35:05, Serialize complete at 16-12-2001 19:35:05, Itemize by SMTP Server on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/12/2001 19:35:31, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/12/2001 19:35:36, Serialize complete at 16/12/2001 19:35:36 Content-Type: multipart/alternative; boundary="=_alternative 00635EBEC2256B1E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00635EBEC2256B1E_= Content-Type: text/plain; charset="US-ASCII" Meng, owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42: > I have several questions about multiple connections: > > (1) Are multiple connections between initiator and a > target common? I mean, how many applications will > require iSCSI implementation to be able to handle > multiple connections within a session? Can anybody > give me some overview idea about the application of > multiple TCP connections, like: is it an exceptional > case? or common case? > I assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it. > (2) Consider a hard drive on the network. It only has > one hardware port. If we want to develop a iSCSI box > to handle all incoming iSCSI commands for it, is it > necessary for the box to handle multiple TCP > connections for this hard drive? How? Does the box > need more than one IP addresses? > I don't think you need this for one disk although you may want to admit two for recovery. > Thanks, > Meng > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com Julo --=_alternative 00635EBEC2256B1E_= Content-Type: text/html; charset="US-ASCII"
Meng,

owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42:

> I have several questions about multiple connections:
>
> (1) Are multiple connections between initiator and a
> target common? I mean, how many applications will
> require iSCSI implementation to be able to handle
> multiple connections within a session? Can anybody
> give me some overview idea about the application of
> multiple TCP connections, like: is it an exceptional
> case? or common case?
>

I  assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it.

> (2) Consider a hard drive on the network. It only has
> one hardware port. If we want to develop a iSCSI box
> to handle all incoming iSCSI commands for it, is it
> necessary for the box to handle multiple TCP
> connections for this hard drive? How? Does the box
> need more than one IP addresses?
>

I don't think you need this for one disk although you may want to admit two for  recovery.


> Thanks,
> Meng
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
Julo --=_alternative 00635EBEC2256B1E_=-- From owner-ips@ece.cmu.edu Sun Dec 16 13:18:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03457 for ; Sun, 16 Dec 2001 13:18:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBGHPFG26565 for ips-outgoing; Sun, 16 Dec 2001 12:25:15 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBGHPDZ26559 for ; Sun, 16 Dec 2001 12:25:13 -0500 (EST) Received: from somesh ([12.81.3.193]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20011216172457.YYOI5540.mtiwmhc21.worldnet.att.net@somesh>; Sun, 16 Dec 2001 17:24:57 +0000 Reply-To: From: "Somesh Gupta" To: "Julian Satran" , "IPS" Subject: RE: iSCSI: abort task & abort task set Date: Sun, 16 Dec 2001 09:23:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C18613.522EBD60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C18613.522EBD60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Julian, Based on how the protocol is specified, the initiator could determine that the target has violated the protocol. Assume that the initiator did not send a status ACK because there was no real reason to do so, and it is waiting for a time-out or some such condition before sending the status ack. If the status for the task management command is received in the meantime, it is a good thing, although not necessarily compliant with the spec (unless the spec is changed). I think it is a good idea to add this text to the spec. Also perhaps in the spec text, it should be mentioned that the initiators are encouraged to send status acks aggressively when they send a task management request is sent (till the task management status is received). Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, December 14, 2001 12:50 PM To: somesh_gupta@silverbacksystems.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: abort task & abort task set Somesh, "Somesh Gupta" wrote on 14-12-2001 20:52:04: > Julian, > > > > I like the proposal made at the IETF. I had two follow up questions > > > > 1. For targets that only support single connection per session, and do > > not support error recovery, would it be ok to send the status for the > > task management command without having to wait for the status ack > > for all previously sent statuses? > > I assume that you are on safe ground as the target is doing it and no one could be wiser (no way to observe extrnally any difference) and there is no need to specify this behavior. Or is it? > > 2. I have to analyze in more detail, but there is an interesting case > > where let us say that the status sent prior to the > > task management status suffers from a digest error, or a connection > > failure. The initiator retries the command on another connection. I > > have not fully figured out the implications of this. > > Statuses are recovered by SNACK. I doubt initiators will retry abborted commands! > > Somesh > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, December 03, 2001 10:51 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: abort task & abort task set > > > Dear all, > > On a phone conversation we have agreed to change the required > behaviour along those lines enabling the initiator to drop all > outstanding commands after a response from a the task management > abort/clear-task-set is received. > The iSCSI target will carry the burden for waiting for all > outstanding statuses on all connections to be acknowledged after > receiving the abort confirmation from the SCSI target and sending > all statuses before returning the task management response. > > Julo > > > "Mallikarjun C." > Sent by: owner-ips@ece.cmu.edu > > 12-03-01 07:53 PM > Please respond to cbm > > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: abort task & abort task set > > > > > > Resolution of this certainly requires an offline discussion - > which we two plan to have. But one comment to make my proposal > clear to the list. > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > That is not possible since as I said above, the 'abort task set' > TMF response is sent only after all StatSN "snapshots" are ack'ed > on all connections. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > > Julian Satran wrote: > > > > Mallikarjun, > > > > Comments in text - Julo > > > > PS - I would like also to point out that we may want to consider a > > very simple alternative to the barrier scheme outlined in 9.4 > > - that will require less cooperation between initiator and will be > > simpler to read and implement. > > I will outline such a scheme soon. > > > > "Mallikarjun C." > > To: "ips" > > Sent by: owner-ips@ece.cmu.edu > > cc: > > 12/03/2001 01:33 AM Subject: iSCSI: > > abort task & abort task set > > > > > > > > Julian, > > > > iSCSI currently requires two responses to be returned for an aborted > > task - > > one for the original task with a "good" status, and the second for the > > task > > management function (TMF) itself. So, the following legal behaviors > > are > > required of a target - > > a) plug the CmdSN gap if the command was not received, > > b) send a SCSI response and TMF response if the task still is > > active, > > c) send a TMF response if the task isn't active (if already > > complete). > > > > I would like to suggest that we reconsider our approach for case (b) > > for > > a variety of reasons, to change it to: > > b) send a TMF response signalling that the abort is complete, if > > the > > task > > still is active. > > > > Here are my reasons - > > > > 1. Target iSCSI layer would need to make a SCSI response up on > > an abort of an active task. It then follows that the iSCSI > > layer > > may have to make up several SCSI responses on an 'abort task > > set'. > > > > 2. The current approach also creates a side effect that isn't > > readily > > apparent for 'abort task set'. Initiators would need to stall > > processing > > 'abort task set' TMF response till task responses (to account > > for > > all > > the tasks in the task set) on multiple TCP connections > > (possibly on > > different NICs) are received - which I am afraid would > > tantamount to > > an initiator scoreboard. > > +++ That is not entirely correct. The whole purpose of requiring the > > target to send a "good status" is to allow the initiator to send the > > response immediately and have the initiator mark its internal data > > structures as aborted - but avoid reusing ITT untill it gets the good > > answer. > > This way initiator can make progress and it can be sure that it won't > > be surprised by an "old" answer after it has reused the ITT > > +++ > > 3. The current approach complicates initiator implementations that > > want > > to process a successful SCSI completion even after they > > initiated > > timeout processing since on an 'abort task set', initiators can > > never > > be sure if the response was pre-abort, or post-abort (made up > > "good" > > status). I believe it is worth preserving this implementation > > choice. > > +++ see above +++ > > 4. I am further concerned that iSCSI is possibly in violation of > > the > > spirit of > > SAM-2, rev20. > > - clause 5.6.2 that states - > > "When an initiator causes its own task(s) to be aborted, no > > notification > > that the task(s) have been aborted shall be > > returned to the initiator other than the completion response for the > > command > > or task management function action > > that caused the task(s) to be aborted and notification(s) associated > > with > > related effects of the action (e.g., a target > > reset unit attention condition)." > > +++ I did say explicitly that the good status is a "good-will" message > > between iSCSI target and initiator. It does not have to reach SCSI. > > SAM also allows statuses that have been sent before an abort was > > executed but received after the TM response to be delivered or not at > > initiators will +++ > > - clause 5.3.1 that states - > > "GOOD. This status indicates that the device server has successfully > > completed the task." > > > > I propose that the target deliver only the TMF response on an abort of > > an active task on an 'abort task' TMF, and not transmit an 'abort task > > set' > > TMF response until all the current StatSN's on all connections (as on > > the > > completion of "abort task set') in the session are ack'ed. This ack > > may be > > solicited by way of a NOP-IN with valid TTT. > > > > +++ that may result in an initiator reusing prematurely an ITT and > > being hit by a late arriving status > > for a "former" task - i.e. non-deterministic behavior +++ > > > > This gives the determinism to initiators that (a) abort task set TMF > > response > > signifies that the entire task set had been dealt with, and (b) every > > task > > response > > is a true SCSI end-to-end reponse (not generated by iSCSI), besides > > doing > > away with SCSI-response code in the target iSCSI layer. > > > > Comments? Did I miss any corner cases? > > > > +++ see above +++ > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > Hewlett-Packard MS 5668 > > Roseville CA 95747 > ------=_NextPart_000_0098_01C18613.522EBD60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Julian,
 
Based=20 on how the protocol is specified, the initiator could determine that the = target
has=20 violated the protocol. Assume that the initiator did not send a status = ACK=20 because
there=20 was no real reason to do so, and it is waiting for a time-out or some=20 such
condition before sending the status ack. If = the status=20 for the task management command
is=20 received in the meantime, it is a good thing, although not necessarily = compliant=20 with
the=20 spec (unless the spec is changed).
 
I=20 think it is a good idea to add this text to the = spec.
 
Also=20 perhaps in the spec text, it should be mentioned that the initiators are = encouraged to
send=20 status acks aggressively when they send a task management request is = sent=20 (till
the=20 task management status is received).
 
Somesh
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Friday, December 14, 2001 12:50 = PM
To:=20 somesh_gupta@silverbacksystems.com
Cc:=20 ips@ece.cmu.edu
Subject: RE: iSCSI: abort task & abort = task=20 set


Somesh,=20

"Somesh Gupta"=20 <somesh_gupta@silverbacksystems.com> wrote on 14-12-2001=20 20:52:04:

> Julian,
>
>  
>
> I=20 like the proposal made at the IETF. I had two follow up = questions
>=20
>  
>=20
> 1. For targets = that only=20 support single connection per session, and do
>
> not support error recovery, would = it be ok to=20 send the status for the
>
> task management command without having to wait for the = status=20 ack
>
> for = all previously=20 sent statuses?
>
>=20
I assume that you are = on safe=20 ground as the target is doing it and no one could be wiser =
(no way to observe extrnally any = difference) and=20 there is no need to specify this behavior. Or is it?
 
>
> 2. I have to analyze in more detail, but there is an = interesting=20 case
>
> where = let us say=20 that the status sent prior to the
>
> task management status suffers from a digest error, or a = connection
>
> = failure.=20 The initiator retries the command on another connection. I
>=20
> have not fully = figured out the=20 implications of this.
>
>
Statuses = are recovered=20 by SNACK. I doubt initiators will retry abborted commands! =

>
> Somesh
>
>=20 -----Original Message-----
> From: owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian = Satran
>=20 Sent: Monday, December 03, 2001 10:51 PM
> To: = ips@ece.cmu.edu
>=20 Subject: Re: iSCSI: abort task & abort task set
> =
>
> Dear all,
> =
> On a phone=20 conversation we have agreed to change the required
> behaviour = along=20 those lines enabling the initiator to drop all
> outstanding = commands=20 after a response from a the task management
> = abort/clear-task-set is=20 received.
> The iSCSI target will carry the burden for waiting = for all=20
> outstanding statuses on all connections to be acknowledged = after=20
> receiving the abort confirmation from the SCSI target and = sending=20
> all statuses before returning the task management response. =
>=20
> Julo
>
>
> "Mallikarjun C." <cbm@rose.hp.com>
> Sent = by:=20 owner-ips@ece.cmu.edu
>
>=20 12-03-01 07:53 PM
> Please respond to cbm
> =
>         =
>  =20       To:        ips@ece.cmu.edu =
>=20         cc:        
> =  =20       Subject:        Re: iSCSI: = abort task=20 & abort task set
>
>       =  
>=20
>
>
> = Resolution=20 of this certainly requires an offline discussion -
> which we = two plan=20 to have.  But one comment to make my proposal
> clear to = the=20 list.
>
> > I propose that the target deliver only the = TMF=20 response on an abort of
> > an active task on an 'abort task' = TMF,=20 and not transmit an 'abort task
> > set'
> > TMF = response=20 until all the current StatSN's on all connections (as on
> >=20 the
> > completion of "abort task set') in the session are = ack'ed.=20  This ack
> > may be
> > solicited by way of a = NOP-IN=20 with valid TTT.
> >
> > +++ that may result in an = initiator=20 reusing prematurely an ITT and
> > being hit by a late = arriving=20 status
> > for a "former" task - i.e. non-deterministic = behavior=20 +++
>
> That is not possible since as I said above, the = 'abort=20 task set'
> TMF response is sent only after all StatSN = "snapshots" are=20 ack'ed
> on all connections.
> --
> = Mallikarjun
>=20
> Mallikarjun Chadalapaka
> Networked Storage=20 Architecture
> Network Storage Solutions Organization
>=20 Hewlett-Packard MS 5668
> Roseville CA 95747
>
> =
>=20 Julian Satran wrote:
> >
> > Mallikarjun,
> = >=20
> > Comments in text - Julo
> >
> > PS - = I would=20 like also to point out that we may want to consider a
> > = very simple=20 alternative to the barrier scheme outlined in 9.4
> > - that = will=20 require less cooperation between initiator and will be
> > = simpler to=20 read and implement.
> > I will outline such a scheme = soon.
>=20 >
> >   "Mallikarjun C."
> >  =20 <cbm@rose.hp.com>             =  =20         To:       =  "ips"
> >=20   Sent by: owner-ips@ece.cmu.edu =  <ips@ece.cmu.edu>
>=20 >                   =  =20                     =  =20 cc:
> >   12/03/2001 01:33 AM       =    =20           Subject:      =20  iSCSI:
> >             =  =20                     = abort=20 task & abort task set
> >
> >
> > =
>=20 > Julian,
> >
> > iSCSI currently requires two = responses=20 to be returned for an aborted
> > task -
> > one for = the=20 original task with a "good" status, and the second for the
> = >=20 task
> > management function (TMF) itself.  So, the = following=20 legal behaviors
> > are
> > required of a target = -
>=20 >    a) plug the CmdSN gap if the command was not=20 received,
> >    b) send a SCSI response and TMF = response=20 if the task still is
> > active,
> >    c) = send a=20 TMF response if the task isn't active (if already
> >=20 complete).
> >
> > I would like to suggest that we=20 reconsider our approach for case (b)
> > for
> > a = variety=20 of reasons, to change it to:
> >    b) send a TMF = response=20 signalling that the abort is complete, if
> > the
> = >=20 task
> >        still is active.
> = >=20
> > Here are my reasons -
> >
> >   =  1.=20 Target iSCSI layer would need to make a SCSI response up on
> = >=20        an abort of an active task.  It then = follows=20 that the iSCSI
> > layer
> >       =  may=20 have to make up several SCSI responses on an 'abort task
> >=20 set'.
> >
> >   2.  The current approach = also=20 creates a side effect that isn't
> > readily
> > =  =20      apparent for 'abort task set'.  Initiators = would need=20 to stall
> > processing
> >      =20  'abort task set' TMF response till task responses (to = account
>=20 > for
> > all
> >        the = tasks=20 in the task set) on multiple TCP connections
> > (possibly = on
>=20 >        different NICs) are received - which I = am=20 afraid would
> > tantamount to
> >     =  =20  an initiator scoreboard.
> > +++ That is not entirely = correct.=20 The whole purpose of requiring the
> > target to send a "good = status"=20 is to allow the initiator to send the
> > response = immediately and=20 have the initiator mark its internal data
> > structures as = aborted -=20 but avoid reusing ITT untill it gets the good
> > = answer.
>=20 > This way initiator can make progress and it can be sure that it=20 won't
> > be surprised by an "old" answer after it has reused = the=20 ITT
> > +++
> >    3. The current approach = complicates initiator implementations that
> > want
> = >=20        to process a successful SCSI completion = even after=20 they
> > initiated
> >       =  timeout=20 processing since on an 'abort task set', initiators can
> >=20 never
> >        be sure if the response = was=20 pre-abort, or post-abort (made up
> > "good"
> > =  =20      status).  I believe it is worth preserving = this=20 implementation
> > choice.
> > +++ see above = +++
>=20 >   4.  I am further concerned that iSCSI is possibly in=20 violation of
> > the
> > spirit of
> > =  =20      SAM-2, rev20.
> >       =   -=20 clause 5.6.2 that states -
> > "When an initiator causes its = own=20 task(s) to be aborted, no
> > notification
> > that = the=20 task(s) have been aborted shall be
> > returned to the = initiator=20 other than the completion response for the
> > = command
> >=20 or task management function action
> > that caused the = task(s) to be=20 aborted and notification(s) associated
> > with
> > = related=20 effects of the action (e.g., a target
> > reset unit = attention=20 condition)."
> > +++ I did say explicitly that the good = status is a=20 "good-will" message
> > between iSCSI target and initiator. = It does=20 not have to reach SCSI.
> > SAM also allows statuses that = have been=20 sent before an abort was
> > executed but received after the = TM=20 response to be delivered or not at
> > initiators will = +++
>=20 >         - clause 5.3.1 that states -
> = >=20 "GOOD. This status indicates that the device server has = successfully
>=20 > completed the task."
> >
> > I propose that = the target=20 deliver only the TMF response on an abort of
> > an active = task on an=20 'abort task' TMF, and not transmit an 'abort task
> > = set'
>=20 > TMF response until all the current StatSN's on all connections = (as=20 on
> > the
> > completion of "abort task set') in = the=20 session are ack'ed.  This ack
> > may be
> > = solicited=20 by way of a NOP-IN with valid TTT.
> >
> > +++ that = may=20 result in an initiator reusing prematurely an ITT and
> > = being hit=20 by a late arriving status
> > for a "former" task - i.e.=20 non-deterministic behavior +++
> >
> > This gives = the=20 determinism to initiators that  (a) abort task set TMF
> = >=20 response
> > signifies that the entire task set had been = dealt with,=20 and (b) every
> > task
> > response
> > is = a true=20 SCSI end-to-end reponse (not generated by iSCSI), besides
> > = doing
> > away with SCSI-response code in the target iSCSI=20 layer.
> >
> > Comments?  Did I miss any = corner=20 cases?
> >
> > +++ see above +++
> > =
> >=20 Regards.
> > --
> > Mallikarjun
> > =
> >=20 Mallikarjun Chadalapaka
> > Networked Storage = Architecture
>=20 > Network Storage Solutions Organization
> > = Hewlett-Packard MS=20 5668
> > Roseville CA 95747
>=20
------=_NextPart_000_0098_01C18613.522EBD60-- From owner-ips@ece.cmu.edu Sun Dec 16 13:19:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03481 for ; Sun, 16 Dec 2001 13:19:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBGHlqY27871 for ips-outgoing; Sun, 16 Dec 2001 12:47:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBGHUOZ26838; Sun, 16 Dec 2001 12:30:24 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA88804; Sun, 16 Dec 2001 18:30:18 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBGHUk9153208; Sun, 16 Dec 2001 18:30:46 +0100 Received: from PS180-18 ([32.226.99.175]) by d10hubm1.telaviv.ibm.com (Lotus Domino Release 5.0.8) with ESMTP id 2001121619303895:1529 ; Sun, 16 Dec 2001 19:30:38 +0200 From: Julian_Satran/Haifa/IBM%IBMIL@telaviv.ibm.com To: ips@ece.cmu.edu Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Questions about implementation of Multiple connections MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: Date: Mon, 10 Dec 2001 20:05:23 +0200 X-MIMETrack: Serialize by Notes Client on Julian Satran/Haifa/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 16-12-2001 19:30:13, Serialize complete at 16-12-2001 19:30:13, Itemize by SMTP Server on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/12/2001 19:30:40, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/12/2001 19:30:45, Serialize complete at 16/12/2001 19:30:45 Content-Type: multipart/alternative; boundary="=_alternative 00635EBEC2256B1E_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00635EBEC2256B1E_= Content-Type: text/plain; charset="US-ASCII" Meng, owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42: > I have several questions about multiple connections: > > (1) Are multiple connections between initiator and a > target common? I mean, how many applications will > require iSCSI implementation to be able to handle > multiple connections within a session? Can anybody > give me some overview idea about the application of > multiple TCP connections, like: is it an exceptional > case? or common case? > I assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it. > (2) Consider a hard drive on the network. It only has > one hardware port. If we want to develop a iSCSI box > to handle all incoming iSCSI commands for it, is it > necessary for the box to handle multiple TCP > connections for this hard drive? How? Does the box > need more than one IP addresses? > I don't think you need this for one disk although you may want to admit two for recovery. > Thanks, > Meng > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com Julo --=_alternative 00635EBEC2256B1E_= Content-Type: text/html; charset="US-ASCII"
Meng,

owner-ips@ece.cmu.edu wrote on 10-12-2001 08:28:42:

> I have several questions about multiple connections:
>
> (1) Are multiple connections between initiator and a
> target common? I mean, how many applications will
> require iSCSI implementation to be able to handle
> multiple connections within a session? Can anybody
> give me some overview idea about the application of
> multiple TCP connections, like: is it an exceptional
> case? or common case?
>

I  assume that many mid and high end boxes (RAID, JBOD and NAS with iSCSI "personality") will have it.

> (2) Consider a hard drive on the network. It only has
> one hardware port. If we want to develop a iSCSI box
> to handle all incoming iSCSI commands for it, is it
> necessary for the box to handle multiple TCP
> connections for this hard drive? How? Does the box
> need more than one IP addresses?
>

I don't think you need this for one disk although you may want to admit two for  recovery.


> Thanks,
> Meng
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
Julo --=_alternative 00635EBEC2256B1E_=-- From owner-ips@ece.cmu.edu Sun Dec 16 13:19:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03493 for ; Sun, 16 Dec 2001 13:19:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBGHOEE26509 for ips-outgoing; Sun, 16 Dec 2001 12:24:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBGHOCZ26504 for ; Sun, 16 Dec 2001 12:24:12 -0500 (EST) Received: from somesh ([12.81.3.193]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20011216172358.YYEP5540.mtiwmhc21.worldnet.att.net@somesh>; Sun, 16 Dec 2001 17:23:58 +0000 Reply-To: From: "Somesh Gupta" To: "Julian Satran" , Subject: RE: Re: iSCSI Marker questions Date: Sun, 16 Dec 2001 09:22:30 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01C18613.2FEEBC00" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C18613.2FEEBC00 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Julian, Should the marker interval be counted from the begining of 1 marker to the begining of the next, or from the end of one marker to the begining of the next. Having the marker interval counted from the begining of 1 marker to the begining of the next makes it easier for the receiver to determine where the next marker will be. Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, December 11, 2001 4:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questionsLink Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. ------=_NextPart_000_0091_01C18613.2FEEBC00 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Julian,
 
Should=20 the marker interval be counted from the begining of 1 marker to=20 the
begining of the next, or from the end of one = marker to=20 the begining of the next.
Having=20 the marker interval counted from the begining of 1 marker to the=20 begining
of the=20 next makes it easier for the receiver to determine where the next=20 marker
will=20 be.
 
Somesh
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Tuesday, December 11, 2001 4:54 = PM
To:=20 ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker=20 questions


----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39=20 -----
Julian=20 Satran=20

11-12-01 14:44 =


  =  =20     To:        IPS List =
        cc: =    =20    
  =  =20     Subject:        Re: iSCSI = Marker=20 questionsLink=20


Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 = 03:09:11:

> The=20 iSCSI Draft 9 Appendix C makes the following statements about
> = Markers=20 and the Initial Marker-less Interval:
>
>    =20  "The offset to the next iSCSI PDU header is counted in = terms
>=20       of the TCP stream data. Anything counted in the = TCP=20
>       sequence-number is counted for the = offset.=20 Specifically this
>       includes any bytes = "inserted"=20 in the TCP stream by an UFL and
>       it = excludes any=20 other markers inserted between the one we are
>     =  =20 examining and the next PDU header."...
>
>     =  "To enable the connection setup including the login phase =
>=20       negotiation, marking (if any) is started only at = the=20 first
>       marker interval after the end of = the login=20 phase."
>
> I understand that markers are not inserted = until=20 after login phase.
> Am I correct to assume that the placement = of the=20 first marker
> determined by the TCP sequence numbers on the = final=20 Login Request/
> Response PDUs, or is initial marker position = determined=20 by the
> TCP sequence numbers at connection = establishment?
>=20
> Assume the following interaction:
>
> I-> =  SYN=20     (TCP sequenceNum=3D1000)  -- irrelevant to this=20 discussion?
>
> T->  SYN-ACK (TCP = sequenceNum=3D2000)=20  -- irrelevant to this discussion?
>
> I-> =  Login=20 Request PDU, T=3D0,CSG=3D1,NSG=3D0:
>    =20  InitiatorName=3Dxxx
>     =  TargetName=3Dyyy
>=20      SessionType=3Dnormal
>     =  ...
>=20      FMarker=3Dsend-receive
>    =20  RFMarkInt=3D512,1024
>
> T->  Login = Response PDU,=20 T=3D0,CSG=3D1,NSG=3D0:
>      ...
>   =  =20  FMarker=3Dsend-receive
>     =  SFMarkInt=3D1024
>=20      RFMarkInt=3D1024
>
> I-> =  Login Request=20 PDU, T=3D1,CSG=3D1,NSG=3D3:
>     =  SFMarkInt=3D1024
>=20      (64-byte PDU... TCP = sequenceNum=3D1301-1364)
>=20
> T->  Login Response PDU, = T=3D1,CSG=3D1,NSG=3D3:
>  =20    (48-byte PDU... TCP sequenceNum=3D2201-2248)
> =
> The=20 above interaction designates a 1024 x 4 =3D 4096-byte marker
> = interval=20 in both directions. The first PDU byte sent by the
> intitiator = in=20 full-feature mode will have sequenceNum=3D1365, and
> the first = byte sent=20 by the target will have sequenceNum=3D2249.
>
> Assuming = the=20 markerless interval starts at the end of login
> phase, the = first two=20 markers in each direction will have the
> following TCP = sequence=20 numbers:
>
>             =  =20  TCP SeqNum of    TCP SeqNum of
>     =  =20          First Marker     Second=20 Marker
>              =20  ------------     -------------
> Initiator: =  =20   5461-5468        9565-9572
> Target: =  =20      6345-6352      =20  10449-10456
>
No - the=20 correct numbers are dependent only on the marker interval (not the = length of=20 the login phase) and are:

Initiator        5096-5103     =  =20  9200-9201
Target =  =20         6096-6103      =20  10200-10201
 =20
 
> Is this the = correct=20 interpretation of marker usage in iSCSI
> Draft 9, or does = marker=20 placement depend on the connection's
> initial sequence = numbers?
>=20
> Also, is "RFMarkInt=3D..." always considered an offer, and=20 "SFMarkInt=3D"
> considered a reply to that offer? If an offer = is sent=20 with "FMarker=3D..."
> and "RFMarkInt=3D...", MUST the reply = contain either=20 "FMarker=3Dno" or
> BOTH "FMarker=3Dyes" and = "SFMarkInt=3D..."?
>=20

Fmarker is not boolean - = legal values=20 are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is = ready to=20 use
otherwise the = responder can't=20 answer.
I assume a = normal dialogue=20 may go like:

I->FMarker=3Dsend-receive,RFMarkInt=3D1,4,SFMarkInt=3D1,512=20
T->FMarker=3Dsend-receive,RFMarkInt=3D8,=20 SFMarkInt=3D2

Please observe that=20 target answers with RFMarkInt to the initiators SFMarkInt and=20 viceversa.

I will = attempt an=20 example in draft 10 (last?).


 
> Thanks,
> Dean Scoville
> QLogic=20 Corp.

------=_NextPart_000_0091_01C18613.2FEEBC00-- From owner-ips@ece.cmu.edu Sun Dec 16 23:05:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09272 for ; Sun, 16 Dec 2001 23:05:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBH39UM26480 for ips-outgoing; Sun, 16 Dec 2001 22:09:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBH39LZ26469 for ; Sun, 16 Dec 2001 22:09:26 -0500 (EST) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 08:42:26 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A02D74A8B@DCMTECHDOM> From: Nayan Kumar Garg To: ips@ece.cmu.edu Subject: remove Date: Mon, 17 Dec 2001 08:42:24 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C186A8.A6305E60" Sender: owner-ips@ece.cmu.edu 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_01C186A8.A6305E60 Content-Type: text/plain; charset="iso-8859-1" remove ------_=_NextPart_001_01C186A8.A6305E60 Content-Type: text/html; charset="iso-8859-1"
remove
------_=_NextPart_001_01C186A8.A6305E60-- From owner-ips@ece.cmu.edu Mon Dec 17 10:15:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04820 for ; Mon, 17 Dec 2001 10:15:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHELGM10779 for ips-outgoing; Mon, 17 Dec 2001 09:21:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHELEZ10774 for ; Mon, 17 Dec 2001 09:21:14 -0500 (EST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id GAA00802; Mon, 17 Dec 2001 06:21:07 -0800 (PST) From: Keith McCloghrie Message-Id: <200112171421.GAA00802@cisco.com> Subject: Re: iSCSI - structured values To: marjorie_krueger@hp.com ("KRUEGER,MARJORIE (HP-Roseville,ex1)") Date: Mon, 17 Dec 2001 06:21:07 -0800 (PST) Cc: kzm@cisco.com ('Keith McCloghrie'), ips@ece.cmu.edu In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87805CCF29D@xrose06.rose.hp.com> from "KRUEGER,MARJORIE (HP-Roseville,ex1)" at Dec 10, 2001 07:31:44 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think the issue is that multiple assignments within a 16-bit identifier assume that there is coordination between the various components that need to make/use those assignments for the same iSCSI instance. Obviously, that is true if the components will share the same assignment. However, the expansion beyond 16-bits for ISID recognizes that such coordination is not possible in all cases in Initiators. I suggest that even if one can not see it today, we should not prohibit future innovation which could well create the same problem for Target Portal Groups. Furthermore, it is now apparent that the proposed resolution of the problem for Initiators punts the problem to vendors. That is, the WG is requiring vendors to implement a proprietary mechanism in order to have interoperability between two different products from the same vendor. I'm very doubtful that is kosher. Keith. > What is the problem you would like to solve by applying the same scheme to > assigning Target Portal Group numbers? The problem of ISID assignment was > different than Target Portal Group number assignment. Since I don't see a > similar problem with targets and their portal group assignment, I don't see > the need for changes regarding TPG numbering. > > Marjorie > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Wednesday, December 05, 2001 9:23 AM > > To: ips@ece.cmu.edu > > Cc: kzm@cisco.com > > Subject: iSCSI - structured values > > > > > > Hi, > > > > The following ideas came up in a discussion I had about iSCSI. > > > > The first issue is about the algorithm to use for allocating the > > structured ISID values, which contain three fields: > > > > - The Type field identifies the format: > > 00h - IEEE OUI > > 01h - IANA Enterprise Number (EN) > > 02h - "Random" > > 03h-FFh - Reserved > > - The Naming Authority field identifies the vendor or organization > > - The Qualifier field is a 16 bit value that provides a range of > > possible values for the ISID within the Type and Naming Authority > > namespace. > > > > The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify: > > > > (a) As noted, the structure of the ISID namespace provides each > > vendor with its own piece of the ISID namespace. In effect, this > > provides for a vendor-partitioning of that namespace within each > > initiator. > > > > So, this puts the onus on a "vendor" to come up with the vendor's own > > scheme for allocating ISID values. For the situation where a vendor > > wants to assign different values to different interfaces/HBAs, the > > simplest scheme would be to use a unique value which is shipped with > > each product, such as a MAC address. This would be simple because it > > would obviate any need to coordinate between different interfaces > > (even those from the same vendor). In fact, the first three bytes of > > a 6-byte MAC address are an IEEE OUI, which is exactly what type=0 > > specifies, except that the MAC address has 3 more bytes, and the > > Qualifier field is only 2 bytes. So, in order to allow vendors to > > adopt such a simple scheme, I'd like to propose that the Qualifier > > field be enlarged to at least 3 bytes. It probably doesn't make much > > sense to make the overall ISID to be 7 bytes long. So, how about > > making the Qualifier be 4 bytes so that the ISID is 8 bytes long ? > > As far as I'm aware the performance impact of this is virtually > > negligible, and so I can't really see any disadvantage in doing so. > > > > The second issue concerns Portal Group Tags. It seems that despite > > the difference in terminology, that an ISID and a Portal Group Tag > > are corresponding concepts. For example, a SCSI Port Name is defined > > as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag". However, > > a Portal Group Tag is defined as a 16-bit integer. Now, I understand > > that an ISID was originally defined as a 16-bit integer, before its > > format was expanded (as discussed above). So, with the correspondence > > of ISID and Portal Group Tag, surely it makes sense for a Portal Group > > Tag to have the same format as an ISID. This will allow vendors of > > iSCSI targets with multiple interfaces/HBAs to use a simple scheme as > > and when they need to assign different Portal Group Tag values to the > > different interfaces/HBAs. So, whether or not the ISID format is > > changed based on the first issue above, I propose that the same > > structured format be used for both ISIDs and Portal Group Tags. > > > > Keith. > > > From owner-ips@ece.cmu.edu Mon Dec 17 11:04:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07705 for ; Mon, 17 Dec 2001 11:04:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHF7LF13832 for ips-outgoing; Mon, 17 Dec 2001 10:07:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHF7KZ13827 for ; Mon, 17 Dec 2001 10:07:20 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fBHF7D605248; Mon, 17 Dec 2001 07:07:13 -0800 (PST) Received: from cisco.com (IDENT:58509@mbakke-lnx.cisco.com [161.44.68.87]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id HAA17665; Mon, 17 Dec 2001 07:07:12 -0800 (PST) Message-ID: <3C1E0757.9887E0E0@cisco.com> Date: Mon, 17 Dec 2001 08:55:19 -0600 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Luben Tuikov CC: Paul Koning , VICENTE V CAVANNA , ips@ece.cmu.edu Subject: Re: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: <20011216104343.69064.qmail@web12808.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is becoming somewhat disturbing, given the comment about the Ethernet CRC. The intent of the document is absolutely, positively to keep the CRC identical to Ethernet, with the exception of the generator, just as Paul had said. I'm not enough of a mathematician to complain about the definition; if there's a good way to fix it so it says what we intend, we should do so. We got around this problem somewhat by simply providing a set of examples. If someone has an implementation that does not match the examples, they simply try a few variations until they get it right. This has worked very well for everyone I have talked to who is implementing the CRC. Here is some text that I had suggested adding instead of (or in addition to) the mathematical description a while ago: The generator polynomial selected is evaluated in [Castagnioli93]. When using the CRC the CRC register must be initialized to all 1s (0xFFFFFFFF). Input bytes are processed with bit 7 being the most significant bit. Before transmission, the CRC bits must be reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1, etc.), and complemented. The CRC bytes must be transmitted in network order. Padding bytes, when present, in a segment covered by a CRC, should be set to 0 and are included in the CRC. Running the CRC-32C generator on an input stream that includes a valid CRC-32C will result in the constant remainder 0x1c2d19ed, (without being reversed and complemented). The above, plus the examples, have seem to work out just fine for the implementors. Getting the math right would be nice, but most of us implementors don't look at it anyway, and prefer the more practical description. If we are going to include the math, it has to match the examples. Anyway, my guess is that is what you are discussing; it was just disturbing to think that anything but the Ethernet + new poly was being considered, since that has been agreed on for a long time, and is being widely implemented. -- Mark Luben Tuikov wrote: > > --- Paul Koning wrote: > > Excerpt of message (sent 14 December 2001) by Luben > > > This is actually equivalent to XORing the first > > > 32 bits of the message with the magic constant as Vince > > > and I have shown. > > > > Are you saying that you believe the intent of the current > > spec is NOT > > the same as the Ethernet CRC, i.e., complement the first > > 32 bits, > > multiply by x^32, then divide by G(x)? > > In our profession we cannot talk about beliefs and > intentions, more so for documents, rfc, etc. > > If you show the current description of the CRC of the draft > to a mathematician, they will object to the same thing I've > objected. > > The reason is that they don't have the preconception about > what circuit is being used, and any such higher level > notions. > > All they would have and all I had was long division in Z_2. > (Actually Z_2[x] since we deal with polynomials.) > > Then I started from first principles of CRC, polydivision, > etc, etc. -- similarly to how Williams proceeds in his > paper, but my treatment was purely algebraic. > > The same applies to anyone looking at a description of an > algorithm. (An ``algorithm'' has a precise definition in > Computer Science.) > > In its current form the description of the algorithm to > compute the CRC in the iSCSI draft is not consistent, just > because there is an unspoken assumption that a SMD circuit > will be used. We cannot afford to do this in a definition > document, unless we refer explicitly to it. We cannot even > assume that a circuit will be used... > > Please also note that the Ethernet spec CRC algorithm, is > an optimized version of a basic > prefix-postfix-initialize-the- > CRC-register-to-some-constant algoritm. BUT as SMD it > operates on NON-AUGMENTED messages. FOR THAT REASON you > cannot say that we have to multiply M(x) by x^32!!! > > I.e. SMD algoritms like the one in the Ethernet spec, > operate on non-augmented messages, while simple Division > (D) algorithms operate on augmented messages. > > Any D can be optimized to SMD, but the constant has to be > changed. Also, prefixing a message is equivalent to loading > the CRC register with that prefix (WLG), but this is not so > for SMD. (elaborated below) > > Further more for any SMD there is an equivalent D, > including for the Ethernet spec SMD; and for any D there is > an equivalent SMD. > > > If that is your interpretation, then we absolutely MUST > > fix the spec, > > I'm quite sure that the intent of the spec is as I wrote > > it, i.e., > > Ethernet except for the generator. > > Probably it is. But lets not hasten here. > We can further generalize the explanation of the algorithm. > > > > If this is changed, then the message in its form: > > > M'(x) = x^32 M(x) + x^(32+n) I(x) > > > > > > yields to better optimizations as Vince and I have > > shown. > > > (see his circuits and worksheet4.pdf, which I posted > > > yesterday) > > > > > > I.e. the message is augmented (mult by x^32, aka > > postfixed) > > > and prefixed by 32 1's (aka CRC=32 1's). > > > > But that is NOT what the spec currently says. What you > > describe may > > be a fine CRC but it is not the one that's in the spec. > > Initializing > > the CRC register to all 1 is not the same as prefixing 32 > > 1 bits onto > > the message. > > It is, in a simple division, e.g. in D. This is clearly and > simply explained in the Williams paper. It is an equivalent > to a long division. > > Now, in D, if I initialize the CRC to all 1's and then do > division of M(x) by G(x), so that I catch 0's at the > beginning of the message, > > (which is equivalent to prefixing the message by 1's of the > number of the width of the CRC, and then do just simple > division,(CRC=0), since after so many clicks the CRC will > be loaded with the prefixing bits, and also 0/G(x) = 0) > > then I can find a constant which I can XOR to the first 32 > bits of the message and then perform the division, still in > D, with the same effect. In this particular case that > constant is the magic constant. (We are one step closer to > SMD...) > > (Now we jump to SMD, by means of worksheet4.pdf, Prefixing > part.) > > Now, in the Ethernet CRC spec, that constant is 32 1's, and > XORing 32 1's with the 32 MSb of the message is equivalent > to complementing them. > > BUT the Ethernet spec uses SMD, not D, so I claim that > there is an equivalent D, which for a suitable initial CRC > (also equivalent to prefixing the message with it) value > will yield IDENTICAL results as Ethernet SMD. > > Now using a bit of algebra similar to worksheet4.pdf which > I posted a couple of days ago and numerical methods > (solving a linear system of 33 unknowns) I have found such > a constant: > 0x2a26f826 which in simple division, D, will yield results > identical to SMD of Ethernet. > > So, here is an abstractization of the Ethernet CRC SMD, > explained in a simple, simple, simple division only way: > > TX: > 1. Mutliply the message, M(x), by x^32. > 2. Prefix the result of 1. with 0x2a26f826. > 3. Find the remainder of the result of 2. > 4. Complement that remainder and add it to the > result of 1. > 5. Send the result of 4. to the recipient. > > RX: (same as steps 1-3 in TX) > 1. Mutliply the message by x^32. > 2. Prefix the result of 1. with 0x2a26f826. > 3. Find the remainder of the result of 2. > > The result of 3 should be 0x1c2d19ed (the magic constant). > > Of course I've ommitted the mirroring of bytes for clarity > and brevity. It can be mentioned on the side, e.g. How to > build the message: mirror the bytes == to swapping the bits > inside the bytes, .... > > Also note that step 4 in TX, adding means exactly that, > since we already mult. by x^32, so the remainder will > nicely fit in the last 32 0 bits. > > Also note that step 2, can be made clearer: > let C(x), be the polynomial representation of 0x2a26f826. > Let n = deg G(x), k-1 = deg M(x) (there are k bits), then > step 2 is: > > 2. Add x^n x^k C(x) to the message M(x). > > Or we can swap step 1 and 2: > > 1. Add x^k C(x) to M(x). > 2. Multiply the result of 1. by x^n. > > I hope this makes things a bit clearer. > > So from this D specification above, I can derive SMD > exaclty as it is in the Ethernet spec. I'll include this > derivation in the paper -- it will be pure math, but in > english it goes like this: First we notice that after 32 > clicks the CRC register will contain only 32 1's XOR-ed > with the message, then we see that we can just load the crc > with ones and then kick one byte off the left xor it with > the next message bit... > > The above equivalence I've tested empirically. > > > What does "better optimizations" mean? > > See above. > > > > In an SMD, one would have to set the CRC to the magic > > > constant and then proceed as the algorithm indicates, > > > (this is identical to what you'd find in Ethernet, ... > > > > No it isn't. The Ethernet spec appendix C, and, more > > importantly, the > > formal definition of the CRC in the body of the spec, > > makes it quite > > clear that it isn't. I don't understand how you arrive > > at any other > > conclusion. > > I didn't mean identical as in the constant. I meant > identical in a way of equivalence of algorithms, that one > can be derived from the other, etc. See above. Or simpler > answer: Math. > > -l > > ===== > -- > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Dec 17 11:05:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07793 for ; Mon, 17 Dec 2001 11:05:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHFb7715887 for ips-outgoing; Mon, 17 Dec 2001 10:37:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHFb5Z15883 for ; Mon, 17 Dec 2001 10:37:05 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBHFaaQ30993; Mon, 17 Dec 2001 10:36:36 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBHFaZL14602; Mon, 17 Dec 2001 10:36:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15390.4355.623462.667567@pkoning.dev.equallogic.com> Date: Mon, 17 Dec 2001 10:36:35 -0500 (EST) From: Paul Koning To: ltuikov@yahoo.com Cc: vince_cavanna@agilent.com, ips@ece.cmu.edu Subject: iSCSI: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: <15387.46883.407000.525991@gargle.gargle.HOWL> <20011216104343.69064.qmail@web12808.mail.yahoo.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Luben" == Luben Tuikov writes: Luben> --- Paul Koning wrote: >> Excerpt of message (sent 14 December 2001) by Luben > This is >> actually equivalent to XORing the first > 32 bits of the message >> with the magic constant as Vince > and I have shown. >> >> Are you saying that you believe the intent of the current spec is >> NOT the same as the Ethernet CRC, i.e., complement the first 32 >> bits, multiply by x^32, then divide by G(x)? Luben> In our profession we cannot talk about beliefs and intentions, Luben> more so for documents, rfc, etc. Luben> If you show the current description of the CRC of the draft to Luben> a mathematician, they will object to the same thing I've Luben> objected. Luben> ... Luben> In its current form the description of the algorithm to Luben> compute the CRC in the iSCSI draft is not consistent, just Luben> because there is an unspoken assumption that a SMD circuit Luben> will be used. We cannot afford to do this in a definition Luben> document, unless we refer explicitly to it. We cannot even Luben> assume that a circuit will be used... I agree that the current description is not consistent and is confusing. That's why I proposed replacement text. I'd be interested in comments on that text. Luben> Please also note that the Ethernet spec CRC algorithm, is an Luben> optimized version of a basic prefix-postfix-initialize-the- Luben> CRC-register-to-some-constant algoritm. I'm not sure what spec you're talking about. The algorithm in the Ethernet spec (section 6.2.4) which was copied into the 802.3 spec (section 3.2.8) pretty much verbatim except for a typo, is not a prefix-postfix-whatever algorithm at all. Instead, it is a mathematical definition of the CRC value. The phrase "initialize the CRC register" does not occur at all in any form. Luben> ... Luben> TX: 1. Mutliply the message, M(x), by x^32. 2. Prefix the Luben> result of 1. with 0x2a26f826. 3. Find the remainder of the Luben> result of 2. 4. Complement that remainder and add it to the Luben> result of 1. 5. Send the result of 4. to the recipient. Luben> RX: (same as steps 1-3 in TX) 1. Mutliply the message by x^32. Luben> 2. Prefix the result of 1. with 0x2a26f826. 3. Find the Luben> remainder of the result of 2. If I understand right, this is a mathematically equivalent way of describing an Ethernet-style CRC. Fine, no problem. But what's the point? All we need is a single formal definition. And it would make the most sense for that definition to look like the ones found in other standards, so it will be clear to the reader that the CRC in iSCSI is the same as the one used in many other places except for the G(x). The text I proposed does that, since it uses the classic text except for G(x). The description you gave may be mathematically equivalent, but that is not at all obvious unless you're fluent in abstract math. In any case, no mathematical description by itself translates easily to an implementation (again, unless you're fluent in abstract math). Most specs disregard that concern and leave it up to the implementer to search the literature. My current proposal is to do likewise for iSCSI. The only exception I've seen is the Ethernet spec, which gives a single example implementation in its appendix. paul From owner-ips@ece.cmu.edu Mon Dec 17 13:06:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13726 for ; Mon, 17 Dec 2001 13:06:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHHR4N23943 for ips-outgoing; Mon, 17 Dec 2001 12:27:04 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHHR2Z23939 for ; Mon, 17 Dec 2001 12:27:02 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA93340; Mon, 17 Dec 2001 18:26:55 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHHRPG190246; Mon, 17 Dec 2001 18:27:25 +0100 To: "Jim Pinkerton" , ips@ece.cmu.edu Cc: allyn@cisco.com, csapuntz@cisco.com, howard.c.herbert@intel.com, "Stephen Bailey" , uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Mon, 17 Dec 2001 19:27:19 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/12/2001 19:27:23, Serialize complete at 17/12/2001 19:27:23 Content-Type: multipart/alternative; boundary="=_alternative 005F687CC2256B25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005F687CC2256B25_= Content-Type: text/plain; charset="US-ASCII" Jim, There are some things attractive about COWS - 1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side 2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved 3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation Julo "Jim Pinkerton" wrote on 17-12-2001 17:32:04: > > My main concern with this approach is that we could kill the product but > win the spec wars. Specifically, this approach means that an > end-customer has one of two choices in deploying the technology: > > 1) Upgrade both ends, and they'll see the full benefit > 2) Upgrade only the server side, and see roughly 2-4 times the > CPU > utilization on the client if their current > implementation is optimized > on the client side (a mere 2x if they are doing > significant > receives that already require a copy, more like 4x if > they > are primarily doing sends, which currently has no bcopy > in > many OS implementations). > > This means that if they pick option 2) and their machines are CPU bound, > that the data center capacity to handle requests will actually > *decrease* if they deploy the technology. If the front end has enough > idle CPU cycles, then they probably could select option 2). > > In my experience, we need to make sure we have a volume solution to > enable NIC vendors to make enough profit to fund the next generation > (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU > architecture). This means we need a path to the front-end boxes in the > data center. My concern is that there is no half-measure in the above > scenario - the IT manager must upgrade the thousand front-end boxes at > the same time as they upgrade the back end, or deploy asymmetric configs > where some front end boxes are upgraded. I'm not sure how attractive > this deployment scenario is. > > Howard and Uri, can you comment on this issue? > > > > Jim > > > > > > > > > -----Original Message----- > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > > Sent: Monday, December 17, 2001 7:13 AM > > To: uri@broadcom.com; howard.c.herbert@intel.com > > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com; > > allyn@cisco.com > > Subject: Wot I `know' about COWS in hardware > > > > Hi, > > > > I haven't gotten a chance to do a full implementation yet, but here's > > some architectural properties I believe to be true of a hardware COWS > > implementation: > > > > 1) can be implemented `in line' on receive > > 2) requires an MTU-sized RAM on send > > 3) expected touches to send RAM is 2 per data word (just the `fifo' > > write and read ops, no editing), assuming the headers are merged > > on the outbound side. > > 4) worst case touches to send RAM is 3 per data word (assuming every > > word must be edited) > > 5) eliminates the need for the funky `make sure you don't send > > anything that's false positive under non-nominal conditions' > > behavior of the key/length proposal (I kinda doubted hardware > > impls were going to do this anyway, since it was a SHOULD). > > > > Basically, it looks OK to me. Slowing the sender is much better than > > slowing the receiver. Theoretically, we could reverse the pointer > > chain and allow in-line send, but RAM on receive, but that seems > > stupid to me. > > > > It's clearly a design tradeoff whether you chose to use the COWS > > send-side RAM for other purposes, or not. > > > > I'm hoping you guys can tell me whether you think this blows your > > budget, or other noteworthy (unfortunate) properties. As you can > > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...). > > > > Thanks, > > Steph --=_alternative 005F687CC2256B25_= Content-Type: text/html; charset="US-ASCII"
Jim,

There are some things attractive about COWS -

1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side

2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved

3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation

Julo

"Jim Pinkerton" <jpink@microsoft.com> wrote on 17-12-2001 17:32:04:

>
> My main concern with this approach is that we could kill the product but
> win the spec wars. Specifically, this approach means that an
> end-customer has one of two choices in deploying the technology:
>
>    1) Upgrade both ends, and they'll see the full benefit
>    2) Upgrade only the server side, and see roughly 2-4 times the
> CPU
>       utilization on the client if their current
>       implementation is optimized
>       on the client side (a mere 2x if they are doing
> significant
>       receives that already require a copy, more like 4x if
> they
>       are primarily doing sends, which currently has no bcopy
> in
>       many OS implementations).
>
> This means that if they pick option 2) and their machines are CPU bound,
> that the data center capacity to handle requests will actually
> *decrease* if they deploy the technology. If the front end has enough
> idle CPU cycles, then they probably could select option 2).
>
> In my experience, we need to make sure we have a volume solution to
> enable NIC vendors to make enough profit to fund the next generation
> (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU
> architecture). This means we need a path to the front-end boxes in the
> data center. My concern is that there is no half-measure in the above
> scenario - the IT manager must upgrade the thousand front-end boxes at
> the same time as they upgrade the back end, or deploy asymmetric configs
> where some front end boxes are upgraded. I'm not sure how attractive
> this deployment scenario is.
>
> Howard and Uri, can you comment on this issue?
>
>
>
> Jim
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> > Sent: Monday, December 17, 2001 7:13 AM
> > To: uri@broadcom.com; howard.c.herbert@intel.com
> > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com;
> > allyn@cisco.com
> > Subject: Wot I `know' about COWS in hardware
> >
> > Hi,
> >
> > I haven't gotten a chance to do a full implementation yet, but here's
> > some architectural properties I believe to be true of a hardware COWS
> > implementation:
> >
> >   1) can be implemented `in line' on receive
> >   2) requires an MTU-sized RAM on send
> >   3) expected touches to send RAM is 2 per data word (just the `fifo'
> >      write and read ops, no editing), assuming the headers are merged
> >      on the outbound side.
> >   4) worst case touches to send RAM is 3 per data word (assuming every
> >      word must be edited)
> >   5) eliminates the need for the funky `make sure you don't send
> >      anything that's false positive under non-nominal conditions'
> >      behavior of the key/length proposal (I kinda doubted hardware
> >      impls were going to do this anyway, since it was a SHOULD).
> >
> > Basically, it looks OK to me.  Slowing the sender is much better than
> > slowing the receiver.  Theoretically, we could reverse the pointer
> > chain and allow in-line send, but RAM on receive, but that seems
> > stupid to me.
> >
> > It's clearly a design tradeoff whether you chose to use the COWS
> > send-side RAM for other purposes, or not.
> >
> > I'm hoping you guys can tell me whether you think this blows your
> > budget, or other noteworthy (unfortunate) properties.  As you can
> > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...).
> >
> > Thanks,
> >   Steph
 --=_alternative 005F687CC2256B25_=-- From owner-ips@ece.cmu.edu Mon Dec 17 13:17:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14047 for ; Mon, 17 Dec 2001 13:17:52 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHH6nt22374 for ips-outgoing; Mon, 17 Dec 2001 12:06:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBH2HZZ23691 for ; Sun, 16 Dec 2001 21:17:35 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id DAA118862; Mon, 17 Dec 2001 03:17:27 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBH2HrC128836; Mon, 17 Dec 2001 03:17:59 +0100 Received: from PS180-18 ([9.141.221.35]) by d10hubm1.telaviv.ibm.com (Lotus Domino Release 5.0.8) with ESMTP id 2001121704174662:101 ; Mon, 17 Dec 2001 04:17:46 +0200 From: Julian_Satran/Haifa/IBM%IBMIL@telaviv.ibm.com To: Cc: ips@ece.cmu.edu Subject: RE: Re: iSCSI Marker questions MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: Date: Sun, 16 Dec 2001 21:53:59 +0200 X-MIMETrack: Serialize by Notes Client on Julian Satran/Haifa/IBM(Build M11_11052001 Beta 4|November 05, 2001) at 17-12-2001 04:17:21, Serialize complete at 17-12-2001 04:17:21, Itemize by SMTP Server on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/12/2001 04:17:47, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/12/2001 04:17:56, Serialize complete at 17/12/2001 04:17:56 Content-Type: multipart/alternative; boundary="=_alternative 006D4FE0C2256B24_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006D4FE0C2256B24_= Content-Type: text/plain; charset="US-ASCII" Somesh, Marker interval is from the end-of-marker to the beginning-of-next marker. The pointers to the next header do not include markers either. Calculating the marker position is trivial anyway. Pointers are not dependent on the marker interval and can be computed without knowing the TCP sequence numbers (makes layering cleaner). Regards, Julo "Somesh Gupta" 16-12-01 19:22 Please respond to somesh_gupta To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: Re: iSCSI Marker questions Julian, Should the marker interval be counted from the begining of 1 marker to the begining of the next, or from the end of one marker to the begining of the next. Having the marker interval counted from the begining of 1 marker to the begining of the next makes it easier for the receiver to determine where the next marker will be. Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, December 11, 2001 4:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questionsLink Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. --=_alternative 006D4FE0C2256B24_= Content-Type: text/html; charset="US-ASCII"
Somesh,

Marker interval is from the end-of-marker to the beginning-of-next marker.
The pointers to the next header do not include markers either.

Calculating the marker position is trivial anyway.
Pointers are not dependent on the marker interval and can be computed without knowing the TCP sequence numbers (makes layering cleaner).

Regards,
Julo


"Somesh Gupta" <somesh_gupta@silverbacksystems.com>

16-12-01 19:22
Please respond to somesh_gupta

       
        To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: Re: iSCSI Marker questions



Julian,
 
Should the marker interval be counted from the begining of 1 marker to the
begining of the next, or from the end of one marker to the begining of the next.
Having the marker interval counted from the begining of 1 marker to the begining
of the next makes it easier for the receiver to determine where the next marker
will be.
 
Somesh
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Tuesday, December 11, 2001 4:54 PM
To: ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker questions

----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


       To:        IPS List
       cc:        
       Subject:        Re: iSCSI Marker questionsLink



Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 

> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).



> Thanks,
> Dean Scoville
> QLogic Corp.

--=_alternative 006D4FE0C2256B24_=-- From owner-ips@ece.cmu.edu Mon Dec 17 14:02:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15075 for ; Mon, 17 Dec 2001 14:02:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHIFNL27483 for ips-outgoing; Mon, 17 Dec 2001 13:15:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.com (040.dsl6660175.bstatic.surewest.net [66.60.175.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHIFKZ27478 for ; Mon, 17 Dec 2001 13:15:20 -0500 (EST) Received: by homer.lmg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 10:13:50 -0800 Message-ID: From: Dean Scoville To: "ips@ece. cmu. edu (E-mail)" Subject: RE: Re: iSCSI Marker questions Date: Mon, 17 Dec 2001 10:13:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18726.92051C40" Sender: owner-ips@ece.cmu.edu 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_01C18726.92051C40 Content-Type: text/plain; charset="iso-8859-1" Julian, An undesirable side affect of starting the marker interval at connection establishment time and including the SYN char in the interval is that the alignment of markers will ALWAYS be different than the alignment of iSCSI PDUs. This is messy for anyone who is looking at things in 4-byte pieces. The alignment of the markers will ALWAYS differ by one byte from the PDU alignment. Using the example cited in the earlier posting, the first marker byte will ALWAYS have an EVEN-numbered TCP sequence number, and the first PDU byte will ALWAYS have an ODD-numbered TCP sequence number. > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) > > T-> SYN-ACK (TCP sequenceNum=2000) > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > TCP SeqNum of > First Marker > ------------ > Initiator: 5096-5103 > Target: 6096-6103 > Since the layer that inserts the markers needs to be aware of login anyway (it can't insert markers during login phase), I would rather that the marker interval didn't start until the end of login phase. It would avoid some messy corner cases (see next paragraph). If this is unacceptable, then let's at least not count the SYN char in the marker interval, so that the markers can be on the same 4-byte alignment as the PDUs. If the marker interval remains as it is currently defined, how are partial markers treated at the end of login phase? Modifying the previous example a little, if the initiator's final PDU during login phase had TCP sequence numbers 5035-5098 should we insert the last 5-bytes of the marker into the data stream? If the final PDU were at 5039-5102, would we insert 1-byte of the marker into the data stream? Or would we skip the first marker altogether because part of it would have begun during login phase? Either way, it is messy. -Dean -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 7:58 PM To: Dean Scoville Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: RE: Re: iSCSI Marker questions You are right there is no range today for SFMarkint - we may want to change this to enable a one-shot negotiation. Julo Dean Scoville Sent by: owner-ips@ece.cmu.edu 14-12-01 20:10 To: "ips@ece. cmu. edu (E-mail)" cc: Subject: RE: Re: iSCSI Marker questions Julian, Thanks for the response. Some examples would be very helpful. Your response shows a parameter negotiation with SFMarkInt=1,512 but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt. Is a range also being allowed for SFMarkInt? > > I assume a normal dialogue may go like: > > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 > Section 2.2.4 of the draft currently requires all integer parameter negotiations to have a response . (Responses are optional only with boolean negotiations where the offered value allows only a single outcome -- such as an "OR" boolean function with a "Yes" offer). Are responses always required for RFMarkInt and SFMarkInt, or is the following acceptable? I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4 Would it also be allowed to respond with the following and, if so, is one preferred over the other? (I'm not sure about the current state of using "0" as a "don't care" value, but is that also permitted in cases where the response would be irrelevant?) I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant With the following exchange, is the target required to respond with any RFMarkInt or SFMarkInt values, since there is no real choice of values? Agreeing to send markers implies that the interval is 512, and not agreeing to receive markers implies that there is no receive interval. Is the following allowed, or should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned by the target? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=send Is the following acceptable, even though it doesn't reply to RFMarkInt and SFMarkInt? I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 T-> FMarker=no It would also be helpful to explain what happens if the login phase goes beyond the negotiated first marker interval. Assume, for example, the following: SYN - at TCP sequence num 1000. SYN-ACK - at TCP sequence num 2000. negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100. If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404, full-feature phase starts in the middle of what would have been a marker. Is a partial marker inserted? What would be the TCP seqNum of the first and second marker? If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810, what would be the TCP seqNum of the first and second marker? thanks, Dean -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, December 11, 2001 4:54 PM To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI Marker questions ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- Julian Satran 11-12-01 14:44 To: IPS List cc: Subject: Re: iSCSI Marker questions Link Dean, owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > The iSCSI Draft 9 Appendix C makes the following statements about > Markers and the Initial Marker-less Interval: > > "The offset to the next iSCSI PDU header is counted in terms > of the TCP stream data. Anything counted in the TCP > sequence-number is counted for the offset. Specifically this > includes any bytes "inserted" in the TCP stream by an UFL and > it excludes any other markers inserted between the one we are > examining and the next PDU header."... > > "To enable the connection setup including the login phase > negotiation, marking (if any) is started only at the first > marker interval after the end of the login phase." > > I understand that markers are not inserted until after login phase. > Am I correct to assume that the placement of the first marker > determined by the TCP sequence numbers on the final Login Request/ > Response PDUs, or is initial marker position determined by the > TCP sequence numbers at connection establishment? > > Assume the following interaction: > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > InitiatorName=xxx > TargetName=yyy > SessionType=normal > ... > FMarker=send-receive > RFMarkInt=512,1024 > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > ... > FMarker=send-receive > SFMarkInt=1024 > RFMarkInt=1024 > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > SFMarkInt=1024 > (64-byte PDU... TCP sequenceNum=1301-1364) > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > (48-byte PDU... TCP sequenceNum=2201-2248) > > The above interaction designates a 1024 x 4 = 4096-byte marker > interval in both directions. The first PDU byte sent by the > intitiator in full-feature mode will have sequenceNum=1365, and > the first byte sent by the target will have sequenceNum=2249. > > Assuming the markerless interval starts at the end of login > phase, the first two markers in each direction will have the > following TCP sequence numbers: > > TCP SeqNum of TCP SeqNum of > First Marker Second Marker > ------------ ------------- > Initiator: 5461-5468 9565-9572 > Target: 6345-6352 10449-10456 > No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are: Initiator 5096-5103 9200-9201 Target 6096-6103 10200-10201 > Is this the correct interpretation of marker usage in iSCSI > Draft 9, or does marker placement depend on the connection's > initial sequence numbers? > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > considered a reply to that offer? If an offer is sent with "FMarker=..." > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > BOTH "FMarker=yes" and "SFMarkInt=..."? > Fmarker is not boolean - legal values are no, send, receive, send-receive The sender and receiver must set the interval it wants/is ready to use otherwise the responder can't answer. I assume a normal dialogue may go like: I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa. I will attempt an example in draft 10 (last?). > Thanks, > Dean Scoville > QLogic Corp. ------_=_NextPart_001_01C18726.92051C40 Content-Type: text/html; charset="iso-8859-1"
Julian,
An undesirable side affect of starting the marker interval at connection establishment time and including the SYN char in the interval is that the alignment of markers will ALWAYS be different than the alignment of iSCSI PDUs. This is messy for anyone who is looking at things in 4-byte pieces. The alignment of the markers will ALWAYS differ by one byte from the PDU alignment. Using the example cited in the earlier posting, the first marker byte will ALWAYS have an EVEN-numbered TCP sequence number, and the first PDU byte will ALWAYS have an ODD-numbered TCP sequence number.
 
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)
>
> T->  SYN-ACK (TCP sequenceNum=2000)
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
>                TCP SeqNum of    
>                First Marker    
>                ------------    
> Initiator:     5096-5103        
> Target:        6096-6103 
> 
 
Since the layer that inserts the markers needs to be aware of login anyway (it can't insert markers during login phase), I would rather that the marker interval didn't start until the end of login phase. It would avoid some messy corner cases (see next paragraph). If this is unacceptable, then let's at least not count the SYN char in the marker interval, so that the markers can be on the same 4-byte alignment as the PDUs.
 
If the marker interval remains as it is currently defined, how are partial markers treated at the end of login phase? Modifying the previous example a little, if the initiator's final PDU during login phase had TCP sequence numbers 5035-5098 should we insert the last 5-bytes of the marker into the data stream? If the final PDU were at 5039-5102, would we insert 1-byte of the marker into the data stream? Or would we skip the first marker altogether because part of it would have begun during login phase? Either way, it is messy.
 
-Dean
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, December 14, 2001 7:58 PM
To: Dean Scoville
Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
Subject: RE: Re: iSCSI Marker questions


You are right there is no range today for SFMarkint - we may want to change this to enable a one-shot negotiation.

Julo


Dean Scoville <Dean.Scoville@qlogic.com>
Sent by: owner-ips@ece.cmu.edu

14-12-01 20:10

       
        To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: Re: iSCSI Marker questions



Julian,
Thanks for the response. Some examples would be very helpful.
Your response shows a parameter negotiation with SFMarkInt=1,512
but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt.
Is a range also being allowed for SFMarkInt?
 
>
> I assume a normal dialogue may go like:
>
> I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
>
Section 2.2.4 of the draft currently requires all integer parameter
negotiations to have a response . (Responses are optional only
with boolean negotiations where the offered value allows only a
single outcome -- such as an "OR" boolean function with a "Yes"
offer). Are responses always required for RFMarkInt and SFMarkInt,
or is the following acceptable?
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4
 
Would it also be allowed to respond with the following and, if so,
is one preferred over the other? (I'm not sure about the current
state of using "0" as a "don't care" value, but is that also
permitted in cases where the response would be irrelevant?)
 
I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant
 
With the following exchange, is the target required to respond
with any RFMarkInt or SFMarkInt values, since there is no
real choice of values? Agreeing to send markers implies that
the interval is 512, and not agreeing to receive markers implies
that there is no receive interval. Is the following allowed, or
should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned
by the target?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=send
 
Is the following acceptable, even though it doesn't reply to
RFMarkInt and SFMarkInt?
 
I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
T-> FMarker=no
 
It would also be helpful to explain what happens if the login
phase goes beyond the negotiated first marker interval.
Assume, for example, the following:
 
  SYN - at TCP sequence num 1000.
  SYN-ACK - at TCP sequence num 2000.
  negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100.
 
If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404,
full-feature phase starts in the middle of what would have been a marker.
Is a partial marker inserted? What would be the TCP seqNum of the first and
second marker?
 
If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810,
what would be the TCP seqNum of the first and second marker?
 
thanks,
Dean
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, December 11, 2001 4:54 PM
To: ips@ece.cmu.edu
Subject: Fw: Re: iSCSI Marker questions


----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
Julian Satran

11-12-01 14:44


       To:        IPS List
       cc:        
       Subject:        Re: iSCSI Marker questionsLink



Dean,



owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:

> The iSCSI Draft 9 Appendix C makes the following statements about
> Markers and the Initial Marker-less Interval:
>
>      "The offset to the next iSCSI PDU header is counted in terms
>       of the TCP stream data. Anything counted in the TCP
>       sequence-number is counted for the offset. Specifically this
>       includes any bytes "inserted" in the TCP stream by an UFL and
>       it excludes any other markers inserted between the one we are
>       examining and the next PDU header."...
>
>      "To enable the connection setup including the login phase
>       negotiation, marking (if any) is started only at the first
>       marker interval after the end of the login phase."
>
> I understand that markers are not inserted until after login phase.
> Am I correct to assume that the placement of the first marker
> determined by the TCP sequence numbers on the final Login Request/
> Response PDUs, or is initial marker position determined by the
> TCP sequence numbers at connection establishment?
>
> Assume the following interaction:
>
> I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
>
> T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
>
> I->  Login Request PDU, T=0,CSG=1,NSG=0:
>      InitiatorName=xxx
>      TargetName=yyy
>      SessionType=normal
>      ...
>      FMarker=send-receive
>      RFMarkInt=512,1024
>
> T->  Login Response PDU, T=0,CSG=1,NSG=0:
>      ...
>      FMarker=send-receive
>      SFMarkInt=1024
>      RFMarkInt=1024
>
> I->  Login Request PDU, T=1,CSG=1,NSG=3:
>      SFMarkInt=1024
>      (64-byte PDU... TCP sequenceNum=1301-1364)
>
> T->  Login Response PDU, T=1,CSG=1,NSG=3:
>      (48-byte PDU... TCP sequenceNum=2201-2248)
>
> The above interaction designates a 1024 x 4 = 4096-byte marker
> interval in both directions. The first PDU byte sent by the
> intitiator in full-feature mode will have sequenceNum=1365, and
> the first byte sent by the target will have sequenceNum=2249.
>
> Assuming the markerless interval starts at the end of login
> phase, the first two markers in each direction will have the
> following TCP sequence numbers:
>
>                TCP SeqNum of    TCP SeqNum of
>                First Marker     Second Marker
>                ------------     -------------
> Initiator:     5461-5468        9565-9572
> Target:        6345-6352        10449-10456
>
No - the correct numbers are dependent only on the marker interval (not the length of the login phase) and are:

Initiator        5096-5103        9200-9201
Target           6096-6103        10200-10201
 

> Is this the correct interpretation of marker usage in iSCSI
> Draft 9, or does marker placement depend on the connection's
> initial sequence numbers?
>
> Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> considered a reply to that offer? If an offer is sent with "FMarker=..."
> and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> BOTH "FMarker=yes" and "SFMarkInt=..."?
>

Fmarker is not boolean - legal values are no, send, receive, send-receive
The sender and receiver must set the interval it wants/is ready to use
otherwise the responder can't answer.
I assume a normal dialogue may go like:

I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2

Please observe that target answers with RFMarkInt to the initiators SFMarkInt and viceversa.

I will attempt an example in draft 10 (last?).



> Thanks,
> Dean Scoville
> QLogic Corp.


------_=_NextPart_001_01C18726.92051C40-- From owner-ips@ece.cmu.edu Mon Dec 17 14:08:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15213 for ; Mon, 17 Dec 2001 14:08:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHI9JC27020 for ips-outgoing; Mon, 17 Dec 2001 13:09:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-m02.mx.aol.com (imo-m02.mx.aol.com [64.12.136.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHI9HZ27011 for ; Mon, 17 Dec 2001 13:09:17 -0500 (EST) Received: from VAHUJA@aol.com by imo-m02.mx.aol.com (mail_out_v31_r1.9.) id 3.146.67e4807 (4330) for ; Mon, 17 Dec 2001 13:09:10 -0500 (EST) From: VAHUJA@aol.com Message-ID: <146.67e4807.294f8ec6@aol.com> Date: Mon, 17 Dec 2001 13:09:10 EST Subject: Outboard Tunnel Mode To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Mon Dec 17 14:14:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15343 for ; Mon, 17 Dec 2001 14:14:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHI5i226764 for ips-outgoing; Mon, 17 Dec 2001 13:05:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHI5fZ26753 for ; Mon, 17 Dec 2001 13:05:41 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DF3E21ECF; Mon, 17 Dec 2001 11:05:40 -0700 (MST) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 7007F3F0; Mon, 17 Dec 2001 11:05:40 -0700 (MST) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Dec 2001 11:05:40 -0700 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 11:05:40 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF4654@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Mark Bakke'" Cc: Paul Koning , "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu, Luben Tuikov , "THALER,PAT (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Mon, 17 Dec 2001 11:05:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, I have to admit the iSCSI spec is _not_ ambiguous but only by virtue of having provided examples whose results can only be obtained by a circuit for which initializing to 1s is equivalent to initializing to 0s and XORing 1s with the most significant 32 bits of the message. I do not think we should rely on examples to serve as the specification. For this reason I recommend that we modify the spec in one of 3 ways: 1. explicitly show the reference implementation- what I call the multiply-divide implementation and which I have sent to the reflector. It is basically the ethernet reference implementation modified for the iSCSI poly. 2. use Paul's description 3. use Luben's formal description Please note that what I have been calling the multiply-divide implementation (a serial implementation) does not restrict you to processing one bit at a time. The circuit can be easily modified to process n bits at a time without changing its properties. What I have been calling the divide-only serial implementation also does not restrict you to processing one bit at a time. This circuit accomplishes the same division (you have to pre-multiply the message by x^32) externally but this circuit (and all its parallel variants) responds differently to initial conditions than the multiply-divide implementaion. See my inline comments below for more details. Vince |-----Original Message----- |From: Mark Bakke [mailto:mbakke@cisco.com] |Sent: Monday, December 17, 2001 6:55 AM |To: Luben Tuikov |Cc: Paul Koning; VICENTE V CAVANNA; ips@ece.cmu.edu |Subject: Re: effect of initializing CRC reg to 1's depends on |implementati on? iSCSI | | |This is becoming somewhat disturbing, given the comment about |the Ethernet CRC. The intent of the document is absolutely, |positively to keep the CRC identical to Ethernet, with the |exception of the generator, just as Paul had said. I'm not |enough of a mathematician to complain about the definition; if |there's a good way to fix it so it says what we intend, we |should do so. We got around this problem somewhat by simply |providing a set of examples. If someone has an implementation |that does not match the examples, they simply try a few |variations until they get it right. This has worked very well |for everyone I have talked to who is implementing the CRC. | |Here is some text that I had suggested adding instead of (or |in addition to) the mathematical description a while ago: | | |The generator polynomial selected is evaluated in [Castagnioli93]. |When using the CRC the CRC register must be initialized to all 1s |(0xFFFFFFFF). Input bytes are processed with bit 7 being the most The point I have been trying to make is that initializing the register to 1s does not necessarily result in the same process as described in the ethernet spec. Initializing the register to 1s only results in the desired results (i.e. agrees with the examples in the iSCSI spec) if you are using the implementation that I have been calling the multiply-divide implementation. This is the implementation that ethernet had in mind and iSCSI had in mind. On the other hand this is not the only implementation, and in particular is not hte implementation that Luben tried at first. Actually Luben tried the mathematical version of the divide-only implementation. I have since tried the actual implementation and that is what finally convinced me that the iSCSI spec is still ambiguous. |significant bit. Before transmission, the CRC bits must be |reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1, |etc.), and complemented. The CRC bytes must be transmitted in |network order. Padding bytes, when present, in a segment covered |by a CRC, should be set to 0 and are included in the CRC. | |Running the CRC-32C generator on an input stream that includes a |valid CRC-32C will result in the constant remainder 0x1c2d19ed, |(without being reversed and complemented). | | |The above, plus the examples, have seem to work out just fine |for the implementors. Getting the math right would be nice, but |most of us implementors don't look at it anyway, and prefer the |more practical description. If we are going to include the math, |it has to match the examples. The only reason that the above has worked right for implementors is that they all use the equivalent of a multiply-divide implementation as was described in the ethernet spec but that has not been described in any manner in iSCSI and that I have since recommended that we specify. I have to admit that by giving examples the iSCSI spec has removed the ambiguity since nobody will be able to get results that agree with the examples _unless_ they use the multiply-divide implementation but why not make it explicit and eliminate the need for implementors to have familiarity with ethernet and its implementations. Please note that any parallel implementations (that process 8 or 16 or 32 input bits at once) for ethernet are equivalent to the serial implementation that is shown as reference in the ethernet spec. I can however implement the iSCSi (and ethernet) CRCs using what I call a divide-only circuit and, if I initialize the circuit to 1's, and process the examples I will not get the results in the iSCSI spec but I will still get the magic constant at the receiver! What I will get instead are the same results as if I had XORed the most significant 32 bits of the messages in the examples with the magic constant and then processed them. | |Anyway, my guess is that is what you are discussing; it was just |disturbing to think that anything but the Ethernet + new poly |was being considered, since that has been agreed on for a long |time, and is being widely implemented. | |-- |Mark | | |Luben Tuikov wrote: |> |> --- Paul Koning wrote: |> > Excerpt of message (sent 14 December 2001) by Luben |> > > This is actually equivalent to XORing the first |> > > 32 bits of the message with the magic constant as Vince |> > > and I have shown. |> > |> > Are you saying that you believe the intent of the current |> > spec is NOT |> > the same as the Ethernet CRC, i.e., complement the first |> > 32 bits, |> > multiply by x^32, then divide by G(x)? |> |> In our profession we cannot talk about beliefs and |> intentions, more so for documents, rfc, etc. |> |> If you show the current description of the CRC of the draft |> to a mathematician, they will object to the same thing I've |> objected. |> |> The reason is that they don't have the preconception about |> what circuit is being used, and any such higher level |> notions. |> |> All they would have and all I had was long division in Z_2. |> (Actually Z_2[x] since we deal with polynomials.) |> |> Then I started from first principles of CRC, polydivision, |> etc, etc. -- similarly to how Williams proceeds in his |> paper, but my treatment was purely algebraic. |> |> The same applies to anyone looking at a description of an |> algorithm. (An ``algorithm'' has a precise definition in |> Computer Science.) |> |> In its current form the description of the algorithm to |> compute the CRC in the iSCSI draft is not consistent, just |> because there is an unspoken assumption that a SMD circuit |> will be used. We cannot afford to do this in a definition |> document, unless we refer explicitly to it. We cannot even |> assume that a circuit will be used... |> |> Please also note that the Ethernet spec CRC algorithm, is |> an optimized version of a basic |> prefix-postfix-initialize-the- |> CRC-register-to-some-constant algoritm. BUT as SMD it |> operates on NON-AUGMENTED messages. FOR THAT REASON you |> cannot say that we have to multiply M(x) by x^32!!! |> |> I.e. SMD algoritms like the one in the Ethernet spec, |> operate on non-augmented messages, while simple Division |> (D) algorithms operate on augmented messages. |> |> Any D can be optimized to SMD, but the constant has to be |> changed. Also, prefixing a message is equivalent to loading |> the CRC register with that prefix (WLG), but this is not so |> for SMD. (elaborated below) |> |> Further more for any SMD there is an equivalent D, |> including for the Ethernet spec SMD; and for any D there is |> an equivalent SMD. |> |> > If that is your interpretation, then we absolutely MUST |> > fix the spec, |> > I'm quite sure that the intent of the spec is as I wrote |> > it, i.e., |> > Ethernet except for the generator. |> |> Probably it is. But lets not hasten here. |> We can further generalize the explanation of the algorithm. |> |> > > If this is changed, then the message in its form: |> > > M'(x) = x^32 M(x) + x^(32+n) I(x) |> > > |> > > yields to better optimizations as Vince and I have |> > shown. |> > > (see his circuits and worksheet4.pdf, which I posted |> > > yesterday) |> > > |> > > I.e. the message is augmented (mult by x^32, aka |> > postfixed) |> > > and prefixed by 32 1's (aka CRC=32 1's). |> > |> > But that is NOT what the spec currently says. What you |> > describe may |> > be a fine CRC but it is not the one that's in the spec. |> > Initializing |> > the CRC register to all 1 is not the same as prefixing 32 |> > 1 bits onto |> > the message. |> |> It is, in a simple division, e.g. in D. This is clearly and |> simply explained in the Williams paper. It is an equivalent |> to a long division. |> |> Now, in D, if I initialize the CRC to all 1's and then do |> division of M(x) by G(x), so that I catch 0's at the |> beginning of the message, |> |> (which is equivalent to prefixing the message by 1's of the |> number of the width of the CRC, and then do just simple |> division,(CRC=0), since after so many clicks the CRC will |> be loaded with the prefixing bits, and also 0/G(x) = 0) |> |> then I can find a constant which I can XOR to the first 32 |> bits of the message and then perform the division, still in |> D, with the same effect. In this particular case that |> constant is the magic constant. (We are one step closer to |> SMD...) |> |> (Now we jump to SMD, by means of worksheet4.pdf, Prefixing |> part.) |> |> Now, in the Ethernet CRC spec, that constant is 32 1's, and |> XORing 32 1's with the 32 MSb of the message is equivalent |> to complementing them. |> |> BUT the Ethernet spec uses SMD, not D, so I claim that |> there is an equivalent D, which for a suitable initial CRC |> (also equivalent to prefixing the message with it) value |> will yield IDENTICAL results as Ethernet SMD. |> |> Now using a bit of algebra similar to worksheet4.pdf which |> I posted a couple of days ago and numerical methods |> (solving a linear system of 33 unknowns) I have found such |> a constant: |> 0x2a26f826 which in simple division, D, will yield results |> identical to SMD of Ethernet. |> |> So, here is an abstractization of the Ethernet CRC SMD, |> explained in a simple, simple, simple division only way: |> |> TX: |> 1. Mutliply the message, M(x), by x^32. |> 2. Prefix the result of 1. with 0x2a26f826. |> 3. Find the remainder of the result of 2. |> 4. Complement that remainder and add it to the |> result of 1. |> 5. Send the result of 4. to the recipient. |> |> RX: (same as steps 1-3 in TX) |> 1. Mutliply the message by x^32. |> 2. Prefix the result of 1. with 0x2a26f826. |> 3. Find the remainder of the result of 2. |> |> The result of 3 should be 0x1c2d19ed (the magic constant). |> |> Of course I've ommitted the mirroring of bytes for clarity |> and brevity. It can be mentioned on the side, e.g. How to |> build the message: mirror the bytes == to swapping the bits |> inside the bytes, .... |> |> Also note that step 4 in TX, adding means exactly that, |> since we already mult. by x^32, so the remainder will |> nicely fit in the last 32 0 bits. |> |> Also note that step 2, can be made clearer: |> let C(x), be the polynomial representation of 0x2a26f826. |> Let n = deg G(x), k-1 = deg M(x) (there are k bits), then |> step 2 is: |> |> 2. Add x^n x^k C(x) to the message M(x). |> |> Or we can swap step 1 and 2: |> |> 1. Add x^k C(x) to M(x). |> 2. Multiply the result of 1. by x^n. |> |> I hope this makes things a bit clearer. |> |> So from this D specification above, I can derive SMD |> exaclty as it is in the Ethernet spec. I'll include this |> derivation in the paper -- it will be pure math, but in |> english it goes like this: First we notice that after 32 |> clicks the CRC register will contain only 32 1's XOR-ed |> with the message, then we see that we can just load the crc |> with ones and then kick one byte off the left xor it with |> the next message bit... |> |> The above equivalence I've tested empirically. |> |> > What does "better optimizations" mean? |> |> See above. |> |> > > In an SMD, one would have to set the CRC to the magic |> > > constant and then proceed as the algorithm indicates, |> > > (this is identical to what you'd find in Ethernet, ... |> > |> > No it isn't. The Ethernet spec appendix C, and, more |> > importantly, the |> > formal definition of the CRC in the body of the spec, |> > makes it quite |> > clear that it isn't. I don't understand how you arrive |> > at any other |> > conclusion. |> |> I didn't mean identical as in the constant. I meant |> identical in a way of equivalence of algorithms, that one |> can be derived from the other, etc. See above. Or simpler |> answer: Math. |> |> -l |> |> ===== |> -- |> |> __________________________________________________ |> Do You Yahoo!? |> Check out Yahoo! Shopping and Yahoo! Auctions for all of |> your unique holiday gifts! Buy at http://shopping.yahoo.com |> or bid at http://auctions.yahoo.com | |-- |Mark A. Bakke |Cisco Systems |mbakke@cisco.com |763.398.1054 | From owner-ips@ece.cmu.edu Mon Dec 17 15:00:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16593 for ; Mon, 17 Dec 2001 15:00:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHJEHw01808 for ips-outgoing; Mon, 17 Dec 2001 14:14:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12806.mail.yahoo.com (web12806.mail.yahoo.com [216.136.174.41]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHJEFZ01804 for ; Mon, 17 Dec 2001 14:14:16 -0500 (EST) Message-ID: <20011217191415.95260.qmail@web12806.mail.yahoo.com> Received: from [207.219.118.250] by web12806.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 11:14:15 PST Date: Mon, 17 Dec 2001 11:14:15 -0800 (PST) From: Luben Tuikov Subject: Re: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: Mark Bakke Cc: Paul Koning , VICENTE V CAVANNA , ips@ece.cmu.edu In-Reply-To: <3C1E0757.9887E0E0@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Mark Bakke wrote: > This is becoming somewhat disturbing, given the comment > about > the Ethernet CRC. Which comment did you have in mind? > The intent of the document is > absolutely, > positively to keep the CRC identical to Ethernet, with > the > exception of the generator, just as Paul had said. Then we should JUST say THAT in the iSCSI spec. I think that it is enough. > If someone has an > implementation > that does not match the examples, they simply try a few > variations until they get it right. Mark, iSCSI draft/rfc is supposed to be THE AUTHORITY reference for iSCSI implementation. You cannot say ``just try a few variations until you get it right''! > This has worked very > well > for everyone I have talked to who is implementing the > CRC. The reason is that they know and/or have a preconception about what is being talked about. I.e. the current description is very IMPLICIT. As part of a definition document it has to be EXPLICIT. You need an outsider, an impartial party to scrutinize the draft. All parts of it. > Here is some text that I had suggested adding instead of > (or > in addition to) the mathematical description a while ago: I liked the one you had above better. > The above, plus the examples, have seem to work out just > fine > for the implementors. Getting the math right would be > nice, but > most of us implementors don't look at it anyway, and > prefer the > more practical description. If we are going to include > the math, > it has to match the examples. Most certainly agree! Including math is not necessary. We can prepare a document (what I and Vince are doing) and make a reference to it in the draft for all the math, optimization, derivation, equivalence and implementaion details. > Anyway, my guess is that is what you are discussing; it > was just > disturbing to think that anything but the Ethernet + new > poly > was being considered, since that has been agreed on for a > long > time, and is being widely implemented. ... and not being mentioned anywhere in the draft! -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 15:05:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16729 for ; Mon, 17 Dec 2001 15:05:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHJF6N01877 for ips-outgoing; Mon, 17 Dec 2001 14:15:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHJF5Z01871 for ; Mon, 17 Dec 2001 14:15:05 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA26292; Mon, 17 Dec 2001 14:12:12 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHJDlm198720; Mon, 17 Dec 2001 12:13:47 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: Outboard Tunnel Mode To: VAHUJA@aol.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 17 Dec 2001 11:13:00 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/17/2001 12:13:46 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Installations can do what ever they want. The Security functions are must implement, NOT must use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Outboard Tunnel Mode Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Mon Dec 17 15:14:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16929 for ; Mon, 17 Dec 2001 15:14:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHJ4oQ01102 for ips-outgoing; Mon, 17 Dec 2001 14:04:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHJ4nZ01097 for ; Mon, 17 Dec 2001 14:04:49 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA60414; Mon, 17 Dec 2001 14:01:51 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHJ3Om64374; Mon, 17 Dec 2001 12:03:25 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: scope of keys To: "Mallikarjun C." Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 16 Dec 2001 23:03:51 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/17/2001 12:03:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not think that this has anything to do with sending stale values. Whenever it is sent, it will be the value at that time. Regardless of how set. No need to have async updates. That is the way normal reporting values work. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Mallikarjun C." @ece.cmu.edu on 12/14/2001 04:44:45 PM Sent by: owner-ips@ece.cmu.edu To: "ips" cc: Subject: Re: iSCSI: scope of keys Julian, I actually suggest something along the following lines at the beginning of Appendix D, than labelling each key. This would also allow us to not specifically call out each "IO" key as we currently do. All keys with LO or FFPO, or qualified as Declarative use have session-wide applicability. All keys with IO or ALL usage have connection-wide applicability. With that said, some general comments on keys - - InitiatorAlias, TargetAlias and TargetAddress keys should be qualified with the "Declarative" label. - I recommend changing InitialR2T, BidiInitialR2T and ImmediateData as IO, fom the current ALL (with the one-time change restrictions). This makes it simple, and besides I can not quite picture a scenario the current allowance could be useful in. - InitiatorAlias and TargetAlias are keys that merely report an alias set in a different management domain (hence declarative), with the currently specified usage as ALL. I assume it is so because the alias could be changed while the session is in progress outside of iSCSI. iSCSI does not however require this key to be sent everytime the alias is changed during a session. We should either require this to avoid stale values, or much better, drop aliases altogether from iSCSI (can be asynchronously set in a different domain, and not useful for iSCSI protocol interactions).... - Editorial: MaxRecvPDULength - s/b "Use: All" with "Use: ALL". -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Julian Satran" To: Sent: Friday, December 14, 2001 12:50 PM Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a ?scope? to each key definition? The IO and LO ?use:? labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Mon Dec 17 15:16:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17012 for ; Mon, 17 Dec 2001 15:16:49 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHJFop01952 for ips-outgoing; Mon, 17 Dec 2001 14:15:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHJFmZ01945; Mon, 17 Dec 2001 14:15:48 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id UAA20994; Mon, 17 Dec 2001 20:15:28 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHJFsG69556; Mon, 17 Dec 2001 20:15:59 +0100 To: Dean Scoville Cc: "ips@ece. cmu. edu (E-mail)" , owner-ips@ece.cmu.edu Subject: RE: Re: iSCSI Marker questions MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Mon, 17 Dec 2001 21:15:45 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/12/2001 21:15:57, Serialize complete at 17/12/2001 21:15:57 Content-Type: multipart/alternative; boundary="=_alternative 0068AE07C2256B25_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0068AE07C2256B25_= Content-Type: text/plain; charset="US-ASCII" Dean, Very good point. I think we will want to explicitly say that the TCP sequence number to start counting will be the first sequence number used by iSCSI (the first Login Request and the first Login Response). Thanks for bringing this to our attention. Julo owner-ips@ece.cmu.edu wrote on 17-12-2001 20:13:47: > Julian, > > An undesirable side affect of starting the marker interval at > connection establishment time and including the SYN char in the > interval is that the alignment of markers will ALWAYS be different > than the alignment of iSCSI PDUs. This is messy for anyone who is > looking at things in 4-byte pieces. The alignment of the markers > will ALWAYS differ by one byte from the PDU alignment. Using the > example cited in the earlier posting, the first marker byte will > ALWAYS have an EVEN-numbered TCP sequence number, and the first PDU > byte will ALWAYS have an ODD-numbered TCP sequence number. > > > > > Assume the following interaction: > > > > I-> SYN (TCP sequenceNum=1000) > > > > T-> SYN-ACK (TCP sequenceNum=2000) > > > > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > > InitiatorName=xxx > > TargetName=yyy > > SessionType=normal > > ... > > FMarker=send-receive > > RFMarkInt=512,1024 > > > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > > ... > > FMarker=send-receive > > SFMarkInt=1024 > > RFMarkInt=1024 > > > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > > SFMarkInt=1024 > > (64-byte PDU... TCP sequenceNum=1301-1364) > > > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > > (48-byte PDU... TCP sequenceNum=2201-2248) > > > > The above interaction designates a 1024 x 4 = 4096-byte marker > > interval in both directions. The first PDU byte sent by the > > intitiator in full-feature mode will have sequenceNum=1365, and > > the first byte sent by the target will have sequenceNum=2249. > > > > TCP SeqNum of > > > First Marker > > > ------------ > > > Initiator: 5096-5103 > > Target: 6096-6103 > > > > Since the layer that inserts the markers needs to be aware of login > anyway (it can't insert markers during login phase), I would rather > that the marker interval didn't start until the end of login phase. > It would avoid some messy corner cases (see next paragraph). If this > is unacceptable, then let's at least not count the SYN char in the > marker interval, so that the markers can be on the same 4-byte > alignment as the PDUs. > > > > If the marker interval remains as it is currently defined, how are > partial markers treated at the end of login phase? Modifying the > previous example a little, if the initiator's final PDU during login > phase had TCP sequence numbers 5035-5098 should we insert the last > 5-bytes of the marker into the data stream? If the final PDU were at > 5039-5102, would we insert 1-byte of the marker into the data > stream? Or would we skip the first marker altogether because part of > it would have begun during login phase? Either way, it is messy. > > > > -Dean > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, December 14, 2001 7:58 PM > To: Dean Scoville > Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu > Subject: RE: Re: iSCSI Marker questions > > > You are right there is no range today for SFMarkint - we may want to > change this to enable a one-shot negotiation. > > Julo > > > Dean Scoville > Sent by: owner-ips@ece.cmu.edu > > 14-12-01 20:10 > > > To: "ips@ece. cmu. edu (E-mail)" > cc: > Subject: RE: Re: iSCSI Marker questions > > > > > Julian, > Thanks for the response. Some examples would be very helpful. > Your response shows a parameter negotiation with SFMarkInt=1,512 > but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt. > Is a range also being allowed for SFMarkInt? > > > > > I assume a normal dialogue may go like: > > > > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 > > > Section 2.2.4 of the draft currently requires all integer parameter > negotiations to have a response . (Responses are optional only > with boolean negotiations where the offered value allows only a > single outcome -- such as an "OR" boolean function with a "Yes" > offer). Are responses always required for RFMarkInt and SFMarkInt, > or is the following acceptable? > > I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T-> FMarker=send,SFMarkInt=4 > > Would it also be allowed to respond with the following and, if so, > is one preferred over the other? (I'm not sure about the current > state of using "0" as a "don't care" value, but is that also > permitted in cases where the response would be irrelevant?) > > I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant > > With the following exchange, is the target required to respond > with any RFMarkInt or SFMarkInt values, since there is no > real choice of values? Agreeing to send markers implies that > the interval is 512, and not agreeing to receive markers implies > that there is no receive interval. Is the following allowed, or > should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned > by the target? > > I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 > T-> FMarker=send > > Is the following acceptable, even though it doesn't reply to > RFMarkInt and SFMarkInt? > > I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512 > T-> FMarker=no > > It would also be helpful to explain what happens if the login > phase goes beyond the negotiated first marker interval. > Assume, for example, the following: > > SYN - at TCP sequence num 1000. > SYN-ACK - at TCP sequence num 2000. > negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100. > > If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404, > full-feature phase starts in the middle of what would have been a marker. > Is a partial marker inserted? What would be the TCP seqNum of the first and > second marker? > > If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810, > what would be the TCP seqNum of the first and second marker? > > thanks, > Dean > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Tuesday, December 11, 2001 4:54 PM > To: ips@ece.cmu.edu > Subject: Fw: Re: iSCSI Marker questions > > > ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 ----- > > Julian Satran > > 11-12-01 14:44 > > > To: IPS List > cc: > Subject: Re: iSCSI Marker questionsLink > > > > > Dean, > > > > owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11: > > > The iSCSI Draft 9 Appendix C makes the following statements about > > Markers and the Initial Marker-less Interval: > > > > "The offset to the next iSCSI PDU header is counted in terms > > of the TCP stream data. Anything counted in the TCP > > sequence-number is counted for the offset. Specifically this > > includes any bytes "inserted" in the TCP stream by an UFL and > > it excludes any other markers inserted between the one we are > > examining and the next PDU header."... > > > > "To enable the connection setup including the login phase > > negotiation, marking (if any) is started only at the first > > marker interval after the end of the login phase." > > > > I understand that markers are not inserted until after login phase. > > Am I correct to assume that the placement of the first marker > > determined by the TCP sequence numbers on the final Login Request/ > > Response PDUs, or is initial marker position determined by the > > TCP sequence numbers at connection establishment? > > > > Assume the following interaction: > > > > I-> SYN (TCP sequenceNum=1000) -- irrelevant to this discussion? > > > > T-> SYN-ACK (TCP sequenceNum=2000) -- irrelevant to this discussion? > > > > I-> Login Request PDU, T=0,CSG=1,NSG=0: > > InitiatorName=xxx > > TargetName=yyy > > SessionType=normal > > ... > > FMarker=send-receive > > RFMarkInt=512,1024 > > > > T-> Login Response PDU, T=0,CSG=1,NSG=0: > > ... > > FMarker=send-receive > > SFMarkInt=1024 > > RFMarkInt=1024 > > > > I-> Login Request PDU, T=1,CSG=1,NSG=3: > > SFMarkInt=1024 > > (64-byte PDU... TCP sequenceNum=1301-1364) > > > > T-> Login Response PDU, T=1,CSG=1,NSG=3: > > (48-byte PDU... TCP sequenceNum=2201-2248) > > > > The above interaction designates a 1024 x 4 = 4096-byte marker > > interval in both directions. The first PDU byte sent by the > > intitiator in full-feature mode will have sequenceNum=1365, and > > the first byte sent by the target will have sequenceNum=2249. > > > > Assuming the markerless interval starts at the end of login > > phase, the first two markers in each direction will have the > > following TCP sequence numbers: > > > > TCP SeqNum of TCP SeqNum of > > First Marker Second Marker > > ------------ ------------- > > Initiator: 5461-5468 9565-9572 > > Target: 6345-6352 10449-10456 > > > No - the correct numbers are dependent only on the marker interval > (not the length of the login phase) and are: > > Initiator 5096-5103 9200-9201 > Target 6096-6103 10200-10201 > > > > Is this the correct interpretation of marker usage in iSCSI > > Draft 9, or does marker placement depend on the connection's > > initial sequence numbers? > > > > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt=" > > considered a reply to that offer? If an offer is sent with "FMarker=..." > > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or > > BOTH "FMarker=yes" and "SFMarkInt=..."? > > > > Fmarker is not boolean - legal values are no, send, receive, send-receive > The sender and receiver must set the interval it wants/is ready to use > otherwise the responder can't answer. > I assume a normal dialogue may go like: > > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512 > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2 > > Please observe that target answers with RFMarkInt to the initiators > SFMarkInt and viceversa. > > I will attempt an example in draft 10 (last?). > > > > > Thanks, > > Dean Scoville > > QLogic Corp. > --=_alternative 0068AE07C2256B25_= Content-Type: text/html; charset="US-ASCII"
Dean,

Very good point.

I think we will want to explicitly say that the TCP sequence number to start counting will be the first sequence number used by iSCSI (the first Login Request and the first Login Response).

Thanks for bringing this to our attention.

Julo

owner-ips@ece.cmu.edu wrote on 17-12-2001 20:13:47:

> Julian,
>
> An undesirable side affect of starting the marker interval at
> connection establishment time and including the SYN char in the
> interval is that the alignment of markers will ALWAYS be different
> than the alignment of iSCSI PDUs. This is messy for anyone who is
> looking at things in 4-byte pieces. The alignment of the markers
> will ALWAYS differ by one byte from the PDU alignment. Using the
> example cited in the earlier posting, the first marker byte will
> ALWAYS have an EVEN-numbered TCP sequence number, and the first PDU
> byte will ALWAYS have an ODD-numbered TCP sequence number.
>
>  
>
> > Assume the following interaction:
> >
> > I->  SYN     (TCP sequenceNum=1000)
> >
> > T->  SYN-ACK (TCP sequenceNum=2000)
>
> >
> > I->  Login Request PDU, T=0,CSG=1,NSG=0:
> >      InitiatorName=xxx
> >      TargetName=yyy
> >      SessionType=normal
> >      ...
> >      FMarker=send-receive
> >      RFMarkInt=512,1024
> >
> > T->  Login Response PDU, T=0,CSG=1,NSG=0:
> >      ...
> >      FMarker=send-receive
> >      SFMarkInt=1024
> >      RFMarkInt=1024
> >
> > I->  Login Request PDU, T=1,CSG=1,NSG=3:
> >      SFMarkInt=1024
> >      (64-byte PDU... TCP sequenceNum=1301-1364)
> >
> > T->  Login Response PDU, T=1,CSG=1,NSG=3:
> >      (48-byte PDU... TCP sequenceNum=2201-2248)
> >
> > The above interaction designates a 1024 x 4 = 4096-byte marker
> > interval in both directions. The first PDU byte sent by the
> > intitiator in full-feature mode will have sequenceNum=1365, and
> > the first byte sent by the target will have sequenceNum=2249.
> >
> >                TCP SeqNum of    
>
> >                First Marker    
>
> >                ------------    
>
> > Initiator:     5096-5103        
> > Target:        6096-6103
> >
>  
> Since the layer that inserts the markers needs to be aware of login
> anyway (it can't insert markers during login phase), I would rather
> that the marker interval didn't start until the end of login phase.
> It would avoid some messy corner cases (see next paragraph). If this
> is unacceptable, then let's at least not count the SYN char in the
> marker interval, so that the markers can be on the same 4-byte
> alignment as the PDUs.
>
>  
>
> If the marker interval remains as it is currently defined, how are
> partial markers treated at the end of login phase? Modifying the
> previous example a little, if the initiator's final PDU during login
> phase had TCP sequence numbers 5035-5098 should we insert the last
> 5-bytes of the marker into the data stream? If the final PDU were at
> 5039-5102, would we insert 1-byte of the marker into the data
> stream? Or would we skip the first marker altogether because part of
> it would have begun during login phase? Either way, it is messy.
>
>  
>
> -Dean
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Friday, December 14, 2001 7:58 PM
> To: Dean Scoville
> Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
> Subject: RE: Re: iSCSI Marker questions
>
>
> You are right there is no range today for SFMarkint - we may want to
> change this to enable a one-shot negotiation.
>
> Julo
>
>
> Dean Scoville <Dean.Scoville@qlogic.com>
> Sent by: owner-ips@ece.cmu.edu
>
> 14-12-01 20:10
>
>        
>         To:        "ips@ece. cmu. edu (E-mail)" <ips@ece.cmu.edu>
>         cc:        
>         Subject:        RE: Re: iSCSI Marker questions
>
>
>
>
> Julian,
> Thanks for the response. Some examples would be very helpful.
> Your response shows a parameter negotiation with SFMarkInt=1,512
> but Draft 9 doesn't allow a range for SFMarkInt... only for RFMarkInt.
> Is a range also being allowed for SFMarkInt?
>  
> >
> > I assume a normal dialogue may go like:
> >
> > I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> > T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
> >
> Section 2.2.4 of the draft currently requires all integer parameter
> negotiations to have a response . (Responses are optional only
> with boolean negotiations where the offered value allows only a
> single outcome -- such as an "OR" boolean function with a "Yes"
> offer). Are responses always required for RFMarkInt and SFMarkInt,
> or is the following acceptable?
>  
> I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T-> FMarker=send,SFMarkInt=4
>  
> Would it also be allowed to respond with the following and, if so,
> is one preferred over the other? (I'm not sure about the current
> state of using "0" as a "don't care" value, but is that also
> permitted in cases where the response would be irrelevant?)
>  
> I-> FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T-> FMarker=send,SFMarkInt=4,RFMarkInt=irrelevant
>  
> With the following exchange, is the target required to respond
> with any RFMarkInt or SFMarkInt values, since there is no
> real choice of values? Agreeing to send markers implies that
> the interval is 512, and not agreeing to receive markers implies
> that there is no receive interval. Is the following allowed, or
> should "RFMarkInt=4" and "SFMarkInt=irrelevant" be returned
> by the target?
>  
> I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
> T-> FMarker=send
>  
> Is the following acceptable, even though it doesn't reply to
> RFMarkInt and SFMarkInt?
>  
> I-> FMarker=send-receive,RFMarkInt=4,SFMarkInt=512
> T-> FMarker=no
>  
> It would also be helpful to explain what happens if the login
> phase goes beyond the negotiated first marker interval.
> Assume, for example, the following:
>  
>   SYN - at TCP sequence num 1000.
>   SYN-ACK - at TCP sequence num 2000.
>   negotiate to FMarker=send-receive,RFMarkInt=100, SFMarkInt=100.
>  
> If the 1st byte of 1st initiator PDU in full-feature mode has TCP seqNum=1404,
> full-feature phase starts in the middle of what would have been a marker.
> Is a partial marker inserted? What would be the TCP seqNum of the first and
> second marker?
>  
> If the 1st byte of 1st target PDU in full-feature mode has TCP seqNum=2810,
> what would be the TCP seqNum of the first and second marker?
>  
> thanks,
> Dean
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Tuesday, December 11, 2001 4:54 PM
> To: ips@ece.cmu.edu
> Subject: Fw: Re: iSCSI Marker questions
>
>
> ----- Forwarded by Julian Satran/Haifa/IBM on 12-12-01 02:39 -----
>
> Julian Satran
>
> 11-12-01 14:44
>
>
>        To:        IPS List
>        cc:        
>        Subject:        Re: iSCSI Marker questionsLink
>
>
>
>
> Dean,
>
>
>
> owner-ips@ece.cmu.edu wrote on 11-12-2001 03:09:11:
>
> > The iSCSI Draft 9 Appendix C makes the following statements about
> > Markers and the Initial Marker-less Interval:
> >
> >      "The offset to the next iSCSI PDU header is counted in terms
> >       of the TCP stream data. Anything counted in the TCP
> >       sequence-number is counted for the offset. Specifically this
> >       includes any bytes "inserted" in the TCP stream by an UFL and
> >       it excludes any other markers inserted between the one we are
> >       examining and the next PDU header."...
> >
> >      "To enable the connection setup including the login phase
> >       negotiation, marking (if any) is started only at the first
> >       marker interval after the end of the login phase."
> >
> > I understand that markers are not inserted until after login phase.
> > Am I correct to assume that the placement of the first marker
> > determined by the TCP sequence numbers on the final Login Request/
> > Response PDUs, or is initial marker position determined by the
> > TCP sequence numbers at connection establishment?
> >
> > Assume the following interaction:
> >
> > I->  SYN     (TCP sequenceNum=1000)  -- irrelevant to this discussion?
> >
> > T->  SYN-ACK (TCP sequenceNum=2000)  -- irrelevant to this discussion?
> >
> > I->  Login Request PDU, T=0,CSG=1,NSG=0:
> >      InitiatorName=xxx
> >      TargetName=yyy
> >      SessionType=normal
> >      ...
> >      FMarker=send-receive
> >      RFMarkInt=512,1024
> >
> > T->  Login Response PDU, T=0,CSG=1,NSG=0:
> >      ...
> >      FMarker=send-receive
> >      SFMarkInt=1024
> >      RFMarkInt=1024
> >
> > I->  Login Request PDU, T=1,CSG=1,NSG=3:
> >      SFMarkInt=1024
> >      (64-byte PDU... TCP sequenceNum=1301-1364)
> >
> > T->  Login Response PDU, T=1,CSG=1,NSG=3:
> >      (48-byte PDU... TCP sequenceNum=2201-2248)
> >
> > The above interaction designates a 1024 x 4 = 4096-byte marker
> > interval in both directions. The first PDU byte sent by the
> > intitiator in full-feature mode will have sequenceNum=1365, and
> > the first byte sent by the target will have sequenceNum=2249.
> >
> > Assuming the markerless interval starts at the end of login
> > phase, the first two markers in each direction will have the
> > following TCP sequence numbers:
> >
> >                TCP SeqNum of    TCP SeqNum of
> >                First Marker     Second Marker
> >                ------------     -------------
> > Initiator:     5461-5468        9565-9572
> > Target:        6345-6352        10449-10456
> >
> No - the correct numbers are dependent only on the marker interval
> (not the length of the login phase) and are:
>
> Initiator        5096-5103        9200-9201
> Target           6096-6103        10200-10201
>  
>
> > Is this the correct interpretation of marker usage in iSCSI
> > Draft 9, or does marker placement depend on the connection's
> > initial sequence numbers?
> >
> > Also, is "RFMarkInt=..." always considered an offer, and "SFMarkInt="
> > considered a reply to that offer? If an offer is sent with "FMarker=..."
> > and "RFMarkInt=...", MUST the reply contain either "FMarker=no" or
> > BOTH "FMarker=yes" and "SFMarkInt=..."?
> >
>
> Fmarker is not boolean - legal values are no, send, receive, send-receive
> The sender and receiver must set the interval it wants/is ready to use
> otherwise the responder can't answer.
> I assume a normal dialogue may go like:
>
> I->FMarker=send-receive,RFMarkInt=1,4,SFMarkInt=1,512
> T->FMarker=send-receive,RFMarkInt=8, SFMarkInt=2
>
> Please observe that target answers with RFMarkInt to the initiators
> SFMarkInt and viceversa.
>
> I will attempt an example in draft 10 (last?).
>
>
>
> > Thanks,
> > Dean Scoville
> > QLogic Corp.
>
--=_alternative 0068AE07C2256B25_=-- From owner-ips@ece.cmu.edu Mon Dec 17 15:37:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17522 for ; Mon, 17 Dec 2001 15:37:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHJiWk04059 for ips-outgoing; Mon, 17 Dec 2001 14:44:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12807.mail.yahoo.com (web12807.mail.yahoo.com [216.136.174.42]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHJiUZ04052 for ; Mon, 17 Dec 2001 14:44:30 -0500 (EST) Message-ID: <20011217194429.45576.qmail@web12807.mail.yahoo.com> Received: from [207.219.118.250] by web12807.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 11:44:29 PST Date: Mon, 17 Dec 2001 11:44:29 -0800 (PST) From: Luben Tuikov Subject: Re: iSCSI: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: Paul Koning Cc: vince_cavanna@agilent.com, ips@ece.cmu.edu In-Reply-To: <15390.4355.623462.667567@pkoning.dev.equallogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- Paul Koning wrote: > > I agree that the current description is not consistent > and is > confusing. That's why I proposed replacement text. I'd > be interested > in comments on that text. I gave you a comment in my last letter: Please also note that the Ethernet spec CRC algorithm, is an optimized version of a basic prefix-postfix-initialize-the- CRC-register-to-some-constant algoritm. BUT as SMD it operates on NON-AUGMENTED messages. FOR THAT REASON you cannot say that we have to multiply M(x) by x^32!!! You see, you cannot say that the message has to be multiplied by x^32, if you are describing the Ethernet CRC algo. > Luben> Please also note that the Ethernet spec CRC > algorithm, is an > Luben> optimized version of a basic > prefix-postfix-initialize-the- > Luben> CRC-register-to-some-constant algoritm. > > I'm not sure what spec you're talking about. The one you always mention, the one you quote in you messages. The one iSCSI is trying to present. > The algorithm in the Ethernet spec (section 6.2.4) which > was copied > into the 802.3 spec (section 3.2.8) pretty much verbatim > except for a > typo, is not a prefix-postfix-whatever algorithm at all. Yes, it is. I'll send you the math when I finish it (later this week). I'll also send you 2 algorithms, one simplest division, and another as per Ethernet, which produce identical results. (I can send it now, but no time.) > Instead, it > is a mathematical definition of the CRC value. The > phrase "initialize > the CRC register" does not occur at all in any form. So it doesn't in the definition I gave you. If it is a formal, mathematical definition, then you should see the same initial constant as I found: 0x2a26f826. If it mentiones 0xFFFFFFFF, then it means that SMD (Simultaneous Divide and Multiply) algo is described, which is hardly a formal mathematical definition. > If I understand right, this is a mathematically > equivalent way of > describing an Ethernet-style CRC. Yep. Mathematically, and when implemented, by hand, by a program, by a handheld calculator, by a mathematics analysis program, it will yield identical results as in ``Ethernet-style CRC''. > Fine, no problem. But what's the point? All we need is > a single > formal definition. The point? You and Pat wanted a mathematical definition, so here it is! This is a ``single formal definition''. > And it would make the most sense for > that > definition to look like the ones found in other > standards, so it will > be clear to the reader that the CRC in iSCSI is the same > as the one > used in many other places except for the G(x). Then lets forget about trying to REPHRASE Ethernet and just mention that: that it is equivalent to Ethernet, but just that it uses a different polynomial. > The > description you gave may be mathematically equivalent, > but that is not > at all obvious unless you're fluent in abstract math. True. > In any case, no mathematical description by itself > translates easily > to an implementation (again, unless you're fluent in > abstract math). True. > Most specs disregard that concern and leave it up to the > implementer > to search the literature. My current proposal is to do > likewise for > iSCSI. The only exception I've seen is the Ethernet > spec, which gives > a single example implementation in its appendix. Example implementation is good, as are examples. I'd vote for both to be included in iSCSI. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 15:39:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17590 for ; Mon, 17 Dec 2001 15:39:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHK6jW05633 for ips-outgoing; Mon, 17 Dec 2001 15:06:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12801.mail.yahoo.com (web12801.mail.yahoo.com [216.136.174.36]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHK6hZ05629 for ; Mon, 17 Dec 2001 15:06:43 -0500 (EST) Message-ID: <20011217200642.55181.qmail@web12801.mail.yahoo.com> Received: from [207.219.118.250] by web12801.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 12:06:42 PST Date: Mon, 17 Dec 2001 12:06:42 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , "'Mark Bakke'" Cc: Paul Koning , "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , ips@ece.cmu.edu, Luben Tuikov , "THALER,PAT \(A-Roseville,ex1\)" , "SHEEHY,DAVE \(A-Americas,unix1\)" In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED9201BF4654@axcs13.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "CAVANNA,VICENTE V (A-Roseville,ex1)" wrote: > > I do not think we should rely on examples to serve as the > specification. Absolutely true. But lets include examples _just_ to back it up, and maybe a sample implementation (skeleton of), that will be good for both hardware and software. Of course some optimization will be sacrificed... (e.g. like processing more than one bit at a time). > For > this reason I recommend that we modify the spec in one of > 3 ways: > > 1. explicitly show the reference implementation- what I > call the > multiply-divide implementation and which I have sent to > the reflector. It is > basically the ethernet reference implementation modified > for the iSCSI poly. Yep, maybe we should just mention that, plus plenty of references, the 4 examples with correct values, and a sample bit-at-a-time skeleton implementation. > 2. use Paul's description It says that the message is multiplied by x^32, which is not correct. See below. > 3. use Luben's formal description I wouldn't. In implementor wants to get some speedup, and optimization and as a formal definition it doesn't offer them. Maybe the implementor will notice that after 32 clicks the CRC will be all 1's, and that they don't need to multiply the message by x^32 if they init the CRC register with all 1's and only xor the message bit and the MSb of CRC on each click.... but that implies that the implementor will have to do extra thinking work. > The point I have been trying to make is that initializing > the register to 1s > does not necessarily result in the same process as > described in the ethernet > spec. Initializing the register to 1s only results in the > desired results > (i.e. agrees with the examples in the iSCSI spec) if you > are using the > implementation that I have been calling the > multiply-divide implementation. > This is the implementation that ethernet had in mind and > iSCSI had in mind. Absolutely true. > The only reason that the above has worked right for > implementors is that > they all use the equivalent of a multiply-divide > implementation as was > described in the ethernet spec but that has not been > described in any manner > in iSCSI and that I have since recommended that we > specify. Abosultely true. > I have to admit that by giving examples the iSCSI spec > has removed the > ambiguity since nobody will be able to get results that > agree with the > examples _unless_ they use the multiply-divide > implementation but why not > make it explicit and eliminate the need for implementors > to have familiarity > with ethernet and its implementations. Please note that > any parallel > implementations (that process 8 or 16 or 32 input bits at > once) for ethernet > are equivalent to the serial implementation that is shown > as reference in > the ethernet spec. Abosultely true. > I can however implement the iSCSi (and ethernet) CRCs > using what I call a > divide-only circuit and, if I initialize the circuit to > 1's, and process the > examples I will not get the results in the iSCSI spec but > I will still get > the magic constant at the receiver! What I will get > instead are the same > results as if I had XORed the most significant 32 bits of > the messages in > the examples with the magic constant and then processed > them. Aboslutely true. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 15:44:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17686 for ; Mon, 17 Dec 2001 15:44:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHK5dN05557 for ips-outgoing; Mon, 17 Dec 2001 15:05:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHK5WZ05550 for ; Mon, 17 Dec 2001 15:05:32 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA62412; Mon, 17 Dec 2001 14:02:29 -0600 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHK43m118620; Mon, 17 Dec 2001 13:04:03 -0700 Importance: Normal Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "CAVANNA,VICENTE V (A-Roseville,ex1)" Cc: "'Mark Bakke'" , Paul Koning , "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu, Luben Tuikov , "THALER,PAT (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 17 Dec 2001 12:02:57 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/17/2001 01:04:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark said that as long as the math matches the example, great, otherwise come up with the Math to match the example. His point is that the current stuff is just find for the implementations. I think it would be nice to have the math, match. But I support Marks position. If that is what you are doing, then fine, we can even put that math in its own draft, and point to it. But if the current Draft is good enough for the various different vendors to create good interoperable implementation, that should be the goal. Mark is right Engineers do not build based on Math. Having said that, the Math is good to ensure we have not fallen in a ditch. So unless you have a point that the math shows the current Examples are invalid, then I would think Marks point is that the current Draft Works fine in this area. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "CAVANNA,VICENTE V (A-Roseville,ex1)" @ece.cmu.edu on 12/17/2001 10:05:39 AM Sent by: owner-ips@ece.cmu.edu To: "'Mark Bakke'" cc: Paul Koning , "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu, Luben Tuikov , "THALER,PAT (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Mark, I have to admit the iSCSI spec is _not_ ambiguous but only by virtue of having provided examples whose results can only be obtained by a circuit for which initializing to 1s is equivalent to initializing to 0s and XORing 1s with the most significant 32 bits of the message. I do not think we should rely on examples to serve as the specification. For this reason I recommend that we modify the spec in one of 3 ways: 1. explicitly show the reference implementation- what I call the multiply-divide implementation and which I have sent to the reflector. It is basically the ethernet reference implementation modified for the iSCSI poly. 2. use Paul's description 3. use Luben's formal description Please note that what I have been calling the multiply-divide implementation (a serial implementation) does not restrict you to processing one bit at a time. The circuit can be easily modified to process n bits at a time without changing its properties. What I have been calling the divide-only serial implementation also does not restrict you to processing one bit at a time. This circuit accomplishes the same division (you have to pre-multiply the message by x^32) externally but this circuit (and all its parallel variants) responds differently to initial conditions than the multiply-divide implementaion. See my inline comments below for more details. Vince |-----Original Message----- |From: Mark Bakke [mailto:mbakke@cisco.com] |Sent: Monday, December 17, 2001 6:55 AM |To: Luben Tuikov |Cc: Paul Koning; VICENTE V CAVANNA; ips@ece.cmu.edu |Subject: Re: effect of initializing CRC reg to 1's depends on |implementati on? iSCSI | | |This is becoming somewhat disturbing, given the comment about |the Ethernet CRC. The intent of the document is absolutely, |positively to keep the CRC identical to Ethernet, with the |exception of the generator, just as Paul had said. I'm not |enough of a mathematician to complain about the definition; if |there's a good way to fix it so it says what we intend, we |should do so. We got around this problem somewhat by simply |providing a set of examples. If someone has an implementation |that does not match the examples, they simply try a few |variations until they get it right. This has worked very well |for everyone I have talked to who is implementing the CRC. | |Here is some text that I had suggested adding instead of (or |in addition to) the mathematical description a while ago: | | |The generator polynomial selected is evaluated in [Castagnioli93]. |When using the CRC the CRC register must be initialized to all 1s |(0xFFFFFFFF). Input bytes are processed with bit 7 being the most The point I have been trying to make is that initializing the register to 1s does not necessarily result in the same process as described in the ethernet spec. Initializing the register to 1s only results in the desired results (i.e. agrees with the examples in the iSCSI spec) if you are using the implementation that I have been calling the multiply-divide implementation. This is the implementation that ethernet had in mind and iSCSI had in mind. On the other hand this is not the only implementation, and in particular is not hte implementation that Luben tried at first. Actually Luben tried the mathematical version of the divide-only implementation. I have since tried the actual implementation and that is what finally convinced me that the iSCSI spec is still ambiguous. |significant bit. Before transmission, the CRC bits must be |reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1, |etc.), and complemented. The CRC bytes must be transmitted in |network order. Padding bytes, when present, in a segment covered |by a CRC, should be set to 0 and are included in the CRC. | |Running the CRC-32C generator on an input stream that includes a |valid CRC-32C will result in the constant remainder 0x1c2d19ed, |(without being reversed and complemented). | | |The above, plus the examples, have seem to work out just fine |for the implementors. Getting the math right would be nice, but |most of us implementors don't look at it anyway, and prefer the |more practical description. If we are going to include the math, |it has to match the examples. The only reason that the above has worked right for implementors is that they all use the equivalent of a multiply-divide implementation as was described in the ethernet spec but that has not been described in any manner in iSCSI and that I have since recommended that we specify. I have to admit that by giving examples the iSCSI spec has removed the ambiguity since nobody will be able to get results that agree with the examples _unless_ they use the multiply-divide implementation but why not make it explicit and eliminate the need for implementors to have familiarity with ethernet and its implementations. Please note that any parallel implementations (that process 8 or 16 or 32 input bits at once) for ethernet are equivalent to the serial implementation that is shown as reference in the ethernet spec. I can however implement the iSCSi (and ethernet) CRCs using what I call a divide-only circuit and, if I initialize the circuit to 1's, and process the examples I will not get the results in the iSCSI spec but I will still get the magic constant at the receiver! What I will get instead are the same results as if I had XORed the most significant 32 bits of the messages in the examples with the magic constant and then processed them. | |Anyway, my guess is that is what you are discussing; it was just |disturbing to think that anything but the Ethernet + new poly |was being considered, since that has been agreed on for a long |time, and is being widely implemented. | |-- |Mark | | |Luben Tuikov wrote: |> |> --- Paul Koning wrote: |> > Excerpt of message (sent 14 December 2001) by Luben |> > > This is actually equivalent to XORing the first |> > > 32 bits of the message with the magic constant as Vince |> > > and I have shown. |> > |> > Are you saying that you believe the intent of the current |> > spec is NOT |> > the same as the Ethernet CRC, i.e., complement the first |> > 32 bits, |> > multiply by x^32, then divide by G(x)? |> |> In our profession we cannot talk about beliefs and |> intentions, more so for documents, rfc, etc. |> |> If you show the current description of the CRC of the draft |> to a mathematician, they will object to the same thing I've |> objected. |> |> The reason is that they don't have the preconception about |> what circuit is being used, and any such higher level |> notions. |> |> All they would have and all I had was long division in Z_2. |> (Actually Z_2[x] since we deal with polynomials.) |> |> Then I started from first principles of CRC, polydivision, |> etc, etc. -- similarly to how Williams proceeds in his |> paper, but my treatment was purely algebraic. |> |> The same applies to anyone looking at a description of an |> algorithm. (An ``algorithm'' has a precise definition in |> Computer Science.) |> |> In its current form the description of the algorithm to |> compute the CRC in the iSCSI draft is not consistent, just |> because there is an unspoken assumption that a SMD circuit |> will be used. We cannot afford to do this in a definition |> document, unless we refer explicitly to it. We cannot even |> assume that a circuit will be used... |> |> Please also note that the Ethernet spec CRC algorithm, is |> an optimized version of a basic |> prefix-postfix-initialize-the- |> CRC-register-to-some-constant algoritm. BUT as SMD it |> operates on NON-AUGMENTED messages. FOR THAT REASON you |> cannot say that we have to multiply M(x) by x^32!!! |> |> I.e. SMD algoritms like the one in the Ethernet spec, |> operate on non-augmented messages, while simple Division |> (D) algorithms operate on augmented messages. |> |> Any D can be optimized to SMD, but the constant has to be |> changed. Also, prefixing a message is equivalent to loading |> the CRC register with that prefix (WLG), but this is not so |> for SMD. (elaborated below) |> |> Further more for any SMD there is an equivalent D, |> including for the Ethernet spec SMD; and for any D there is |> an equivalent SMD. |> |> > If that is your interpretation, then we absolutely MUST |> > fix the spec, |> > I'm quite sure that the intent of the spec is as I wrote |> > it, i.e., |> > Ethernet except for the generator. |> |> Probably it is. But lets not hasten here. |> We can further generalize the explanation of the algorithm. |> |> > > If this is changed, then the message in its form: |> > > M'(x) = x^32 M(x) + x^(32+n) I(x) |> > > |> > > yields to better optimizations as Vince and I have |> > shown. |> > > (see his circuits and worksheet4.pdf, which I posted |> > > yesterday) |> > > |> > > I.e. the message is augmented (mult by x^32, aka |> > postfixed) |> > > and prefixed by 32 1's (aka CRC=32 1's). |> > |> > But that is NOT what the spec currently says. What you |> > describe may |> > be a fine CRC but it is not the one that's in the spec. |> > Initializing |> > the CRC register to all 1 is not the same as prefixing 32 |> > 1 bits onto |> > the message. |> |> It is, in a simple division, e.g. in D. This is clearly and |> simply explained in the Williams paper. It is an equivalent |> to a long division. |> |> Now, in D, if I initialize the CRC to all 1's and then do |> division of M(x) by G(x), so that I catch 0's at the |> beginning of the message, |> |> (which is equivalent to prefixing the message by 1's of the |> number of the width of the CRC, and then do just simple |> division,(CRC=0), since after so many clicks the CRC will |> be loaded with the prefixing bits, and also 0/G(x) = 0) |> |> then I can find a constant which I can XOR to the first 32 |> bits of the message and then perform the division, still in |> D, with the same effect. In this particular case that |> constant is the magic constant. (We are one step closer to |> SMD...) |> |> (Now we jump to SMD, by means of worksheet4.pdf, Prefixing |> part.) |> |> Now, in the Ethernet CRC spec, that constant is 32 1's, and |> XORing 32 1's with the 32 MSb of the message is equivalent |> to complementing them. |> |> BUT the Ethernet spec uses SMD, not D, so I claim that |> there is an equivalent D, which for a suitable initial CRC |> (also equivalent to prefixing the message with it) value |> will yield IDENTICAL results as Ethernet SMD. |> |> Now using a bit of algebra similar to worksheet4.pdf which |> I posted a couple of days ago and numerical methods |> (solving a linear system of 33 unknowns) I have found such |> a constant: |> 0x2a26f826 which in simple division, D, will yield results |> identical to SMD of Ethernet. |> |> So, here is an abstractization of the Ethernet CRC SMD, |> explained in a simple, simple, simple division only way: |> |> TX: |> 1. Mutliply the message, M(x), by x^32. |> 2. Prefix the result of 1. with 0x2a26f826. |> 3. Find the remainder of the result of 2. |> 4. Complement that remainder and add it to the |> result of 1. |> 5. Send the result of 4. to the recipient. |> |> RX: (same as steps 1-3 in TX) |> 1. Mutliply the message by x^32. |> 2. Prefix the result of 1. with 0x2a26f826. |> 3. Find the remainder of the result of 2. |> |> The result of 3 should be 0x1c2d19ed (the magic constant). |> |> Of course I've ommitted the mirroring of bytes for clarity |> and brevity. It can be mentioned on the side, e.g. How to |> build the message: mirror the bytes == to swapping the bits |> inside the bytes, .... |> |> Also note that step 4 in TX, adding means exactly that, |> since we already mult. by x^32, so the remainder will |> nicely fit in the last 32 0 bits. |> |> Also note that step 2, can be made clearer: |> let C(x), be the polynomial representation of 0x2a26f826. |> Let n = deg G(x), k-1 = deg M(x) (there are k bits), then |> step 2 is: |> |> 2. Add x^n x^k C(x) to the message M(x). |> |> Or we can swap step 1 and 2: |> |> 1. Add x^k C(x) to M(x). |> 2. Multiply the result of 1. by x^n. |> |> I hope this makes things a bit clearer. |> |> So from this D specification above, I can derive SMD |> exaclty as it is in the Ethernet spec. I'll include this |> derivation in the paper -- it will be pure math, but in |> english it goes like this: First we notice that after 32 |> clicks the CRC register will contain only 32 1's XOR-ed |> with the message, then we see that we can just load the crc |> with ones and then kick one byte off the left xor it with |> the next message bit... |> |> The above equivalence I've tested empirically. |> |> > What does "better optimizations" mean? |> |> See above. |> |> > > In an SMD, one would have to set the CRC to the magic |> > > constant and then proceed as the algorithm indicates, |> > > (this is identical to what you'd find in Ethernet, ... |> > |> > No it isn't. The Ethernet spec appendix C, and, more |> > importantly, the |> > formal definition of the CRC in the body of the spec, |> > makes it quite |> > clear that it isn't. I don't understand how you arrive |> > at any other |> > conclusion. |> |> I didn't mean identical as in the constant. I meant |> identical in a way of equivalence of algorithms, that one |> can be derived from the other, etc. See above. Or simpler |> answer: Math. |> |> -l |> |> ===== |> -- |> |> __________________________________________________ |> Do You Yahoo!? |> Check out Yahoo! Shopping and Yahoo! Auctions for all of |> your unique holiday gifts! Buy at http://shopping.yahoo.com |> or bid at http://auctions.yahoo.com | |-- |Mark A. Bakke |Cisco Systems |mbakke@cisco.com |763.398.1054 | From owner-ips@ece.cmu.edu Mon Dec 17 15:46:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17813 for ; Mon, 17 Dec 2001 15:46:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHK8Tr05779 for ips-outgoing; Mon, 17 Dec 2001 15:08:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHK8RZ05775 for ; Mon, 17 Dec 2001 15:08:27 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBHK8G500517; Mon, 17 Dec 2001 15:08:16 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBHK8GZ27410; Mon, 17 Dec 2001 15:08:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15390.20654.872083.764027@pkoning.dev.equallogic.com> Date: Mon, 17 Dec 2001 15:08:14 -0500 (EST) From: Paul Koning To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: <15390.4355.623462.667567@pkoning.dev.equallogic.com> <20011217194429.45576.qmail@web12807.mail.yahoo.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Luben" == Luben Tuikov writes: Luben> --- Paul Koning wrote: >> I agree that the current description is not consistent and is >> confusing. That's why I proposed replacement text. I'd be >> interested in comments on that text. Luben> I gave you a comment in my last letter: Luben> Please also note that the Ethernet spec CRC algorithm, is an Luben> optimized version of a basic prefix-postfix-initialize-the- Luben> CRC-register-to-some-constant algoritm. BUT as SMD it operates Luben> on NON-AUGMENTED messages. FOR THAT REASON you cannot say that Luben> we have to multiply M(x) by x^32!!! Luben> You see, you cannot say that the message has to be multiplied Luben> by x^32, if you are describing the Ethernet CRC algo. >> Please also note that the Ethernet spec CRC >> algorithm, is an >> optimized version of a basic >> prefix-postfix-initialize-the- >> CRC-register-to-some-constant algoritm. > I'm not sure what spec you're talking about. Luben> The one you always mention, the one you quote in you Luben> messages. The one iSCSI is trying to present. I don't think so. The one I'm always quoting from says the following (section 6.2.4, page 30): Mathematically, the CRC value corresponding to a given frame is defined by the following procedure: 1. The first 32 bits of the frame are complemented. 2. The n bits of the frame are then considered to be the coefficients of a polynomial M(x) of degree n-1. (The first bit of the destination address field corresponds to the x^(n-1) term and the last bit of the data field corresponds to the x^0 term.) 3. M(x) is multiplied by x^32 and divided by G(x), producing a remainder R(x) of degree <= 31. (rest omitted) So as you can see, the statement about multiplying the message by x^32 is taken directly from the Ethernet spec. That is why I put it into my proposed text. Your statement that "you cannot say that the message has to be multiplied by x^32, if you are describing the Ethernet CRC algo" is clearly not correct. The text in my proposed replacement text is the Ethernet text, except for some terminology and context changes (like "PDU" instead of "frame") and a slightly different but equivalent way of stating bit order). paul From owner-ips@ece.cmu.edu Mon Dec 17 15:51:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17925 for ; Mon, 17 Dec 2001 15:51:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHKN7007022 for ips-outgoing; Mon, 17 Dec 2001 15:23:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHKN4Z07014 for ; Mon, 17 Dec 2001 15:23:04 -0500 (EST) Message-ID: <20011217202304.34500.qmail@web12803.mail.yahoo.com> Received: from [207.219.118.250] by web12803.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 12:23:04 PST Date: Mon, 17 Dec 2001 12:23:04 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: John Hufferd , "CAVANNA,VICENTE V \(A-Roseville,ex1\)" Cc: "'Mark Bakke'" , Paul Koning , "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , ips@ece.cmu.edu, "THALER,PAT \(A-Roseville,ex1\)" , "SHEEHY,DAVE \(A-Americas,unix1\)" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- John Hufferd wrote: > > Mark said that as long as the math matches the example, > great, otherwise > come up with the Math to match the example. But this is not the dark-ages! Examples should not dictate math. Math should dictate examples. > His point is > that the current > stuff is just find for the implementations. I'm an implementor. But you probably meant engineers which have their minds set to SMD. > own draft, and point to it. But if the current Draft is > good enough for > the various different vendors to create good > interoperable implementation, > that should be the goal. Wait until the Linux community at large starts implementing iSCSI. This would mean ppl of all science backgrounds, including math... > ditch. So unless you have a point that the math shows > the current Examples > are invalid, then I would think Marks point is that the > current Draft Works > fine in this area. I'm working with Vince on this. We'll verify it shortly. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 16:25:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18761 for ; Mon, 17 Dec 2001 16:25:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHKqUK09109 for ips-outgoing; Mon, 17 Dec 2001 15:52:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHKenZ08265 for ; Mon, 17 Dec 2001 15:40:49 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 12:40:42 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Dec 2001 12:40:42 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 12:40:41 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 12:40:41 -0800 Received: from win-msg-03.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.198]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 17 Dec 2001 12:39:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE:iSCSI: Outboard Tunnel Mode Date: Mon, 17 Dec 2001 12:39:08 -0800 Message-ID: Thread-Topic: RE:iSCSI: Outboard Tunnel Mode Thread-Index: AcGHNgPnLLtW8g2CThCmV+OG0TOmnwABKDug From: "Lakshmi Ramasubramanian" To: "John Hufferd" , Cc: X-OriginalArrivalTime: 17 Dec 2001 20:39:08.0481 (UTC) FILETIME=[E0582310:01C1873A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBHKenZ08266 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit If it is NOT MUST USE, I guess most implementations would just choose "None" for security options. What is the point in saying MUST IMPLEMENT but is NOT MUST USE? -lakshmi -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 17, 2001 11:13 AM To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: Re: Outboard Tunnel Mode Installations can do what ever they want. The Security functions are must implement, NOT must use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Outboard Tunnel Mode Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Mon Dec 17 16:31:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18901 for ; Mon, 17 Dec 2001 16:31:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHKnYr08903 for ips-outgoing; Mon, 17 Dec 2001 15:49:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHKnRZ08896 for ; Mon, 17 Dec 2001 15:49:27 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A8E942600AE; Mon, 17 Dec 2001 14:43:21 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id AA261A7F00F4; Mon, 17 Dec 2001 14:48:38 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: responding to a logout request Date: Mon, 17 Dec 2001 15:31:26 -0500 Message-ID: <000701c18739$cdebe8c0$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C1870F.E515E0C0" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1870F.E515E0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Section 3.9.1 says: Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session" [ESQ1] , to completely close the session, but ONLY if it does not support or use multiple connections in the specific session. I think this should say: Initiator MUST send a Logout with a reason code of “Close the connection" (if not the only connection) or “Close the session” (if using multiple connections). Because once you comply with the 1st sentence, you would not be able To comply with the 2nd sentence. Eddy _____ [ESQ1] If a target closes the connection and there is only one connection, issue two logouts (one to close the connection and one to close the session)? But how if you just closed the connection. ------=_NextPart_000_0008_01C1870F.E515E0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 [ESQ1] If a target closes = the connection and there is only one connection, issue two logouts (one to = close the connection and one to close the session)? But how if you just = closed the connection.

------=_NextPart_000_0008_01C1870F.E515E0C0-- From owner-ips@ece.cmu.edu Mon Dec 17 18:04:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21228 for ; Mon, 17 Dec 2001 18:04:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHM8nP15025 for ips-outgoing; Mon, 17 Dec 2001 17:08:49 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHM8lZ15020 for ; Mon, 17 Dec 2001 17:08:48 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA115018; Mon, 17 Dec 2001 17:05:55 -0500 Received: from d03nm045.boulder.ibm.com (d03nm045.boulder.ibm.com [9.99.140.45]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBHM7Tm127094; Mon, 17 Dec 2001 15:07:29 -0700 Importance: Normal Subject: Re: Outboard Tunnel Mode To: "John Hufferd" Cc: VAHUJA@aol.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "David F Hepner" Date: Mon, 17 Dec 2001 14:06:19 -0800 X-MIMETrack: Serialize by Router on D03NM045/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/17/2001 03:07:29 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk With most corporations security at the corporate firewall is a MUST no mater what is done at the machine I/O. With Security functions a MUST for iSCSI, an installation will pay for security twice and only use it once. Why pay for security at every I/O when the corporation mandates it at the edge? This seems like motorcycle helmet laws. Why mandate something that a reasonable person would do any way? David ------------------------------------------------------ David F. Hepner WA7UHT dfhepner@us.ibm.com IBM SSG San Jose, CA (408) 256-4981 Fax (408) 256-6214 Tie Line 8-276-4981 ----------------------------------------------------- John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 12/17/2001 11:13:00 AM Sent by: owner-ips@ece.cmu.edu To: VAHUJA@aol.com cc: ips@ece.cmu.edu Subject: Re: Outboard Tunnel Mode Installations can do what ever they want. The Security functions are must implement, NOT must use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Outboard Tunnel Mode Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Mon Dec 17 18:09:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21269 for ; Mon, 17 Dec 2001 18:09:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHMhqw17604 for ips-outgoing; Mon, 17 Dec 2001 17:43:52 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHMhnZ17596 for ; Mon, 17 Dec 2001 17:43:50 -0500 (EST) Received: from somesh (sdsl-66-80-0-42.dsl.sca.megapath.net [66.80.0.42]) by philotas.hosting.pacbell.net id RAA28974; Mon, 17 Dec 2001 17:43:37 -0500 (EST) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Julian Satran" , "Jim Pinkerton" , Cc: , , , "Stephen Bailey" , Subject: RE: Wot I `know' about COWS in hardware Date: Mon, 17 Dec 2001 14:41:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01C18708.FBE547C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C18708.FBE547C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think the COBS/COWS should more potential than the markers proposal, or the ULP framing without COBS. There is one case where it does add more overhead, but the question is how prevelent is the scenario - when outbound zero copy is enabled/possible and the NIC does checksum offload and cannot be changed to do COBS. Of course changes are required :-). I also hope that data-centers will use acclerated iSCSI/Clustering HBAs/NICs rather than the current solutions. The current solutions MAY be useful for desktops/laptops where hopefully there are plenty of spare cycles to do COBS in software. COBS also has alignment benefits - the header could be aligned with the ULP PDU, and the ULP PDU can be aligned with the TCP header and there are no false positives. The alignment with the TCP header may not always happen (the mythical box in the middle that does TCP resegmentation), but can be detected - in the presence of such a box, the performance could reduce to the levels encountered when IP fragmentation happens. I think it is better to have a couple of inter-operable implementations that demonstrate the benefit of any of the alternate proposals (especially markers vs cobs) before selecting one. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, December 17, 2001 9:27 AM To: Jim Pinkerton; ips@ece.cmu.edu Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware Jim, There are some things attractive about COWS - 1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side 2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved 3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation Julo "Jim Pinkerton" wrote on 17-12-2001 17:32:04: > > My main concern with this approach is that we could kill the product but > win the spec wars. Specifically, this approach means that an > end-customer has one of two choices in deploying the technology: > > 1) Upgrade both ends, and they'll see the full benefit > 2) Upgrade only the server side, and see roughly 2-4 times the > CPU > utilization on the client if their current > implementation is optimized > on the client side (a mere 2x if they are doing > significant > receives that already require a copy, more like 4x if > they > are primarily doing sends, which currently has no bcopy > in > many OS implementations). > > This means that if they pick option 2) and their machines are CPU bound, > that the data center capacity to handle requests will actually > *decrease* if they deploy the technology. If the front end has enough > idle CPU cycles, then they probably could select option 2). > > In my experience, we need to make sure we have a volume solution to > enable NIC vendors to make enough profit to fund the next generation > (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU > architecture). This means we need a path to the front-end boxes in the > data center. My concern is that there is no half-measure in the above > scenario - the IT manager must upgrade the thousand front-end boxes at > the same time as they upgrade the back end, or deploy asymmetric configs > where some front end boxes are upgraded. I'm not sure how attractive > this deployment scenario is. > > Howard and Uri, can you comment on this issue? > > > > Jim > > > > > > > > > -----Original Message----- > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > > Sent: Monday, December 17, 2001 7:13 AM > > To: uri@broadcom.com; howard.c.herbert@intel.com > > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com; > > allyn@cisco.com > > Subject: Wot I `know' about COWS in hardware > > > > Hi, > > > > I haven't gotten a chance to do a full implementation yet, but here's > > some architectural properties I believe to be true of a hardware COWS > > implementation: > > > > 1) can be implemented `in line' on receive > > 2) requires an MTU-sized RAM on send > > 3) expected touches to send RAM is 2 per data word (just the `fifo' > > write and read ops, no editing), assuming the headers are merged > > on the outbound side. > > 4) worst case touches to send RAM is 3 per data word (assuming every > > word must be edited) > > 5) eliminates the need for the funky `make sure you don't send > > anything that's false positive under non-nominal conditions' > > behavior of the key/length proposal (I kinda doubted hardware > > impls were going to do this anyway, since it was a SHOULD). > > > > Basically, it looks OK to me. Slowing the sender is much better than > > slowing the receiver. Theoretically, we could reverse the pointer > > chain and allow in-line send, but RAM on receive, but that seems > > stupid to me. > > > > It's clearly a design tradeoff whether you chose to use the COWS > > send-side RAM for other purposes, or not. > > > > I'm hoping you guys can tell me whether you think this blows your > > budget, or other noteworthy (unfortunate) properties. As you can > > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...). > > > > Thanks, > > Steph ------=_NextPart_000_00C2_01C18708.FBE547C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
I=20 think the COBS/COWS should more potential than the markers proposal,=20 or
the=20 ULP framing without COBS. There is one case where it does add more=20 overhead,
but=20 the question is how prevelent is the scenario - when outbound zero copy=20 is
enabled/possible and the NIC does checksum = offload and=20 cannot be changed to
do=20 COBS. Of course changes are required = :-).
 
I also=20 hope that data-centers will use acclerated iSCSI/Clustering HBAs/NICs=20 rather
than=20 the current solutions. The current solutions MAY be useful for=20 desktops/laptops
where=20 hopefully there are plenty of spare cycles to do COBS in=20 software.
 
COBS=20 also has alignment benefits - the header could be aligned with the ULP=20 PDU,
and=20 the ULP PDU can be aligned with the TCP header and there are no=20 false
positives. The alignment with the TCP header = may not=20 always happen (the mythical
box in=20 the middle that does TCP resegmentation), but can be detected - in=20 the
presence of such a box, the performance could = reduce to=20 the levels encountered
when=20 IP fragmentation happens.
 
I=20 think it is better to have a couple of inter-operable implementations = that=20 demonstrate
the=20 benefit of any of the alternate proposals (especially markers vs cobs) = before=20 selecting
one.
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Monday, December 17, 2001 9:27 AM
To: = Jim=20 Pinkerton; ips@ece.cmu.edu
Cc: allyn@cisco.com; = csapuntz@cisco.com;=20 howard.c.herbert@intel.com; Stephen Bailey;=20 uri@broadcom.com
Subject: RE: Wot I `know' about COWS in=20 hardware


Jim,=20

There are some things = attractive about=20 COWS -

1. the hard = work - touching=20 every data word has to be done only by the sender (on the normal path) = and can=20 be easily included in NIC with accelerator cards that seem to do a = good job on=20 the send side

2. If = you are doing=20 CRC or IPsec on a client in software there is no additional penalty = (provided=20 you can include the code in the right layer of software) as no data = gets=20 moved

3.It does not = have to=20 associated with a TCP packet alignment - and can work in face of TCP=20 segmentation

Julo=20

"Jim Pinkerton"=20 <jpink@microsoft.com> wrote on 17-12-2001 17:32:04:

> =
>=20 My main concern with this approach is that we could kill the product=20 but
> win the spec wars. Specifically, this approach means that=20 an
> end-customer has one of two choices in deploying the=20 technology:
>
>    1) Upgrade both ends, and = they'll=20 see the full benefit
>    2) Upgrade only the server = side, and=20 see roughly 2-4 times the
> CPU
>       = utilization=20 on the client if their current
>       = implementation is=20 optimized
>       on the client side (a mere 2x = if they=20 are doing
> significant
>       receives = that=20 already require a copy, more like 4x if
> they
>   =  =20   are primarily doing sends, which currently has no bcopy
> = in
>       many OS implementations).
> =
>=20 This means that if they pick option 2) and their machines are CPU=20 bound,
> that the data center capacity to handle requests will=20 actually
> *decrease* if they deploy the technology. If the = front end=20 has enough
> idle CPU cycles, then they probably could select = option=20 2).
>
> In my experience, we need to make sure we have a = volume=20 solution to
> enable NIC vendors to make enough profit to fund = the next=20 generation
> (otherwise RDMA/TOE is a one-shot deal and won't = keep up=20 with the CPU
> architecture). This means we need a path to the = front-end=20 boxes in the
> data center. My concern is that there is no = half-measure=20 in the above
> scenario - the IT manager must upgrade the = thousand=20 front-end boxes at
> the same time as they upgrade the back end, = or=20 deploy asymmetric configs
> where some front end boxes are = upgraded. I'm=20 not sure how attractive
> this deployment scenario is.
> =
>=20 Howard and Uri, can you comment on this issue?
>
> =
>=20
> Jim
>
>
>
>
>
> =
>=20
> > -----Original Message-----
> > From: Stephen = Bailey=20 [mailto:steph@cs.uchicago.edu]
> > Sent: Monday, December 17, = 2001=20 7:13 AM
> > To: uri@broadcom.com; = howard.c.herbert@intel.com
>=20 > Cc: csapuntz@cisco.com; Jim Pinkerton; = Julian_Satran@il.ibm.com;
>=20 > allyn@cisco.com
> > Subject: Wot I `know' about COWS in=20 hardware
> >
> > Hi,
> >
> > I = haven't=20 gotten a chance to do a full implementation yet, but here's
> = > some=20 architectural properties I believe to be true of a hardware = COWS
> >=20 implementation:
> >
> >   1) can be = implemented `in=20 line' on receive
> >   2) requires an MTU-sized RAM on=20 send
> >   3) expected touches to send RAM is 2 per data = word=20 (just the `fifo'
> >      write and read ops, = no=20 editing), assuming the headers are merged
> >     =  on=20 the outbound side.
> >   4) worst case touches to send = RAM is 3=20 per data word (assuming every
> >      word = must be=20 edited)
> >   5) eliminates the need for the funky `make = sure=20 you don't send
> >      anything that's false = positive=20 under non-nominal conditions'
> >     =  behavior of the=20 key/length proposal (I kinda doubted hardware
> >   =  =20  impls were going to do this anyway, since it was a = SHOULD).
> >=20
> > Basically, it looks OK to me.  Slowing the sender = is much=20 better than
> > slowing the receiver.  Theoretically, we = could=20 reverse the pointer
> > chain and allow in-line send, but RAM = on=20 receive, but that seems
> > stupid to me.
> > =
> >=20 It's clearly a design tradeoff whether you chose to use the = COWS
> >=20 send-side RAM for other purposes, or not.
> >
> > = I'm=20 hoping you guys can tell me whether you think this blows your
> = >=20 budget, or other noteworthy (unfortunate) properties.  As you = can
>=20 > tell, I have the utmost enthusiasm for the mission (Dr.=20 Chandra...).
> >
> > Thanks,
> >  =20 Steph
 ------=_NextPart_000_00C2_01C18708.FBE547C0-- From owner-ips@ece.cmu.edu Mon Dec 17 18:11:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21314 for ; Mon, 17 Dec 2001 18:11:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHMYlD17003 for ips-outgoing; Mon, 17 Dec 2001 17:34:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHMYjZ16997 for ; Mon, 17 Dec 2001 17:34:45 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel11.hp.com (Postfix) with ESMTP id B64B71FA10; Mon, 17 Dec 2001 14:34:39 -0800 (PST) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 4FDDC400147; Mon, 17 Dec 2001 14:34:33 -0800 (PST) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 14:34:39 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2B4@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Keith McCloghrie'" Cc: ips@ece.cmu.edu Subject: RE: iSCSI - structured values Date: Mon, 17 Dec 2001 14:34:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Because of the specialized nature of target IO subsystems, target's will require more control of the iSCSI session manager logic, and it is not likely that the Target Portal Group numbering will be out of the control of a single logical session manager at the target node level. If there are no target vendors/implementors calling this a problem, why solve it? As for: > Furthermore, it is now apparent that the proposed resolution of the > problem for Initiators punts the problem to vendors. That is, the WG > is requiring vendors to implement a proprietary mechanism in order to > have interoperability between two different products from the same > vendor. I'm very doubtful that is kosher. That's how MAC address assignment and FC WWNs work - vendors must develop internal schemes for assuring uniqueness beyond their vendor numbers. Why should this be any more difficult? From owner-ips@ece.cmu.edu Mon Dec 17 18:12:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21325 for ; Mon, 17 Dec 2001 18:12:13 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHMI5o15727 for ips-outgoing; Mon, 17 Dec 2001 17:18:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHMI3Z15723 for ; Mon, 17 Dec 2001 17:18:03 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 6922136D; Mon, 17 Dec 2001 15:18:02 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id AB0BC12D; Mon, 17 Dec 2001 15:18:01 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 15:18:01 -0700 Message-ID: <01A7DAF31F93D511AEE300D0B706ED9201BF465A@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Luben Tuikov'" , "'Mark Bakke'" Cc: Paul Koning , "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu, "THALER,PAT (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Mon, 17 Dec 2001 15:17: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-ips@ece.cmu.edu Precedence: bulk Luben is right, Paul's description is still ambiguous, although I do not quite agree that the issue is the multiplication by x^32. I will attempt to clarify. When Paul, in his 12/14/01 memo "re:effect of initializing CRC reg to 1's depends on implementation? iSCSI", says to multiply the message by x^32 he means that is what the implied circuit does. He does not mean to multiply the message by x^32 and _then_ to perform the CRC computation with a circuit that multiplies by x^32 and divides by the CRC polynomial. Note also that Paul said to complement the first 32 bits of the PDU and he did not say that this is equivalent to initializing the CRC to ones like the iSCSI spec currently says. Anyone who attempts to implement Paul's process using a multiply-divide circuit will obtain the results in the examples in hte iSCSI spec. If that person then, instead of complementing the first 32 bits of the PDU, initializes the circuit to 1s, he will also obtain the results in the iSCSI spec. On the other hand, if that person implements paul's process using a divide-only circuit as Luben I and others have tried to do, the circuit will not yield the results in the examples and furthermore for that circuit initializing the circuit to ones is not the same as complementing the first 32 bits of the PDU. So it is important that we either specify the circuit or we specify the process more rigorously. Again, specifying the circuit means specifying its response to an input _and_ its response to an initial state. This can be accomplished by specifying the serial implementation that I have posted or by specifying the complete response that I have also posted. I repeat below two ways to specify the implementation unambiguously: One way to specify the circuit is to show the reference implementation (e.g. the serial implementation of the multiply-divide circuit that I posted) and to say that any circuit that performs the same function, ie. has the exact same response to initial state and to the input is also acceptable. Another way is to describe the response of the implied circuit (the multiply-divide implementation) after the application of n input bits is: 1. when I(x) is zero, multiplies the input, M(x), by x^32 and divides by G(x). 2. when M(x) is zero, multiplies the initial state, I(x), by x^n and divides by G(x). where I(x) represents the initial state of the CRC register and M(x) represents the input. I also claim that the description in the ethernet spec is also ambiguous but got away with it because of the implementation that they referenced (a multiply-divide implementation) and which removed the ambiguity - whether folk realized it or not. The parallel implementations that were derived from _that_ serial implementation had exactly the same response to an input and to an initial state. Vince |-----Original Message----- |From: Luben Tuikov [mailto:ltuikov@yahoo.com] |Sent: Monday, December 17, 2001 12:07 PM |To: CAVANNA,VICENTE V (A-Roseville,ex1); 'Mark Bakke' |Cc: Paul Koning; CAVANNA,VICENTE V (A-Roseville,ex1); ips@ece.cmu.edu; |Luben Tuikov; THALER,PAT (A-Roseville,ex1); SHEEHY,DAVE |(A-Americas,unix1) |Subject: RE: effect of initializing CRC reg to 1's depends on |implementati on? iSCSI | | |--- "CAVANNA,VICENTE V (A-Roseville,ex1)" | wrote: |> |> I do not think we should rely on examples to serve as the |> specification. | |Absolutely true. | |But lets include examples _just_ to back it up, and maybe a |sample implementation (skeleton of), that will be good for |both hardware and software. Of course some optimization |will be sacrificed... (e.g. like processing more than one |bit at a time). | |> For |> this reason I recommend that we modify the spec in one of |> 3 ways: |> |> 1. explicitly show the reference implementation- what I |> call the |> multiply-divide implementation and which I have sent to |> the reflector. It is |> basically the ethernet reference implementation modified |> for the iSCSI poly. | |Yep, maybe we should just mention that, plus plenty of |references, the 4 examples with correct values, and a |sample bit-at-a-time skeleton implementation. | |> 2. use Paul's description | |It says that the message is multiplied by x^32, which |is not correct. See below. | |> 3. use Luben's formal description | |I wouldn't. In implementor wants to get some speedup, and |optimization and as a formal definition it doesn't offer |them. Maybe the implementor will notice that after 32 |clicks the CRC will be all 1's, and that they don't need to |multiply the message by x^32 if they init the CRC register |with all 1's and only xor the message bit and the MSb of |CRC on each click.... but that implies that the implementor |will have to do extra thinking work. | |> The point I have been trying to make is that initializing |> the register to 1s |> does not necessarily result in the same process as |> described in the ethernet |> spec. Initializing the register to 1s only results in the |> desired results |> (i.e. agrees with the examples in the iSCSI spec) if you |> are using the |> implementation that I have been calling the |> multiply-divide implementation. |> This is the implementation that ethernet had in mind and |> iSCSI had in mind. | |Absolutely true. | |> The only reason that the above has worked right for |> implementors is that |> they all use the equivalent of a multiply-divide |> implementation as was |> described in the ethernet spec but that has not been |> described in any manner |> in iSCSI and that I have since recommended that we |> specify. | |Abosultely true. | |> I have to admit that by giving examples the iSCSI spec |> has removed the |> ambiguity since nobody will be able to get results that |> agree with the |> examples _unless_ they use the multiply-divide |> implementation but why not |> make it explicit and eliminate the need for implementors |> to have familiarity |> with ethernet and its implementations. Please note that |> any parallel |> implementations (that process 8 or 16 or 32 input bits at |> once) for ethernet |> are equivalent to the serial implementation that is shown |> as reference in |> the ethernet spec. | |Abosultely true. | |> I can however implement the iSCSi (and ethernet) CRCs |> using what I call a |> divide-only circuit and, if I initialize the circuit to |> 1's, and process the |> examples I will not get the results in the iSCSI spec but |> I will still get |> the magic constant at the receiver! What I will get |> instead are the same |> results as if I had XORed the most significant 32 bits of |> the messages in |> the examples with the magic constant and then processed |> them. | |Aboslutely true. | |-l | | | | |===== |-- | |__________________________________________________ |Do You Yahoo!? |Check out Yahoo! Shopping and Yahoo! Auctions for all of |your unique holiday gifts! Buy at http://shopping.yahoo.com |or bid at http://auctions.yahoo.com | From owner-ips@ece.cmu.edu Mon Dec 17 19:05:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21883 for ; Mon, 17 Dec 2001 19:05:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHN5uE19141 for ips-outgoing; Mon, 17 Dec 2001 18:05:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pepsi.splentec.com (IDENT:root@www.splentec.com [207.219.118.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBHMsIZ18315 for ; Mon, 17 Dec 2001 17:54:18 -0500 (EST) Received: from splentec.com (canoe.splentec.com [207.219.118.250]) by pepsi.splentec.com (8.11.6/8.11.0) with ESMTP id fBHMrMU02350; Mon, 17 Dec 2001 17:53:22 -0500 Message-ID: <3C1E7797.906F8610@splentec.com> Date: Mon, 17 Dec 2001 17:54:15 -0500 From: Luben Tuikov Organization: Splentec Ltd. X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.16 i686) X-Accept-Language: en MIME-Version: 1.0 To: vince_cavanna@agilent.com Subject: Re: summary References: <01A7DAF31F93D511AEE300D0B706ED9201BF4656@axcs13.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Vince, Part 1 ====== D = Divide only simple circuit. SMD = Simultaneous Multiply and Divide. Now, in SMD we never talk about prepending the message. In SMD we only talk about what we do to the first 32 MSb of the message and that is only because we know how the circuit works. We talk about prepending (prefixing) only for D. Now follow carefully and check the following, some of it is really trivial and some is very tricky to _see_ and understand. Let k = the message bits, n = deg G(x), also = to # of bits in CRC In D: ----- (0) M'(x) = x^n M(x) + x^n x^k D(x) = x^n ( M(x) + x^k D(x) ) where D(x) is some initial constant poly. The above means that we are prepending the message with D(x) and we are allocating 32 0's at the end. Now since we are going to divide by G(x) anyway, lets see the equivalence: (1) M'(x) = x^n M(x) + x^k E(x) (mod G(x)) deg E(x) = n-1, so deg(x^kE(x)) = k+n-1, and deg(x^nM(x)) = k+n-1 so here is where we see that prepending the message with D(x) is equivalent to XORing the 32 MSb of the message with E(x). In (1) we can factor out x^n, resulting in a similar conclusion: k-1 (2) M'(x) = x^n ( M(x) + SUM e_i x^{k-n+i} ) i=max(0, n-k) When k >> n, i.e. message bits are a lot more than the width of the CRC (32 bits), which is 99.99% of the time, then the above expression just XORs the bits of E(x) to the 32 MSb of the message and THEN the message is multiplied by x^n. When k < n, i.e. the message has less than the bits of the CRC width then we also XOR, but only the bits which make sense. Part 2 ====== Now imagine a ``serial'', or long division simple circuit: Now from (2), we can derive SMD, by noting that multiplication by x^n allocates n 0's at the end of M(x). The reason for this is that the computation will be carried out for n more clicks, i.e. until the REAL data is out the left, and the CRC is full of those n 0s (32 0s). Also imagine the message as a long string of bits and the CRC below it, bit by bit shifting to the right (started from the far left, exactly as in long division). At any moment of the computation the contents if the CRC is a function of the initial constant and the number of ``clicks'' and the current window of bits we are under of the message. (at the very beginning that state was the constant XOR 32 MSb of the message) But, (3) A xor (B xor C xor D xor .... xor X) = (A xor B xor ... xor Y) xor X and also note that the decision is made ONLY when a bit pops out the left of the CRC register. IF 1 poped out we put the next mesage bit at the right and then we xor with the poly, ELSE we just put the next message bit at the right (this is equivalent to long division and I'm sure are know it very well) So instead of the message bits travelling through the register each time going another XOR with some value which is equal to some funcion of the number of clicks and initial const, (CRC(0 state) = const XOR 32 MSb of message) (0 state is initial state) I can keep the message bits separate and xor only when I need to. So at 0 state: CRC = const XOR 32 MSb of message. at 1 state CRC = CRC shifted left, next message bit appended and xored with the Poly given a what popped out, etc. Upon close inspection I see that (4) | CRC(i-1) << 1 XOR poly(32 LSb) CRC(i state) = { | CRC(i-1) << 1 Plus the message bits being XORed at each click, which I've isolated now. I.e. a window of n message bits being XOR-ed at each click. The first condition above if the message bit XOR the bit poping out is 1, and the second if 0. All this is by (3). Now at the very last state of the CRC I'd have a window of 0, being XORed with the CRC and THAT WILL BE MY final CRC value, All the other bits of the message went through the CRC register to change my XOR-ing pattern as seen above (4). But a xor 0 = a, so here is SMD: ====================== 0. The CRC register contains the CRC ---atomic---- 1. Take the next bit B. 2. Shift left the CRC register, bit A popped out. 3. If A xor B is 1 (one) then CRC = CRC XOR last 32 bits of poly (since G(x) is 33 bits) else NOTHING (CRC was already shifted left in 2.) ---atomic---- 4. The CRC register contains the CRC. ======================= Initial constraint: CRC should be initialized to 0xFFFFFFFF. Part 3 ====== Now, we ask: what is this 0xFFFFFFFF equivalent to in D? Well, going back to our definitions: 0xFFFFFFFF is E(x). Looking at (1) and (0) we see that we are seeking D(x) where: x^nD(x) = K(x)G(x) + E(x) (mod G(x)) where deg x^nD(x) = 2n-1 <- that is important! so the LHS has to have deg = 2n-1 but deg E(x) = n-1, thus deg K(x)G(x) = 2n-1, but deg G(x) = n thus deg K(x) = n-1 <- that is important! Note that all n-1 lower degree terms of x^nD(x) are 0, and that E(x) is all 1's. This implies that the n-1 lower degree terms of K(x) are 1s. Now, n-1 K(x)G(x) = SUM k_i x^i G(x) i=0 But we are interested only in the n-1 lower terms. So let n-1 n-1-i R(x) = SUM k_i x^i ( SUM g_j x^j ) i=0 j=0 Now this gives a linear system G*K = R, where G is (n)x(n), K is (n)x(1) and R is (n)x(1). We need to solve for R = [n 1's] = [32 1's]. Then K = inverse(G)*R. Finding K is trivial. Finding K(x)G(x) is also trivial. Then x^n D(x) = K(x)G(x) + E(x) = 0x2a26f82600000000 + 0xFFFFFFFF = 0x2a26f826FFFFFFFF so D(x) = 0x2a26f826. Thus in simple division-prepending-postfixing algorithm, prepending the message by D(x) (equivalently init the CRC by D(x)) and postfixing the message by 32 0's and then computing the CRC is EQUIVALENT to simultaneous multiply and divide, WITHOUT the message being prefixed or postfixed (it doesn't make sense). ONLY the CRC has to be init to 0xFFFFFFFF. Part 4 (please implement and verify!!!!) ====== Lets test and verify the examples as given in the iSCSI draft: 28 zeros, 28 ones, 28 incs (0..27), and 28 decs (27..0). Those are bytes AND are BIG endian on bytes BIG endian on bits in memory, e.g. natural (black board) order of bytes and bits. A. mirror the bytes all 28 of them. B. initialize CRC to 0xFFFFFFFF. ---atomic--- 1. Take the next bit B. 2. Shift left the CRC register, bit A popped out. 3. If A xor B is 1 (one) then CRC = CRC XOR last 32 bits of poly (since G(x) is 33 bits) else NOTHING (CRC was already shifted left in 2.) ---atomic---- C. The CRC register contains the CRC. Please note that this algorithm means that we do not need any information on what the PREVIOUS bit(s) is(are) or what the NEXT bit(s) is(are). Implement this -- simulation, circuit, program, whatever and then let me know what you get. -- Luben Tuikov, Senior Software Engineer, Splentec Ltd. Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974. From owner-ips@ece.cmu.edu Mon Dec 17 19:08:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21964 for ; Mon, 17 Dec 2001 19:08:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBHNact21241 for ips-outgoing; Mon, 17 Dec 2001 18:36:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12802.mail.yahoo.com (web12802.mail.yahoo.com [216.136.174.37]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBHNaaZ21237 for ; Mon, 17 Dec 2001 18:36:36 -0500 (EST) Message-ID: <20011217233635.99509.qmail@web12802.mail.yahoo.com> Received: from [207.219.118.250] by web12802.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 15:36:35 PST Date: Mon, 17 Dec 2001 15:36:35 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , "'Mark Bakke'" Cc: Paul Koning , "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , ips@ece.cmu.edu, "THALER,PAT \(A-Roseville,ex1\)" , "SHEEHY,DAVE \(A-Americas,unix1\)" In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED9201BF465A@axcs13.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "CAVANNA,VICENTE V (A-Roseville,ex1)" wrote: > > When Paul, in his 12/14/01 memo "re:effect of > initializing CRC reg to 1's > depends on implementation? iSCSI", says to multiply the > message by x^32 he > means that is what the implied circuit does. He does not > mean to multiply > the message by x^32 and _then_ to perform the CRC > computation with a circuit > that multiplies by x^32 and divides by the CRC > polynomial. Note also that > Paul said to complement the first 32 bits of the PDU and > he did not say that > this is equivalent to initializing the CRC to ones like > the iSCSI spec > currently says. > > Anyone who attempts to implement Paul's process using a > multiply-divide > circuit will obtain the results in the examples in hte > iSCSI spec. If that > person then, instead of complementing the first 32 bits > of the PDU, > initializes the circuit to 1s, he will also obtain the > results in the iSCSI > spec. > > On the other hand, if that person implements paul's > process using a > divide-only circuit as Luben I and others have tried to > do, the circuit will > not yield the results in the examples and furthermore for > that circuit > initializing the circuit to ones is not the same as > complementing the first > 32 bits of the PDU. > > So it is important that we either specify the circuit or > we specify the > process more rigorously. Again, specifying the circuit > means specifying its > response to an input _and_ its response to an initial > state. All true. But let's not really aim at ``circuit''. A simple explanation of how to compute the CRC, bit at a time will suffice. From it an engineer can make a circuit, and a computer scientist can make a program. It would also be nice to make a document describing all the math, derivations, etc. cleanly and clearly and make a reference to it in the draft. So if anyone is interested they can follow the reference, if not, an implementaion is clearly defined. > I repeat below two ways to specify the implementation > unambiguously: > > One way to specify the circuit is to show the reference > implementation (e.g. Circuit? > the serial implementation of the multiply-divide circuit > that I posted) and > to say that any circuit that performs the same function, > ie. has the exact > same response to initial state and to the input is also > acceptable. > > Another way is to describe the response of the implied > circuit (the Circuit again? > I also claim that the description in the ethernet spec is > also ambiguous but > got away with it because of the implementation that they > referenced (a > multiply-divide implementation) and which removed the > ambiguity - whether > folk realized it or not. Absolutely AGREE! -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 19:57:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22392 for ; Mon, 17 Dec 2001 19:57:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI012P22865 for ips-outgoing; Mon, 17 Dec 2001 19:01:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI00rZ22853 for ; Mon, 17 Dec 2001 19:00:55 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A5C772200AA; Mon, 17 Dec 2001 17:54:47 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A70E15400F0; Mon, 17 Dec 2001 18:00:14 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: iSCSI: responding to a logout request Date: Mon, 17 Dec 2001 18:43:05 -0500 Message-ID: <000c01c18754$93816d20$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C1872A.AAAB6520" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C1872A.AAAB6520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit I think I made an error in my suggested wording… It should be: Initiator MUST send a Logout with a reason code of “Close the connection" (if using multiple connections) or “Close the session” (if not using multiple connections). Eddy -----Original Message----- From: Amir Shalit [mailto:amir@astutenetworks.com] Sent: Monday, December 17, 2001 5:23 PM To: Eddy Quicksall Subject: RE: iSCSI: responding to a logout request It can also change to: Initiator MUST send a Logout with a reason code of “Close the connection" or “Close the session”. Why do we have to close multiple connections, at the iSCSI level, one by one? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 17, 2001 12:31 PM To: ips@ece. cmu. edu (E-mail) Subject: iSCSI: responding to a logout request Section 3.9.1 says: Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session" [ESQ1] , to completely close the session, but ONLY if it does not support or use multiple connections in the specific session. I think this should say: Initiator MUST send a Logout with a reason code of “Close the connection" (if not the only connection) or “Close the session” (if using multiple connections). Because once you comply with the 1st sentence, you would not be able To comply with the 2nd sentence. Eddy _____ [ESQ1] If a target closes the connection and there is only one connection, issue two logouts (one to close the connection and one to close the session)? But how if you just closed the connection. ------=_NextPart_000_000D_01C1872A.AAAB6520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = think I made an error in my suggested = wording…

 

It = should be:

 

 Initiator MUST send a Logout = with a reason code of “Close the

 connection" (if using = multiple connections) or “Close the

 session” (if not using = multiple connections).

 

Eddy<= /span>

 

 

-----Original Message-----
From: Amir Shalit [mailto:amir@astutenetworks.com]
Sent: Monday, December = 17, 2001 5:23 PM
To: Eddy Quicksall
Subject: RE: iSCSI: = responding to a logout request

 

It can also change to: 

 

 Initiator = MUST send a Logout with a reason code of “Close the

 connection" or “Close the session”.

 

=

Why do we have to close multiple connections, at the = iSCSI level, one by one?

 

=

Amir

 

-----Ori= ginal Message-----
From: = owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On = Behalf Of Eddy Quicksall
Sent: Monday, December = 17, 2001 12:31 PM
To: ips@ece. cmu. edu = (E-mail)
Subject: iSCSI: = responding to a logout request

Section 3.9.1 says:

 <= /p>

 Initiator = MUST send a Logout with a reason code of "Close the

 connection" to cleanly shutdown the connection. The initiator

 MAY also = issue a Logout with the reason code of "Close the

 session"[ESQ1] , to completely close the session, but ONLY if it does

 not support = or use multiple connections in the specific

 session.

 

I think this should say:

 

 Initiator = MUST send a Logout with a reason code of “Close the

 connection" (if not the only connection) or “Close the = session”

 (if using = multiple connections).

 

Because once you comply with the 1st sentence, = you would not be able

To comply with the 2nd = sentence.

 

Eddy

 [ESQ1] If a target closes the connection and there is only one = connection, issue two logouts (one to close the connection and one to close the = session)? But how if you just closed the connection.

------=_NextPart_000_000D_01C1872A.AAAB6520-- From owner-ips@ece.cmu.edu Mon Dec 17 20:14:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22538 for ; Mon, 17 Dec 2001 20:14:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI0dpd25035 for ips-outgoing; Mon, 17 Dec 2001 19:39:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI0doZ25031 for ; Mon, 17 Dec 2001 19:39:50 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id AEE45F700B0; Mon, 17 Dec 2001 18:33:40 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A0205D101A0; Mon, 17 Dec 2001 18:38:56 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: F and TTT=0xFFFFFFFF in final text response Date: Mon, 17 Dec 2001 19:21:43 -0500 Message-ID: <001e01c18759$fadb4e00$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C18730.12054600" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C18730.12054600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Section 3.11.1 says that the F bit is set to 1 when the target has finished. Then 3.10.3 implies that the target must set the TTT to 0xFFFFFFFF in the final response (it is also backed up by an example). Since the F bit should tell the story and we shouldn’t have two ways to tell when the target is finished, I think we should not make this implication. Can we add a statement that says 3.10.3 “Note that the TTT is not applicable when the target sets the F bit to 1”. 3.11.1 “When the F bit is set to 1 in a text response, the TTT is not applicable”? Or if there is a good reason for this, then we should state it clearly. Eddy ------=_NextPart_000_001F_01C18730.12054600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 3.11.1 says that the F bit is set to 1 when the target has finished. = Then 3.10.3 implies that the target must set the TTT to 0xFFFFFFFF in the = final response (it is also backed up by an = example).

 

Since the F bit should tell the story and we shouldn’t have two ways to = tell when the target is finished, I think we should not make this = implication.

 

Can we add a statement that says

 

3.10.3

 

“Note that the TTT is not applicable when the target sets the F bit to = 1”.

 

3.11.1

 

“When the F bit is set to 1 in a text response, the TTT is not = applicable”?

 

Or if there is a good reason for this, then we should state it = clearly.

 

Eddy<= /span>

------=_NextPart_000_001F_01C18730.12054600-- From owner-ips@ece.cmu.edu Mon Dec 17 20:20:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22598 for ; Mon, 17 Dec 2001 20:20:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI0X1024680 for ips-outgoing; Mon, 17 Dec 2001 19:33:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12801.mail.yahoo.com (web12801.mail.yahoo.com [216.136.174.36]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBI0WxZ24676 for ; Mon, 17 Dec 2001 19:32:59 -0500 (EST) Message-ID: <20011218003258.6549.qmail@web12801.mail.yahoo.com> Received: from [207.219.118.250] by web12801.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 16:32:58 PST Date: Mon, 17 Dec 2001 16:32:58 -0800 (PST) From: Luben Tuikov Subject: Re: summary [iSCSI] To: iscsi MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk A message from me might have slipped to the iSCSI mailing list. Please ignore it as it is not intended for you. If you decide not to ignore it: There is a couple of ommisions copying the equations from my worksheets. You need not go after them as the original recipient has been notified -- I've corrected them. In general ignore the message! A clearer and typeset version will appear in the future for those interested. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 21:11:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23317 for ; Mon, 17 Dec 2001 21:11:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI1Sst27828 for ips-outgoing; Mon, 17 Dec 2001 20:28:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI1SqZ27821 for ; Mon, 17 Dec 2001 20:28:52 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA80182; Mon, 17 Dec 2001 20:26:00 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBI1RZm185856; Mon, 17 Dec 2001 18:27:35 -0700 Importance: Normal Subject: RE:iSCSI: Outboard Tunnel Mode To: "Lakshmi Ramasubramanian" Cc: , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 17 Dec 2001 17:26:46 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/17/2001 06:27:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk You need to parse the word Installation and Implementation more carefully. "Use" applies to the Installation locations choices. Implement is what the vendors must provide. We do not need to go over this any more! There is an IETF requirement for "MUST Implement, and Optional to USE". Debate is useless. Lets move on. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Lakshmi Ramasubramanian" @ece.cmu.edu on 12/17/2001 12:39:08 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, cc: Subject: RE:iSCSI: Outboard Tunnel Mode If it is NOT MUST USE, I guess most implementations would just choose "None" for security options. What is the point in saying MUST IMPLEMENT but is NOT MUST USE? -lakshmi -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 17, 2001 11:13 AM To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: Re: Outboard Tunnel Mode Installations can do what ever they want. The Security functions are must implement, NOT must use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Outboard Tunnel Mode Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Mon Dec 17 21:11:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23334 for ; Mon, 17 Dec 2001 21:11:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI1gth28647 for ips-outgoing; Mon, 17 Dec 2001 20:42:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI1gsZ28643 for ; Mon, 17 Dec 2001 20:42:54 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 8CBCB2063; Mon, 17 Dec 2001 18:42:53 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 23B62E9; Mon, 17 Dec 2001 18:42:53 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Dec 2001 18:42:52 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 18:42:52 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0097D494B@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: mbakke@cisco.com, ltuikov@yahoo.com Cc: ni1d@arrl.net, vince_cavanna@agilent.com, ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Mon, 17 Dec 2001 18:42:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, The text you suggest assumes a specific implementation. It is not suitable to go into the spec. The text describing the CRC in the spec should be in the mathematical form similar to what was used to describe the CRC in Ethernet. Describe: Formation of the message polynomial Division by G(x) to get the remainder Inversion of the remainder Don't talk about initiating registers which will be different for different forms of valid implementation. Pat -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Here is some text that I had suggested adding instead of (or in addition to) the mathematical description a while ago: The generator polynomial selected is evaluated in [Castagnioli93]. When using the CRC the CRC register must be initialized to all 1s (0xFFFFFFFF). Input bytes are processed with bit 7 being the most significant bit. Before transmission, the CRC bits must be reflected (bit 31 swapped with bit 0, bit 30 swapped with bit 1, etc.), and complemented. The CRC bytes must be transmitted in network order. Padding bytes, when present, in a segment covered by a CRC, should be set to 0 and are included in the CRC. Running the CRC-32C generator on an input stream that includes a valid CRC-32C will result in the constant remainder 0x1c2d19ed, (without being reversed and complemented). The above, plus the examples, have seem to work out just fine for the implementors. Getting the math right would be nice, but most of us implementors don't look at it anyway, and prefer the more practical description. If we are going to include the math, it has to match the examples. Anyway, my guess is that is what you are discussing; it was just disturbing to think that anything but the Ethernet + new poly was being considered, since that has been agreed on for a long time, and is being widely implemented. -- Mark Luben Tuikov wrote: > > --- Paul Koning wrote: > > Excerpt of message (sent 14 December 2001) by Luben > > > This is actually equivalent to XORing the first > > > 32 bits of the message with the magic constant as Vince > > > and I have shown. > > > > Are you saying that you believe the intent of the current > > spec is NOT > > the same as the Ethernet CRC, i.e., complement the first > > 32 bits, > > multiply by x^32, then divide by G(x)? > > In our profession we cannot talk about beliefs and > intentions, more so for documents, rfc, etc. > > If you show the current description of the CRC of the draft > to a mathematician, they will object to the same thing I've > objected. > > The reason is that they don't have the preconception about > what circuit is being used, and any such higher level > notions. > > All they would have and all I had was long division in Z_2. > (Actually Z_2[x] since we deal with polynomials.) > > Then I started from first principles of CRC, polydivision, > etc, etc. -- similarly to how Williams proceeds in his > paper, but my treatment was purely algebraic. > > The same applies to anyone looking at a description of an > algorithm. (An ``algorithm'' has a precise definition in > Computer Science.) > > In its current form the description of the algorithm to > compute the CRC in the iSCSI draft is not consistent, just > because there is an unspoken assumption that a SMD circuit > will be used. We cannot afford to do this in a definition > document, unless we refer explicitly to it. We cannot even > assume that a circuit will be used... > > Please also note that the Ethernet spec CRC algorithm, is > an optimized version of a basic > prefix-postfix-initialize-the- > CRC-register-to-some-constant algoritm. BUT as SMD it > operates on NON-AUGMENTED messages. FOR THAT REASON you > cannot say that we have to multiply M(x) by x^32!!! > > I.e. SMD algoritms like the one in the Ethernet spec, > operate on non-augmented messages, while simple Division > (D) algorithms operate on augmented messages. > > Any D can be optimized to SMD, but the constant has to be > changed. Also, prefixing a message is equivalent to loading > the CRC register with that prefix (WLG), but this is not so > for SMD. (elaborated below) > > Further more for any SMD there is an equivalent D, > including for the Ethernet spec SMD; and for any D there is > an equivalent SMD. > > > If that is your interpretation, then we absolutely MUST > > fix the spec, > > I'm quite sure that the intent of the spec is as I wrote > > it, i.e., > > Ethernet except for the generator. > > Probably it is. But lets not hasten here. > We can further generalize the explanation of the algorithm. > > > > If this is changed, then the message in its form: > > > M'(x) = x^32 M(x) + x^(32+n) I(x) > > > > > > yields to better optimizations as Vince and I have > > shown. > > > (see his circuits and worksheet4.pdf, which I posted > > > yesterday) > > > > > > I.e. the message is augmented (mult by x^32, aka > > postfixed) > > > and prefixed by 32 1's (aka CRC=32 1's). > > > > But that is NOT what the spec currently says. What you > > describe may > > be a fine CRC but it is not the one that's in the spec. > > Initializing > > the CRC register to all 1 is not the same as prefixing 32 > > 1 bits onto > > the message. > > It is, in a simple division, e.g. in D. This is clearly and > simply explained in the Williams paper. It is an equivalent > to a long division. > > Now, in D, if I initialize the CRC to all 1's and then do > division of M(x) by G(x), so that I catch 0's at the > beginning of the message, > > (which is equivalent to prefixing the message by 1's of the > number of the width of the CRC, and then do just simple > division,(CRC=0), since after so many clicks the CRC will > be loaded with the prefixing bits, and also 0/G(x) = 0) > > then I can find a constant which I can XOR to the first 32 > bits of the message and then perform the division, still in > D, with the same effect. In this particular case that > constant is the magic constant. (We are one step closer to > SMD...) > > (Now we jump to SMD, by means of worksheet4.pdf, Prefixing > part.) > > Now, in the Ethernet CRC spec, that constant is 32 1's, and > XORing 32 1's with the 32 MSb of the message is equivalent > to complementing them. > > BUT the Ethernet spec uses SMD, not D, so I claim that > there is an equivalent D, which for a suitable initial CRC > (also equivalent to prefixing the message with it) value > will yield IDENTICAL results as Ethernet SMD. > > Now using a bit of algebra similar to worksheet4.pdf which > I posted a couple of days ago and numerical methods > (solving a linear system of 33 unknowns) I have found such > a constant: > 0x2a26f826 which in simple division, D, will yield results > identical to SMD of Ethernet. > > So, here is an abstractization of the Ethernet CRC SMD, > explained in a simple, simple, simple division only way: > > TX: > 1. Mutliply the message, M(x), by x^32. > 2. Prefix the result of 1. with 0x2a26f826. > 3. Find the remainder of the result of 2. > 4. Complement that remainder and add it to the > result of 1. > 5. Send the result of 4. to the recipient. > > RX: (same as steps 1-3 in TX) > 1. Mutliply the message by x^32. > 2. Prefix the result of 1. with 0x2a26f826. > 3. Find the remainder of the result of 2. > > The result of 3 should be 0x1c2d19ed (the magic constant). > > Of course I've ommitted the mirroring of bytes for clarity > and brevity. It can be mentioned on the side, e.g. How to > build the message: mirror the bytes == to swapping the bits > inside the bytes, .... > > Also note that step 4 in TX, adding means exactly that, > since we already mult. by x^32, so the remainder will > nicely fit in the last 32 0 bits. > > Also note that step 2, can be made clearer: > let C(x), be the polynomial representation of 0x2a26f826. > Let n = deg G(x), k-1 = deg M(x) (there are k bits), then > step 2 is: > > 2. Add x^n x^k C(x) to the message M(x). > > Or we can swap step 1 and 2: > > 1. Add x^k C(x) to M(x). > 2. Multiply the result of 1. by x^n. > > I hope this makes things a bit clearer. > > So from this D specification above, I can derive SMD > exaclty as it is in the Ethernet spec. I'll include this > derivation in the paper -- it will be pure math, but in > english it goes like this: First we notice that after 32 > clicks the CRC register will contain only 32 1's XOR-ed > with the message, then we see that we can just load the crc > with ones and then kick one byte off the left xor it with > the next message bit... > > The above equivalence I've tested empirically. > > > What does "better optimizations" mean? > > See above. > > > > In an SMD, one would have to set the CRC to the magic > > > constant and then proceed as the algorithm indicates, > > > (this is identical to what you'd find in Ethernet, ... > > > > No it isn't. The Ethernet spec appendix C, and, more > > importantly, the > > formal definition of the CRC in the body of the spec, > > makes it quite > > clear that it isn't. I don't understand how you arrive > > at any other > > conclusion. > > I didn't mean identical as in the constant. I meant > identical in a way of equivalence of algorithms, that one > can be derived from the other, etc. See above. Or simpler > answer: Math. > > -l > > ===== > -- > > __________________________________________________ > Do You Yahoo!? > Check out Yahoo! Shopping and Yahoo! Auctions for all of > your unique holiday gifts! Buy at http://shopping.yahoo.com > or bid at http://auctions.yahoo.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Dec 17 21:16:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23413 for ; Mon, 17 Dec 2001 21:16:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI1h2D28655 for ips-outgoing; Mon, 17 Dec 2001 20:43:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI1h0Z28651 for ; Mon, 17 Dec 2001 20:43:00 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id C0AB9651; Mon, 17 Dec 2001 18:42:59 -0700 (MST) Received: from axcsbh2.cos.agilent.com (axcsbh2.cos.agilent.com [130.29.152.144]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 87717D5; Mon, 17 Dec 2001 18:42:59 -0700 (MST) Received: from 130.29.152.144 by axcsbh2.cos.agilent.com (InterScan E-Mail VirusWall NT); Mon, 17 Dec 2001 18:42:59 -0700 Received: by axcsbh2.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 18:42:59 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0097D494C@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Luben Tuikov , Paul Koning , VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Mon, 17 Dec 2001 18:42:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, The Ethernet spec does not use SMD, D or any other implementation. Here is the text from IEEE 802.3 on CRC computation: "A cyclic redundancy check (CRC)is used by the transmit and receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS)field contains a 4-octet (32-bit)cyclic redundancy check (CRC)value. This value is computed as a function of the contents of the source address, destination address, length, LLC data and pad (that is, all fields except the preamble, SFD, FCS, and extension). The encoding is de?ned by the following generating polynomial. G(x)=x^32 +x^26 +x^23 +x^22 +x^16 +x^12 +x^11 +x^10 +x^8 +x^7 +x^5 +x^4 +x^2 +x +1 Mathematically, the CRC value corresponding to a given frame is defned by the following procedure: a)The first 32 bits of the frame are complemented. b)The n bits of the frame are then considered to be the coefficients of a polynomial M(x)of degree n -1. (The first bit of the Destination Address field corresponds to the x^(n -1)term and the last bit of the data field corresponds to the x^0 term.) c)M(x)is multiplied by x^32 and divided by G(x), producing a remainder R(x)of degree 31. d)The coefficients of R(x)are considered to be a 32-bit sequence. e)The bit sequence is complemented and the result is the CRC. The 32 bits of the CRC value are placed in the frame check sequence field so that the x 31 term is the left-most bit of the first octet,and the x^0 term is the right most bit of the last octet. (The bits of the CRC are thus transmitted in the order x^31 ,x^30 ,...,x^1 ,x^0 .) See reference [B37 ]." Note that Ethernet MAC describes bit serial transmission of the packet so the final paragraph is a sensible way for Ethernet to describe the bit ordering of the CRC result in the transmitted packet. For iSCSI, one would describe the placement of the bits into the message format instead of transmission order. Pat -----Original Message----- From: Luben Tuikov [mailto:ltuikov@yahoo.com] Sent: Sunday, December 16, 2001 2:44 AM To: Paul Koning; VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI --- Paul Koning wrote: > Excerpt of message (sent 14 December 2001) by Luben > > This is actually equivalent to XORing the first > > 32 bits of the message with the magic constant as Vince > > and I have shown. > > Are you saying that you believe the intent of the current > spec is NOT > the same as the Ethernet CRC, i.e., complement the first > 32 bits, > multiply by x^32, then divide by G(x)? In our profession we cannot talk about beliefs and intentions, more so for documents, rfc, etc. If you show the current description of the CRC of the draft to a mathematician, they will object to the same thing I've objected. The reason is that they don't have the preconception about what circuit is being used, and any such higher level notions. All they would have and all I had was long division in Z_2. (Actually Z_2[x] since we deal with polynomials.) Then I started from first principles of CRC, polydivision, etc, etc. -- similarly to how Williams proceeds in his paper, but my treatment was purely algebraic. The same applies to anyone looking at a description of an algorithm. (An ``algorithm'' has a precise definition in Computer Science.) In its current form the description of the algorithm to compute the CRC in the iSCSI draft is not consistent, just because there is an unspoken assumption that a SMD circuit will be used. We cannot afford to do this in a definition document, unless we refer explicitly to it. We cannot even assume that a circuit will be used... Please also note that the Ethernet spec CRC algorithm, is an optimized version of a basic prefix-postfix-initialize-the- CRC-register-to-some-constant algoritm. BUT as SMD it operates on NON-AUGMENTED messages. FOR THAT REASON you cannot say that we have to multiply M(x) by x^32!!! I.e. SMD algoritms like the one in the Ethernet spec, operate on non-augmented messages, while simple Division (D) algorithms operate on augmented messages. Any D can be optimized to SMD, but the constant has to be changed. Also, prefixing a message is equivalent to loading the CRC register with that prefix (WLG), but this is not so for SMD. (elaborated below) Further more for any SMD there is an equivalent D, including for the Ethernet spec SMD; and for any D there is an equivalent SMD. > If that is your interpretation, then we absolutely MUST > fix the spec, > I'm quite sure that the intent of the spec is as I wrote > it, i.e., > Ethernet except for the generator. Probably it is. But lets not hasten here. We can further generalize the explanation of the algorithm. > > If this is changed, then the message in its form: > > M'(x) = x^32 M(x) + x^(32+n) I(x) > > > > yields to better optimizations as Vince and I have > shown. > > (see his circuits and worksheet4.pdf, which I posted > > yesterday) > > > > I.e. the message is augmented (mult by x^32, aka > postfixed) > > and prefixed by 32 1's (aka CRC=32 1's). > > But that is NOT what the spec currently says. What you > describe may > be a fine CRC but it is not the one that's in the spec. > Initializing > the CRC register to all 1 is not the same as prefixing 32 > 1 bits onto > the message. It is, in a simple division, e.g. in D. This is clearly and simply explained in the Williams paper. It is an equivalent to a long division. Now, in D, if I initialize the CRC to all 1's and then do division of M(x) by G(x), so that I catch 0's at the beginning of the message, (which is equivalent to prefixing the message by 1's of the number of the width of the CRC, and then do just simple division,(CRC=0), since after so many clicks the CRC will be loaded with the prefixing bits, and also 0/G(x) = 0) then I can find a constant which I can XOR to the first 32 bits of the message and then perform the division, still in D, with the same effect. In this particular case that constant is the magic constant. (We are one step closer to SMD...) (Now we jump to SMD, by means of worksheet4.pdf, Prefixing part.) Now, in the Ethernet CRC spec, that constant is 32 1's, and XORing 32 1's with the 32 MSb of the message is equivalent to complementing them. BUT the Ethernet spec uses SMD, not D, so I claim that there is an equivalent D, which for a suitable initial CRC (also equivalent to prefixing the message with it) value will yield IDENTICAL results as Ethernet SMD. Now using a bit of algebra similar to worksheet4.pdf which I posted a couple of days ago and numerical methods (solving a linear system of 33 unknowns) I have found such a constant: 0x2a26f826 which in simple division, D, will yield results identical to SMD of Ethernet. So, here is an abstractization of the Ethernet CRC SMD, explained in a simple, simple, simple division only way: TX: 1. Mutliply the message, M(x), by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. 4. Complement that remainder and add it to the result of 1. 5. Send the result of 4. to the recipient. RX: (same as steps 1-3 in TX) 1. Mutliply the message by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. The result of 3 should be 0x1c2d19ed (the magic constant). Of course I've ommitted the mirroring of bytes for clarity and brevity. It can be mentioned on the side, e.g. How to build the message: mirror the bytes == to swapping the bits inside the bytes, .... Also note that step 4 in TX, adding means exactly that, since we already mult. by x^32, so the remainder will nicely fit in the last 32 0 bits. Also note that step 2, can be made clearer: let C(x), be the polynomial representation of 0x2a26f826. Let n = deg G(x), k-1 = deg M(x) (there are k bits), then step 2 is: 2. Add x^n x^k C(x) to the message M(x). Or we can swap step 1 and 2: 1. Add x^k C(x) to M(x). 2. Multiply the result of 1. by x^n. I hope this makes things a bit clearer. So from this D specification above, I can derive SMD exaclty as it is in the Ethernet spec. I'll include this derivation in the paper -- it will be pure math, but in english it goes like this: First we notice that after 32 clicks the CRC register will contain only 32 1's XOR-ed with the message, then we see that we can just load the crc with ones and then kick one byte off the left xor it with the next message bit... The above equivalence I've tested empirically. > What does "better optimizations" mean? See above. > > In an SMD, one would have to set the CRC to the magic > > constant and then proceed as the algorithm indicates, > > (this is identical to what you'd find in Ethernet, ... > > No it isn't. The Ethernet spec appendix C, and, more > importantly, the > formal definition of the CRC in the body of the spec, > makes it quite > clear that it isn't. I don't understand how you arrive > at any other > conclusion. I didn't mean identical as in the constant. I meant identical in a way of equivalence of algorithms, that one can be derived from the other, etc. See above. Or simpler answer: Math. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 22:58:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26201 for ; Mon, 17 Dec 2001 22:58:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI3FMm03996 for ips-outgoing; Mon, 17 Dec 2001 22:15:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI3FGZ03991 for ; Mon, 17 Dec 2001 22:15:17 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id TAA14908; Mon, 17 Dec 2001 19:15:02 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id SAA16117; Mon, 17 Dec 2001 18:59:28 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Dec 2001 19:15:01 -0800 Message-ID: From: "Mukund, Shridhar" To: "'THALER,PAT (A-Roseville,ex1)'" , Luben Tuikov , Paul Koning , VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Mon, 17 Dec 2001 19:15:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, This thread seems to be going on and on. I think that Pat has hit the nail on the head. Ethernet Spec does describe CRC computation "precisely". Additionally, if we spec the order of bits in the iSCSI message format, we are done. All other "stuff" in the discussion is related to implementation and could go into papers "outside" the iSCSI spec - "The Art of Implementing iSCSI CRC" or something like that. I do not intend to ridicule, but some implementers may need help in this area while others may not. Anybody trying to realize a high-speed implementation will figure it out either thru' a primer in Galois Field, symbolic simulation, simple plain brute-force or they will go out and buy an IP. -Shridhar Mukund -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Monday, December 17, 2001 5:43 PM To: Luben Tuikov; Paul Koning; VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Luben, The Ethernet spec does not use SMD, D or any other implementation. Here is the text from IEEE 802.3 on CRC computation: "A cyclic redundancy check (CRC)is used by the transmit and receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS)field contains a 4-octet (32-bit)cyclic redundancy check (CRC)value. This value is computed as a function of the contents of the source address, destination address, length, LLC data and pad (that is, all fields except the preamble, SFD, FCS, and extension). The encoding is de?ned by the following generating polynomial. G(x)=x^32 +x^26 +x^23 +x^22 +x^16 +x^12 +x^11 +x^10 +x^8 +x^7 +x^5 +x^4 +x^2 +x +1 Mathematically, the CRC value corresponding to a given frame is defned by the following procedure: a)The first 32 bits of the frame are complemented. b)The n bits of the frame are then considered to be the coefficients of a polynomial M(x)of degree n -1. (The first bit of the Destination Address field corresponds to the x^(n -1)term and the last bit of the data field corresponds to the x^0 term.) c)M(x)is multiplied by x^32 and divided by G(x), producing a remainder R(x)of degree 31. d)The coefficients of R(x)are considered to be a 32-bit sequence. e)The bit sequence is complemented and the result is the CRC. The 32 bits of the CRC value are placed in the frame check sequence field so that the x 31 term is the left-most bit of the first octet,and the x^0 term is the right most bit of the last octet. (The bits of the CRC are thus transmitted in the order x^31 ,x^30 ,...,x^1 ,x^0 .) See reference [B37 ]." Note that Ethernet MAC describes bit serial transmission of the packet so the final paragraph is a sensible way for Ethernet to describe the bit ordering of the CRC result in the transmitted packet. For iSCSI, one would describe the placement of the bits into the message format instead of transmission order. Pat -----Original Message----- From: Luben Tuikov [mailto:ltuikov@yahoo.com] Sent: Sunday, December 16, 2001 2:44 AM To: Paul Koning; VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI --- Paul Koning wrote: > Excerpt of message (sent 14 December 2001) by Luben > > This is actually equivalent to XORing the first > > 32 bits of the message with the magic constant as Vince > > and I have shown. > > Are you saying that you believe the intent of the current > spec is NOT > the same as the Ethernet CRC, i.e., complement the first > 32 bits, > multiply by x^32, then divide by G(x)? In our profession we cannot talk about beliefs and intentions, more so for documents, rfc, etc. If you show the current description of the CRC of the draft to a mathematician, they will object to the same thing I've objected. The reason is that they don't have the preconception about what circuit is being used, and any such higher level notions. All they would have and all I had was long division in Z_2. (Actually Z_2[x] since we deal with polynomials.) Then I started from first principles of CRC, polydivision, etc, etc. -- similarly to how Williams proceeds in his paper, but my treatment was purely algebraic. The same applies to anyone looking at a description of an algorithm. (An ``algorithm'' has a precise definition in Computer Science.) In its current form the description of the algorithm to compute the CRC in the iSCSI draft is not consistent, just because there is an unspoken assumption that a SMD circuit will be used. We cannot afford to do this in a definition document, unless we refer explicitly to it. We cannot even assume that a circuit will be used... Please also note that the Ethernet spec CRC algorithm, is an optimized version of a basic prefix-postfix-initialize-the- CRC-register-to-some-constant algoritm. BUT as SMD it operates on NON-AUGMENTED messages. FOR THAT REASON you cannot say that we have to multiply M(x) by x^32!!! I.e. SMD algoritms like the one in the Ethernet spec, operate on non-augmented messages, while simple Division (D) algorithms operate on augmented messages. Any D can be optimized to SMD, but the constant has to be changed. Also, prefixing a message is equivalent to loading the CRC register with that prefix (WLG), but this is not so for SMD. (elaborated below) Further more for any SMD there is an equivalent D, including for the Ethernet spec SMD; and for any D there is an equivalent SMD. > If that is your interpretation, then we absolutely MUST > fix the spec, > I'm quite sure that the intent of the spec is as I wrote > it, i.e., > Ethernet except for the generator. Probably it is. But lets not hasten here. We can further generalize the explanation of the algorithm. > > If this is changed, then the message in its form: > > M'(x) = x^32 M(x) + x^(32+n) I(x) > > > > yields to better optimizations as Vince and I have > shown. > > (see his circuits and worksheet4.pdf, which I posted > > yesterday) > > > > I.e. the message is augmented (mult by x^32, aka > postfixed) > > and prefixed by 32 1's (aka CRC=32 1's). > > But that is NOT what the spec currently says. What you > describe may > be a fine CRC but it is not the one that's in the spec. > Initializing > the CRC register to all 1 is not the same as prefixing 32 > 1 bits onto > the message. It is, in a simple division, e.g. in D. This is clearly and simply explained in the Williams paper. It is an equivalent to a long division. Now, in D, if I initialize the CRC to all 1's and then do division of M(x) by G(x), so that I catch 0's at the beginning of the message, (which is equivalent to prefixing the message by 1's of the number of the width of the CRC, and then do just simple division,(CRC=0), since after so many clicks the CRC will be loaded with the prefixing bits, and also 0/G(x) = 0) then I can find a constant which I can XOR to the first 32 bits of the message and then perform the division, still in D, with the same effect. In this particular case that constant is the magic constant. (We are one step closer to SMD...) (Now we jump to SMD, by means of worksheet4.pdf, Prefixing part.) Now, in the Ethernet CRC spec, that constant is 32 1's, and XORing 32 1's with the 32 MSb of the message is equivalent to complementing them. BUT the Ethernet spec uses SMD, not D, so I claim that there is an equivalent D, which for a suitable initial CRC (also equivalent to prefixing the message with it) value will yield IDENTICAL results as Ethernet SMD. Now using a bit of algebra similar to worksheet4.pdf which I posted a couple of days ago and numerical methods (solving a linear system of 33 unknowns) I have found such a constant: 0x2a26f826 which in simple division, D, will yield results identical to SMD of Ethernet. So, here is an abstractization of the Ethernet CRC SMD, explained in a simple, simple, simple division only way: TX: 1. Mutliply the message, M(x), by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. 4. Complement that remainder and add it to the result of 1. 5. Send the result of 4. to the recipient. RX: (same as steps 1-3 in TX) 1. Mutliply the message by x^32. 2. Prefix the result of 1. with 0x2a26f826. 3. Find the remainder of the result of 2. The result of 3 should be 0x1c2d19ed (the magic constant). Of course I've ommitted the mirroring of bytes for clarity and brevity. It can be mentioned on the side, e.g. How to build the message: mirror the bytes == to swapping the bits inside the bytes, .... Also note that step 4 in TX, adding means exactly that, since we already mult. by x^32, so the remainder will nicely fit in the last 32 0 bits. Also note that step 2, can be made clearer: let C(x), be the polynomial representation of 0x2a26f826. Let n = deg G(x), k-1 = deg M(x) (there are k bits), then step 2 is: 2. Add x^n x^k C(x) to the message M(x). Or we can swap step 1 and 2: 1. Add x^k C(x) to M(x). 2. Multiply the result of 1. by x^n. I hope this makes things a bit clearer. So from this D specification above, I can derive SMD exaclty as it is in the Ethernet spec. I'll include this derivation in the paper -- it will be pure math, but in english it goes like this: First we notice that after 32 clicks the CRC register will contain only 32 1's XOR-ed with the message, then we see that we can just load the crc with ones and then kick one byte off the left xor it with the next message bit... The above equivalence I've tested empirically. > What does "better optimizations" mean? See above. > > In an SMD, one would have to set the CRC to the magic > > constant and then proceed as the algorithm indicates, > > (this is identical to what you'd find in Ethernet, ... > > No it isn't. The Ethernet spec appendix C, and, more > importantly, the > formal definition of the CRC in the body of the spec, > makes it quite > clear that it isn't. I don't understand how you arrive > at any other > conclusion. I didn't mean identical as in the constant. I meant identical in a way of equivalence of algorithms, that one can be derived from the other, etc. See above. Or simpler answer: Math. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Mon Dec 17 23:50:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26969 for ; Mon, 17 Dec 2001 23:50:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI440906715 for ips-outgoing; Mon, 17 Dec 2001 23:04:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12805.mail.yahoo.com (web12805.mail.yahoo.com [216.136.174.40]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBI43xZ06709 for ; Mon, 17 Dec 2001 23:03:59 -0500 (EST) Message-ID: <20011218040358.49454.qmail@web12805.mail.yahoo.com> Received: from [24.42.134.59] by web12805.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 20:03:58 PST Date: Mon, 17 Dec 2001 20:03:58 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "THALER,PAT \(A-Roseville,ex1\)" , Paul Koning , VICENTE V CAVANNA Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0097D494C@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Pat, First I refer you to this message by Vince. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08109.html Read it again, please. Then, let us think a bit. In Ethernet realm, we get bits off the wire, one at a time. A good CRC algorithm will have to be as strong as being able to produce the CRC at any time. That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived. I.e. in any moment in time, if I were to say STOP, I would have to be able to ``produce'' the right CRC. In other words, the algorithm needs NOT know in advance how many bits there are of the message. This eliminates the need to store the whole message and then ``multiply it by x^32''. I.e. I need only 32 + 1 bits of storage to compute the CRC of any length message, and I can do so as the bits are coming in from/to the wire, no need to store any bits. 32 for the CRC and 1 for the newly arrived bit. I don't need to know the previous or next bits. AND I will give you a CRC which is the same as if you HAD multiplied the message by x^32, and done division of the message, putting a suitable constant in the CRC register (equivalent to prepending the message by it and CRC=0) in D. You see, this is the whole point of SMD (Simultaneous Multiply and Divide) algorithm. It needs not multiply by x^32, or prepend the message. This multiplication of x^32 is needed only when we are in D (simple Division) algorithm. And this is where it is coming from. Lets see a simple example in the decimal system: let G(x) = 4 and M(x) = 7 (WLG). then R(x) = 7 modulo 4 = 3 But this is wrong, we should have computed the remainder of 70 modulo 4 which is 2. and then we'd send 72, which has remainder 0 modulo 4. And this is the SMD in Ethernet (WLG), if you feed it 7 it will tell you 2 (not 3), so that you can append 2 at the end to get 72 which has 0 remainder, etc. Once we have a 0 remainder I can add any value from 1 to 3 to get that value back when the thing is received and the remainder is computed e.g. 7 append (2+1) = 73. 73 modulo 4 = 1, etc. as per the spec. and this is where the magical constant comes from... And then the next digit comes along, say 5, now we have 75, but the algorithm gives 2 (rather than 75 modulo 4 = 3). And 2 is correct since 752 modulo 4 = 0... So you see, before quoting the document, please try to actually implement it, at least. And then see how that would fit into Ethernet. You can even implement it by hand, as arithmetic in Z_2 is quite easy (XOR). And the make things interesting make the message be one bit longer than G(x), i.e. 34 bits. Then you'll see how cumbersome is the multiplication by x^32. And that a better way has to exist. In fact SMD is what is actually implemented in Ethernet, and in a real circuit I bet you'd never see actual multiplication by x^32. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Tue Dec 18 01:11:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28499 for ; Tue, 18 Dec 2001 01:11:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI5SGi11080 for ips-outgoing; Tue, 18 Dec 2001 00:28:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12806.mail.yahoo.com (web12806.mail.yahoo.com [216.136.174.41]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBI5SDZ11073 for ; Tue, 18 Dec 2001 00:28:13 -0500 (EST) Message-ID: <20011218052807.89279.qmail@web12806.mail.yahoo.com> Received: from [24.42.134.59] by web12806.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 21:28:07 PST Date: Mon, 17 Dec 2001 21:28:07 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: "Mukund, Shridhar" , "'THALER,PAT \(A-Roseville,ex1\)'" , Paul Koning , VICENTE V CAVANNA Cc: ips@ece.cmu.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- "Mukund, Shridhar" wrote: > > This thread seems to be going on and on. I think that Pat > has hit the nail on the head. Ethernet Spec does describe > CRC > computation "precisely". Certainly. Then lets leave it at that. We'll have to probably fix the examples in the draft... -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Tue Dec 18 02:51:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15338 for ; Tue, 18 Dec 2001 02:51:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBI7DPi16440 for ips-outgoing; Tue, 18 Dec 2001 02:13:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtv01ex01.mindtree.com ([202.56.255.246]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBI7DLZ16426 for ; Tue, 18 Dec 2001 02:13:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: sessions and connections Date: Tue, 18 Dec 2001 12:42:00 +0530 Message-ID: Thread-Topic: sessions and connections Thread-Index: AcGHk0l1YH4gM0XlTcmZIpRFMvvWOA== From: "Murali S" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBI7DNZ16432 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, do we have to do a login for each connection in a session? If not where do we generate a CID for each connection. Draft says that CID should be generated during login phase. -Murali From owner-ips@ece.cmu.edu Tue Dec 18 10:25:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19868 for ; Tue, 18 Dec 2001 10:25:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIEVl920410 for ips-outgoing; Tue, 18 Dec 2001 09:31:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIEViZ20397 for ; Tue, 18 Dec 2001 09:31:44 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A1C211DC00BC; Tue, 18 Dec 2001 08:25:06 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A2F462400D6; Tue, 18 Dec 2001 08:30:12 -0600 From: "Eddy Quicksall" To: "'John Hufferd'" , "'Julian Satran'" Cc: Subject: RE: iSCSI: Checking the I bit Date: Tue, 18 Dec 2001 09:30:34 -0500 Message-ID: <000401c187d0$8f53b6a0$0102a8c0@eddydesktop> 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This has become three issues: 1) The issue of a device checking to see if the other device is compliant (the "reserved I bit" happens to fall into this category). 2) The issue of a "1" bit being called a reserved bit 3) The issue of forcing the "I" bit to be 1 for all responses What I am most interested in is issue 1. Because that can be an unnecessary performance hit (if there are too many things to check) and a nuisance. This should be an implementation issue. For issue 2, I now have mixed emotions. You guys have read many more documents than I have. But I have always assumed that reserved fields are set to 0. If it needs to be a 1, why not just say that? For issue 3, I also wonder why it needs to be a 1. We should probably explain that in the spec so the need is not lost. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, December 14, 2001 7:17 PM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Checking the I bit OK, Except for the fact that Eddy pointed out to me 3.2.1.1 does call it the I bit that is always set to 1 for responses (and Async Msgs by the way), I think my basic statement is still true -- It is not a reserved bit. So the UNH statements really does not apply. And if it is a bit that is always set to one but does not need to be checked, why is it set to one? Why not set it to zero and mark it reserved, so that the UNH statement does apply, and then we can use it for something else in the future. The bit seems redundant, why do we need it to be set? Does this have something to do about with expediting the handling of responses in a target which is working on extended copy commands? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 12/14/2001 09:15:29 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Checking the I bit I think that Eddy's suggestion to state that parties have to check only what they have to check is valuable and we may want to include a general statement about that. Julo John Hufferd Sent by: To: owner-ips@ece.c "Eddy mu.edu Quicksall" cc: "ips@ece. cmu. edu \(E-mail\)" Subject: Re: iSCSI: Checking the I bit Eddy, Technically, the In coming PDUs all have Byte 0, Bit 6, set to one. It is not identified as the I (Immediate) bit. And it is NOT reserved. So the Statement from the UNH Plugfest does not apply. I think your point is that if all the incoming PDUs have that bit set, why do we need to set the bit, and why do we need to check it. I think this bit has evolved over time, and perhaps up to now no one has noticed. If every incoming PDU has the bit set, we may not need the bit to be set, and perhaps it should be reserved, thereby not requiring the check. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/13/2001 03:26:18 AM Sent by: owner-ips@ece.cmu.edu To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: Checking the I bit Is it necessary for the initiator to check the I bit in every response? If an initiator does not need it, then I don't want to take the extra time to check it. I think this is consistent with the thinking of all attendees of the UNH Plug Fest because the report from UNH IOL was that "all companies failed that test". I would like to propose adding some wording to 3.2.1.1 similar to "It is not necessary to check this bit for 1 if the implementation in the initiator does not need its use". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Dec 18 11:14:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20696 for ; Tue, 18 Dec 2001 11:14:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFRhH24547 for ips-outgoing; Tue, 18 Dec 2001 10:27:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFRgZ24543 for ; Tue, 18 Dec 2001 10:27:42 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id AEDC14A900BC; Tue, 18 Dec 2001 09:21:00 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A0077640154; Tue, 18 Dec 2001 09:25:59 -0600 From: "Eddy Quicksall" To: "'Julian Satran'" , Subject: RE: iSCSI: scope of keys Date: Tue, 18 Dec 2001 10:25:44 -0500 Message-ID: <000501c187d8$43e96720$0102a8c0@eddydesktop> 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Tue Dec 18 11:14:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20707 for ; Tue, 18 Dec 2001 11:14:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFWMC24950 for ips-outgoing; Tue, 18 Dec 2001 10:32:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFWKZ24945 for ; Tue, 18 Dec 2001 10:32:20 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:32:14 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293728D@CORPMX14> From: Black_David@emc.com To: nramas@windows.microsoft.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Outboard Tunnel Mode Date: Tue, 18 Dec 2001 10:20:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk So that when a situation arises in which the security is needed, it's available to be used. It's usually easy to disable something that is present but not needed, but it's much harder to enable something that is needed but present. As John indicated earlier, this is a closed issue based on instructions from the IESG. Comments questioning the IESG's wisdom should be sent to the IESG or (preferably) /dev/null. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > Sent: Monday, December 17, 2001 3:39 PM > To: John Hufferd; VAHUJA@aol.com > Cc: ips@ece.cmu.edu > Subject: RE:iSCSI: Outboard Tunnel Mode > > > If it is NOT MUST USE, I guess most implementations would just > choose "None" for security options. What is the point in saying > MUST IMPLEMENT but is NOT MUST USE? > > -lakshmi > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Monday, December 17, 2001 11:13 AM > To: VAHUJA@aol.com > Cc: ips@ece.cmu.edu > Subject: Re: Outboard Tunnel Mode > > > > Installations can do what ever they want. The Security functions are > must implement, NOT must use. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home > Office (408) 997-6136, Cell: (408) 499-9702 Internet address: > hufferd@us.ibm.com > > > VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: Outboard Tunnel Mode > > > > Folks, > > May be I missed something in SLC meeting. I can expect several > implementations of iSCSI not include any security.Reason - I can see > that customers would often rely on the company's existing > VPNs (outboard > Router > etc) to protect their data (storage or otherwise) over IP > networks. From > a CIO's viewpoint, this approach may make more sense than > extending yet > another layer of IPSec into its servers just for storage data. > > It is not clear to me from the standard if it will be a > non-compliance > of iSCSI standard. If so, we may potentially have many > non-compliances. > > > From owner-ips@ece.cmu.edu Tue Dec 18 11:17:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20778 for ; Tue, 18 Dec 2001 11:17:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFTlt24692 for ips-outgoing; Tue, 18 Dec 2001 10:29:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFTjZ24682 for ; Tue, 18 Dec 2001 10:29:45 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:32:14 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293728C@CORPMX14> From: Black_David@emc.com To: VAHUJA@aol.com, ips@ece.cmu.edu Subject: RE: Outboard Tunnel Mode Date: Tue, 18 Dec 2001 10:18:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The iSCSI standard will REQUIRE implementation of the appropriate portions of IPsec. An iSCSI implementation that omits all of IPsec will not comply with the standard. It really is that simple. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: VAHUJA@aol.com [mailto:VAHUJA@aol.com] > Sent: Monday, December 17, 2001 1:09 PM > To: ips@ece.cmu.edu > Subject: Outboard Tunnel Mode > > > Folks, > > May be I missed something in SLC meeting. I can expect several > implementations of iSCSI not include any security.Reason - I > can see that > customers would often rely on the company's existing VPNs > (outboard Router > etc) to protect their data (storage or otherwise) over IP > networks. From a > CIO's viewpoint, this approach may make more sense than > extending yet another > layer of IPSec into its servers just for storage data. > > It is not clear to me from the standard if it will be a > non-compliance of > iSCSI standard. If so, we may potentially have many non-compliances. > From owner-ips@ece.cmu.edu Tue Dec 18 11:18:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20791 for ; Tue, 18 Dec 2001 11:18:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFcM925401 for ips-outgoing; Tue, 18 Dec 2001 10:38:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFcKZ25395 for ; Tue, 18 Dec 2001 10:38:21 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:40:51 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293728F@CORPMX14> From: Black_David@emc.com To: nramas@windows.microsoft.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Outboard Tunnel Mode Date: Tue, 18 Dec 2001 10:26:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Trying again with an important correction: So that when a situation arises in which the security is needed, it's available to be used. It's usually easy to disable something that is present but not needed, but it's much harder to enable something that is needed but **not** present. As John indicated earlier, this is a closed issue based on instructions from the IESG. Comments questioning the IESG's wisdom should be sent to the IESG or (preferably) /dev/null. Thanks, --David > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, December 18, 2001 10:21 AM > To: nramas@windows.microsoft.com > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI: Outboard Tunnel Mode > > > So that when a situation arises in which the security is needed, > it's available to be used. It's usually easy to disable something > that is present but not needed, but it's much harder to enable > something that is needed but present. As John indicated earlier, > this is a closed issue based on instructions from the IESG. > Comments questioning the IESG's wisdom should be sent to the IESG > or (preferably) /dev/null. > > Thanks, > --David > > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 435-1000 FAX: +1 (508) 497-8500 > black_david@emc.com Mobile: +1 (978) 394-7754 > --------------------------------------------------- > > > -----Original Message----- > > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com] > > Sent: Monday, December 17, 2001 3:39 PM > > To: John Hufferd; VAHUJA@aol.com > > Cc: ips@ece.cmu.edu > > Subject: RE:iSCSI: Outboard Tunnel Mode > > > > > > If it is NOT MUST USE, I guess most implementations would just > > choose "None" for security options. What is the point in saying > > MUST IMPLEMENT but is NOT MUST USE? > > > > -lakshmi > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Monday, December 17, 2001 11:13 AM > > To: VAHUJA@aol.com > > Cc: ips@ece.cmu.edu > > Subject: Re: Outboard Tunnel Mode > > > > > > > > Installations can do what ever they want. The Security > functions are > > must implement, NOT must use. > > > > . > > . > > . > > John L. Hufferd > > Senior Technical Staff Member (STSM) > > IBM/SSG San Jose Ca > > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) > 904-4688 Home > > Office (408) 997-6136, Cell: (408) 499-9702 Internet address: > > hufferd@us.ibm.com > > > > > > VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Outboard Tunnel Mode > > > > > > > > Folks, > > > > May be I missed something in SLC meeting. I can expect several > > implementations of iSCSI not include any security.Reason - I can see > > that customers would often rely on the company's existing > > VPNs (outboard > > Router > > etc) to protect their data (storage or otherwise) over IP > > networks. From > > a CIO's viewpoint, this approach may make more sense than > > extending yet > > another layer of IPSec into its servers just for storage data. > > > > It is not clear to me from the standard if it will be a > > non-compliance > > of iSCSI standard. If so, we may potentially have many > > non-compliances. > > > > > > > From owner-ips@ece.cmu.edu Tue Dec 18 11:18:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20803 for ; Tue, 18 Dec 2001 11:18:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFR6e24496 for ips-outgoing; Tue, 18 Dec 2001 10:27:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFR5Z24490 for ; Tue, 18 Dec 2001 10:27:05 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:22:45 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293728B@CORPMX14> From: Black_David@emc.com To: muralis@mindtree.com, ips@ece.cmu.edu Subject: RE: sessions and connections Date: Tue, 18 Dec 2001 10:15:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes, you must do a login for each connection. --David > -----Original Message----- > From: Murali S [mailto:muralis@mindtree.com] > Sent: Tuesday, December 18, 2001 2:12 AM > To: ips@ece.cmu.edu > Subject: sessions and connections > > > Hi all, > > do we have to do a login for each connection in a > session? If not > where do we generate a CID for each connection. > Draft says that CID should be generated during login phase. > > -Murali > From owner-ips@ece.cmu.edu Tue Dec 18 11:19:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20828 for ; Tue, 18 Dec 2001 11:19:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIFajZ25279 for ips-outgoing; Tue, 18 Dec 2001 10:36:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from maho3msx2.isus.emc.com (maho3msx2.isus.emc.com [128.221.11.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIFaiZ25273 for ; Tue, 18 Dec 2001 10:36:44 -0500 (EST) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 10:36:38 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E0293728E@CORPMX14> From: Black_David@emc.com To: dfhepner@us.ibm.com Cc: ips@ece.cmu.edu Subject: RE: Outboard Tunnel Mode Date: Tue, 18 Dec 2001 10:25:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The assumption that all (or even the most serious) security threats originate from outside the firewall is incorrect, and the analogy with motorcycle helmet laws is badly flawed. Further discussion on this issue is discouraged. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: David F Hepner [mailto:dfhepner@us.ibm.com] > Sent: Monday, December 17, 2001 5:06 PM > To: John Hufferd > Cc: VAHUJA@aol.com; ips@ece.cmu.edu > Subject: Re: Outboard Tunnel Mode > > > > With most corporations security at the corporate firewall is a MUST no > mater what is done at the machine I/O. With Security > functions a MUST for > iSCSI, an installation will pay for security twice and only > use it once. > Why pay for security at every I/O when the corporation > mandates it at the > edge? > This seems like motorcycle helmet laws. Why mandate something that a > reasonable person would do any way? > > David > > ------------------------------------------------------ > David F. Hepner WA7UHT > dfhepner@us.ibm.com > IBM SSG San Jose, CA > (408) 256-4981 Fax (408) 256-6214 > Tie Line 8-276-4981 > ----------------------------------------------------- > > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 12/17/2001 11:13:00 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: VAHUJA@aol.com > cc: ips@ece.cmu.edu > Subject: Re: Outboard Tunnel Mode > > > > > Installations can do what ever they want. The Security > functions are must > implement, NOT must use. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: Outboard Tunnel Mode > > > > Folks, > > May be I missed something in SLC meeting. I can expect several > implementations of iSCSI not include any security.Reason - I > can see that > customers would often rely on the company's existing VPNs > (outboard Router > etc) to protect their data (storage or otherwise) over IP > networks. From a > CIO's viewpoint, this approach may make more sense than extending yet > another > layer of IPSec into its servers just for storage data. > > It is not clear to me from the standard if it will be a > non-compliance of > iSCSI standard. If so, we may potentially have many non-compliances. > > > > > > > From owner-ips@ece.cmu.edu Tue Dec 18 13:19:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23364 for ; Tue, 18 Dec 2001 13:19:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIGt5x01830 for ips-outgoing; Tue, 18 Dec 2001 11:55:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIGt3Z01822 for ; Tue, 18 Dec 2001 11:55:03 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A370275A00A0; Tue, 18 Dec 2001 10:48:57 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A4C37D80144; Tue, 18 Dec 2001 10:54:27 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: text spanning Date: Tue, 18 Dec 2001 11:54:54 -0500 Message-ID: <000701c187e4$b9329e00$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C187BA.D05C9600" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C187BA.D05C9600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Section 3.10.4 says: A Key=value pair can span Text request or response boundaries (i.e. a key=value pair can start in one PDU and continue on the next). This paragraph says that code must be able to process every text request/response in such a way as to accommodate really silly possibilities (like “ke” in one PDU and “y=value” in the next). This could be a bit of a burden for low end controllers. I don’t think that was the intent of the statement. Can we think of better wording to cover the needed case without impacting the simple case? Eddy _____ ------=_NextPart_000_0008_01C187BA.D05C9600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 3.10.4 says:

 

 A Key=3Dvalue pair can span = Text request or response boundaries (i.e. a

 key=3Dvalue pair can start in = one PDU and continue on the next).

 

This paragraph says that code must be able to process every text = request/response in such a way as to accommodate really silly possibilities (like = “ke” in one PDU and “y=3Dvalue” in the next). This could be a bit of a = burden for low end controllers.

 

I don’t think that was the intent of the = statement.

 

Can we think of better wording to cover the needed case without impacting = the simple case?

 

Eddy

------=_NextPart_000_0008_01C187BA.D05C9600-- From owner-ips@ece.cmu.edu Tue Dec 18 16:15:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26880 for ; Tue, 18 Dec 2001 16:15:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIKMUa16590 for ips-outgoing; Tue, 18 Dec 2001 15:22:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBIKMSZ16586 for ; Tue, 18 Dec 2001 15:22:29 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBIKM8k08284; Tue, 18 Dec 2001 15:22:08 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBIKM8L19082; Tue, 18 Dec 2001 15:22:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.42352.379920.909062@pkoning.dev.equallogic.com> Date: Tue, 18 Dec 2001 15:22:08 -0500 (EST) From: Paul Koning To: Eddy_Quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Checking the I bit References: <000401c187d0$8f53b6a0$0102a8c0@eddydesktop> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Eddy" == Eddy Quicksall writes: Eddy> This has become three issues: 1) The issue of a device checking Eddy> to see if the other device is compliant (the "reserved I bit" Eddy> happens to fall into this category). 2) The issue of a "1" bit Eddy> being called a reserved bit 3) The issue of forcing the "I" bit Eddy> to be 1 for all responses Eddy> What I am most interested in is issue 1. Because that can be an Eddy> unnecessary performance hit (if there are too many things to Eddy> check) and a nuisance. This should be an implementation issue. We had a discussion about this a few weeks ago on the list. I believe the outcome was that checking reserved bits is, minimally, not needed, and in fact either disallowed entirely or at the very least discouraged. (I.e., it is either "MUST NOT check" or "SHOULD NOT check".) paul From owner-ips@ece.cmu.edu Tue Dec 18 16:18:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27045 for ; Tue, 18 Dec 2001 16:18:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIKFx116122 for ips-outgoing; Tue, 18 Dec 2001 15:15:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cygnus.equallogic.com (cygnus.equallogic.com [65.170.102.10]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBIKFvZ16117 for ; Tue, 18 Dec 2001 15:15:57 -0500 (EST) Received: from deneb.dev.equallogic.com (localhost.localdomain [127.0.0.1]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id fBIKFkK08256; Tue, 18 Dec 2001 15:15:46 -0500 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.6/8.11.2) with SMTP id fBIKFj018773; Tue, 18 Dec 2001 15:15:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15391.41969.32683.999529@pkoning.dev.equallogic.com> Date: Tue, 18 Dec 2001 15:15:45 -0500 (EST) From: Paul Koning To: Shridhar_Mukund@adaptec.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI References: X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Mukund," == Mukund, Shridhar writes: Mukund,> Folks, Mukund,> This thread seems to be going on and on. I think that Pat Mukund,> has hit the nail on the head. Ethernet Spec does describe Mukund,> CRC computation "precisely". Additionally, if we spec the Mukund,> order of bits in the iSCSI message format, we are done. That's exactly what I did in my message of last Friday. Do you agree, or do you have comments on how to make it do the job? paul From owner-ips@ece.cmu.edu Tue Dec 18 17:27:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28001 for ; Tue, 18 Dec 2001 17:27:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBILWtD21476 for ips-outgoing; Tue, 18 Dec 2001 16:32:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBILWrZ21468 for ; Tue, 18 Dec 2001 16:32:53 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 6FFC3C0E; Tue, 18 Dec 2001 14:32:45 -0700 (MST) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 8502B584; Tue, 18 Dec 2001 14:32:42 -0700 (MST) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 18 Dec 2001 14:32:41 -0700 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 14:32:41 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0097D4B04@axcs04.cos.agilent.com> From: pat_thaler@agilent.com To: ltuikov@yahoo.com, pat_thaler@agilent.com, ni1d@arrl.net, vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Tue, 18 Dec 2001 14:32:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, I have a pretty fair idea of the constraints on Ethernet implementations having worked on Ethernet implementations and standards for over 15 years. The issue is not whether a certain implementation is common or not. It isn't the merits of one implementation method over another. The point is that whereever possible (that is wherever it doesn't damage interoperability) standards should be written in terms of results - that is in terms of the behavior of the black box at its interfaces. Any implementation that produces that behavior is valid and the implementor should be left with the freedom to use whatever implementation method fits the implementation's circumstances. I agree with the analysis of D and SMD. SMD is a widely used implementation method. However, that is irrelavent to what should go into the standard. By the way, there is an error in your statement below with respect to Ethernet behavior: "A good CRC algorithm will have to be as strong as being able to produce the CRC at any time. That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived. I.e. in any moment in time, if I were to say STOP, I would have to be able to ``produce'' the right CRC." Actually and Ethernet implementation is specifically required not to behave this way. If you will refer to IEEE 802.3 4.2.9 procedure ReceiveLinkMgmt processes the frame before function ReceiveDataDecap checks the CRC (an interaction controlled by receiveSucceeding). ReceiveLinkManagement truncates the frame to an octet boundary. This was done to be tolerant of some untidy physical layer implementations that add a few "dribble bits" to frames (sad but true). The CRC is the last 4 full octets of the frame rather than the last 32 bits - a difference that only matters when there are dribble bits. If an implementation calculated the CRC as each bit arrived, it would have to back out the effect of the dribble bits to check the CRC on an octet boundary which would be inconvenient. Most implementations I am aware of calculate the CRC on a byte or multi-byte parallel basis rather than a bit at a time. Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:ltuikov@yahoo.com] Sent: Monday, December 17, 2001 8:04 PM To: THALER,PAT (A-Roseville,ex1); Paul Koning; VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Pat, First I refer you to this message by Vince. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08109.html Read it again, please. Then, let us think a bit. In Ethernet realm, we get bits off the wire, one at a time. A good CRC algorithm will have to be as strong as being able to produce the CRC at any time. That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived. I.e. in any moment in time, if I were to say STOP, I would have to be able to ``produce'' the right CRC. In other words, the algorithm needs NOT know in advance how many bits there are of the message. This eliminates the need to store the whole message and then ``multiply it by x^32''. I.e. I need only 32 + 1 bits of storage to compute the CRC of any length message, and I can do so as the bits are coming in from/to the wire, no need to store any bits. 32 for the CRC and 1 for the newly arrived bit. I don't need to know the previous or next bits. AND I will give you a CRC which is the same as if you HAD multiplied the message by x^32, and done division of the message, putting a suitable constant in the CRC register (equivalent to prepending the message by it and CRC=0) in D. You see, this is the whole point of SMD (Simultaneous Multiply and Divide) algorithm. It needs not multiply by x^32, or prepend the message. This multiplication of x^32 is needed only when we are in D (simple Division) algorithm. And this is where it is coming from. Lets see a simple example in the decimal system: let G(x) = 4 and M(x) = 7 (WLG). then R(x) = 7 modulo 4 = 3 But this is wrong, we should have computed the remainder of 70 modulo 4 which is 2. and then we'd send 72, which has remainder 0 modulo 4. And this is the SMD in Ethernet (WLG), if you feed it 7 it will tell you 2 (not 3), so that you can append 2 at the end to get 72 which has 0 remainder, etc. Once we have a 0 remainder I can add any value from 1 to 3 to get that value back when the thing is received and the remainder is computed e.g. 7 append (2+1) = 73. 73 modulo 4 = 1, etc. as per the spec. and this is where the magical constant comes from... And then the next digit comes along, say 5, now we have 75, but the algorithm gives 2 (rather than 75 modulo 4 = 3). And 2 is correct since 752 modulo 4 = 0... So you see, before quoting the document, please try to actually implement it, at least. And then see how that would fit into Ethernet. You can even implement it by hand, as arithmetic in Z_2 is quite easy (XOR). And the make things interesting make the message be one bit longer than G(x), i.e. 34 bits. Then you'll see how cumbersome is the multiplication by x^32. And that a better way has to exist. In fact SMD is what is actually implemented in Ethernet, and in a real circuit I bet you'd never see actual multiplication by x^32. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Tue Dec 18 17:31:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28094 for ; Tue, 18 Dec 2001 17:31:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBILSbc21106 for ips-outgoing; Tue, 18 Dec 2001 16:28:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBILSWZ21094 for ; Tue, 18 Dec 2001 16:28:32 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A392125200B8; Tue, 18 Dec 2001 15:22:26 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A4C1411E0148; Tue, 18 Dec 2001 15:27:29 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: first CmdSN clearification Date: Tue, 18 Dec 2001 16:27:06 -0500 Message-ID: <000f01c1880a$bedadef0$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C187E0.D604D6F0" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C187E0.D604D6F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 3.12.9 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). The target MUST use the value presented with the first login request. Why does it spell out “the first non-immediate command”? It would seem like it should just say “the first command … “. Because immediate commands always get the next CmdSN anyway. Eddy ------=_NextPart_000_0010_01C187E0.D604D6F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 3.12.9 CmdSN =

        

  CmdSN is either the initial command sequence number of = a session (for

  the first Login request of a = session - the "leading" login) or the

  command sequence number in the = command stream (e.g., if the leading

  login carries the CmdSN 123 = all other Login requests carry the CmdSN

  123 and the first = non-immediate command also carries the CmdSN 123).  =

 

  The target MUST use the value = presented with the first login request.

 =

 

Why does it spell out “the first non-immediate command”? It = would seem like it should just say “the first command … “. Because = immediate commands always get the next CmdSN anyway.

 

Eddy<= /span>

 

------=_NextPart_000_0010_01C187E0.D604D6F0-- From owner-ips@ece.cmu.edu Tue Dec 18 18:09:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28852 for ; Tue, 18 Dec 2001 18:09:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIMLQI24917 for ips-outgoing; Tue, 18 Dec 2001 17:21:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBIMLOZ24910 for ; Tue, 18 Dec 2001 17:21:24 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 4F8257DA; Tue, 18 Dec 2001 15:21:23 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 281A3501; Tue, 18 Dec 2001 15:21:23 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 15:21:23 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0097D4B2D@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Paul Koning , ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Tue, 18 Dec 2001 15:21:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I like your text. I would include the note about Ethernet. My preference would be to not include the implementation notes though I don't find anything terribly objectionable in them. It would be nice to include a reference to additional informative information on CRC generation particularly since some references out in the world seem to be misleading. Regards, Pat -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Friday, December 14, 2001 12:18 PM To: ltuikov@yahoo.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI I guess the problem with the spec is that it is a confusing mix of pieces of the mathematical definition and pieces of description from a specific (and unstated) implementation. Ok, so let me propose specific replacement text. This is for Appendix D, starting at the top of page 193 in the -09 rev of the spec. ---------------- The generator polynomial for the CRC is x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + x^18 +x^14 + x+13 + x+11 + x^10 + x^9 + x^8 +x^6 + 1. The CRC value for a PDU is defined mathematically as follows: 1. The first 32 bits of the PDU are complemented. 2. The N bits of the PDU are then considered to be coefficients of a polynomial M(x) of degree N-1. Bit 0 of byte 0, i.e., the low order bit of the high order byte of the first word of the PDU, corresponds to the X^(N-1) term of this polynomial, and the high order bit of the last byte of the PDU corresponds to the x^0 term. Note that any pad bytes for the PDU are included. 3. M(x) is multiplied by x^32, and divided by G(x), producing a remainder R(x) of degree < 32. 4. The coefficients of R(x) are considered to be a 32-bit sequence. 5. This bit sequence is complemented and the result is the CRC. The CRC is trannsmitted with the high order bit (corresponding to the x^31 term of R(x)) in the low order bit of the first byte transmitted, and the low order bit (corresponding to the x^0 term of R(x)) in the high order bit of the fourth byte transmitted. ---------------- This text is inspired by the text in the Ethernet spec, with some wording changes needed for the iSCSI context. I believe this is a precise definition of what is needed. For additional information, more text could be included. For example: ---------------- The above algorithm is exactly that used in the Ethernet/802.3 LAN, with the exception of the choice of generator polynomial. ---------------- And perhaps a note on implementation: ---------------- The above algorithm may be efficiently implemented in a variety of ways, such as linear feedback shift registers, table lookup, etc. ---------------- Finally, we could capture the "magic constant" receive algorithm as follows: ---------------- Implementation of the CRC32C checking for PDU reception can be done in several ways. One approach is to calculate the CRC over the PDU not including the CRC field, and compare that with the received CRC. If the two values are equal, the digest is considered valid. Another approach is to perform the above algorithm over the entire received PDU, including the CRC field. With that approach, a valid digest results in R(x) having the value x^28 + x^27 + x^26 + x^21 + x^19 + x^18 +x^16 + x^12 + x^11 + x^8 + x^7 + x^6 + x^5 + x^3 + x^2 + 1, i.e., the value of the 32-bit sequence obtained in step 4 is 0x1c2d19ed. ---------------- Following Pat Thaler's comments, I am not proposing any more text on implementation approaches. Both the table based approaches and the LFSR approach can be covered by references to literature, though admittedly some of the references may not be all that easy to acquire. So my proposal is to replace the text on page 193 up to the "Proprietary algorithms MAY also..." with the four pieces given above. If people don't like the later pieces, then I'll fall back to proposing just the first chunk of text (the formal definition of the CRC) as replacement for the current text. paul From owner-ips@ece.cmu.edu Tue Dec 18 18:55:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00409 for ; Tue, 18 Dec 2001 18:55:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBIMv7A27249 for ips-outgoing; Tue, 18 Dec 2001 17:57:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web12807.mail.yahoo.com (web12807.mail.yahoo.com [216.136.174.42]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id fBIMv4Z27243 for ; Tue, 18 Dec 2001 17:57:04 -0500 (EST) Message-ID: <20011218225703.15883.qmail@web12807.mail.yahoo.com> Received: from [207.219.118.250] by web12807.mail.yahoo.com via HTTP; Tue, 18 Dec 2001 14:57:03 PST Date: Tue, 18 Dec 2001 14:57:03 -0800 (PST) From: Luben Tuikov Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: pat_thaler@agilent.com, ni1d@arrl.net, vince_cavanna@agilent.com Cc: ips@ece.cmu.edu In-Reply-To: <1BEBA5E8600DD4119A50009027AF54A0097D4B04@axcs04.cos.agilent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk --- pat_thaler@agilent.com wrote: > > method. However, that is irrelavent to what should go > into the standard. I never posted a message of the sort: ``Here guys put this into the draft: ...''. And I don't want to post one. All I've been doing is mathematical analysis of the algorithm(s). And all I've been looking for is an unambiguious definition. > By the way, there is an error in your statement below > with respect to > Ethernet behavior: "A good CRC algorithm will have to be > as strong as being > able to produce the CRC at any time. That is, it has to > have the correct CRC _after_ _each_ _bit_ has arrived. > > I.e. in any moment in time, if I were to say STOP, I > would > have to be able to ``produce'' the right CRC." Read the sentence again please: indefinite article ``a''. This means ``any'' CRC algorithm. No there is no error. > Actually and Ethernet implementation is specifically > required not to behave > this way. If you will refer to IEEE 802.3 4.2.9 procedure > ReceiveLinkMgmt ... [cut] Don't you think I can read this myself? Then again: indefinite article ``a''. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Tue Dec 18 20:39:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03061 for ; Tue, 18 Dec 2001 20:39:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJ0cdx03643 for ips-outgoing; Tue, 18 Dec 2001 19:38:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJ0cYZ03623 for ; Tue, 18 Dec 2001 19:38:34 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA19322; Tue, 18 Dec 2001 16:38:24 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA22495; Tue, 18 Dec 2001 16:22:49 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 16:38:24 -0800 Message-ID: From: "Mukund, Shridhar" To: "'Paul Koning'" , "Mukund, Shridhar" Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Tue, 18 Dec 2001 16:38:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I largely agree with your message of last Friday. I prefer we stay away from implementation notes or analysis. Reference to additional information is perfectly fine. -Shridhar Mukund >>>>>>>>>>>>>>>>>>>> Paul, I like your text. I would include the note about Ethernet. My preference would be to not include the implementation notes though I don't find anything terribly objectionable in them. It would be nice to include a reference to additional informative information on CRC generation particularly since some references out in the world seem to be misleading. Regards, Pat >>>>>>>>>>>>>>>>>>>> Mukund,> Folks, Mukund,> This thread seems to be going on and on. I think that Pat Mukund,> has hit the nail on the head. Ethernet Spec does describe Mukund,> CRC computation "precisely". Additionally, if we spec the Mukund,> order of bits in the iSCSI message format, we are done. That's exactly what I did in my message of last Friday. Do you agree, or do you have comments on how to make it do the job? paul >>>>>>>>>>>>>>>>>>>>> From owner-ips@ece.cmu.edu Tue Dec 18 23:20:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06770 for ; Tue, 18 Dec 2001 23:20:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJ3XGf13449 for ips-outgoing; Tue, 18 Dec 2001 22:33:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJ3XGZ13445 for ; Tue, 18 Dec 2001 22:33:16 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 22:28:55 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372A1@CORPMX14> From: Black_David@emc.com To: muralir@lightsand.com Cc: ips@ece.cmu.edu Subject: RE: FCIP: WWN short frame and IPsec Date: Tue, 18 Dec 2001 22:21:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Murali Sorry for the delay in responding to this. > Could you please characterize and hence clarify the problem > with the existing use of WWN to add additional TCP connection. > I am hearing different views of the problem from different people. > I would like to get us all on the same page by answering: > > 1) When is this a problem? With IPSec or without ? It is a problem in both situations, although the nature of the problem differs. In the absence of IPsec, there is a direct exposure to false authentication (the WWN in the short frame is not checked, and hence any connection from anywhere could present any WWN). In the presence of IPsec, there is an exposure to a device using an IPsec identity that does not match the WWN presented in the short frame (i.e., Bob announces himself as Bob to IKE, but then presents Alice's WWN to intercept traffic to her and/or inject traffic as if it were from her). > 2) What are the threat assumptions? I suggest looking at section 2 of the security draft. The threat in the absence of IPsec includes a variant of [4] that is much easier to pull off than hijacking the TCP connection - the description of [4] in the security draft may need to be expanded to encompass this. > Is the rogue device a party that is assumed to be "trusted" ? I suspect the question is ill-formed. Classifying the world into "trusted" and "un-trusted" entities is not a good way to think about security. The fundamental threat here is a device exceeding its authorization by presenting a WWN that it is not authorized to present and therefore being able to receive traffic forwarded to or through that WWN and send traffic as if it came from or through that WWN. As indicated previously on the list, an assumption that the WWN must be correct if presented on an IPsec-secured connection on which the other party has passed IKE authentication is not good enough - in the absence of other measures, the WWN would have to be checked against the IKE identity to prevent the above problem with Bob presenting Alice's WWN. In other words, the fact that a connection has passed an IPsec authentication is not in general sufficient to fully trust it; there are conditions in which this may be the case, but they depend on local security policy. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 435-1000 FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Dec 18 23:21:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06791 for ; Tue, 18 Dec 2001 23:21:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJ3hu513989 for ips-outgoing; Tue, 18 Dec 2001 22:43:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJ3hrZ13984 for ; Tue, 18 Dec 2001 22:43:54 -0500 (EST) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 09:16:58 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A8B6@DCMTECHDOM> From: Nitin Dhingra To: "'Black_David@emc.com'" , muralis@mindtree.com, ips@ece.cmu.edu Subject: RE: sessions and connections Date: Wed, 19 Dec 2001 09:16:57 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk But you don't need to authenticate & negotiate parameters for all the connections in the session or do you? Isn't the leading connection sufficient... -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, December 18, 2001 7:16 AM To: muralis@mindtree.com; ips@ece.cmu.edu Subject: RE: sessions and connections Yes, you must do a login for each connection. --David > -----Original Message----- > From: Murali S [mailto:muralis@mindtree.com] > Sent: Tuesday, December 18, 2001 2:12 AM > To: ips@ece.cmu.edu > Subject: sessions and connections > > > Hi all, > > do we have to do a login for each connection in a > session? If not > where do we generate a CID for each connection. > Draft says that CID should be generated during login phase. > > -Murali > From owner-ips@ece.cmu.edu Tue Dec 18 23:22:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06803 for ; Tue, 18 Dec 2001 23:22:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJ402s14836 for ips-outgoing; Tue, 18 Dec 2001 23:00:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJ401Z14832 for ; Tue, 18 Dec 2001 23:00:01 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Dec 2001 22:55:40 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372A2@CORPMX14> From: Black_David@emc.com To: nitin.dhingra@dcmtech.co.in, ips@ece.cmu.edu Subject: RE: sessions and connections Date: Tue, 18 Dec 2001 22:48:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk > But you don't need to authenticate & negotiate parameters for > all the connections in the session or do you? > Isn't the leading connection sufficient... NO!! The IP addresses don't have to be the same for connections in a session. If subsequent connections aren't authenticated, an attacker waits for the first connection to establish, adds his connection to the Target to the session and sends a format command ... Some of the negotiated parameters can only be negotiated on the leading connection and are indicated as such in the draft. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Mobile: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Dec 19 06:14:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26914 for ; Wed, 19 Dec 2001 06:14:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJAHIa03758 for ips-outgoing; Wed, 19 Dec 2001 05:17:18 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJAHDZ03753 for ; Wed, 19 Dec 2001 05:17:14 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id LAA43980; Wed, 19 Dec 2001 11:17:02 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBJAHBd16810; Wed, 19 Dec 2001 11:17:22 +0100 Importance: Normal Subject: Re: iSCSI: Security (SRP) To: "Lee Xing" Cc: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Wed, 19 Dec 2001 12:16:41 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 19/12/2001 12:17:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Lee, Appendix A. iSCSI Security and Integrity ... 02 Authentication ... Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1). U is a text string, N,g,s,A,B,M and H(A | M | K) are binary items and their binary length (not the encoded length) MUST not exceed 1024 And on Section 3.10.4 Text : Character strings are represented as plain text. Binary items can be encoded using their decimal representation (with or without leading zeros) or hexadecimal representation (e.g., 8190 is 0x1ffe). Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC, 0X1aBc and 0x1ABC are equivalent). Binary items can also be encoded using the more compact Base64 encoding as specified by [RFC2045] preceded by the 0b. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Lee Xing" @ece.cmu.edu on 14/12/2001 23:03:44 Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: Security (SRP) Hi, I got a question on iSCSI security-SRP, and would appreciate it if someone could help. Based on iSCSI v.09, several key=value pairs are used to exchange SRP parameters and keys. Such as: SRP_N= SRP_g= SRP_s= SRP_A= SRP_B= SRP_M= SRP_HM= The question is what types of data formats should be used for each key=value pair? Should decimal, hex, base64 or something else be used? It seems iSCSI v.09 or RTF2945 don't specify it. Thanks. Lee Xing Crossroads Systems, Inc. From owner-ips@ece.cmu.edu Wed Dec 19 12:32:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02196 for ; Wed, 19 Dec 2001 12:32:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJGTgi06670 for ips-outgoing; Wed, 19 Dec 2001 11:29:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from HQMAILNODE1.COMMSTOR.Crossroads.com (65-68-235-68.crossroads.com [65.68.235.68] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJGTQZ06656 for ; Wed, 19 Dec 2001 11:29:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: iSCSI: Security (SRP) Disposition-Notification-To: "Lee Xing" Date: Wed, 19 Dec 2001 10:29:22 -0600 Message-ID: Thread-Topic: iSCSI: Security (SRP) Thread-Index: AcGIdlq2pAhVDq2OSWW3gcwN941qzQAMsrFw From: "Lee Xing" To: "Ofer Biran" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBJGTZZ06662 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Ofer, Should we specify which encoding method to use? It seems Base64 is probably better for this. Thanks. Lee -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Wednesday, December 19, 2001 4:17 AM To: Lee Xing Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Security (SRP) Lee, Appendix A. iSCSI Security and Integrity ... 02 Authentication ... Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1). U is a text string, N,g,s,A,B,M and H(A | M | K) are binary items and their binary length (not the encoded length) MUST not exceed 1024 And on Section 3.10.4 Text : Character strings are represented as plain text. Binary items can be encoded using their decimal representation (with or without leading zeros) or hexadecimal representation (e.g., 8190 is 0x1ffe). Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC, 0X1aBc and 0x1ABC are equivalent). Binary items can also be encoded using the more compact Base64 encoding as specified by [RFC2045] preceded by the 0b. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Lee Xing" @ece.cmu.edu on 14/12/2001 23:03:44 Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: Security (SRP) Hi, I got a question on iSCSI security-SRP, and would appreciate it if someone could help. Based on iSCSI v.09, several key=value pairs are used to exchange SRP parameters and keys. Such as: SRP_N= SRP_g= SRP_s= SRP_A= SRP_B= SRP_M= SRP_HM= The question is what types of data formats should be used for each key=value pair? Should decimal, hex, base64 or something else be used? It seems iSCSI v.09 or RTF2945 don't specify it. Thanks. Lee Xing Crossroads Systems, Inc. From owner-ips@ece.cmu.edu Wed Dec 19 12:33:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02224 for ; Wed, 19 Dec 2001 12:33:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJGrbR08323 for ips-outgoing; Wed, 19 Dec 2001 11:53:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.com (040.dsl6660175.bstatic.surewest.net [66.60.175.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJGrXZ08316 for ; Wed, 19 Dec 2001 11:53:34 -0500 (EST) Received: by homer.lmg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 08:52:01 -0800 Message-ID: From: Dean Scoville To: ips@ece.cmu.edu Subject: RE: Wot I `know' about COWS in hardware Date: Wed, 19 Dec 2001 08:52:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188AD.7ACA90E0" Sender: owner-ips@ece.cmu.edu 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_01C188AD.7ACA90E0 Content-Type: text/plain; charset="iso-8859-1" Hi, For those of us on the reflector who aren't familiar with COBS/COWS, could someone point us to background information on what is being proposed? Thanks, Dean -----Original Message----- From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] Sent: Monday, December 17, 2001 2:42 PM To: Julian Satran; Jim Pinkerton; ips@ece.cmu.edu Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware I think the COBS/COWS should more potential than the markers proposal, or the ULP framing without COBS. There is one case where it does add more overhead, but the question is how prevelent is the scenario - when outbound zero copy is enabled/possible and the NIC does checksum offload and cannot be changed to do COBS. Of course changes are required :-). I also hope that data-centers will use acclerated iSCSI/Clustering HBAs/NICs rather than the current solutions. The current solutions MAY be useful for desktops/laptops where hopefully there are plenty of spare cycles to do COBS in software. COBS also has alignment benefits - the header could be aligned with the ULP PDU, and the ULP PDU can be aligned with the TCP header and there are no false positives. The alignment with the TCP header may not always happen (the mythical box in the middle that does TCP resegmentation), but can be detected - in the presence of such a box, the performance could reduce to the levels encountered when IP fragmentation happens. I think it is better to have a couple of inter-operable implementations that demonstrate the benefit of any of the alternate proposals (especially markers vs cobs) before selecting one. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, December 17, 2001 9:27 AM To: Jim Pinkerton; ips@ece.cmu.edu Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware Jim, There are some things attractive about COWS - 1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side 2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved 3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation Julo "Jim Pinkerton" wrote on 17-12-2001 17:32:04: > > My main concern with this approach is that we could kill the product but > win the spec wars. Specifically, this approach means that an > end-customer has one of two choices in deploying the technology: > > 1) Upgrade both ends, and they'll see the full benefit > 2) Upgrade only the server side, and see roughly 2-4 times the > CPU > utilization on the client if their current > implementation is optimized > on the client side (a mere 2x if they are doing > significant > receives that already require a copy, more like 4x if > they > are primarily doing sends, which currently has no bcopy > in > many OS implementations). > > This means that if they pick option 2) and their machines are CPU bound, > that the data center capacity to handle requests will actually > *decrease* if they deploy the technology. If the front end has enough > idle CPU cycles, then they probably could select option 2). > > In my experience, we need to make sure we have a volume solution to > enable NIC vendors to make enough profit to fund the next generation > (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU > architecture). This means we need a path to the front-end boxes in the > data center. My concern is that there is no half-measure in the above > scenario - the IT manager must upgrade the thousand front-end boxes at > the same time as they upgrade the back end, or deploy asymmetric configs > where some front end boxes are upgraded. I'm not sure how attractive > this deployment scenario is. > > Howard and Uri, can you comment on this issue? > > > > Jim > > > > > > > > > -----Original Message----- > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > > Sent: Monday, December 17, 2001 7:13 AM > > To: uri@broadcom.com; howard.c.herbert@intel.com > > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com; > > allyn@cisco.com > > Subject: Wot I `know' about COWS in hardware > > > > Hi, > > > > I haven't gotten a chance to do a full implementation yet, but here's > > some architectural properties I believe to be true of a hardware COWS > > implementation: > > > > 1) can be implemented `in line' on receive > > 2) requires an MTU-sized RAM on send > > 3) expected touches to send RAM is 2 per data word (just the `fifo' > > write and read ops, no editing), assuming the headers are merged > > on the outbound side. > > 4) worst case touches to send RAM is 3 per data word (assuming every > > word must be edited) > > 5) eliminates the need for the funky `make sure you don't send > > anything that's false positive under non-nominal conditions' > > behavior of the key/length proposal (I kinda doubted hardware > > impls were going to do this anyway, since it was a SHOULD). > > > > Basically, it looks OK to me. Slowing the sender is much better than > > slowing the receiver. Theoretically, we could reverse the pointer > > chain and allow in-line send, but RAM on receive, but that seems > > stupid to me. > > > > It's clearly a design tradeoff whether you chose to use the COWS > > send-side RAM for other purposes, or not. > > > > I'm hoping you guys can tell me whether you think this blows your > > budget, or other noteworthy (unfortunate) properties. As you can > > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...). > > > > Thanks, > > Steph ------_=_NextPart_001_01C188AD.7ACA90E0 Content-Type: text/html; charset="iso-8859-1"
Hi,
For those of us on the reflector who aren't familiar with COBS/COWS, could someone point us to background information on what is being proposed?
Thanks,
Dean
-----Original Message-----
From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com]
Sent: Monday, December 17, 2001 2:42 PM
To: Julian Satran; Jim Pinkerton; ips@ece.cmu.edu
Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com
Subject: RE: Wot I `know' about COWS in hardware

I think the COBS/COWS should more potential than the markers proposal, or
the ULP framing without COBS. There is one case where it does add more overhead,
but the question is how prevelent is the scenario - when outbound zero copy is
enabled/possible and the NIC does checksum offload and cannot be changed to
do COBS. Of course changes are required :-).
 
I also hope that data-centers will use acclerated iSCSI/Clustering HBAs/NICs rather
than the current solutions. The current solutions MAY be useful for desktops/laptops
where hopefully there are plenty of spare cycles to do COBS in software.
 
COBS also has alignment benefits - the header could be aligned with the ULP PDU,
and the ULP PDU can be aligned with the TCP header and there are no false
positives. The alignment with the TCP header may not always happen (the mythical
box in the middle that does TCP resegmentation), but can be detected - in the
presence of such a box, the performance could reduce to the levels encountered
when IP fragmentation happens.
 
I think it is better to have a couple of inter-operable implementations that demonstrate
the benefit of any of the alternate proposals (especially markers vs cobs) before selecting
one.
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Monday, December 17, 2001 9:27 AM
To: Jim Pinkerton; ips@ece.cmu.edu
Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com
Subject: RE: Wot I `know' about COWS in hardware


Jim,

There are some things attractive about COWS -

1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side

2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved

3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation

Julo

"Jim Pinkerton" <jpink@microsoft.com> wrote on 17-12-2001 17:32:04:

>
> My main concern with this approach is that we could kill the product but
> win the spec wars. Specifically, this approach means that an
> end-customer has one of two choices in deploying the technology:
>
>    1) Upgrade both ends, and they'll see the full benefit
>    2) Upgrade only the server side, and see roughly 2-4 times the
> CPU
>       utilization on the client if their current
>       implementation is optimized
>       on the client side (a mere 2x if they are doing
> significant
>       receives that already require a copy, more like 4x if
> they
>       are primarily doing sends, which currently has no bcopy
> in
>       many OS implementations).
>
> This means that if they pick option 2) and their machines are CPU bound,
> that the data center capacity to handle requests will actually
> *decrease* if they deploy the technology. If the front end has enough
> idle CPU cycles, then they probably could select option 2).
>
> In my experience, we need to make sure we have a volume solution to
> enable NIC vendors to make enough profit to fund the next generation
> (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU
> architecture). This means we need a path to the front-end boxes in the
> data center. My concern is that there is no half-measure in the above
> scenario - the IT manager must upgrade the thousand front-end boxes at
> the same time as they upgrade the back end, or deploy asymmetric configs
> where some front end boxes are upgraded. I'm not sure how attractive
> this deployment scenario is.
>
> Howard and Uri, can you comment on this issue?
>
>
>
> Jim
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Stephen Bailey [mailto:steph@cs.uchicago.edu]
> > Sent: Monday, December 17, 2001 7:13 AM
> > To: uri@broadcom.com; howard.c.herbert@intel.com
> > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com;
> > allyn@cisco.com
> > Subject: Wot I `know' about COWS in hardware
> >
> > Hi,
> >
> > I haven't gotten a chance to do a full implementation yet, but here's
> > some architectural properties I believe to be true of a hardware COWS
> > implementation:
> >
> >   1) can be implemented `in line' on receive
> >   2) requires an MTU-sized RAM on send
> >   3) expected touches to send RAM is 2 per data word (just the `fifo'
> >      write and read ops, no editing), assuming the headers are merged
> >      on the outbound side.
> >   4) worst case touches to send RAM is 3 per data word (assuming every
> >      word must be edited)
> >   5) eliminates the need for the funky `make sure you don't send
> >      anything that's false positive under non-nominal conditions'
> >      behavior of the key/length proposal (I kinda doubted hardware
> >      impls were going to do this anyway, since it was a SHOULD).
> >
> > Basically, it looks OK to me.  Slowing the sender is much better than
> > slowing the receiver.  Theoretically, we could reverse the pointer
> > chain and allow in-line send, but RAM on receive, but that seems
> > stupid to me.
> >
> > It's clearly a design tradeoff whether you chose to use the COWS
> > send-side RAM for other purposes, or not.
> >
> > I'm hoping you guys can tell me whether you think this blows your
> > budget, or other noteworthy (unfortunate) properties.  As you can
> > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...).
> >
> > Thanks,
> >   Steph
------_=_NextPart_001_01C188AD.7ACA90E0-- From owner-ips@ece.cmu.edu Wed Dec 19 12:35:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02284 for ; Wed, 19 Dec 2001 12:35:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJGgSv07571 for ips-outgoing; Wed, 19 Dec 2001 11:42:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from homer.qlogic.com (040.dsl6660175.bstatic.surewest.net [66.60.175.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJGgOZ07558 for ; Wed, 19 Dec 2001 11:42:24 -0500 (EST) Received: by homer.lmg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 08:40:51 -0800 Message-ID: From: Dean Scoville To: ips@ece.cmu.edu Subject: RE: iSCSI: Security (SRP) Date: Wed, 19 Dec 2001 08:40:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Just curious... Why are we so flexible in our encoding? Does anyone plan to send their binary login parameters as encoded Base64 values? Decimal values are all I've ever seen used up to this point. -Dean -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Wednesday, December 19, 2001 2:17 AM To: Lee Xing Cc: ips@ece.cmu.edu Subject: Re: iSCSI: Security (SRP) Lee, Appendix A. iSCSI Security and Integrity ... 02 Authentication ... Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945] (using the SHA1 hash function, i.e., SRP-SHA1). U is a text string, N,g,s,A,B,M and H(A | M | K) are binary items and their binary length (not the encoded length) MUST not exceed 1024 And on Section 3.10.4 Text : Character strings are represented as plain text. Binary items can be encoded using their decimal representation (with or without leading zeros) or hexadecimal representation (e.g., 8190 is 0x1ffe). Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC, 0X1aBc and 0x1ABC are equivalent). Binary items can also be encoded using the more compact Base64 encoding as specified by [RFC2045] preceded by the 0b. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Lee Xing" @ece.cmu.edu on 14/12/2001 23:03:44 Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: Security (SRP) Hi, I got a question on iSCSI security-SRP, and would appreciate it if someone could help. Based on iSCSI v.09, several key=value pairs are used to exchange SRP parameters and keys. Such as: SRP_N= SRP_g= SRP_s= SRP_A= SRP_B= SRP_M= SRP_HM= The question is what types of data formats should be used for each key=value pair? Should decimal, hex, base64 or something else be used? It seems iSCSI v.09 or RTF2945 don't specify it. Thanks. Lee Xing Crossroads Systems, Inc. From owner-ips@ece.cmu.edu Wed Dec 19 14:12:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04511 for ; Wed, 19 Dec 2001 14:12:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJHcr911644 for ips-outgoing; Wed, 19 Dec 2001 12:38:53 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJHckZ11623 for ; Wed, 19 Dec 2001 12:38:51 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id AF3863B400A0; Wed, 19 Dec 2001 11:32:40 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A078110188; Wed, 19 Dec 2001 11:38:00 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: What can go on during a text negotiation? Date: Wed, 19 Dec 2001 12:09:06 -0500 Message-ID: <003701c188b3$ef815a80$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C1888A.06AB5280" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0038_01C1888A.06AB5280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Can anything go on during a text negotiation? I.e., does the I/O continue as normal if a text request is sent but the text response has not been sent yet? Or, if a multi-message parameter negotiation is going on but it has not finished yet. Eddy ------=_NextPart_000_0038_01C1888A.06AB5280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Can anything go on during a text negotiation? I.e., does the I/O continue as = normal if a text request is sent but the text response has not been sent yet? = Or, if a multi-message parameter negotiation is going on but it has not finished = yet.

 

Eddy<= /span>

------=_NextPart_000_0038_01C1888A.06AB5280-- From owner-ips@ece.cmu.edu Wed Dec 19 18:00:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09820 for ; Wed, 19 Dec 2001 18:00:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJM9b902558 for ips-outgoing; Wed, 19 Dec 2001 17:09:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from exch2k.aarohicommunications.com (cpe-66-87-94-158.ca.sprintbbd.net [66.87.94.158]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJM5PZ02262 for ; Wed, 19 Dec 2001 17:05:25 -0500 (EST) content-class: urn:content-classes:message Subject: Recovery Within Connection - Command Restart Date: Wed, 19 Dec 2001 14:06:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C188D9.71D58E0A" Thread-Topic: Recovery Within Connection - Command Restart Thread-Index: AcGIEiO5npEh3bGLQLeDQBNdN6r5MAAxv22g From: "shaileshm" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C188D9.71D58E0A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 1. The draft says a) Requests not acknowledged for a long time..... Does the SCSI timeout's introduce the notion of time, or does iscsi has to have timeout's at the transport layer. Also for detecting connection failures don't the NOP's have to be timed. 2. Request not acknowledged would be most of the time due to a header digest errors at the target end. If the header is bad how would one know at the target, that this was a command PDU v/s a Data PDU, since the target will have to implement a command scoreboard if it is a command PDU. 3. Usage of Reject PDU talks about Reject on Command PDU : however the error codes for Reject PDU do not indicate a command PDU error. 4. Is the recovery R2T different from the usual R2T. =20 These things are not clear from the draft ! =20 Shailesh Manjrekar. ------_=_NextPart_001_01C188D9.71D58E0A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

  1. The draft says a) Requests not acknowledged for a long time….. = Does the SCSI timeout’s introduce the notion of time, or does iscsi = has to have timeout’s at the transport layer. Also for detecting = connection failures don’t the NOP’s have to be = timed.
  2. Request not acknowledged would be most of the time due to a header digest = errors at the target end. If the header is bad how would one know at the = target, that this was a command PDU v/s a Data PDU, since the target will = have to implement a command scoreboard if it is a command = PDU.
  3. Usage of Reject PDU talks about Reject on Command PDU : however the error = codes for Reject PDU do not indicate a command PDU = error.
  4. Is the recovery R2T = different from the usual R2T.

 

These things are not clear from the draft = !

 

Shailesh Manjrekar.

------_=_NextPart_001_01C188D9.71D58E0A-- From owner-ips@ece.cmu.edu Wed Dec 19 18:02:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09852 for ; Wed, 19 Dec 2001 18:02:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJM53X02244 for ips-outgoing; Wed, 19 Dec 2001 17:05:03 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJM51Z02239 for ; Wed, 19 Dec 2001 17:05:01 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id XAA39354 for ; Wed, 19 Dec 2001 23:04:53 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBJM5Od186866 for ; Wed, 19 Dec 2001 23:05:24 +0100 Subject: RE:iSCSI: Outboard Tunnel Mode To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Wed, 19 Dec 2001 23:30:18 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 00:05:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Lakshmi, I think that what must implements means is that the function should be available if an administrator decides to activate it. May use refers to the fact that not using a facility can be a result of an agreement between parties. Julo "Lakshmi Ramasubramanian" To: John Hufferd/San osoft.com> cc: Sent by: Subject: RE:iSCSI: Outboard Tunnel owner-ips@ece.cmu.ed Mode u 17-12-01 22:39 If it is NOT MUST USE, I guess most implementations would just choose "None" for security options. What is the point in saying MUST IMPLEMENT but is NOT MUST USE? -lakshmi -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 17, 2001 11:13 AM To: VAHUJA@aol.com Cc: ips@ece.cmu.edu Subject: Re: Outboard Tunnel Mode Installations can do what ever they want. The Security functions are must implement, NOT must use. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com VAHUJA@aol.com@ece.cmu.edu on 12/17/2001 10:09:10 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Outboard Tunnel Mode Folks, May be I missed something in SLC meeting. I can expect several implementations of iSCSI not include any security.Reason - I can see that customers would often rely on the company's existing VPNs (outboard Router etc) to protect their data (storage or otherwise) over IP networks. From a CIO's viewpoint, this approach may make more sense than extending yet another layer of IPSec into its servers just for storage data. It is not clear to me from the standard if it will be a non-compliance of iSCSI standard. If so, we may potentially have many non-compliances. From owner-ips@ece.cmu.edu Wed Dec 19 18:47:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10409 for ; Wed, 19 Dec 2001 18:47:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJMtv105999 for ips-outgoing; Wed, 19 Dec 2001 17:55:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1.cos.agilent.com (msgbas1x.cos.agilent.com [192.25.240.36]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJMtuZ05995 for ; Wed, 19 Dec 2001 17:55:56 -0500 (EST) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DF046335B; Wed, 19 Dec 2001 15:55:55 -0700 (MST) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 9CB34333; Wed, 19 Dec 2001 15:55:55 -0700 (MST) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 15:55:55 -0700 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0097D4DB2@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Luben Tuikov , "THALER,PAT (A-Roseville,ex1)" , ni1d@arrl.net, "CAVANNA,VICENTE V (A-Roseville,ex1)" Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Date: Wed, 19 Dec 2001 15:55:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Luben, Your statement "That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived." is incorrect for Ethernet. If the frame was not an integral number of bytes, then the excess bits (the ones that are not part of a complete byte) are not to be used in the CRC calculation. The IEEE 802.3 spec (and the earlier DIX Ethernet spec) requires that the CRC checking algorithm only process whole bytes. Therefore, a good CRC algorithm for Ethernet would only process bits once a whole byte worth of bits had arrived. This really isn't relevant to the iSCSI reflector so I suggest we take this offline if you want to discuss it further. IEEE 802.3 is about 1500 pages in the 2000 edition so if I am making a point with respect to it, I think it is polite to provide a reference to where that information can be found so that people can read it for themselves. Certainly no offense was intended by making a specific citation. Regards, Pat Thaler -----Original Message----- From: Luben Tuikov [mailto:ltuikov@yahoo.com] Sent: Tuesday, December 18, 2001 2:57 PM To: pat_thaler@agilent.com; ni1d@arrl.net; vince_cavanna@agilent.com Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI --- pat_thaler@agilent.com wrote: > > method. However, that is irrelavent to what should go > into the standard. I never posted a message of the sort: ``Here guys put this into the draft: ...''. And I don't want to post one. All I've been doing is mathematical analysis of the algorithm(s). And all I've been looking for is an unambiguious definition. > By the way, there is an error in your statement below > with respect to > Ethernet behavior: "A good CRC algorithm will have to be > as strong as being > able to produce the CRC at any time. That is, it has to > have the correct CRC _after_ _each_ _bit_ has arrived. > > I.e. in any moment in time, if I were to say STOP, I > would > have to be able to ``produce'' the right CRC." Read the sentence again please: indefinite article ``a''. This means ``any'' CRC algorithm. No there is no error. > Actually and Ethernet implementation is specifically > required not to behave > this way. If you will refer to IEEE 802.3 4.2.9 procedure > ReceiveLinkMgmt ... [cut] Don't you think I can read this myself? Then again: indefinite article ``a''. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Wed Dec 19 18:50:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10482 for ; Wed, 19 Dec 2001 18:50:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBJMkYn05104 for ips-outgoing; Wed, 19 Dec 2001 17:46:34 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBJMkNZ05087 for ; Wed, 19 Dec 2001 17:46:32 -0500 (EST) Received: from somesh ([12.81.8.42]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20011219224612.VDRG7926.mtiwmhc23.worldnet.att.net@somesh>; Wed, 19 Dec 2001 22:46:12 +0000 Reply-To: From: "Somesh Gupta" To: "Dean Scoville" , "IPS" Subject: RE: Wot I `know' about COWS in hardware Date: Wed, 19 Dec 2001 14:44:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1889B.A9A6E4C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1889B.A9A6E4C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Following is the message that Jim sent out earlier on the reflector - Here is the URL for a COBS (Consistent Overhead Byte Stuffing) paper. The technique can also be applied at the word level. http://www.stuartcheshire.org/papers/COBSforToN.pdf http://ieeexplore.ieee.org/iel5/90/16693/00769765.pdf?isNumber=16693 Jim -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Dean Scoville Sent: Wednesday, December 19, 2001 8:52 AM To: ips@ece.cmu.edu Subject: RE: Wot I `know' about COWS in hardware Hi, For those of us on the reflector who aren't familiar with COBS/COWS, could someone point us to background information on what is being proposed? Thanks, Dean -----Original Message----- From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] Sent: Monday, December 17, 2001 2:42 PM To: Julian Satran; Jim Pinkerton; ips@ece.cmu.edu Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware I think the COBS/COWS should more potential than the markers proposal, or the ULP framing without COBS. There is one case where it does add more overhead, but the question is how prevelent is the scenario - when outbound zero copy is enabled/possible and the NIC does checksum offload and cannot be changed to do COBS. Of course changes are required :-). I also hope that data-centers will use acclerated iSCSI/Clustering HBAs/NICs rather than the current solutions. The current solutions MAY be useful for desktops/laptops where hopefully there are plenty of spare cycles to do COBS in software. COBS also has alignment benefits - the header could be aligned with the ULP PDU, and the ULP PDU can be aligned with the TCP header and there are no false positives. The alignment with the TCP header may not always happen (the mythical box in the middle that does TCP resegmentation), but can be detected - in the presence of such a box, the performance could reduce to the levels encountered when IP fragmentation happens. I think it is better to have a couple of inter-operable implementations that demonstrate the benefit of any of the alternate proposals (especially markers vs cobs) before selecting one. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, December 17, 2001 9:27 AM To: Jim Pinkerton; ips@ece.cmu.edu Cc: allyn@cisco.com; csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey; uri@broadcom.com Subject: RE: Wot I `know' about COWS in hardware Jim, There are some things attractive about COWS - 1. the hard work - touching every data word has to be done only by the sender (on the normal path) and can be easily included in NIC with accelerator cards that seem to do a good job on the send side 2. If you are doing CRC or IPsec on a client in software there is no additional penalty (provided you can include the code in the right layer of software) as no data gets moved 3.It does not have to associated with a TCP packet alignment - and can work in face of TCP segmentation Julo "Jim Pinkerton" wrote on 17-12-2001 17:32:04: > > My main concern with this approach is that we could kill the product but > win the spec wars. Specifically, this approach means that an > end-customer has one of two choices in deploying the technology: > > 1) Upgrade both ends, and they'll see the full benefit > 2) Upgrade only the server side, and see roughly 2-4 times the > CPU > utilization on the client if their current > implementation is optimized > on the client side (a mere 2x if they are doing > significant > receives that already require a copy, more like 4x if > they > are primarily doing sends, which currently has no bcopy > in > many OS implementations). > > This means that if they pick option 2) and their machines are CPU bound, > that the data center capacity to handle requests will actually > *decrease* if they deploy the technology. If the front end has enough > idle CPU cycles, then they probably could select option 2). > > In my experience, we need to make sure we have a volume solution to > enable NIC vendors to make enough profit to fund the next generation > (otherwise RDMA/TOE is a one-shot deal and won't keep up with the CPU > architecture). This means we need a path to the front-end boxes in the > data center. My concern is that there is no half-measure in the above > scenario - the IT manager must upgrade the thousand front-end boxes at > the same time as they upgrade the back end, or deploy asymmetric configs > where some front end boxes are upgraded. I'm not sure how attractive > this deployment scenario is. > > Howard and Uri, can you comment on this issue? > > > > Jim > > > > > > > > > -----Original Message----- > > From: Stephen Bailey [mailto:steph@cs.uchicago.edu] > > Sent: Monday, December 17, 2001 7:13 AM > > To: uri@broadcom.com; howard.c.herbert@intel.com > > Cc: csapuntz@cisco.com; Jim Pinkerton; Julian_Satran@il.ibm.com; > > allyn@cisco.com > > Subject: Wot I `know' about COWS in hardware > > > > Hi, > > > > I haven't gotten a chance to do a full implementation yet, but here's > > some architectural properties I believe to be true of a hardware COWS > > implementation: > > > > 1) can be implemented `in line' on receive > > 2) requires an MTU-sized RAM on send > > 3) expected touches to send RAM is 2 per data word (just the `fifo' > > write and read ops, no editing), assuming the headers are merged > > on the outbound side. > > 4) worst case touches to send RAM is 3 per data word (assuming every > > word must be edited) > > 5) eliminates the need for the funky `make sure you don't send > > anything that's false positive under non-nominal conditions' > > behavior of the key/length proposal (I kinda doubted hardware > > impls were going to do this anyway, since it was a SHOULD). > > > > Basically, it looks OK to me. Slowing the sender is much better than > > slowing the receiver. Theoretically, we could reverse the pointer > > chain and allow in-line send, but RAM on receive, but that seems > > stupid to me. > > > > It's clearly a design tradeoff whether you chose to use the COWS > > send-side RAM for other purposes, or not. > > > > I'm hoping you guys can tell me whether you think this blows your > > budget, or other noteworthy (unfortunate) properties. As you can > > tell, I have the utmost enthusiasm for the mission (Dr. Chandra...). > > > > Thanks, > > Steph ------=_NextPart_000_0007_01C1889B.A9A6E4C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Following is the=20 message that Jim sent out = earlier on the=20 reflector -

Here is the = URL for a COBS=20 (Consistent Overhead Byte Stuffing) paper.

The technique can also be applied at the word = level.

http://www.stuartcheshire.org/papers/COBSforToN.pdf

http://ieeexplore.ieee.org/iel5/90/16693/00769765.pdf?isNumber=3D= 16693

Jim

-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Dean=20 Scoville
Sent: Wednesday, December 19, 2001 8:52 = AM
To:=20 ips@ece.cmu.edu
Subject: RE: Wot I `know' about COWS in=20 hardware

Hi,
For=20 those of us on the reflector who aren't familiar with COBS/COWS,=20 could someone point us to background information on what is = being=20 proposed?
Thanks,
Dean
-----Original Message-----
From: Somesh Gupta=20 [mailto:somesh_gupta@silverbacksystems.com]
Sent: Monday, = December=20 17, 2001 2:42 PM
To: Julian Satran; Jim Pinkerton;=20 ips@ece.cmu.edu
Cc: allyn@cisco.com; csapuntz@cisco.com;=20 howard.c.herbert@intel.com; Stephen Bailey;=20 uri@broadcom.com
Subject: RE: Wot I `know' about COWS in=20 hardware

I=20 think the COBS/COWS should more potential than the markers proposal, = or
the ULP framing without COBS. There is = one case=20 where it does add more overhead,
but the question is how prevelent is the = scenario -=20 when outbound zero copy is
enabled/possible and the NIC does = checksum offload=20 and cannot be changed to
do=20 COBS. Of course changes are required = :-).
 
I=20 also hope that data-centers will use acclerated iSCSI/Clustering = HBAs/NICs=20 rather
than the current solutions. The current = solutions=20 MAY be useful for desktops/laptops
where hopefully there are plenty of spare = cycles to=20 do COBS in software.
 
COBS also has alignment benefits - the = header could=20 be aligned with the ULP PDU,
and the ULP PDU can be aligned with the = TCP header=20 and there are no false
positives. The alignment with the TCP = header may=20 not always happen (the mythical
box in the middle that does TCP = resegmentation),=20 but can be detected - in the
presence of such a box, the performance = could=20 reduce to the levels encountered
when IP fragmentation = happens.
 
I=20 think it is better to have a couple of inter-operable = implementations that=20 demonstrate
the benefit of any of the alternate = proposals=20 (especially markers vs cobs) before selecting
one.
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Monday, December 17, 2001 9:27 = AM
To: Jim=20 Pinkerton; ips@ece.cmu.edu
Cc: allyn@cisco.com;=20 csapuntz@cisco.com; howard.c.herbert@intel.com; Stephen Bailey;=20 uri@broadcom.com
Subject: RE: Wot I `know' about COWS in = hardware


Jim,=20

There are some things = attractive=20 about COWS -

1. = the hard work=20 - touching every data word has to be done only by the sender (on = the=20 normal path) and can be easily included in NIC with accelerator = cards that=20 seem to do a good job on the send side

2. If you are doing CRC or IPsec on a = client in=20 software there is no additional penalty (provided you can include = the code=20 in the right layer of software) as no data gets moved =

3.It does not have to associated with a = TCP packet=20 alignment - and can work in face of TCP segmentation =

Julo

"Jim Pinkerton" <jpink@microsoft.com> wrote on = 17-12-2001=20 17:32:04:

>
> My main concern with this approach = is that=20 we could kill the product but
> win the spec wars. = Specifically,=20 this approach means that an
> end-customer has one of two = choices in=20 deploying the technology:
>
>    1) Upgrade = both=20 ends, and they'll see the full benefit
>    2) = Upgrade=20 only the server side, and see roughly 2-4 times the
> = CPU
>=20       utilization on the client if their current =
>=20       implementation is optimized
>   =  =20   on the client side (a mere 2x if they are doing
>=20 significant
>       receives that already = require a=20 copy, more like 4x if
> they
>       = are=20 primarily doing sends, which currently has no bcopy
> = in
>=20       many OS implementations).
>
> = This means=20 that if they pick option 2) and their machines are CPU = bound,
> that=20 the data center capacity to handle requests will actually
>=20 *decrease* if they deploy the technology. If the front end has=20 enough
> idle CPU cycles, then they probably could select = option=20 2).
>
> In my experience, we need to make sure we = have a=20 volume solution to
> enable NIC vendors to make enough = profit to=20 fund the next generation
> (otherwise RDMA/TOE is a one-shot = deal=20 and won't keep up with the CPU
> architecture). This means = we need a=20 path to the front-end boxes in the
> data center. My concern = is that=20 there is no half-measure in the above
> scenario - the IT = manager=20 must upgrade the thousand front-end boxes at
> the same time = as they=20 upgrade the back end, or deploy asymmetric configs
> where = some=20 front end boxes are upgraded. I'm not sure how attractive
> = this=20 deployment scenario is.
>
> Howard and Uri, can you = comment=20 on this issue?
>
>
>
> Jim
> =
>=20
>
>
>
>
>
> > = -----Original=20 Message-----
> > From: Stephen Bailey=20 [mailto:steph@cs.uchicago.edu]
> > Sent: Monday, December = 17,=20 2001 7:13 AM
> > To: uri@broadcom.com;=20 howard.c.herbert@intel.com
> > Cc: csapuntz@cisco.com; = Jim=20 Pinkerton; Julian_Satran@il.ibm.com;
> > = allyn@cisco.com
>=20 > Subject: Wot I `know' about COWS in hardware
> > =
>=20 > Hi,
> >
> > I haven't gotten a chance to = do a full=20 implementation yet, but here's
> > some architectural = properties=20 I believe to be true of a hardware COWS
> >=20 implementation:
> >
> >   1) can be = implemented=20 `in line' on receive
> >   2) requires an MTU-sized = RAM on=20 send
> >   3) expected touches to send RAM is 2 per = data=20 word (just the `fifo'
> >      write and = read ops,=20 no editing), assuming the headers are merged
> >   =  =20  on the outbound side.
> >   4) worst case = touches to=20 send RAM is 3 per data word (assuming every
> >   =  =20  word must be edited)
> >   5) eliminates the = need for=20 the funky `make sure you don't send
> >    =20  anything that's false positive under non-nominal = conditions'
>=20 >      behavior of the key/length proposal (I = kinda=20 doubted hardware
> >      impls were going = to do=20 this anyway, since it was a SHOULD).
> >
> > = Basically,=20 it looks OK to me.  Slowing the sender is much better = than
>=20 > slowing the receiver.  Theoretically, we could reverse = the=20 pointer
> > chain and allow in-line send, but RAM on = receive, but=20 that seems
> > stupid to me.
> >
> > = It's=20 clearly a design tradeoff whether you chose to use the = COWS
> >=20 send-side RAM for other purposes, or not.
> >
> = > I'm=20 hoping you guys can tell me whether you think this blows = your
> >=20 budget, or other noteworthy (unfortunate) properties.  As you = can
> > tell, I have the utmost enthusiasm for the = mission (Dr.=20 Chandra...).
> >
> > Thanks,
> > =  =20 = Steph
------=_NextPart_000_0007_01C1889B.A9A6E4C0-- From owner-ips@ece.cmu.edu Wed Dec 19 20:47:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11637 for ; Wed, 19 Dec 2001 20:47:51 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBK13sh14036 for ips-outgoing; Wed, 19 Dec 2001 20:03:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBK13hZ14020 for ; Wed, 19 Dec 2001 20:03:43 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A774D2012A; Wed, 19 Dec 2001 18:57:24 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A8B417D0152; Wed, 19 Dec 2001 19:02:44 -0600 From: "Eddy Quicksall" To: "'Nitin Dhingra'" , , Subject: RE: sessions and connections Date: Wed, 19 Dec 2001 15:10:31 -0500 Message-ID: <000e01c188f2$1be2b4f0$0102a8c0@eddydesktop> 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 V6.00.2600.0000 In-Reply-To: <7FADCB99FC82D41199F9000629A85D1A0293A8B6@DCMTECHDOM> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit For the parameters marked with use:LO, you only do it for the Leading Login (the 1st connection). That becomes session wide. Eddy -----Original Message----- From: Nitin Dhingra [mailto:nitin.dhingra@dcmtech.co.in] Sent: Tuesday, December 18, 2001 10:47 PM To: 'Black_David@emc.com'; muralis@mindtree.com; ips@ece.cmu.edu Subject: RE: sessions and connections But you don't need to authenticate & negotiate parameters for all the connections in the session or do you? Isn't the leading connection sufficient... -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, December 18, 2001 7:16 AM To: muralis@mindtree.com; ips@ece.cmu.edu Subject: RE: sessions and connections Yes, you must do a login for each connection. --David > -----Original Message----- > From: Murali S [mailto:muralis@mindtree.com] > Sent: Tuesday, December 18, 2001 2:12 AM > To: ips@ece.cmu.edu > Subject: sessions and connections > > > Hi all, > > do we have to do a login for each connection in a > session? If not > where do we generate a CID for each connection. > Draft says that CID should be generated during login phase. > > -Murali > From owner-ips@ece.cmu.edu Wed Dec 19 20:51:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11670 for ; Wed, 19 Dec 2001 20:51:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBK12at13950 for ips-outgoing; Wed, 19 Dec 2001 20:02:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBK12XZ13946 for ; Wed, 19 Dec 2001 20:02:34 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A73BB2012A; Wed, 19 Dec 2001 18:56:27 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A8862080130; Wed, 19 Dec 2001 19:01:58 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: Date: Wed, 19 Dec 2001 15:00:20 -0500 Message-ID: <000001c188f1$ffe295e0$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C188C8.17267E80" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C188C8.17267E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This quote is from section 5.3. Can someone give an example of such a case? Whenever parameter action or acceptance is dependent on other parameters, the dependent parameters MUST be sent after the parameters they depend on. If they are sent within the same command a response for a parameter might imply responses for others. Eddy ------=_NextPart_000_0001_01C188C8.17267E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This quote is from section = 5.3. Can someone give an example of such a case?

 

 Whenever parameter action or acceptance is dependent = on other

 parameters, the dependent parameters MUST be sent = after the

 parameters they depend on.  If they are sent within the same = command

 a response for a parameter might imply responses for = others.

 

Eddy

 

------=_NextPart_000_0001_01C188C8.17267E80-- From owner-ips@ece.cmu.edu Wed Dec 19 21:32:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12039 for ; Wed, 19 Dec 2001 21:32:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBK2D7N17886 for ips-outgoing; Wed, 19 Dec 2001 21:13:07 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBK2D6Z17882 for ; Wed, 19 Dec 2001 21:13:06 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel8.hp.com (Postfix) with ESMTP id 2D446E000AB for ; Wed, 19 Dec 2001 21:13:00 -0500 (EST) Received: from rose.hp.com (hpsil34.rose.hp.com [15.43.211.225]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id SAA26902 for ; Wed, 19 Dec 2001 18:14:32 -0800 (PST) Message-Id: <200112200214.SAA26902@core.rose.hp.com> Date: Wed, 19 Dec 2001 18:26:10 -0800 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard, Roseville X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.10.20 9000/715) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: iSCSI Event data, section 3.9.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Currently the following is stated about the "iSCSI Event data" in the Async Message - "For an iSCSI Event additional data that MAY accompany the report" I believe this is intended for vendor-unique data since we do not call out the format. If so, I suggest - "For an iSCSI Event, additional vendor-unique data MAY accompany the Async event. Initiators MAY ignore the data when not understood while processing the rest of the PDU." Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com From owner-ips@ece.cmu.edu Wed Dec 19 21:35:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13026 for ; Wed, 19 Dec 2001 21:35:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBK1Yw115711 for ips-outgoing; Wed, 19 Dec 2001 20:34:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBK1YtZ15703 for ; Wed, 19 Dec 2001 20:34:55 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA08647 for ; Wed, 19 Dec 2001 17:34:46 -0800 (PST) Received: from aimexc02.corp.adaptec.com (aimexc02.corp.adaptec.com [162.62.62.40]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id RAA14394 for ; Wed, 19 Dec 2001 17:19:09 -0800 (PST) Received: from adaptec.com (ws10-20-142-76.corp.adaptec.com [10.20.142.76]) by aimexc02.corp.adaptec.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y2W33BKY; Wed, 19 Dec 2001 17:34:45 -0800 Message-ID: <3C214038.DA363398@adaptec.com> Date: Wed, 19 Dec 2001 17:34:48 -0800 From: Tow Wang X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ips@ece. cmu. edu (E-mail)" Subject: Order of dependent parameters (Was Re: iSCSI:) References: <000001c188f1$ffe295e0$0102a8c0@eddydesktop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I can infer one example: you should first offer whether you want markers, before offering any marker intervals. Tow Eddy Quicksall wrote: > This quote is from section 5.3. Can someone give an example of such a > case? > > Whenever parameter action or acceptance is dependent on other > > parameters, the dependent parameters MUST be sent after the > > parameters they depend on.If they are sent within the same command > > a response for a parameter might imply responses for others. > > Eddy > -- Tow Wang Adaptec Software Engineer From owner-ips@ece.cmu.edu Thu Dec 20 07:36:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06416 for ; Thu, 20 Dec 2001 07:36:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKBgNR28652 for ips-outgoing; Thu, 20 Dec 2001 06:42:23 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKAfeZ25516 for ; Thu, 20 Dec 2001 05:41:40 -0500 (EST) Received: from io.iol.unh.edu (IDENT:rdr@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.1/8.12.1) with ESMTP id fBKAfYYM007004; Thu, 20 Dec 2001 05:41:34 -0500 Received: from localhost (rdr@localhost) by io.iol.unh.edu (8.12.1/8.12.1/Submit) with ESMTP id fBKAfYOK007001; Thu, 20 Dec 2001 05:41:34 -0500 Date: Thu, 20 Dec 2001 05:41:34 -0500 (EST) From: "Robert D. Russell" To: Eddy Quicksall cc: "ips@ece. cmu. edu (E-mail)" Subject: Re: iSCSI: In-Reply-To: <000001c188f1$ffe295e0$0102a8c0@eddydesktop> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy: An example is the situation where InitialR2T is negotiated to yes (the default) and ImmediateData is negotiated to no. At that point unsolicited data of any kind is disallowed. Therefore the FirstBurstSize parameter becomes irrelevant, since it applies only if unsolicited data is allowed. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 19 Dec 2001, Eddy Quicksall wrote: > This quote is from section 5.3. Can someone give an example of such a case? > > Whenever parameter action or acceptance is dependent on other > parameters, the dependent parameters MUST be sent after the > parameters they depend on. If they are sent within the same command > a response for a parameter might imply responses for others. > > Eddy > > From owner-ips@ece.cmu.edu Thu Dec 20 09:48:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08023 for ; Thu, 20 Dec 2001 09:48:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKDsKn05719 for ips-outgoing; Thu, 20 Dec 2001 08:54:20 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKDsIZ05715 for ; Thu, 20 Dec 2001 08:54:18 -0500 (EST) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id IAA24622 for ips@ece.cmu.edu; Thu, 20 Dec 2001 08:54:12 -0500 (EST) Received: from compuserve.com (dal-tgn-tkj-vty34.as.wcom.net [206.175.238.34]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id IAA24603 for ; Thu, 20 Dec 2001 08:54:00 -0500 (EST) Message-ID: <3C21EDB0.50DE5EF@compuserve.com> Date: Thu, 20 Dec 2001 07:54:56 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: FCIP: Short Frame Security Solution Proposal Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit This message proposes a solution to the security issues surrounding the FCIP Short Frame proposed as a solution to the NAPTs problem. The security issues and directions toward a solution were discussed in Salt Lake and this message is an attempt to follow the path charted in those discussions. Solution Assumptions A) This matters a lot less if IPsec authentication is in use and rigorously managed because IPsec solves this authenticates TCP connections, substantially reducing the opportunity for rogue end-points to make TCP connections to FC/FCIP devices. B) Securing the first TCP connection in an FCIP Link is handled outside the scope of this solution. In Fibre Channel, securing the first TCP connection may be accomplished using FCAP. At this time, it is not clear whether FCAP authentication of the TCP connection needs to be mandatory or recommended for configurations exposed to security risks. C) Once authenticated, the first TCP connection is allowed to carry F Class frames. D) The objective of this solution is to authenticate the second to n-th TCP connections using a protocol that has lower overhead than FCAP or IPsec. Solution Changes in FCIP The principle change in FCIP is to REQUIRE the FCIP Entity to interact with the FC Entity to authenticate the second through n-th TCP connections for a given Link End Point (LEP). Upon receipt of an n-th TCP connect request and Short Frame (SF), the FCIP Entity MUST request (from the FC Entity) confirmation that the TCP connect request is from the same FC/FCIP Entity as the first TCP connection. The FCIP Entity MUST delay return of the SF until the FC Entity provides the confirmation. In addition, a new 64-bit nonce field is needed in the SF. Theoretically, the nonce field could overlay the Destination FC Fabric Entity WWN field. However, the current leaning is to add a new field, lengthening the FCIP Short Frame to the point where it will have to be called the FCIP Special Frame. The FCIP Entity shall communicate the newly defined SF nonce plus other SF information to the FC Entity in the interaction required to confirm the second through n-th TCP connect requests. Solution Changes in FC-BB-2 The principle changes in FC-BB-2 are: a) Discussion of how the FC Entity may respond to an FCIP Entity request for authentication of a second through n-th TCP connect request; b) Definition of a new SW_ILS to be used in confirming the second through n-th TCP connect requests; and c) Description of how the new SW_ILS is exchanged between the FC Entity where the TCP connect request is received an authenticated FC Entity over an existing F Class enabled TCP Connection. N.B. It is important that this negotiation be placed in the FC Entity because the Fibre Channel elements at each end of a link have in place protocol mechanisms for negotiations and exchanges of this type. Solution Mechanics When an FC/FCIP Entity makes a TCP connect request for what it knows to be the second to n-th TCP connection in an FCIP Link, it places a randomly generated 64-bit nonce in the SF. (Note: There needs to be requirements on the nonce generation method to ensure that predicting nonce values is sufficiently difficult. The ULP Framing draft has been recommended as a source for these requirements.) When an FCIP Entity receives a second to n-th TCP connect request, it will delay returning the SF until the SF nonce and other SF information is authenticated by the FC Entity. If the FC Entity reports that authentication failed, the FCIP Entity SHALL close the TCP connection. Details of the mechanism by which the FC Entity authenticates a second to n-th TCP Connect request are to be specified by T11 in FC-BB-2 (along with numerous other Fibre Channel protocol issues related to FCIP). A proposal containing at least the following will be made. The FC Entity may authenticate the TCP Connect request based on configuration information that is outside the scope of the standards. In situations where security risks are possible, the FC Entity shall transmit the information provided by the FCIP Entity via a new SW_ILS on a previously authenticated TCP connection (FCIP Data Engine) enabled for Class F frames. It can be assumed that an authenticated TCP connection enabled for F Class frames exists because the absence on such a connection prohibits basic Fibre Channel link operation (i.e., the problem must be dealt with as a general concern for FC-BB-2 operation over FCIP.) The response to the new SW_ILS will be one of: SW_ACC - indicating that the new TCP Connect request is authenticated SW_RJT - indicating that the new TCP Connect request is not authenticated The response shall be communicated to the FCIP Entity who shall act accordingly, as described above. An FC Entity that receives one of the new SW_ILSs shall perform the requested authentication by verifying that it initiated a TCP connect request and sent the SF nonce. The results of the authentication shall be communicated in the response to the SW_ILS as described above. To further increase the difficulty of snooping TCP connections, an FCIP Entity that receives a duplicate nonce shall close the connection on which that nonce was received immediately without causing the SW_ILS to be sent. Solution Pragmatics This solution binds the authentication of the second through n-th TCP connections to the authentication of the first TCP connection, thus fitting the solution within the bounds of the assumptions (but no more). Once the first TCP connection is properly authenticated, it is reasonable to ask the FC/FCIP Entity at the other end, "Did you make this additional TCP connect request?" The nonce (properly guaranteed for randomness) represents the "this" aspect of the question and renders nearly impossible nonce replay attacks wherein the FC/FCIP Entity asked the SW_ILS question is fooled into believing that SW_ACC should be sent because a correct nonce is presented. This solution slows down the process of establishing TCP connections, but that seems unavoidable. It may be desirable to require that there be no attempts to establish the second through n-th TCP connections until the first is authenticated. This is another slow down in the process, but one that will be imposed anyway at a later step. It may be desirable to further slow down the process by requiring FC/FCIP Entities to process only one TCP connect request at a time, rejecting all TCP connect requests that arrive while another is in process. This will further add to the difficulty of mounting a replay attack. From owner-ips@ece.cmu.edu Thu Dec 20 12:00:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12511 for ; Thu, 20 Dec 2001 12:00:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKFVkZ12516 for ips-outgoing; Thu, 20 Dec 2001 10:31:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKFVhZ12509 for ; Thu, 20 Dec 2001 10:31:44 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id HAA12064 for ; Thu, 20 Dec 2001 07:31:43 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 10:31:34 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF2869CE38@xbl.ad.emulex.com> From: "Ostrowski, Stephen" To: "Ips (ips@ece.cmu.edu)" Subject: Initiator port groups???? Date: Thu, 20 Dec 2001 10:31:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1896B.660F76C0" Sender: owner-ips@ece.cmu.edu 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_01C1896B.660F76C0 Content-Type: text/plain I would like to suggest a change in the initiator name. I would like to be able to add an optional port group tag number at the end. Example: OLD: iqn.2001-03.com.service-provider.users.customer235.host90 NEW: iqn.2001-03.com.service-provider.users.customer235.host90,10 OLD: eui.02004567A425678D NEW: eui.02004567A425678D,11 The problem that I am trying to solve is how to build a San Management Platform to do the initiator to target mapping and once a mapping has occurred, how to make sure the right connection is being made. For example: I have an initiator with 3 HBAs, and a target with 3 hbas. The discovery information provided to the Management platform could see that I have ONE initiator and a target with say 3 Port Groups. With this I can map the initiator to the target, or the initiator to 1 or more port groups. I would like to the same idea to the initiator name to include a field like that so that I could easily expand the choices to maybe map a target port group to an initiator HBA. 1 -- -- 1 Initiator(I) 2 -- Network -- 2 Target(T) 3 -- -- 3 I.e. Before I could do the following: I -> T I -> T1 I -> T2 I -> T1, T2 ETC... If I added the info to the initiator name I could also do the following mappings: I1 -> T1, I2 -> T2 I1 -> T, I2 -> T Etc.. - Stephen ------_=_NextPart_001_01C1896B.660F76C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I would like to suggest a change in the initiator name. I would like to = be able to add an optional port group tag number at the = end.

Example:

OLD: iqn.2001-03.com.service-provider.users.customer235.host90 =

NEW: = iqn.2001-03.com.service-provider.users.customer235.host90,10

OLD: eui.02004567A425678D

NEW: eui.02004567A425678D,11

 

 

The problem that I am trying to solve is how to build a San Management = Platform to do the initiator to target mapping and once a mapping has occurred, how = to make sure the right connection is being made.

 

For example: I have an initiator with 3 HBAs, and a target with 3 hbas. The discovery information provided to the Management platform could see = that I have ONE initiator and a target with say 3 Port Groups. 

      With this I can map the initiator to the target, or the initiator to 1 or = more port groups.  I would like to = the same idea to the initiator name to include a field like that so that I could easily = expand the choices to maybe map a target port group to an initiator = HBA.

 

            &nb= sp;  1 --       &nb= sp;    -- 1

 Initiator(I)  2 --  Network   -- = 2  = Target(T)

       &nb= sp;       3 --       &nb= sp;    -- 3

 

 I.e. Before I could do the = following:

 I -> = T

 I -> = T1

 I -> = T2

 I -> T1, = T2

 ETC...<= /p>

 

 If I added the info to the = initiator name I could also do the following mappings:

 I1 -> T1, I2 -> = T2

 I1 -> T, I2 -> = T

 Etc..

 

 

 - = Stephen

 

 

 

 

------_=_NextPart_001_01C1896B.660F76C0-- From owner-ips@ece.cmu.edu Thu Dec 20 12:31:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13654 for ; Thu, 20 Dec 2001 12:31:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGim218119 for ips-outgoing; Thu, 20 Dec 2001 11:44:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGihZ18096; Thu, 20 Dec 2001 11:44:43 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA96672; Thu, 20 Dec 2001 17:44:34 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGj9Z86082; Thu, 20 Dec 2001 17:45:09 +0100 Subject: Re: iSCSI: F and TTT=0xFFFFFFFF in final text response To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 00:38:40 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:07 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKGiiZ18099 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Thanks - will do something - Julo "Eddy Quicksall" Sent by: cc: owner-ips@ece.cmu. Subject: iSCSI: F and edu TTT=0xFFFFFFFF in final text response 18-12-01 02:21 Section 3.11.1 says that the F bit is set to 1 when the target has finished. Then 3.10.3 implies that the target must set the TTT to 0xFFFFFFFF in the final response (it is also backed up by an example). Since the F bit should tell the story and we shouldn't have two ways to tell when the target is finished, I think we should not make this implication. Can we add a statement that says 3.10.3 "Note that the TTT is not applicable when the target sets the F bit to 1". 3.11.1 "When the F bit is set to 1 in a text response, the TTT is not applicable"? Or if there is a good reason for this, then we should state it clearly. Eddy From owner-ips@ece.cmu.edu Thu Dec 20 12:33:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13727 for ; Thu, 20 Dec 2001 12:33:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGip318137 for ips-outgoing; Thu, 20 Dec 2001 11:44:51 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGilZ18115 for ; Thu, 20 Dec 2001 11:44:47 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA50322 for ; Thu, 20 Dec 2001 17:44:39 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjDZ86096 for ; Thu, 20 Dec 2001 17:45:14 +0100 Subject: Re: iSCSI: text spanning To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 01:39:35 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:11 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKGimZ18120 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, This very issue was subject of debate and I supported the idea of text keys not spanning a record. Unfortunately some other requirements made us support a single receive dictated PDU length and the minimum is uncomfortably low for text keys (512 bytes). This is what made me change sides and support keys spanning PDUs. Julo "Eddy Quicksall" Sent by: cc: owner-ips@ece.cmu. Subject: iSCSI: text spanning edu 18-12-01 18:54 Section 3.10.4 says: A Key=value pair can span Text request or response boundaries (i.e. a key=value pair can start in one PDU and continue on the next). This paragraph says that code must be able to process every text request/response in such a way as to accommodate really silly possibilities (like "ke" in one PDU and "y=value" in the next). This could be a bit of a burden for low end controllers. I don't think that was the intent of the statement. Can we think of better wording to cover the needed case without impacting the simple case? Eddy From owner-ips@ece.cmu.edu Thu Dec 20 12:33:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13747 for ; Thu, 20 Dec 2001 12:33:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGisZ18144 for ips-outgoing; Thu, 20 Dec 2001 11:44:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGinZ18125 for ; Thu, 20 Dec 2001 11:44:49 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA86148 for ; Thu, 20 Dec 2001 17:44:41 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjEk49516 for ; Thu, 20 Dec 2001 17:45:14 +0100 Subject: Re: iSCSI: first CmdSN clearification To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 03:05:50 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:14 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKGioZ18132 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit It is an example. It stresses that the first non-immediate after login still carries the same number - as you would expect. Julo "Eddy Quicksall" Sent by: cc: owner-ips@ece.cmu. Subject: iSCSI: first CmdSN edu clearification 18-12-01 23:27 3.12.9 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login request of a session - the "leading" login) or the command sequence number in the command stream (e.g., if the leading login carries the CmdSN 123 all other Login requests carry the CmdSN 123 and the first non-immediate command also carries the CmdSN 123). The target MUST use the value presented with the first login request. Why does it spell out "the first non-immediate command"? It would seem like it should just say "the first command ? ". Because immediate commands always get the next CmdSN anyway. Eddy From owner-ips@ece.cmu.edu Thu Dec 20 12:34:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13773 for ; Thu, 20 Dec 2001 12:34:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGiiL18098 for ips-outgoing; Thu, 20 Dec 2001 11:44:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGieZ18085; Thu, 20 Dec 2001 11:44:40 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA56284; Thu, 20 Dec 2001 17:44:32 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGj4k103254; Thu, 20 Dec 2001 17:45:04 +0100 Subject: RE: iSCSI: responding to a logout request To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 00:34:20 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKGifZ18088 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit thanks - julo "Eddy Quicksall" Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI: responding to a edu logout request 18-12-01 01:43 I think I made an error in my suggested wording? It should be: Initiator MUST send a Logout with a reason code of "Close the connection" (if using multiple connections) or "Close the session" (if not using multiple connections). Eddy -----Original Message----- From: Amir Shalit [mailto:amir@astutenetworks.com] Sent: Monday, December 17, 2001 5:23 PM To: Eddy Quicksall Subject: RE: iSCSI: responding to a logout request It can also change to: Initiator MUST send a Logout with a reason code of "Close the connection" or "Close the session". Why do we have to close multiple connections, at the iSCSI level, one by one? Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 17, 2001 12:31 PM To: ips@ece. cmu. edu (E-mail) Subject: iSCSI: responding to a logout request Section 3.9.1 says: Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session"[ESQ1] , to completely close the session, but ONLY if it does not support or use multiple connections in the specific session. I think this should say: Initiator MUST send a Logout with a reason code of "Close the connection" (if not the only connection) or "Close the session" (if using multiple connections). Because once you comply with the 1(superscript: st) sentence, you would not be able To comply with the 2(superscript: nd) sentence. Eddy [ESQ1] If a target closes the connection and there is only one connection, issue two logouts (one to close the connection and one to close the session)? But how if you just closed the connection. From owner-ips@ece.cmu.edu Thu Dec 20 12:34:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13797 for ; Thu, 20 Dec 2001 12:34:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGiv818159 for ips-outgoing; Thu, 20 Dec 2001 11:44:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGiqZ18139 for ; Thu, 20 Dec 2001 11:44:52 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA52224 for ; Thu, 20 Dec 2001 17:44:44 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjGk108554 for ; Thu, 20 Dec 2001 17:45:16 +0100 Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 03:09:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Make a note about when a CRC has to be valid. Julo pat_thaler Sent by: To: ltuikov@yahoo.com, owner-ips@ece. pat_thaler@agilent.com, ni1d@arrl.net, cmu.edu vince_cavanna@agilent.com cc: ips@ece.cmu.edu Subject: RE: effect of initializing 18-12-01 23:32 CRC reg to 1's depends on implementati on? iSCSI Luben, I have a pretty fair idea of the constraints on Ethernet implementations having worked on Ethernet implementations and standards for over 15 years. The issue is not whether a certain implementation is common or not. It isn't the merits of one implementation method over another. The point is that whereever possible (that is wherever it doesn't damage interoperability) standards should be written in terms of results - that is in terms of the behavior of the black box at its interfaces. Any implementation that produces that behavior is valid and the implementor should be left with the freedom to use whatever implementation method fits the implementation's circumstances. I agree with the analysis of D and SMD. SMD is a widely used implementation method. However, that is irrelavent to what should go into the standard. By the way, there is an error in your statement below with respect to Ethernet behavior: "A good CRC algorithm will have to be as strong as being able to produce the CRC at any time. That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived. I.e. in any moment in time, if I were to say STOP, I would have to be able to ``produce'' the right CRC." Actually and Ethernet implementation is specifically required not to behave this way. If you will refer to IEEE 802.3 4.2.9 procedure ReceiveLinkMgmt processes the frame before function ReceiveDataDecap checks the CRC (an interaction controlled by receiveSucceeding). ReceiveLinkManagement truncates the frame to an octet boundary. This was done to be tolerant of some untidy physical layer implementations that add a few "dribble bits" to frames (sad but true). The CRC is the last 4 full octets of the frame rather than the last 32 bits - a difference that only matters when there are dribble bits. If an implementation calculated the CRC as each bit arrived, it would have to back out the effect of the dribble bits to check the CRC on an octet boundary which would be inconvenient. Most implementations I am aware of calculate the CRC on a byte or multi-byte parallel basis rather than a bit at a time. Regards, Pat -----Original Message----- From: Luben Tuikov [mailto:ltuikov@yahoo.com] Sent: Monday, December 17, 2001 8:04 PM To: THALER,PAT (A-Roseville,ex1); Paul Koning; VICENTE V CAVANNA Cc: ips@ece.cmu.edu Subject: RE: effect of initializing CRC reg to 1's depends on implementati on? iSCSI Pat, First I refer you to this message by Vince. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08109.html Read it again, please. Then, let us think a bit. In Ethernet realm, we get bits off the wire, one at a time. A good CRC algorithm will have to be as strong as being able to produce the CRC at any time. That is, it has to have the correct CRC _after_ _each_ _bit_ has arrived. I.e. in any moment in time, if I were to say STOP, I would have to be able to ``produce'' the right CRC. In other words, the algorithm needs NOT know in advance how many bits there are of the message. This eliminates the need to store the whole message and then ``multiply it by x^32''. I.e. I need only 32 + 1 bits of storage to compute the CRC of any length message, and I can do so as the bits are coming in from/to the wire, no need to store any bits. 32 for the CRC and 1 for the newly arrived bit. I don't need to know the previous or next bits. AND I will give you a CRC which is the same as if you HAD multiplied the message by x^32, and done division of the message, putting a suitable constant in the CRC register (equivalent to prepending the message by it and CRC=0) in D. You see, this is the whole point of SMD (Simultaneous Multiply and Divide) algorithm. It needs not multiply by x^32, or prepend the message. This multiplication of x^32 is needed only when we are in D (simple Division) algorithm. And this is where it is coming from. Lets see a simple example in the decimal system: let G(x) = 4 and M(x) = 7 (WLG). then R(x) = 7 modulo 4 = 3 But this is wrong, we should have computed the remainder of 70 modulo 4 which is 2. and then we'd send 72, which has remainder 0 modulo 4. And this is the SMD in Ethernet (WLG), if you feed it 7 it will tell you 2 (not 3), so that you can append 2 at the end to get 72 which has 0 remainder, etc. Once we have a 0 remainder I can add any value from 1 to 3 to get that value back when the thing is received and the remainder is computed e.g. 7 append (2+1) = 73. 73 modulo 4 = 1, etc. as per the spec. and this is where the magical constant comes from... And then the next digit comes along, say 5, now we have 75, but the algorithm gives 2 (rather than 75 modulo 4 = 3). And 2 is correct since 752 modulo 4 = 0... So you see, before quoting the document, please try to actually implement it, at least. And then see how that would fit into Ethernet. You can even implement it by hand, as arithmetic in Z_2 is quite easy (XOR). And the make things interesting make the message be one bit longer than G(x), i.e. 34 bits. Then you'll see how cumbersome is the multiplication by x^32. And that a better way has to exist. In fact SMD is what is actually implemented in Ethernet, and in a real circuit I bet you'd never see actual multiplication by x^32. -l ===== -- __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-ips@ece.cmu.edu Thu Dec 20 12:35:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13836 for ; Thu, 20 Dec 2001 12:35:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGis818150 for ips-outgoing; Thu, 20 Dec 2001 11:44:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGimZ18124 for ; Thu, 20 Dec 2001 11:44:49 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id RAA55996 for ; Thu, 20 Dec 2001 17:44:41 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjDk123774 for ; Thu, 20 Dec 2001 17:45:13 +0100 Subject: Re: iSCSI Session Recovery - primary/secondary iSCSI targets? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 03:00:39 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, I am not sure what you are after. As long as you don't kill or let the session die you can keep it alive by replacing failing connections with new connections. If you let the session die but would like to rebuild the session with the target and initiator (the SCSI entities) perceiving the same nexus you can do this too - within the bounds of the naming structures. Julo "Dave Francheski" To: Julian Satran/Haifa/IBM@IBMIL stems.com> Subject: iSCSI Session Recovery - primary/secondary iSCSI targets? 18-12-01 21:52 Julian, If there are multiple network paths from an iSCSI initiator to the *same* iSCSI target, and one of the paths permanently goes down, is there any *standardized* way of performing Session Recovery such that the iSCSI initiator can point to the iSCSI target using the alternate/secondary network path? This would imply that the initiator would have to restart a session on a new set of connection(s) using the alternate network path (should the primary one continue to fail). Perhaps one way is to use multiple iSCSI target names/portals to represent each independent path through the network. If this approach were taken, there doesn't appear to be any standardized way of retrieving *primary*/*secondary* iSCSI target names during Session failure recovery. (At least reading through section 8.11.4 of Draft 09 doesn't mention this.) Best regards, Dave Francheski Seven Systems Technologies 575 Menlo Drive Suite 2 Rocklin CA 916-577-1281 davef@seven-systems.com From owner-ips@ece.cmu.edu Thu Dec 20 12:47:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14355 for ; Thu, 20 Dec 2001 12:47:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGiw618161 for ips-outgoing; Thu, 20 Dec 2001 11:44:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGiuZ18155 for ; Thu, 20 Dec 2001 11:44:56 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA86328 for ; Thu, 20 Dec 2001 17:44:48 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjNZ125944 for ; Thu, 20 Dec 2001 17:45:23 +0100 Subject: Re: iSCSI: What can go on during a text negotiation? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 03:57:20 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk As our thinking stands today - anything but another text negotiation on the same connection. Julo "Eddy Quicksall" Sent by: cc: owner-ips@ece.cmu. Subject: iSCSI: What can go on edu during a text negotiation? 19-12-01 19:09 Can anything go on during a text negotiation? I.e., does the I/O continue as normal if a text request is sent but the text response has not been sent yet? Or, if a multi-message parameter negotiation is going on but it has not finished yet. Eddy From owner-ips@ece.cmu.edu Thu Dec 20 12:50:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14445 for ; Thu, 20 Dec 2001 12:50:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKGiop18126 for ips-outgoing; Thu, 20 Dec 2001 11:44:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKGikZ18112 for ; Thu, 20 Dec 2001 11:44:46 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id RAA113800 for ; Thu, 20 Dec 2001 17:44:38 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKGjAZ29140 for ; Thu, 20 Dec 2001 17:45:10 +0100 Subject: RE: iSCSI: scope of keys To: ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Thu, 20 Dec 2001 01:28:56 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 20/12/2001 18:45:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This key must be sent on the first login request on every connection - it is part of the session identity. Julo "Eddy Quicksall" cc: 18-12-01 17:25 Subject: RE: iSCSI: scope of keys IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Thu Dec 20 14:26:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17806 for ; Thu, 20 Dec 2001 14:26:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKIdte26985 for ips-outgoing; Thu, 20 Dec 2001 13:39:55 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKIdrZ26980 for ; Thu, 20 Dec 2001 13:39:53 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id AF0B6040136; Thu, 20 Dec 2001 12:33:47 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A04916D0114; Thu, 20 Dec 2001 12:39:05 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: same ISID Date: Thu, 20 Dec 2001 13:39:27 -0500 Message-ID: <002f01c18985$a8229960$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C1895B.BF4C9160" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C1895B.BF4C9160 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Section 9.1.1 says: the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets). Note that the ISID RULE (2.5.3) only prohibits reuse to the same target portal group. It also does not "preclude" reuse to other target portal groups. The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source). This is good but the target will still have to sort out ISID's when they are different under the same situations named above. So, since the target still has to have all the code to sort this out, what good is this statement? I think the only thing keeping us from saying you MUST use the same ISID's is the fact that we have allowed an iSCSI Initiator to have more than one session to the iSCSI Target Portal Group. Is that really necessary? If not, then we could make this a MUST and simplify the target code. Eddy ------=_NextPart_000_0030_01C1895B.BF4C9160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 9.1.1 = says:

 

 the same ISID should be used in the Login process to = multiple

 target portal groups (of the same iSCSI Target or = different iSCSI

 Targets).  = Note that the ISID RULE (2.5.3) only prohibits reuse to

 the same target portal group.  It also does not "preclude" reuse to =

 other target portal groups. 

 The principle of conservative reuse = "encourages" reuse to other

 target portal groups.  When a SCSI target device sees the same

 (InitiatorName, ISID) pair in different sessions to = different target

 portal groups, it can identify the underlying SCSI = Initiator Port on

 each session as the same SCSI port (in effect, it can recognize

 multiple paths from the same = source).

 

This is good but the = target will still have to sort out ISID's when they

are different under the = same situations named above. So, since the

target still has to have = all the code to sort this out, what good is

this = statement?

 

I think the only thing = keeping us from saying you MUST use the same

ISID's is the fact that we = have allowed an iSCSI Initiator to have more than

one session to the iSCSI = Target Portal Group. Is that really necessary? If not,

then we could make this a = MUST and simplify the target code.

 

Eddy

 

------=_NextPart_000_0030_01C1895B.BF4C9160-- From owner-ips@ece.cmu.edu Thu Dec 20 14:27:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17837 for ; Thu, 20 Dec 2001 14:27:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKIDJe24838 for ips-outgoing; Thu, 20 Dec 2001 13:13:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKIDDZ24828 for ; Thu, 20 Dec 2001 13:13:13 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A8CB4050136; Thu, 20 Dec 2001 12:07:07 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id AA141A80102; Thu, 20 Dec 2001 12:12:36 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: negotiated more than once Date: Thu, 20 Dec 2001 13:13:05 -0500 Message-ID: <002a01c18981$fa53b1a0$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C18958.117DA9A0" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C18958.117DA9A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Section 5 says: Both initiator and target MUST NOT attempt to negotiate a parameter more than once during any login stage. Attempting to do so MUST result in the login (and connection) being terminated. But section 6 says: Both initiator and target MUST NOT attempt to negotiate a parameter more than once during any negotiation sequence without an intervening reset. If detected by the target this MUST result in a Reject with a reason of "protocol error". The initiator MUST reset the negotiation as outlined above. A reject could mean to terminate the connection but a “reset” doesn’t. So, are these statements consistent? Notice that section 6 says “sequence” but section 5 says “login stage”. Is that the difference? Eddy _____ ------=_NextPart_000_002B_01C18958.117DA9A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Section 5 = says:<= /p>

 <= /p>

 Both initiator and target MUST = NOT attempt to negotiate a parameter

 more than once during any login = stage. Attempting to do so MUST

 result in the login (and = connection) being terminated.

 

But section 6 says:

 

 Both initiator and target MUST = NOT attempt to negotiate a parameter

 more than once during any = negotiation sequence without an intervening

 reset. If detected by the = target this MUST result in a Reject with a

 reason of "protocol = error".  The initiator MUST reset the negotiation

 as outlined = above.

 

A reject could mean to terminate the connection but a “reset” = doesn’t. So, are these statements consistent? Notice that section 6 says = “sequence” but section 5 says “login stage”. Is that the = difference?

 

Eddy<= /p>

------=_NextPart_000_002B_01C18958.117DA9A0-- From owner-ips@ece.cmu.edu Thu Dec 20 15:29:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19529 for ; Thu, 20 Dec 2001 15:29:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKIqef27940 for ips-outgoing; Thu, 20 Dec 2001 13:52:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKIqbZ27927 for ; Thu, 20 Dec 2001 13:52:37 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A1FD6AF0136; Thu, 20 Dec 2001 12:46:21 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A343848011A; Thu, 20 Dec 2001 12:51:47 -0600 From: "Eddy Quicksall" To: "'Julian Satran'" , Subject: RE: iSCSI: scope of keys Date: Thu, 20 Dec 2001 13:52:15 -0500 Message-ID: <003401c18987$72193750$0102a8c0@eddydesktop> 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 V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree but what I was pointing out originally is that the "use" does not specifically say if this key applies to the session or if it applies only to the connection. I may have thrown you off by my example. If no one else thinks this is a problem I'll back off (but I think Mallikarjun, at least partially, agreed with me). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, December 19, 2001 6:29 PM To: ips@ece.cmu.edu Subject: RE: iSCSI: scope of keys This key must be sent on the first login request on every connection - it is part of the session identity. Julo "Eddy Quicksall" cc: 18-12-01 17:25 Subject: RE: iSCSI: scope of keys IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Thu Dec 20 16:25:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21055 for ; Thu, 20 Dec 2001 16:25:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKKbml05783 for ips-outgoing; Thu, 20 Dec 2001 15:37:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKKblZ05779 for ; Thu, 20 Dec 2001 15:37:47 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA133258; Thu, 20 Dec 2001 15:34:53 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKKbiJ214586; Thu, 20 Dec 2001 13:37:44 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: same ISID To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Dec 2001 11:55:54 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/20/2001 01:37:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKKblZ05780 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Eddy, The purpose here is not what you are looking at. First, the Target iSCSI (SCSI) Port can inspect all the session arriving at its Portal Group, to see if any have the same Initiator name and ISID as another one. If so, it is Not Logged-in. This would be parallel Sessions from the same initiator. Second, when an Initiator comes back after a failure, they should use the same ISID they had previously, thereby permitting approprate Nexus to be continued e.g. Persistent Reserves, etc. The second point was the primary reasons for the Conservative reuse. Before this statement, some folks were using a different ISID for each Target Node with which they were working. Then the ISID space could get used up, and then as sessions were stopped and restarted, they would retrieve an ISID from an available pool of ISIDs, and as a result, the approprate Nexus could not be re-established. Hence the words Conservative Reuse means you keep reusing the same ISID number as often as possible. Therefore, you will probably see an individual Initiator have only 1 ISID, ever used. It is only when a Wedge Driver of some type permits Multiple Initiators from the same Host, that you are likely to see the same Initiator Name, and Different ISID. But Still, into any one portal group and Target iSCSI (SCSI) Port there will only be one active "Initiator Name + ISID" entity. Each unique "Initiator Name + ISID" are treated (today) as if they are as different as if they came from different hosts. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/20/2001 10:39:27 AM Sent by: owner-ips@ece.cmu.edu To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: same ISID Section 9.1.1 says:  the same ISID should be used in the Login process to multiple  target portal groups (of the same iSCSI Target or different iSCSI  Targets).  Note that the ISID RULE (2.5.3) only prohibits reuse to  the same target portal group.  It also does not "preclude" reuse to  other target portal groups.  The principle of conservative reuse "encourages" reuse to other  target portal groups.  When a SCSI target device sees the same  (InitiatorName, ISID) pair in different sessions to different target  portal groups, it can identify the underlying SCSI Initiator Port on  each session as the same SCSI port (in effect, it can recognize  multiple paths from the same source). This is good but the target will still have to sort out ISID's when they are different under the same situations named above. So, since the target still has to have all the code to sort this out, what good is this statement? I think the only thing keeping us from saying you MUST use the same ISID's is the fact that we have allowed an iSCSI Initiator to have more than one session to the iSCSI Target Portal Group. Is that really necessary? If not, then we could make this a MUST and simplify the target code. Eddy From owner-ips@ece.cmu.edu Thu Dec 20 16:27:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21104 for ; Thu, 20 Dec 2001 16:27:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKKUhu05064 for ips-outgoing; Thu, 20 Dec 2001 15:30:43 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKKUfZ05055 for ; Thu, 20 Dec 2001 15:30:41 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 44B2CE004BE; Thu, 20 Dec 2001 12:30:35 -0800 (PST) Received: from cup.hp.com (santoshr@hpindhhm.cup.hp.com [15.8.80.197]) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id MAA29236; Thu, 20 Dec 2001 12:30:29 -0800 (PST) Message-ID: <3C224CE7.60AA34CD@cup.hp.com> Date: Thu, 20 Dec 2001 12:41:11 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Eddy Quicksall Cc: "ips@ece. cmu. edu (E-mail)" Subject: Re: iSCSI: same ISID References: <002f01c18985$a8229960$0102a8c0@eddydesktop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, I am opposed to the suggestion that "conservative re-use" of ISIDs be made a MUST. THis is really only required when initiators need to be using the new T10 Reservation scheme that can be shared across initiator ports. For those initiators that don't care about this type of reservation, conservative re-use is of no use and initiators may like to assign ISID's in a per-initiator node fashion, thereby, being able to use these ISIDs as a lookup index for the sessions on that initiator node. Hence, I suggest that "conservative re-use" be worded as "encouraged to use" or something to that effect, but not MUST USE. Comments ? Regards, Santosh -------------------------------------------------------------------------------- Subject: iSCSI: same ISID Date: Thu, 20 Dec 2001 13:39:27 -0500 From: "Eddy Quicksall" To: "ips@ece. cmu. edu (E-mail)" Section 9.1.1 says: the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets). Note that the ISID RULE (2.5.3) only prohibits reuse to the same target portal group. It also does not "preclude" reuse to other target portal groups. The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source). This is good but the target will still have to sort out ISID's when they are different under the same situations named above. So, since the target still has to have all the code to sort this out, what good is this statement? I think the only thing keeping us from saying you MUST use the same ISID's is the fact that we have allowed an iSCSI Initiator to have more than one session to the iSCSI Target Portal Group. Is that really necessary? If not, then we could make this a MUST and simplify the target code. Eddy -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Dec 20 17:45:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23497 for ; Thu, 20 Dec 2001 17:45:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKLSbF09635 for ips-outgoing; Thu, 20 Dec 2001 16:28:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKLSZZ09630 for ; Thu, 20 Dec 2001 16:28:35 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id A6864900CC; Thu, 20 Dec 2001 15:22:14 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id A7AD94B00D0; Thu, 20 Dec 2001 15:27:09 -0600 From: "Eddy Quicksall" To: "'Santosh Rao'" Cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: iSCSI: same ISID Date: Thu, 20 Dec 2001 16:27:31 -0500 Message-ID: <004901c1899d$2414fab0$0102a8c0@eddydesktop> 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 V6.00.2600.0000 In-Reply-To: <3C224CE7.60AA34CD@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, John cleared it up for me ... I misunderstood the intent. Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Thursday, December 20, 2001 3:41 PM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail) Subject: Re: iSCSI: same ISID Eddy, I am opposed to the suggestion that "conservative re-use" of ISIDs be made a MUST. THis is really only required when initiators need to be using the new T10 Reservation scheme that can be shared across initiator ports. For those initiators that don't care about this type of reservation, conservative re-use is of no use and initiators may like to assign ISID's in a per-initiator node fashion, thereby, being able to use these ISIDs as a lookup index for the sessions on that initiator node. Hence, I suggest that "conservative re-use" be worded as "encouraged to use" or something to that effect, but not MUST USE. Comments ? Regards, Santosh ------------------------------------------------------------------------ -------- Subject: iSCSI: same ISID Date: Thu, 20 Dec 2001 13:39:27 -0500 From: "Eddy Quicksall" To: "ips@ece. cmu. edu (E-mail)" Section 9.1.1 says: the same ISID should be used in the Login process to multiple target portal groups (of the same iSCSI Target or different iSCSI Targets). Note that the ISID RULE (2.5.3) only prohibits reuse to the same target portal group. It also does not "preclude" reuse to other target portal groups. The principle of conservative reuse "encourages" reuse to other target portal groups. When a SCSI target device sees the same (InitiatorName, ISID) pair in different sessions to different target portal groups, it can identify the underlying SCSI Initiator Port on each session as the same SCSI port (in effect, it can recognize multiple paths from the same source). This is good but the target will still have to sort out ISID's when they are different under the same situations named above. So, since the target still has to have all the code to sort this out, what good is this statement? I think the only thing keeping us from saying you MUST use the same ISID's is the fact that we have allowed an iSCSI Initiator to have more than one session to the iSCSI Target Portal Group. Is that really necessary? If not, then we could make this a MUST and simplify the target code. Eddy -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## From owner-ips@ece.cmu.edu Thu Dec 20 18:42:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24949 for ; Thu, 20 Dec 2001 18:42:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKMc0514647 for ips-outgoing; Thu, 20 Dec 2001 17:38:00 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKMbwZ14642 for ; Thu, 20 Dec 2001 17:37:58 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id OAA23118; Thu, 20 Dec 2001 14:37:21 -0800 (PST) From: "Murali Rajagopal" To: Cc: "IPS Reflector" Subject: FCIP Port Numbers Date: Thu, 20 Dec 2001 14:36:46 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3C21EDB0.50DE5EF@compuserve.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph: IANA has notified me that the following port numbers have been assigned for FCIP: fcip-port 3225/tcp FCIP fcip-port 3225/udp FCIP -Murali From owner-ips@ece.cmu.edu Thu Dec 20 19:17:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25646 for ; Thu, 20 Dec 2001 19:17:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBKNHBe17221 for ips-outgoing; Thu, 20 Dec 2001 18:17:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBKNH9Z17216 for ; Thu, 20 Dec 2001 18:17:09 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA33684; Thu, 20 Dec 2001 18:13:27 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBKNGAN46580; Thu, 20 Dec 2001 16:16:10 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: Initiator port groups???? To: "Ostrowski, Stephen" Cc: "Ips (ips@ece.cmu.edu)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Dec 2001 13:18:58 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/20/2001 04:16:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBKNHAZ17217 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit The direction you are going, is not the direction we intended to take iSCSI. The Authentication and Masking should be done on an Initiator Node Name value, NOT based on an HBA. There may be multiple HBAs involved in a single, iSCSI Session. Also there might be more then one initiator in a Initiator Node (perhaps each with more then one HBA), I do not see why there would need to be management beyond the Node Name. The Authentication is suppose to be done on a Node Name Basis. In any event the Initiator does not have Portal Group Tags, and Target Portal Group tags are not required to be Static from Target Startup to Target Startup. This Discovery process is suppose to Discover the current values of these items. They are NOT part of the NodeName. Also, the Node Names are suppose to be Long lasting Names, portal groups have no such need. So it is a twist to bring both together and call that an iSCSI Name. Now, if you just intend to do mapping for the purpose of rendering a picture of the network and connections, I suggest you look at the iSCSI MIB Drafts and see how that might be useful or the iSCSI Technical Work Group in SNIA, which is defining APIs for the HBAs. In other words you need to find another way to do what you want. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Ostrowski, Stephen" @ece.cmu.edu on 12/20/2001 07:31:30 AM Sent by: owner-ips@ece.cmu.edu To: "Ips (ips@ece.cmu.edu)" cc: Subject: Initiator port groups???? I would like to suggest a change in the initiator name. I would like to be able to add an optional port group tag number at the end. Example: OLD: iqn.2001-03.com.service-provider.users.customer235.host90 NEW: iqn.2001-03.com.service-provider.users.customer235.host90,10 OLD: eui.02004567A425678D NEW: eui.02004567A425678D,11 The problem that I am trying to solve is how to build a San Management Platform to do the initiator to target mapping and once a mapping has occurred, how to make sure the right connection is being made. For example: I have an initiator with 3 HBAs, and a target with 3 hbas. The discovery information provided to the Management platform could see that I have ONE initiator and a target with say 3 Port Groups.       With this I can map the initiator to the target, or the initiator to 1 or more port groups.  I would like to the same idea to the initiator name to include a field like that so that I could easily expand the choices to maybe map a target port group to an initiator HBA.                1 --            -- 1  Initiator(I)  2 --  Network   -- 2  Target(T)                3 --            -- 3  I.e. Before I could do the following:  I -> T  I -> T1  I -> T2  I -> T1, T2  ETC...  If I added the info to the initiator name I could also do the following mappings:  I1 -> T1, I2 -> T2  I1 -> T, I2 -> T  Etc..  - Stephen From owner-ips@ece.cmu.edu Fri Dec 21 02:32:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16305 for ; Fri, 21 Dec 2001 02:32:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBL6g6n13108 for ips-outgoing; Fri, 21 Dec 2001 01:42:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dcmtechdom.dcmtech.co.in ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBL6frZ13092 for ; Fri, 21 Dec 2001 01:41:59 -0500 (EST) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 12:15:00 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A8FA@DCMTECHDOM> From: Nitin Dhingra To: "'Julian Satran'" , ips@ece.cmu.edu Subject: Re: Implicit Logout Date: Fri, 21 Dec 2001 12:14:58 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Can in any case login response provide implicit logout? Like if you open up a session for discovery, you got your target names, then why do u need to waste time on proper logout procedure, you could have implicit logout in the login response? From owner-ips@ece.cmu.edu Fri Dec 21 07:22:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22257 for ; Fri, 21 Dec 2001 07:22:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLBTv707832 for ips-outgoing; Fri, 21 Dec 2001 06:29:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLBTtZ07828 for ; Fri, 21 Dec 2001 06:29:55 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA28388; Fri, 21 Dec 2001 06:27:02 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBLBTqJ118868; Fri, 21 Dec 2001 04:29:53 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: scope of keys To: "Eddy Quicksall" Cc: "Julian Satran" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 20 Dec 2001 22:05:24 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/21/2001 04:29:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, It not only OK, it is required. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/18/2001 07:25:44 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: scope of keys IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Fri Dec 21 10:09:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24621 for ; Fri, 21 Dec 2001 10:09:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLEFaa16339 for ips-outgoing; Fri, 21 Dec 2001 09:15:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLEFYZ16335 for ; Fri, 21 Dec 2001 09:15:34 -0500 (EST) Received: from eddydesktop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id fBLEEi918791; Fri, 21 Dec 2001 09:14:45 -0500 (EST) From: "Eddy Quicksall" To: "'John Hufferd'" Cc: "'Julian Satran'" , Subject: RE: iSCSI: scope of keys Date: Fri, 21 Dec 2001 09:13:29 -0500 Message-ID: <000b01c18a29$da884360$0102a8c0@eddydesktop> 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, I think my point was missed. Now you have possibly pointed out another angle to my point. My point is that "use" does not contain enough information. In your response below, you have implied that IO now means "required" ... but it does not. I think that "use" has been overloaded and I think each key should have a list of properties (use is one, scope is another and now maybe required should be a third). Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, December 21, 2001 1:05 AM To: Eddy Quicksall Cc: Julian Satran; ips@ece.cmu.edu Subject: RE: iSCSI: scope of keys Eddy, It not only OK, it is required. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/18/2001 07:25:44 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: scope of keys IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Fri Dec 21 11:18:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25794 for ; Fri, 21 Dec 2001 11:18:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLFPuC21002 for ips-outgoing; Fri, 21 Dec 2001 10:25:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLFPaZ20956 for ; Fri, 21 Dec 2001 10:25:36 -0500 (EST) Received: from io.iol.unh.edu (IDENT:djwoolf@localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.1/8.12.1) with ESMTP id fBLFPUYM032359 for ; Fri, 21 Dec 2001 10:25:30 -0500 Received: from localhost (djwoolf@localhost) by io.iol.unh.edu (8.12.1/8.12.1/Submit) with ESMTP id fBLFPUku032356 for ; Fri, 21 Dec 2001 10:25:30 -0500 Date: Fri, 21 Dec 2001 10:25:30 -0500 (EST) From: David Woolf To: ips@ece.cmu.edu Subject: Login Request/Response PDU Formats Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hello, The tables describing both the Login Response and Login Request PDUs (3.12 and 3.13) indicate that at byte 48 a digest will appear if digests had been negotiated. This looks like a carry-over from when digests were negotiated in the Security phase, and would have been used in the Operational Parameter Negotiation. Perhaps the 'if any' statement in these tables should be removed. thank you, David Woolf ************************************************ University of New Hampshire Interoperability Lab iSCSI and Fibre Channel Consortiums Durham, NH 03824 (603) 862 0701 ************************************************ From owner-ips@ece.cmu.edu Fri Dec 21 12:49:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27743 for ; Fri, 21 Dec 2001 12:49:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLGNle25119 for ips-outgoing; Fri, 21 Dec 2001 11:23:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLGNjZ25114 for ; Fri, 21 Dec 2001 11:23:45 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id IAA06776; Fri, 21 Dec 2001 08:23:31 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 11:23:21 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF2869CE94@xbl.ad.emulex.com> From: "Ostrowski, Stephen" To: John Hufferd Cc: "Ips (ips@ece.cmu.edu)" Subject: RE: Initiator port groups???? Date: Fri, 21 Dec 2001 11:23:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27743 John, I missed port groups are dynamic across boots. I think that there MIGHT be a need for static mapping (or preference) for configuration. Example: I have an initiator with two HBAs. If the connection is made from HBA 1 to a certain target, then the connection would be secure, but if the connection if mode from HBA 2 to that target, then it would be insecure. So I would want to be able to configure that, and then to verify that the correct connection was being made during login. Also, I could also see the need to try to balance the traffic load across the HBAs in a non random way. - Stephen -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, December 20, 2001 4:19 PM To: Ostrowski, Stephen Cc: Ips (ips@ece.cmu.edu) Subject: Re: Initiator port groups???? The direction you are going, is not the direction we intended to take iSCSI. The Authentication and Masking should be done on an Initiator Node Name value, NOT based on an HBA. There may be multiple HBAs involved in a single, iSCSI Session. Also there might be more then one initiator in a Initiator Node (perhaps each with more then one HBA), I do not see why there would need to be management beyond the Node Name. The Authentication is suppose to be done on a Node Name Basis. In any event the Initiator does not have Portal Group Tags, and Target Portal Group tags are not required to be Static from Target Startup to Target Startup. This Discovery process is suppose to Discover the current values of these items. They are NOT part of the NodeName. Also, the Node Names are suppose to be Long lasting Names, portal groups have no such need. So it is a twist to bring both together and call that an iSCSI Name. Now, if you just intend to do mapping for the purpose of rendering a picture of the network and connections, I suggest you look at the iSCSI MIB Drafts and see how that might be useful or the iSCSI Technical Work Group in SNIA, which is defining APIs for the HBAs. In other words you need to find another way to do what you want. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Ostrowski, Stephen" @ece.cmu.edu on 12/20/2001 07:31:30 AM Sent by: owner-ips@ece.cmu.edu To: "Ips (ips@ece.cmu.edu)" cc: Subject: Initiator port groups???? I would like to suggest a change in the initiator name. I would like to be able to add an optional port group tag number at the end. Example: OLD: iqn.2001-03.com.service-provider.users.customer235.host90 NEW: iqn.2001-03.com.service-provider.users.customer235.host90,10 OLD: eui.02004567A425678D NEW: eui.02004567A425678D,11 The problem that I am trying to solve is how to build a San Management Platform to do the initiator to target mapping and once a mapping has occurred, how to make sure the right connection is being made. For example: I have an initiator with 3 HBAs, and a target with 3 hbas. The discovery information provided to the Management platform could see that I have ONE initiator and a target with say 3 Port Groups.       With this I can map the initiator to the target, or the initiator to 1 or more port groups.  I would like to the same idea to the initiator name to include a field like that so that I could easily expand the choices to maybe map a target port group to an initiator HBA.                1 --            -- 1  Initiator(I)  2 --  Network   -- 2  Target(T)                3 --            -- 3  I.e. Before I could do the following:  I -> T  I -> T1  I -> T2  I -> T1, T2  ETC...  If I added the info to the initiator name I could also do the following mappings:  I1 -> T1, I2 -> T2  I1 -> T, I2 -> T  Etc..  - Stephen From owner-ips@ece.cmu.edu Fri Dec 21 14:13:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29816 for ; Fri, 21 Dec 2001 14:13:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLIPe403048 for ips-outgoing; Fri, 21 Dec 2001 13:25:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lightsand.com ([64.214.104.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLIPcZ03043 for ; Fri, 21 Dec 2001 13:25:38 -0500 (EST) Received: from MURALIRLAPTOP ([192.168.2.60]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id KAA04588 for ; Fri, 21 Dec 2001 10:25:32 -0800 (PST) From: "Murali Rajagopal" To: Subject: FCIP: 12/19 Teleconference Minutes Date: Fri, 21 Dec 2001 10:24:58 -0800 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.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Minutes submitted by Kha Sin Teow, Brocade Roll call: Andy Neil, Ralph elizabeth, jim nelson raj anil ken hirata, milan merhar, brett ketcham, cnt venkat, dave peterson khasin bill krieg don fraser Agenda ------ - SF Security -Model -draft comments 1) Security - short frame - D. Black's response - ok if the nonce is 64-bit as mentioned in Ralph's write-up. But he (David) reserved the right to review the detailed description. 2) IESG Plenary Report from Elizabeth - one person expressed a very strong objection to the principle of design team (authors) - another comment about should be single author; no long author list 3) Comments to the latest docs - deadline - FC-BB meeting is in 1st week of Feb last call of FC-IP cannot proceed until until BB approval (plenary) - why is this an issue since Annex E has at least 12-13 items that are NOT completely stable? (Venkat) - Murali pointed out that the procedure is that BB-2 needs to be approved during the BB meeting; not outside - If IPS Chairs has issues with BB-2 not procedurally approved the short frame proposal just yet and not pass the last call, we should try to go with the last call. 4) Model - (Andy) model that Murali sent on on Dec 19 afternoon - Andy objects to the model of suggesting that there is one VE_Port to multi-link to another VE_POrt (not consistent with Fig 4 of the fcip draft); the intent of the model is not to imply that (Venkat and Ralph and Murali); so maybe the model should be changed editorially or some verbage be added to BB; so andy is ok with it then other then editorial mod. VE_Port and LEP - one to one - Anil: draft makes no mention of mutliple fcip entity pairs - Ralph is leary about adding more varbage; - Murali will post the model to the T11 reflector since there has been no visibility since Austin - 598v2 - show BPort and E_Port interaction also deal with talk to VE_Port. Need to understand B_Port. FCIP doesn't talk about B_port and E_Port.; no need to - that's FC entities problem and the intelligence behind which is covered in BB 5) comments on the draft - figure 5: need to add text about the "bundling" of the 3 tcp connections. - Murali: need to state/explain about multiple fcip links between multiple pairs of fcip entities; Ralph to come up with something in 5.2. - Anil: left over about IP address - to be replace with "FC-IP Identifier" do we need FC-IP Identifier? -Bob Snively to explain why the Id is necessary; also why the short frame - src has wwpn and fcip-id but dest don't have the fcip-id. would WWPN be sufficient? - Don will review all occurances of "close the (TCP) connection" and determine if it is appropropriate to add a phrase similar to "close and report back to the FC fabric". This is to keep the FCIP work in line with proposed changes to FC-BB-2 that will require notification from a gateawy on loss of the intersite linl. - suggestion to delete (6) from section 4. 6) Next Meeting: Jan 2/2002 - next meeting - to be hosted by Don From owner-ips@ece.cmu.edu Fri Dec 21 14:14:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29847 for ; Fri, 21 Dec 2001 14:14:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLIsBQ04814 for ips-outgoing; Fri, 21 Dec 2001 13:54:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLIsAZ04809 for ; Fri, 21 Dec 2001 13:54:10 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA191454; Fri, 21 Dec 2001 11:53:44 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBLGuax117538; Fri, 21 Dec 2001 09:56:36 -0700 Importance: Normal Subject: RE: Initiator port groups???? To: "Ostrowski, Stephen" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 21 Dec 2001 08:56:35 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/21/2001 08:56:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBLIsAZ04811 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Stephen, But the initiator name is naming the node and has nothing to do with the lower level portal groups or HBAs or anything. Your naming convention is NOT for initiator nodes; it's for initiator portal groups. The protocol and architecture let iniitator nodes discover target portal groups and it then leaves it up to the initiator implementation to decide what logins it will do from each of it's initiator portal groups to the set of target portal groups it has discovered. There is nothing in the protocol or architecture (and their shouldn't be) that determines this policy. I think you're asking for a naming convention on which to implement such a policy. You can use your naming format as a way to name and manage your iSCSI initiator portal groups. You can then do that to coordinate (coerce?) your initiator login policy to each target portal group. But I think this is outside the scope of the standard, though it may be embedded in the iSCSI MIB. Jim Hafner "Ostrowski, Stephen" @ece.cmu.edu on 12/21/2001 08:23:18 am Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: "Ips (ips@ece.cmu.edu)" Subject: RE: Initiator port groups???? John, I missed port groups are dynamic across boots. I think that there MIGHT be a need for static mapping (or preference) for configuration. Example: I have an initiator with two HBAs. If the connection is made from HBA 1 to a certain target, then the connection would be secure, but if the connection if mode from HBA 2 to that target, then it would be insecure. So I would want to be able to configure that, and then to verify that the correct connection was being made during login. Also, I could also see the need to try to balance the traffic load across the HBAs in a non random way. - Stephen -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Thursday, December 20, 2001 4:19 PM To: Ostrowski, Stephen Cc: Ips (ips@ece.cmu.edu) Subject: Re: Initiator port groups???? The direction you are going, is not the direction we intended to take iSCSI. The Authentication and Masking should be done on an Initiator Node Name value, NOT based on an HBA. There may be multiple HBAs involved in a single, iSCSI Session. Also there might be more then one initiator in a Initiator Node (perhaps each with more then one HBA), I do not see why there would need to be management beyond the Node Name. The Authentication is suppose to be done on a Node Name Basis. In any event the Initiator does not have Portal Group Tags, and Target Portal Group tags are not required to be Static from Target Startup to Target Startup. This Discovery process is suppose to Discover the current values of these items. They are NOT part of the NodeName. Also, the Node Names are suppose to be Long lasting Names, portal groups have no such need. So it is a twist to bring both together and call that an iSCSI Name. Now, if you just intend to do mapping for the purpose of rendering a picture of the network and connections, I suggest you look at the iSCSI MIB Drafts and see how that might be useful or the iSCSI Technical Work Group in SNIA, which is defining APIs for the HBAs. In other words you need to find another way to do what you want. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Ostrowski, Stephen" @ece.cmu.edu on 12/20/2001 07:31:30 AM Sent by: owner-ips@ece.cmu.edu To: "Ips (ips@ece.cmu.edu)" cc: Subject: Initiator port groups???? I would like to suggest a change in the initiator name. I would like to be able to add an optional port group tag number at the end. Example: OLD: iqn.2001-03.com.service-provider.users.customer235.host90 NEW: iqn.2001-03.com.service-provider.users.customer235.host90,10 OLD: eui.02004567A425678D NEW: eui.02004567A425678D,11 The problem that I am trying to solve is how to build a San Management Platform to do the initiator to target mapping and once a mapping has occurred, how to make sure the right connection is being made. For example: I have an initiator with 3 HBAs, and a target with 3 hbas. The discovery information provided to the Management platform could see that I have ONE initiator and a target with say 3 Port Groups.       With this I can map the initiator to the target, or the initiator to 1 or more port groups.  I would like to the same idea to the initiator name to include a field like that so that I could easily expand the choices to maybe map a target port group to an initiator HBA.                1 --            -- 1  Initiator(I)  2 --  Network   -- 2  Target(T)                3 --            -- 3  I.e. Before I could do the following:  I -> T  I -> T1  I -> T2  I -> T1, T2  ETC...  If I added the info to the initiator name I could also do the following mappings:  I1 -> T1, I2 -> T2  I1 -> T, I2 -> T  Etc..  - Stephen From owner-ips@ece.cmu.edu Fri Dec 21 15:52:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01794 for ; Fri, 21 Dec 2001 15:52:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLK7cA09369 for ips-outgoing; Fri, 21 Dec 2001 15:07:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLK7aZ09358 for ; Fri, 21 Dec 2001 15:07:36 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 619844006C8 for ; Fri, 21 Dec 2001 12:07:30 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 6154F400097 for ; Fri, 21 Dec 2001 12:07:19 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 12:07:30 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2D2@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips (ips@ece.cmu.edu)" Subject: RE: Initiator port groups???? Date: Fri, 21 Dec 2001 12:07:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Stephen, > I missed port groups are dynamic across boots. I think > that there > MIGHT be a need for static mapping (or preference) for > configuration. I don't think John said portal groups are dynamic, he simple said they are not currently *required* to be static. I think it's reasonable to ask that targets use consistent numbering of portal groups across target boots, ie. if a group of addresses are in portal group 1 today, next boot the target should still report them as portal group 1 (unless the address configuration has changed). > Example: I have an initiator with two HBAs. If the > connection is > made from HBA 1 to a certain target, then the connection > would be secure, > but if the connection if mode from HBA 2 to that target, then > it would be > insecure. So I would want to be able to configure that, and > then to verify > that the correct connection was being made during login. > Also, I could also see the need to try to balance the > traffic load > across the HBAs in a non random way. This is a management task that exists today for initiator implementations - HBA vendors are dealing with it in their "configuration tools" with proprietary interfaces to their HBAs. The change you suggest to "initiator name" is not appropriate - portal groups are only a grouping of IP addresses that can be used for a multi-connection session, they have no association to the construction of "initiator port name" (other than indirectly, thru the session construct). And even if the change you suggest was made, there is no protocol method for "discovering" initiator names - as Jim points out, there is no protocol need for such a thing. Please review the iSCSI MIB and suggest changes the MIB structure which would aid you in your management needs. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com From owner-ips@ece.cmu.edu Fri Dec 21 15:57:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01954 for ; Fri, 21 Dec 2001 15:57:48 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLKEWe09852 for ips-outgoing; Fri, 21 Dec 2001 15:14:32 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLKEUZ09848 for ; Fri, 21 Dec 2001 15:14:30 -0500 (EST) Received: from logs-we.proxy.aol.com (logs-we.proxy.aol.com [205.188.195.5]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id PAA09784 for ; Fri, 21 Dec 2001 15:12:06 -0500 (EST) Received: from D2BVG111 (AC843CC6.ipt.aol.com [172.132.60.198]) by logs-we.proxy.aol.com (8.10.0/8.10.0) with ESMTP id fBLKAHe206832 for ; Fri, 21 Dec 2001 15:10:18 -0500 (EST) From: "Elizabeth G. Rodriguez" To: Subject: IPS-ALL: Draft IPS Meeting minutes from IETF-52 Date: Fri, 21 Dec 2001 14:08:51 -0600 Message-ID: <007001c18a5b$4fb39230$52f1a2ac@D2BVG111> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0071_01C18A29.05192230" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Apparently-From: UserR1846@aol.com Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0071_01C18A29.05192230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Following are the DRAFT IPS meeting minutes from IETF-52 Please send clarifications/additions/corrections, etc to the list, David and I, no later than Jan 3. Thanks, Elizabeth & David IETF IPS Meeting Minutes December 10, 2001 Reference section in all documents must be split into two sections - normative and non-normative. Interim meeting in Feb. Announcement on IPS mailing list & IETF announce. Need RSVPs. Information at www.ietf.org/IESG/IPS-Interim.txt -- FC Encapsulation draft (Ralph Weber) Basically done. SOFc4 will be going in, other minor (editorial) fixes. Rev 5 will be candidate for last call. Last call will be in conjunction with FCIP and/or iFCP -- Security draft (Bernard Aboba) Security documetn will go standards track, but all protocol docs will be self contained. Protocol documents will govern, in case of any discrepancies. Note to this effect will be added to security draft. Cannot require sequence space extension is in ESPv3, since will not be available for some time. NAT traversal language will be non-normative due to IPR issues and problems encountered in testing IPsec NAT traversal. Dependencies - Protocol specs, need SLPv2 security update (2608bis), but may be able to finesse needing a normative reference - IPsec transforms are in progress. See IPsec WG for more, for the AES drafts, MAC is in good shape, CTR requires some attention in ipsec WG - SRP (RFC 2945) - DHCP-ipsec drafts. Transforms Currently specified Must: 3DES-CBC; HMAC-SHA1 Should NOT: DES Should: AES-CTR and CBC-MAC w/ XCBC Q: (William Dixon) - Why not AES-128CBC instead of AES-CTR? Much further along; interoperable implementations are available. Will be discussed in ipsec wg. Resolving issues off of the mailing list. Demoting 3DES will cause interoperability problems. Transport vs. Tunnel mode Specified: iFCP, FCIP Tunnel mode MUST; transport MAY iSCSI, under discussion. Summary of pros/cons Transport mode: Pros: End to end security, Lower overhead, Larger MTU, Negotiation of connection specific selectors is common practice Cons: Requires ipsec to be implemented on the IPS entities Greater difficulties with NAT traversal Tunnel mode: Pros: More compatible with existing VPN gateways, Don't have to implement ipsec on IPS entity Easier to traverse NATs Cons: More overhead, Smaller MTU Tunnel problems - connection-specific selectors and dynamically assigned addresses (problem is use of mode config which is non-standard - standards track documents exist, but not clear whether they will be widely implemented). Tunnel mode + connection-specific selectors are very difficult to do. Many gateways do not do connection-specific selectors well. Need to look at these issues in more detail. Implementors please look into the security gateways you're planning to use. IKE identifiers Both Main and Aggressive are MUST, Aggressive mode is there to deal with dynamic addresses. Open issues in use of specific ID types. Policy Distribution - Constraining IKE is a good first step. - Security policy gets tricky when - Not all nodes in an iSCSI network support security - IKE times out when trying to reach a non-IPsec entity (e.g., 60 sec). Initiator needs to know whether to try IPsec or not to avoid this. Responder-controlled security [TCP SYN in clear, target sets up an SA if it supports IPsec] is an alternative. Currently a MUST NOT to avoid denial of service issues because TCP SYN causes IKE work (much worse than TCP SYN flood case). This limits need for security policy to target. Doesn't work well for target initiating IKE to initiator behind a firewall or NAT. May use iSNS security policy distribution. Existing IPsec policy distribution mechanisms have been problematic. iSNS could be better. Certificates SHOULD: use IKE certificates SHOULD: check certificate revocation list MAY: use certificates to determine authorization Easiest enrollment solution is to have HBAs get/use host certs. Long cert chains cause IP fragmentation in IKE, which can cause problems. Allow any IKE certificate - use these for identity only, avoid adding new OIDs to do iSCSI authorization. General, but inconclusive transport vs. tunnel mode discussion. Pros and Cons for making each the MUST implement brought up. Neither mode will be prohibited. Can make both MUST, but decision has not been made. John Hufferd asks about transport vs. tunnel mode resolution Needs to go to mailing list David Black will write something up. -- iFCP (Charles Monia) - iFCP N_Port address definition Currently IP address of gateway + N port ID behind it. Issue with NAPTs. As of -08, adding TCP port to IP address (gateway address is the pair). No iSNS change required. - FC Broadcast FC Broadcast is best-effort, IPFC and FC-VI use this to do discovery. Not performance-critical. Currently uses UDP/IP, may not be as reliable as FC broadcast over fabric, and relying on IP fragmentation may be a big problem. Changing to a server-based TCP implementation of broadcast - send broadcast frame to broadcast server who then sends it to all gateways. Use 0xFF-FF-FF well known address as port ID for all of the iFCP entities involved in this. Discovery based on iSNS - need iSNS changes for this. Need to look at issue of two broadcast servers in the same domain. - Stale Frame detection Currently optional. Will change to MUST implement and MUST use. -- iFCP MIB (Charles Monia) Minor changes, cleanup from review by Keith. Fairly stable, close to done. -- iSNS (Josh Tseng) - Change to support iFCP transparent mode. - Security Issues. Use IPsec to protect iSNS messages. MUST implement IPsec w/ESP in tunnel mode for iFCP and appropriate mode for iSCSI. Use unicast for query and response message Use multicast for iSNS heartbeat used to discover iSNS server iFCP gateways and iSCSI devices using iSNS SHOULD authenticate to the iSNS server. - Use of iSNS to distribute security policy This is about centralization of security administration. Security bitmap to hold things not already negotiated by ISAKMP. Parameters to be stored and distributed by iSNS - Use/non-use of: IPsec, IKE, Main Mode, Aggressive Mode, Perfect forward secrecy, preshared key, tunnel & transport mode. Need to review this for what's necessary - work with security draft authors (e.g., Bernard Aboba). - DHCP option - make absolutely sure that a new one is needed before asking for one. DHCP name server option may not be appropriate (RFC 2937). -- iSNS MIB No serious content changes - minor cleanups (similar to iFCP MIB), stable, close to done. -- FCIP (Ralph Weber) At -07 draft. Major open issue is WWN short frame security. A few other minor changes will be made (e.g., add SOF and EOF for class 4 FC service). WWN Short Frame Security - Prior to Irvine, FCIP endpoint was IP address. NAT/NAPT support makes this problematic. Sending WWN across as identity. Discussion of how to go about solving this problem - authors would like to do this as part of FC-BB-2 rather than FCIP. IETF IPS oversight/check of this will be necessary. FC-BB-2 - specific solution seems to be preferred to a generic FC solution. Expect to see proposal on list soon, discussion at FC-BB-2 in Feb. and IPS interim that week. -- FCIP SLP No known issues aside from coordination with security draft updates. Will revise to match those and be ready for WG Last Call. FCIP-SLP draft tracks security draft which tracks 2608bis. -- SCSI, FC Mgmt, and FCIP MIBs (Keith McCloghrie) FC Mgmt MIB has been transferred to IPS from IPFC. Keith is rearchitecting (e.g., consistency with IF and Entity MIBs, remove non-FC objects), expect first ietf-ips-fcmgmt-mib draft soon. SCSI MIB - design team nearing completion of UML model. Internet-Draft will be forthcoming shortly. T10 working session on SCSI MIB on Monday, Jan 14 in Houston. Details available at www.t10.org/meeting.htm. FCIP MIB - There are a bunch of work items - NAT, BB-2 changes, dependent on rework of FC Mgmt MIB. Yaron: SCSI and iSCSI MIBs use "instance" abstraction so that one MIB can represent multiple entities, FCIP should do likewise. Security - SNMPv3 has security. Get security boilerplate from IETF OPS MIB site, and expand on it to add specific information about risks involved in specific writable elements. DO NOT say "MUST use SNMPv3". Next draft will be coming in January. End discussion of transport/tunnel mode and related issues. Dynamic address support for tunnel mode is an interoperability issue that weighs against use of tunnel mode. ---------- Tuesday Dec 11--------- -- Agenda rebashing Framing requirements agenda item pulled due to Transport AD/tsvwg issue. Resolution will be posted to the list, soon, we hope. -- SRP IPR requirements (David Black) Note Well statement displayed. Key points - If know about IP, need to disclose. Further, if you should know about IP, need to disclose (e.g. Company cannot keep you in the dark in order to avoid disclosure). But, no patent search is required (e.g. if no way you should know, don't need to go out of your way to find out if there are claims). Should company own IP directly material to standard, IETF will ask Company to publish statement, and request fair, reasonable and non-discriminatory terms for licensing of IP. Company is not obligated to comply. IETF does not judge fairness Claims (rumors) against SRP 1) Stanford. Royalty free license available. 2) Lucent. May have IP that may be essential. If essential, will be licensed under standard Lucent IP licensing practices. 3) Speke patent. No statement. May be owned by Phoenix Technologies. MUST/SHOULD/MAY requirements discussion for SRP at February interim meeting. Closing warning from AD and WG chair about results of Dell and Rambus situations in which hiding patents resulted in patents being unenforceable (FTC consent decree for Dell, actual court decisions in Rambus). -- UNH Plugfest report (Yamini Shastry) Held Oct 28 - Nov 3 Based on -08 draft 15 participated. 4 initiators, 1 initiator, 9 both initiator & target. 1 neither initiator/target. Reserved bits test did not match with "MUST be zero on transmit/MUST be ignored on receive" Summary of changes made to draft as a result of plugfest - most are minor, see slides. OOO issue is number 5 on this list - will come up in main iSCSI section. Areas not tested include - digests - multiple connections/session - discovery sessions - unsolicited and/or immediate data - command windows greater than 1 - Security - No implementations of markers - No real error recovery - No serious parameter negotiation beyond defaults Next plugfest [Feb 11-15] will look at these areas. Based on -09 draft. Information from www.iol.unh.edu or from Yamini at yshastry@iol.unh.edu. New scripts will be available 2 weeks prior to plugfest. Request for minimum conformance of participate products made. Markers - determining whether they're in/out has to wait for resolution of status of tsvwg ULP Framing draft. -- iSCSI (Julian Satran) Open issues - Security (tunnel vs. transport, and transforms) - Framing (tsvwg status)? - Constant overhead word stuffing (version of Constant Overhead Byte Stuffing) as a possible alternative - Abort Task Set/Clear Task Set - OOO PDU handling - Serious issue: are NOPs allowed in a discovery session. * Abort and Clear Task set - Remove ordering discussion for Clear Task Set - Abort Task Set currently requires a SCSI response for every aborted command. Alternate - hold Abort Task Set response until all outstanding responses are ACKed by the initiator. Avoids any need to create "fake" SCSI responses, significantly reduces burden on Initiator. This is slower, but much simpler. Most of section 9.4 will vanish. Sense of the room - follow this approach, modulo working out details on the list. * Out of Order Operation - This is a within-connection issue. No ordering requirements across connections. - Within-connection issue turned up on list in context of allowing a DMA engine to reorder commands at its convenience. Could use multiple connections to do this. Eddy Q: DMA flow-through to wire is a plausible adapter design that increases the desireability of doing ordering. Mallikarjun: Unsolicited non-immediate data provides additional ordering flexibility. Sense of the room - this is the right approach. * NOP in Discovery Sessions Underlying problem is whether to keep discovery session around for detection/notification of configuration changes. Mark Bakke: Want to know when new targets become available. Multiple ways to do this. Discovery session is an in-band way of doing this, allows an async message to be sent to do this (won't need to poll). Wants both NOPs and async messages on on discovery session to keep it alive long-term. Resolution - N&D team to generate text describing applicability and use of the various mechanisms, along with requirements on implementations to yield interoperability. Will ship to list and use that to drive closure on need for long-lived discovery sessions which in turn will drive closure of NOP issues. * Framing Word-stuffing version of COBS is an alternative to markers. Has to touch every byte of message. CRC and ESP also have to, so this might be a good alternative when those techniques are in use. COBS/COWS is the same class of mechanism as markers, similar considerations. Comment that something is needed that doesn't require TCP modifications - that would be either markers or COBS/COWS. Hardware targets talking to software initiators is the scenario of interest. Comment that TCP modification for framing is acceptable, hence no need for COBS/COWS or markers. Discussion is not conclusive - Need to get tsvwg ULP issue resolved, write COBS/COWS up in detail (sense of room is no serious objection to doing so), and take this up on list, resolve at Feb. interim. The -10 version will appear sufficiently prior to interim meeting. -- iSCSI Boot draft iSCSI usage of DHCP option is fine. Will go into next draft. (DHC WG consulted, no need for DHC draft). -- iSCSI Naming and Discovery Will be informational. IQN format will use date codes New ISID format New username and Initiator name usage guidelines Stringprep approach to character normalization ISID format change - ISID will contain vendor ID. Will now be 48 bits, use IEEE OUI or IANA OUI. 02 should be "Local Usage" rather than "Random". Note that this can be coped with at install time. 3 forms now acceptable 1) IEEE OUI 2) IANA Enterprise Number 3) Vendor unique -- locally unique; not globally unique. Recommendation: Double size to 128, so that you can have a WW unique value Response: Not needed -- ISID is relative to iSCSI node name, which is WW unique. Three people support embedding the MAC into the ISID. Will take this to the list. John Hufferd: Embedding the MAC in this ISID binds the session to a single HBA. Conservative Reuse description. Reuse ISIDs across all targets. Needed to deal with T10 changes in progress to persistent reservations. -- Stringprep (Mark Bakke) IDN is close to done on the stringprep/nameprep drafts. This draft is about how to use this for iSCSI names. Q: What about unassigned codepoints. A: Whatever underlying stringprep draft does. Sense of room: adopted as WG draft. -- SLP for iSCSI Document is stable, unicast SLP usage is ok. Will coordinate security w/IPS Security draft. Will work with SLP authors on suitable notification support. -- iSCSI MIB status (Mark Bakke) Fitting into family of MIBs below SCSI MIB that is being developed - FCP MIB may be developed, no plans for parallel SCSI MIB. Details of how these fit together being worked out in SCSI MIB team. Will be looking at how to add usernames/cert identities to access control area of iSCSI MIB w/o large complexity. -- iSNS for iSSI status (Josh Tseng) See iSNS session on Monday. New informational material on how iSNS can be used to map iSCSI and FC devices in a hybrid installation. Final comments - Request to look at applying ISID-like structure to portal group tags for consistency and autoconfiguration reasons. ------=_NextPart_000_0071_01C18A29.05192230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

All,

 

Following are the DRAFT IPS meeting minutes from = IETF-52

Please send clarifications/additions/corrections, etc = to the list, David and I, no later than Jan 3.

 

Thanks,

 

Elizabeth & David

 

IETF IPS Meeting Minutes

 

December 10, 2001

 

Reference section in all documents must be split into = two sections – normative and non-normative.

 

Interim meeting in Feb. Announcement on IPS mailing = list & IETF announce. Need RSVPs.

Information at = www.ietf.org/IESG/IPS-Interim.txt

 

-- FC Encapsulation draft (Ralph = Weber)

 

Basically done.

SOFc4 will be going in, other minor (editorial) = fixes. 

Rev 5 will be candidate for last = call.

Last call will be in conjunction with FCIP and/or = iFCP

 

-- Security draft (Bernard Aboba)

 

Security documetn will go standards track, but all = protocol docs will be self contained.

Protocol documents will govern, in case of any discrepancies.

Note to this effect will be added to security = draft.

 

Cannot require sequence space extension is in ESPv3, = since will not be available for some time.

 

NAT traversal language will be non-normative due to = IPR issues

         =    and problems encountered in testing IPsec NAT = traversal.

 

Dependencies

         =    - Protocol specs, need SLPv2 security update (2608bis), but may = be

         =             &= nbsp;  able to finesse needing a normative reference

         =    - IPsec transforms are in progress.

         =             &= nbsp;  See IPsec WG for more, for the AES drafts, MAC is in good = shape,

         =             &= nbsp;  CTR requires some attention in ipsec WG

         =    - SRP (RFC 2945)

         =    - DHCP-ipsec drafts.

 

Transforms

Currently specified

         =    Must: 3DES-CBC; HMAC-SHA1

         =    Should NOT: DES

         =    Should: AES-CTR and CBC-MAC w/ XCBC

 

Q: (William Dixon) – Why not AES-128CBC instead = of AES-CTR?  Much further along;

interoperable implementations are available.  = Will be discussed in ipsec wg. 

 

         =    Resolving issues off of the mailing list.

         =    Demoting 3DES will cause interoperability problems.

 

Transport vs. Tunnel mode

 

         =    Specified: iFCP, FCIP Tunnel mode MUST; transport MAY

 

         =    iSCSI, under discussion.

         =    Summary of pros/cons

 

         =    Transport mode:

         =             &= nbsp;  Pros: End to end security, Lower overhead, Larger MTU, =

         =             &= nbsp;        Negotiation of connection specific = selectors is common practice

         =             &= nbsp;  Cons: Requires ipsec to be implemented on the IPS = entities

         =             &= nbsp;        Greater difficulties with NAT = traversal

 

         =    Tunnel mode:

 

         =    Pros: More compatible with existing VPN gateways,

         =          Don’t have to implement ipsec on = IPS entity

         =          Easier to traverse NATs

 

         =    Cons: More overhead, Smaller MTU

 

         =    Tunnel problems - connection-specific selectors and dynamically = assigned

         =             &= nbsp;  addresses (problem is use of mode config which is non-standard = -

         =             &= nbsp;  standards track documents exist, but not clear whether they = will

         =             &= nbsp;  be widely implemented).

 

         =    Tunnel mode + connection-specific selectors are very difficult to = do.

         =    Many gateways do not do connection-specific selectors = well.

 

         =    Need to look at these issues in more detail.  Implementors please = look

         =             &= nbsp;  into the security gateways you're planning to use.

 

 

IKE identifiers

         =    Both Main and Aggressive are MUST, = Aggressive mode is there to deal with

         =             &= nbsp;  dynamic addresses.

         =    Open issues in use of specific ID types.

 

Policy Distribution

         =    - Constraining IKE is a good first step.

         =    - Security policy gets tricky when

         =             &= nbsp;  - Not all nodes in an iSCSI network support security

         =             &= nbsp;  - IKE times out when trying to reach a non-IPsec = entity

         =             &= nbsp;           &n= bsp;  (e.g., 60 sec).  Initiator needs to know whether = to

         =             &= nbsp;           &n= bsp;  try IPsec or not to avoid this.

         =    Responder-controlled security [TCP SYN in clear, target sets = up

         =             &= nbsp;  an SA if it supports IPsec] is an alternative.  = Currently

         =             &= nbsp;  a MUST NOT to avoid denial of service issues because = TCP

         =             &= nbsp;  SYN causes IKE work (much worse than TCP SYN flood = case).

         =             &= nbsp;  This limits need for security policy to target.

         =    Doesn't work well for target initiating IKE to initiator = behind

         =             &= nbsp;  a firewall or NAT.

         =    May use iSNS security policy distribution.

         =    Existing IPsec policy distribution mechanisms have been = problematic.

         =             &= nbsp;  iSNS could be better.

 

Certificates

         =    SHOULD: use IKE certificates

         =    SHOULD: check certificate revocation list

         =    MAY: use certificates to determine authorization

 

         =    Easiest enrollment solution is to have HBAs get/use host = certs.

         =    Long cert chains cause IP fragmentation in IKE, which can cause = problems.

         =    Allow any IKE certificate - use these for identity only, avoid = adding

         =             &= nbsp;  new OIDs to do iSCSI authorization.

 

         =    General, but inconclusive transport vs. tunnel mode = discussion.

         =    Pros and Cons for making each the MUST implement brought = up.

         =    Neither mode will be prohibited.  Can make both MUST, but decision = has not been made.

         =   

         =    John Hufferd asks about transport vs. tunnel mode = resolution

         =    Needs to go to mailing list

         =    David Black will write something up.

 

 

-- iFCP (Charles Monia)

 

- iFCP N_Port address definition

         =    Currently IP address of gateway + N port ID behind it. Issue with = NAPTs.

         =    As of -08, adding TCP port to IP address (gateway address is the = pair). 

         =    No iSNS change required.

 

- FC Broadcast

         =    FC Broadcast is best-effort, IPFC and FC-VI use this to do = discovery.

         =    Not performance-critical.  Currently uses UDP/IP, may not be as = reliable

         =    as FC broadcast over fabric, and relying on IP fragmentation may be a = big

         =    problem.  Changing to a server-based TCP implementation of = broadcast -

         =    send broadcast frame to broadcast server who then sends it to all = gateways.

         =    Use 0xFF-FF-FF well known address as port ID for all of the iFCP = entities

         =    involved in this.  Discovery based on iSNS - need iSNS changes for = this.

         =    Need to look at issue of two broadcast servers in the same = domain.

- Stale Frame detection

         =    Currently optional.  Will change to MUST implement and MUST = use.

 

-- iFCP MIB (Charles Monia)

 

Minor changes, cleanup from review by Keith.  = Fairly stable, close to done.

 

-- iSNS (Josh Tseng)

 

- Change to support iFCP transparent = mode.

 

- Security Issues.  Use IPsec to protect iSNS = messages.

         =    MUST implement IPsec w/ESP in tunnel mode for iFCP and appropriate mode = for

         =             &= nbsp;  iSCSI.

         =    Use unicast for query and response message

         =    Use multicast for iSNS heartbeat used to discover iSNS = server

         =    iFCP gateways and iSCSI devices using iSNS SHOULD authenticate to the = iSNS server.

 

- Use of iSNS to distribute security = policy

         =    This is about centralization of security = administration.

         =    Security bitmap to hold things not already negotiated by = ISAKMP.

         =    Parameters to be stored and distributed by iSNS - Use/non-use = of:

         =             &= nbsp;  IPsec, IKE, Main Mode, Aggressive Mode, Perfect forward secrecy, =

         =             &= nbsp;  preshared key, tunnel & transport mode.

         =    Need to review this for what's necessary - work with security = draft

         =    authors (e.g., Bernard Aboba).

 

- DHCP option - make absolutely sure that a new one = is needed before asking for

         =    one.  DHCP name server option may not be appropriate (RFC = 2937).

 

-- iSNS MIB

 

No serious content changes - minor cleanups (similar = to iFCP MIB), stable, close

         =    to done.

 

-- FCIP (Ralph Weber)

 

At -07 draft.  Major open issue is WWN short = frame security.  A few other

minor changes will be made (e.g., add SOF and EOF for = class 4 FC service).

 

WWN Short Frame Security

 

- Prior to Irvine, FCIP = endpoint was IP address.  NAT/NAPT support makes this

         =    problematic.  Sending WWN across as identity.

 

Discussion of how to go about solving this problem - = authors would like to

         =    do this as part of FC-BB-2 rather than FCIP.  IETF IPS = oversight/check

         =    of this will be necessary.  FC-BB-2 - specific solution seems = to

         =    be preferred to a generic FC solution.  Expect to see proposal on = list

         =    soon, discussion at FC-BB-2 in Feb. and IPS interim that = week.

 

-- FCIP SLP

 

No known issues aside from coordination with security = draft updates.  Will

revise to match those and be ready for WG Last = Call.  FCIP-SLP draft tracks

security draft which tracks = 2608bis.

 

-- SCSI, FC Mgmt, and FCIP MIBs (Keith = McCloghrie)

 

FC Mgmt MIB has been transferred to IPS from = IPFC.  Keith is rearchitecting

         =    (e.g., consistency with IF and Entity MIBs, remove non-FC = objects),

         =    expect first ietf-ips-fcmgmt-mib draft soon.

 

SCSI MIB - design team nearing completion of UML model.  Internet-Draft will

         =    be forthcoming shortly.  T10 working session on SCSI MIB on Monday, =

         =    Jan 14 in Houston. Details available at www.t10.org/meeting.htm.

 

FCIP MIB - There are a bunch of work items - NAT, = BB-2 changes, dependent on

         =    rework of FC Mgmt MIB.

         =    Yaron: SCSI and iSCSI MIBs use "instance" abstraction so that = one

         =             &= nbsp;  MIB can represent multiple entities, FCIP should do = likewise.

 

         =    Security - SNMPv3 has security.  Get security boilerplate from = IETF

         =    OPS MIB site, and expand on it to add specific information = about

         =    risks involved in specific writable elements.  DO NOT say = "MUST

         =    use SNMPv3".

 

         =    Next draft will be coming in January.

 

End discussion of transport/tunnel mode and related = issues.

         =    Dynamic address support for tunnel mode is an interoperability issue = that

         =    weighs against use of tunnel mode.

 

 

---------- Tuesday Dec 11---------

 

-- Agenda rebashing

 

Framing requirements agenda item pulled due to = Transport AD/tsvwg issue.  Resolution

will be posted to the list, soon, we = hope.

 

-- SRP IPR requirements (David = Black)

 

         =    Note Well statement displayed.

         =    Key points –

         =             &= nbsp;  If know about IP, need to disclose. Further, if you should know about = IP,

         =             &= nbsp;  need to disclose (e.g. Company cannot keep you in the dark in order to =

         =             &= nbsp;  avoid disclosure). But, no patent search is required (e.g. if no way you =

         =             &= nbsp;  should know, don't need to go out of your way to find out if there are = claims).

 

         =    Should company own IP directly material to standard, IETF will ask = Company to publish statement,

         =    and request fair, reasonable and non-discriminatory terms for licensing = of IP. 

         =    Company is not obligated to comply.

 

         =    IETF does not judge fairness

 

         =    Claims (rumors) against SRP

         =    1)         Stanford.  = Royalty free license available.             =

         =    2)         Lucent.  May = have IP that may be essential. 

         =             &= nbsp;  If essential, will be licensed under standard Lucent IP licensing = practices.

         =    3)         Speke patent.  = No statement. May be owned by Phoenix Technologies.

 

         =    MUST/SHOULD/MAY requirements discussion for SRP at February interim = meeting.

 

Closing warning from AD and WG chair about results of = Dell and Rambus situations

         =    in which hiding patents resulted in patents being unenforceable (FTC = consent

         =    decree for Dell, actual court decisions in Rambus).

 

-- UNH Plugfest report (Yamini = Shastry)

 

Held Oct 28 - Nov 3

Based on -08 draft

15 participated.  4 initiators, 1 initiator, 9 = both initiator & target. 1 neither initiator/target.

 

Reserved bits test did not match with "MUST be = zero on transmit/MUST be ignored

         =    on receive"

 

Summary of changes made to draft as a result of = plugfest - most are minor, see

         =    slides.

 

OOO issue is number 5 on this list - will come up in = main iSCSI section.

 

Areas not tested include

         =    - digests

         =    - multiple connections/session

         =    - discovery sessions

         =    - unsolicited and/or immediate data

         =    - command windows greater than 1

         =    - Security

         =    - No implementations of markers

         =    - No real error recovery

         =    - No serious parameter negotiation beyond defaults

 

Next plugfest [Feb 11-15] will look at these = areas.  Based on -09 draft.

Information from www.iol.unh.edu or from Yamini at yshastry@iol.unh.edu.

New scripts will be available 2 weeks prior to = plugfest.

Request for minimum conformance of participate = products made.

 

Markers - determining whether they're in/out has to = wait for resolution of

         =    status of tsvwg ULP Framing draft. 

 

-- iSCSI (Julian Satran)

 

Open issues

         =    - Security (tunnel vs. transport, and transforms)

         =    - Framing (tsvwg status)?

         =             &= nbsp;  - Constant overhead word stuffing (version of Constant Overhead = Byte

         =             &= nbsp;           &n= bsp;  Stuffing) as a possible alternative

         =    - Abort Task Set/Clear Task Set

         =    - OOO PDU handling

         =    - Serious issue: are NOPs allowed in a discovery = session.

 

* Abort and Clear Task set

         =    - Remove ordering discussion for Clear Task Set

         =    - Abort Task Set currently requires a SCSI response for = every

         =             &= nbsp;  aborted command.  Alternate - hold Abort Task Set = response

         =             &= nbsp;  until all outstanding responses are ACKed by the = initiator.

         =             &= nbsp;  Avoids any need to create "fake" SCSI responses, = significantly

         =             &= nbsp;  reduces burden on Initiator.  This is slower, but much = simpler.

         =             &= nbsp;  Most of section 9.4 will vanish.

Sense of the room - follow this approach, modulo = working out details

         =    on the list.

 

* Out of Order Operation

         =    - This is a within-connection issue.  No ordering requirements = across

         =             &= nbsp;  connections.

         =    - Within-connection issue turned up on list in context of allowing = a

         =             &= nbsp;  DMA engine to reorder commands at its convenience.  Could = use

         =             &= nbsp;  multiple connections to do this.

Eddy Q: DMA flow-through to wire is a plausible = adapter design that increases

         =    the desireability of doing ordering.

Mallikarjun: Unsolicited non-immediate data provides additional ordering

         =    flexibility.

Sense of the room - this is the right = approach.

 

* NOP in Discovery Sessions

 

Underlying problem is whether to keep discovery = session around for

         =    detection/notification of configuration changes.

 

Mark Bakke: Want to know when new targets become available.  Multiple ways

         =    to do this.  Discovery session is an in-band way of doing this, = allows

         =    an async message to be sent to do this (won't need to poll).  = Wants

         =    both NOPs and async messages on on discovery session to keep it = alive

         =    long-term.

 

Resolution - N&D team to generate text describing applicability and use of

         =    the various mechanisms, along with requirements on implementations = to

         =    yield interoperability.  Will ship to list and use that to drive = closure

         =    on need for long-lived discovery sessions which in turn will = drive

         =    closure of NOP issues.

 

* Framing

         =    Word-stuffing version of COBS is an alternative to markers.  Has to = touch

         =             &= nbsp;  every byte of message.  CRC and ESP also have to, so this might = be

         =             &= nbsp;  a good alternative when those techniques are in use.

 

         =    COBS/COWS is the same class of mechanism as markers, similar = considerations.

         =             &= nbsp;  Comment that something is needed that doesn't require TCP = modifications

         =             &= nbsp;  - that would be either markers or COBS/COWS.  Hardware targets = talking

         =             &= nbsp;           &n= bsp;  to software initiators is the scenario of interest.

         =             &= nbsp;  Comment that TCP modification for framing is acceptable, hence = no

         =             &= nbsp;  need for COBS/COWS or markers.

 

         =    Discussion is not conclusive - Need to get tsvwg ULP issue resolved, = write

         =             &= nbsp;  COBS/COWS up in detail (sense of room is no serious objection to = doing

         =             &= nbsp;  so), and take this up on list, resolve at Feb. = interim.

 

The -10 version will appear sufficiently prior to = interim meeting. 

 

-- iSCSI Boot draft

 

iSCSI usage of DHCP option is fine.  Will go = into next draft.

(DHC WG consulted, no need for DHC = draft).

 

-- iSCSI Naming and Discovery

 

         =    Will be informational.

         =    IQN format will use date codes

         =    New ISID format

         =    New username and Initiator name usage guidelines

         =    Stringprep approach to character normalization

 

ISID format change - ISID will contain vendor = ID.  Will now be 48 bits, use

         =    IEEE OUI or IANA OUI.  02 should be "Local Usage" rather = than "Random".

         =    Note that this can be coped with at install time.

 

3 forms now acceptable

1) IEEE OUI

2) IANA Enterprise Number

3) Vendor unique -- locally unique; not globally = unique.

 

Recommendation: Double size to 128, so that you can = have a WW unique value

 

Response:  Not needed -- ISID is relative to = iSCSI node name, which is WW unique.

 

Three people support embedding the MAC into the = ISID.  Will take this to the

         =    list. 

 

John Hufferd: Embedding the MAC in this ISID binds = the session to a single HBA.

 

Conservative Reuse description.  Reuse ISIDs = across all targets.  Needed to

         =    deal with T10 changes in progress to persistent = reservations.

 

-- Stringprep (Mark Bakke)

 

IDN is close to done on the stringprep/nameprep drafts.  This draft is about how

         =    to use this for iSCSI names.

 

Q: What about unassigned = codepoints.

A: Whatever underlying stringprep draft = does.

 

Sense of room: adopted as WG draft.

 

-- SLP for iSCSI

 

Document is stable, unicast SLP usage is = ok.

Will coordinate security w/IPS Security = draft.

Will work with SLP authors on suitable notification = support.

 

-- iSCSI MIB status (Mark Bakke)

 

Fitting into family of MIBs below SCSI MIB that is = being developed -

         =    FCP MIB may be developed, no plans for parallel SCSI MIB.  = Details

         =    of how these fit together being worked out in SCSI MIB = team.

 

Will be looking at how to add usernames/cert = identities to access control

         =    area of iSCSI MIB w/o large complexity.

 

-- iSNS for iSSI status  (Josh = Tseng)

 

See iSNS session on Monday.  New informational = material on how iSNS can

         =    be used to map iSCSI and FC devices in a hybrid = installation.

 

Final comments

- Request to look at applying ISID-like structure to = portal group tags

         =    for consistency and autoconfiguration reasons.

 

------=_NextPart_000_0071_01C18A29.05192230-- From owner-ips@ece.cmu.edu Fri Dec 21 16:03:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02079 for ; Fri, 21 Dec 2001 16:03:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLKcsL11455 for ips-outgoing; Fri, 21 Dec 2001 15:38:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NetworkRelay ([63.119.175.39]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLKcrZ11451 for ; Fri, 21 Dec 2001 15:38:53 -0500 (EST) Received: from quicksall.com [63.119.175.45] by NetworkRelay with ESMTP (SMTPD32-7.04) id AC6F22EA0112; Fri, 21 Dec 2001 14:32:47 -0600 Received: from eddydesktop [24.61.64.49] by quicksall.com with ESMTP (SMTPD32-6.06) id ADB3688004A; Fri, 21 Dec 2001 14:38:11 -0600 From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: LUN in Data-out and NOP PDU's Date: Fri, 21 Dec 2001 15:38:44 -0500 Message-ID: <001801c18a5f$7cde1560$0102a8c0@eddydesktop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C18A35.94080D60" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C18A35.94080D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit What is the LUN for in Data-out and NOP-out PDU’s? I assume the LUN in Data-out could be used for steering but I don’t know what the LUN in NOP-out PDU’s is for. Eddy ------=_NextPart_000_0019_01C18A35.94080D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What is the LUN for in Data-out and NOP-out = PDU’s?

 

I assume the LUN in Data-out could be used for steering but I don’t = know what the LUN in NOP-out PDU’s is = for.

 

Eddy<= /span>

------=_NextPart_000_0019_01C18A35.94080D60-- From owner-ips@ece.cmu.edu Fri Dec 21 16:57:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02848 for ; Fri, 21 Dec 2001 16:57:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLL6c213310 for ips-outgoing; Fri, 21 Dec 2001 16:06:38 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLL6bZ13306 for ; Fri, 21 Dec 2001 16:06:37 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBLL6QT16555 for ; Fri, 21 Dec 2001 16:06:27 -0500 (EST) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBLL6PC21814 for ; Fri, 21 Dec 2001 16:06:25 -0500 (EST) Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZJBSK4JT; Fri, 21 Dec 2001 16:04:54 -0500 Received: from cse-ns-laptop.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XRGW5NB7; Fri, 21 Dec 2001 16:04:56 -0500 Message-Id: <5.1.0.14.2.20011221160821.028d7770@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 21 Dec 2001 16:10:42 -0500 To: "IPS Reflector (E-mail)" From: Franco Travostino Subject: iFCP: Minutes authors' confcall Fri December 21st Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_197112723==_.ALT" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_197112723==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Attendees: Wayland Jeong, Troika Networks Charles Monia, Nishan Systems Franco Travostino, Nortel Networks Josh Tseng, Nishan Systems 1. Debrief from IETF 52th IPS WG Wayland was brought up to date on IPS news in SLC, including the new standard-track status for the IPS security draft. From the IESG plenary, FT took home a couple of guidelines against a) exceedingly long authors' lists, and b) exceedingly long standard-track documents. None of the above was seen as applicable to iFCP. 2. The road to iFCP 08.txt and Last Call 2.1 Detection of multiple broadcast servers In SLC, Charles presented the new, TCP-based approach to realizing broadcast services. In a given zone, broadcast clients (many) and server (one) would be associated dynamically, with the latter advertising its presence to the iSNS. An external comment/concern was presented about two or more broadcast servers unduly coexisting in the same broadcast zone, as a result of misconfigurations, transient network partitions, etc. Since SLC, the authors have exchanged notes on how to best prevent this syndrome from happening. CM described the final solution, which entails a) adding "Broadcast Server" as an attribute in iSNS, b) administratively setting the broadcast server's WWN for a zone into iSNS, and c) having the broadcast server query the iSNS server, and match its own WWN with the one in the iSNS' reply, prior to actually joining the zone and start its broadcast duties. 2.2 Maintaining liveness The aforementioned broadcast clients and server can use a keep-alive mechanism to check their connections. Such optional mechanism is best thought of as a FCP no-op, and purposely refrains from using the underlying TCP keepalive features. Liveness granularity can be dynamically set. Given that the broadcast sessions are undistinguishable from regular iFCP sessions after creation, the authors note that this optional liveness mechanism also applies to iFCP sessions. Regular iFCP sessions may use the liveness mechanism to refresh state in NA(P)T, firewall intervening boxes, and to assemble a somewhat meaningful history of IP prop times. 2.3 Update on Charles' latest changes regarding address translation model et al. Work is well on its way, the authors will get a sneak preview the first week of January. 2.4 Security Certificate words are the last known words still missing in action. JT and FT will exchange notes on a draft text, which they will then submit to the IPS security list for review. 2.5. Misc. Happy Holidays -franco Franco Travostino, Director Content Internetworking Lab Advanced Technology Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA Tel: 978 288 7708 Fax: 978 288 4690 email: travos@nortelnetworks.com --=====================_197112723==_.ALT Content-Type: text/html; charset="us-ascii"
Attendees:

Wayland Jeong, Troika Networks
Charles Monia, Nishan Systems
Franco Travostino, Nortel Networks
Josh Tseng, Nishan Systems

1. Debrief from IETF 52th IPS WG

Wayland was brought up to date on IPS news in SLC, including the new standard-track status for the IPS security draft. From the IESG plenary, FT took home a couple of guidelines against a) exceedingly long authors' lists, and b) exceedingly long standard-track documents. None of the above was seen as applicable to iFCP.

2. The road to iFCP 08.txt and Last Call

2.1 Detection of multiple broadcast servers

In SLC, Charles presented the new, TCP-based approach to realizing broadcast services. In a given zone, broadcast clients (many) and server (one) would be associated dynamically, with the latter advertising its presence to the iSNS. An external comment/concern was presented about two or more broadcast servers unduly coexisting in the same broadcast zone, as a result of misconfigurations, transient network partitions, etc. Since SLC, the authors have exchanged notes on how to best prevent this syndrome from happening. CM described the final solution, which entails a) adding "Broadcast Server" as an attribute in iSNS, b) administratively setting the broadcast server's WWN for a zone into iSNS, and c) having the broadcast server query the iSNS server, and match its own WWN with the one in the iSNS' reply, prior to actually joining the zone and start its broadcast duties.

2.2 Maintaining liveness

The aforementioned broadcast clients and server can use a keep-alive mechanism to check their connections. Such optional mechanism is best thought of as a FCP no-op, and purposely refrains from using the underlying TCP keepalive features. Liveness granularity can be dynamically set. Given that the broadcast sessions are undistinguishable from regular iFCP sessions after creation, the authors note that this optional liveness mechanism also applies to iFCP sessions. Regular iFCP sessions may use the liveness mechanism to refresh state in NA(P)T, firewall intervening boxes, and to assemble a somewhat meaningful history of IP prop times.

2.3 Update on Charles' latest changes regarding address translation model et al.

Work is well on its way, the authors will get a sneak preview the first week of January.

2.4 Security

Certificate words are the last known words still missing in action. JT and FT will exchange notes on a draft text, which they will then submit to the IPS security list for review.

2.5. Misc.

Happy Holidays


-franco


Franco Travostino, Director Content Internetworking Lab
Advanced Technology
Nortel Networks, Inc.
600 Technology Park
Billerica, MA 01821 USA
Tel: 978 288 7708 Fax: 978 288 4690
email: travos@nortelnetworks.com
 --=====================_197112723==_.ALT-- From owner-ips@ece.cmu.edu Fri Dec 21 17:05:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02980 for ; Fri, 21 Dec 2001 17:05:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBLLA1E13566 for ips-outgoing; Fri, 21 Dec 2001 16:10:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBLJAcZ05852 for ; Fri, 21 Dec 2001 14:10:38 -0500 (EST) Received: from logs-mtc-ta.proxy.aol.com (logs-mtc-ta.proxy.aol.com [64.12.105.5]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id OAA09297; Fri, 21 Dec 2001 14:10:21 -0500 (EST) Received: from D2BVG111 (ACA2F152.ipt.aol.com [172.162.241.82]) by logs-mtc-ta.proxy.aol.com (8.10.0/8.10.0) with ESMTP id fBLIpAL427808; Fri, 21 Dec 2001 13:51:10 -0500 (EST) From: "Elizabeth G. Rodriguez" To: Cc: "'David Black'" , Subject: IPS-ALL: Draft IPS Meeting minutes from IETF-52 Date: Fri, 21 Dec 2001 12:49:43 -0600 Message-ID: <005a01c18a50$4257c670$52f1a2ac@D2BVG111> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C18A1D.F7BD5670" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Apparently-From: UserR1846@aol.com Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C18A1D.F7BD5670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Following are the DRAFT IPS meeting minutes from IETF-52 Please send clarifications/additions/corrections, etc to the list, David and I, no later than Jan 3. Thanks, Elizabeth & David IETF IPS Meeting Minutes December 10, 2001 Reference section in all documents must be split into two sections - normative and non-normative. Interim meeting in Feb. Announcement on IPS mailing list & IETF announce. Need RSVPs. Information at www.ietf.org/IESG/IPS-Interim.txt -- FC Encapsulation draft (Ralph Weber) Basically done. SOFc4 will be going in, other minor (editorial) fixes. Rev 5 will be candidate for last call. Last call will be in conjunction with FCIP and/or iFCP -- Security draft (Bernard Aboba) Security documetn will go standards track, but all protocol docs will be self contained. Protocol documents will govern, in case of any discrepancies. Note to this effect will be added to security draft. Cannot require sequence space extension is in ESPv3, since will not be available for some time. NAT traversal language will be non-normative due to IPR issues and problems encountered in testing IPsec NAT traversal. Dependencies - Protocol specs, need SLPv2 security update (2608bis), but may be able to finesse needing a normative reference - IPsec transforms are in progress. See IPsec WG for more, for the AES drafts, MAC is in good shape, CTR requires some attention in ipsec WG - SRP (RFC 2945) - DHCP-ipsec drafts. Transforms Currently specified Must: 3DES-CBC; HMAC-SHA1 Should NOT: DES Should: AES-CTR and CBC-MAC w/ XCBC Q: (William Dixon) - Why not AES-128CBC instead of AES-CTR? Much further along; interoperable implementations are available. Will be discussed in ipsec wg. Resolving issues off of the mailing list. Demoting 3DES will cause interoperability problems. Transport vs. Tunnel mode Specified: iFCP, FCIP Tunnel mode MUST; transport MAY iSCSI, under discussion. Summary of pros/cons Transport mode: Pros: End to end security, Lower overhead, Larger MTU, Negotiation of connection specific selectors is common practice Cons: Requires ipsec to be implemented on the IPS entities Greater difficulties with NAT traversal Tunnel mode: Pros: More compatible with existing VPN gateways, Don't have to implement ipsec on IPS entity Easier to traverse NATs Cons: More overhead, Smaller MTU Tunnel problems - connection-specific selectors and dynamically assigned addresses (problem is use of mode config which is non-standard - standards track documents exist, but not clear whether they will be widely implemented). Tunnel mode + connection-specific selectors are very difficult to do. Many gateways do not do connection-specific selectors well. Need to look at these issues in more detail. Implementors please look into the security gateways you're planning to use. IKE identifiers Both Main and Aggressive are MUST, Aggressive mode is there to deal with dynamic addresses. Open issues in use of specific ID types. Policy Distribution - Constraining IKE is a good first step. - Security policy gets tricky when - Not all nodes in an iSCSI network support security - IKE times out when trying to reach a non-IPsec entity (e.g., 60 sec). Initiator needs to know whether to try IPsec or not to avoid this. Responder-controlled security [TCP SYN in clear, target sets up an SA if it supports IPsec] is an alternative. Currently a MUST NOT to avoid denial of service issues because TCP SYN causes IKE work (much worse than TCP SYN flood case). This limits need for security policy to target. Doesn't work well for target initiating IKE to initiator behind a firewall or NAT. May use iSNS security policy distribution. Existing IPsec policy distribution mechanisms have been problematic. iSNS could be better. Certificates SHOULD: use IKE certificates SHOULD: check certificate revocation list MAY: use certificates to determine authorization Easiest enrollment solution is to have HBAs get/use host certs. Long cert chains cause IP fragmentation in IKE, which can cause problems. Allow any IKE certificate - use these for identity only, avoid adding new OIDs to do iSCSI authorization. General, but inconclusive transport vs. tunnel mode discussion. Pros and Cons for making each the MUST implement brought up. Neither mode will be prohibited. Can make both MUST, but decision has not been made. John Hufferd asks about transport vs. tunnel mode resolution Needs to go to mailing list David Black will write something up. -- iFCP (Charles Monia) - iFCP N_Port address definition Currently IP address of gateway + N port ID behind it. Issue with NAPTs. As of -08, adding TCP port to IP address (gateway address is the pair). No iSNS change required. - FC Broadcast FC Broadcast is best-effort, IPFC and FC-VI use this to do discovery. Not performance-critical. Currently uses UDP/IP, may not be as reliable as FC broadcast over fabric, and relying on IP fragmentation may be a big problem. Changing to a server-based TCP implementation of broadcast - send broadcast frame to broadcast server who then sends it to all gateways. Use 0xFF-FF-FF well known address as port ID for all of the iFCP entities involved in this. Discovery based on iSNS - need iSNS changes for this. Need to look at issue of two broadcast servers in the same domain. - Stale Frame detection Currently optional. Will change to MUST implement and MUST use. -- iFCP MIB (Charles Monia) Minor changes, cleanup from review by Keith. Fairly stable, close to done. -- iSNS (Josh Tseng) - Change to support iFCP transparent mode. - Security Issues. Use IPsec to protect iSNS messages. MUST implement IPsec w/ESP in tunnel mode for iFCP and appropriate mode for iSCSI. Use unicast for query and response message Use multicast for iSNS heartbeat used to discover iSNS server iFCP gateways and iSCSI devices using iSNS SHOULD authenticate to the iSNS server. - Use of iSNS to distribute security policy This is about centralization of security administration. Security bitmap to hold things not already negotiated by ISAKMP. Parameters to be stored and distributed by iSNS - Use/non-use of: IPsec, IKE, Main Mode, Aggressive Mode, Perfect forward secrecy, preshared key, tunnel & transport mode. Need to review this for what's necessary - work with security draft authors (e.g., Bernard Aboba). - DHCP option - make absolutely sure that a new one is needed before asking for one. DHCP name server option may not be appropriate (RFC 2937). -- iSNS MIB No serious content changes - minor cleanups (similar to iFCP MIB), stable, close to done. -- FCIP (Ralph Weber) At -07 draft. Major open issue is WWN short frame security. A few other minor changes will be made (e.g., add SOF and EOF for class 4 FC service). WWN Short Frame Security - Prior to Irvine, FCIP endpoint was IP address. NAT/NAPT support makes this problematic. Sending WWN across as identity. Discussion of how to go about solving this problem - authors would like to do this as part of FC-BB-2 rather than FCIP. IETF IPS oversight/check of this will be necessary. FC-BB-2 - specific solution seems to be preferred to a generic FC solution. Expect to see proposal on list soon, discussion at FC-BB-2 in Feb. and IPS interim that week. -- FCIP SLP No known issues aside from coordination with security draft updates. Will revise to match those and be ready for WG Last Call. FCIP-SLP draft tracks security draft which tracks 2608bis. -- SCSI, FC Mgmt, and FCIP MIBs (Keith McCloghrie) FC Mgmt MIB has been transferred to IPS from IPFC. Keith is rearchitecting (e.g., consistency with IF and Entity MIBs, remove non-FC objects), expect first ietf-ips-fcmgmt-mib draft soon. SCSI MIB - design team nearing completion of UML model. Internet-Draft will be forthcoming shortly. T10 working session on SCSI MIB on Monday, Jan 14 in Houston. Details available at www.t10.org/meeting.htm. FCIP MIB - There are a bunch of work items - NAT, BB-2 changes, dependent on rework of FC Mgmt MIB. Yaron: SCSI and iSCSI MIBs use "instance" abstraction so that one MIB can represent multiple entities, FCIP should do likewise. Security - SNMPv3 has security. Get security boilerplate from IETF OPS MIB site, and expand on it to add specific information about risks involved in specific writable elements. DO NOT say "MUST use SNMPv3". Next draft will be coming in January. End discussion of transport/tunnel mode and related issues. Dynamic address support for tunnel mode is an interoperability issue that weighs against use of tunnel mode. ---------- Tuesday Dec 11--------- -- Agenda rebashing Framing requirements agenda item pulled due to Transport AD/tsvwg issue. Resolution will be posted to the list, soon, we hope. -- SRP IPR requirements (David Black) Note Well statement displayed. Key points - If know about IP, need to disclose. Further, if you should know about IP, need to disclose (e.g. Company cannot keep you in the dark in order to avoid disclosure). But, no patent search is required (e.g. if no way you should know, don't need to go out of your way to find out if there are claims). Should company own IP directly material to standard, IETF will ask Company to publish statement, and request fair, reasonable and non-discriminatory terms for licensing of IP. Company is not obligated to comply. IETF does not judge fairness Claims (rumors) against SRP 1) Stanford. Royalty free license available. 2) Lucent. May have IP that may be essential. If essential, will be licensed under standard Lucent IP licensing practices. 3) Speke patent. No statement. May be owned by Phoenix Technologies. MUST/SHOULD/MAY requirements discussion for SRP at February interim meeting. Closing warning from AD and WG chair about results of Dell and Rambus situations in which hiding patents resulted in patents being unenforceable (FTC consent decree for Dell, actual court decisions in Rambus). -- UNH Plugfest report (Yamini Shastry) Held Oct 28 - Nov 3 Based on -08 draft 15 participated. 4 initiators, 1 initiator, 9 both initiator & target. 1 neither initiator/target. Reserved bits test did not match with "MUST be zero on transmit/MUST be ignored on receive" Summary of changes made to draft as a result of plugfest - most are minor, see slides. OOO issue is number 5 on this list - will come up in main iSCSI section. Areas not tested include - digests - multiple connections/session - discovery sessions - unsolicited and/or immediate data - command windows greater than 1 - Security - No implementations of markers - No real error recovery - No serious parameter negotiation beyond defaults Next plugfest [Feb 11-15] will look at these areas. Based on -09 draft. Information from www.iol.unh.edu or from Yamini at yshastry@iol.unh.edu. New scripts will be available 2 weeks prior to plugfest. Request for minimum conformance of participate products made. Markers - determining whether they're in/out has to wait for resolution of status of tsvwg ULP Framing draft. -- iSCSI (Julian Satran) Open issues - Security (tunnel vs. transport, and transforms) - Framing (tsvwg status)? - Constant overhead word stuffing (version of Constant Overhead Byte Stuffing) as a possible alternative - Abort Task Set/Clear Task Set - OOO PDU handling - Serious issue: are NOPs allowed in a discovery session. * Abort and Clear Task set - Remove ordering discussion for Clear Task Set - Abort Task Set currently requires a SCSI response for every aborted command. Alternate - hold Abort Task Set response until all outstanding responses are ACKed by the initiator. Avoids any need to create "fake" SCSI responses, significantly reduces burden on Initiator. This is slower, but much simpler. Most of section 9.4 will vanish. Sense of the room - follow this approach, modulo working out details on the list. * Out of Order Operation - This is a within-connection issue. No ordering requirements across connections. - Within-connection issue turned up on list in context of allowing a DMA engine to reorder commands at its convenience. Could use multiple connections to do this. Eddy Q: DMA flow-through to wire is a plausible adapter design that increases the desireability of doing ordering. Mallikarjun: Unsolicited non-immediate data provides additional ordering flexibility. Sense of the room - this is the right approach. * NOP in Discovery Sessions Underlying problem is whether to keep discovery session around for detection/notification of configuration changes. Mark Bakke: Want to know when new targets become available. Multiple ways to do this. Discovery session is an in-band way of doing this, allows an async message to be sent to do this (won't need to poll). Wants both NOPs and async messages on on discovery session to keep it alive long-term. Resolution - N&D team to generate text describing applicability and use of the various mechanisms, along with requirements on implementations to yield interoperability. Will ship to list and use that to drive closure on need for long-lived discovery sessions which in turn will drive closure of NOP issues. * Framing Word-stuffing version of COBS is an alternative to markers. Has to touch every byte of message. CRC and ESP also have to, so this might be a good alternative when those techniques are in use. COBS/COWS is the same class of mechanism as markers, similar considerations. Comment that something is needed that doesn't require TCP modifications - that would be either markers or COBS/COWS. Hardware targets talking to software initiators is the scenario of interest. Comment that TCP modification for framing is acceptable, hence no need for COBS/COWS or markers. Discussion is not conclusive - Need to get tsvwg ULP issue resolved, write COBS/COWS up in detail (sense of room is no serious objection to doing so), and take this up on list, resolve at Feb. interim. The -10 version will appear sufficiently prior to interim meeting. -- iSCSI Boot draft iSCSI usage of DHCP option is fine. Will go into next draft. (DHC WG consulted, no need for DHC draft). -- iSCSI Naming and Discovery Will be informational. IQN format will use date codes New ISID format New username and Initiator name usage guidelines Stringprep approach to character normalization ISID format change - ISID will contain vendor ID. Will now be 48 bits, use IEEE OUI or IANA OUI. 02 should be "Local Usage" rather than "Random". Note that this can be coped with at install time. 3 forms now acceptable 1) IEEE OUI 2) IANA Enterprise Number 3) Vendor unique -- locally unique; not globally unique. Recommendation: Double size to 128, so that you can have a WW unique value Response: Not needed -- ISID is relative to iSCSI node name, which is WW unique. Three people support embedding the MAC into the ISID. Will take this to the list. John Hufferd: Embedding the MAC in this ISID binds the session to a single HBA. Conservative Reuse description. Reuse ISIDs across all targets. Needed to deal with T10 changes in progress to persistent reservations. -- Stringprep (Mark Bakke) IDN is close to done on the stringprep/nameprep drafts. This draft is about how to use this for iSCSI names. Q: What about unassigned codepoints. A: Whatever underlying stringprep draft does. Sense of room: adopted as WG draft. -- SLP for iSCSI Document is stable, unicast SLP usage is ok. Will coordinate security w/IPS Security draft. Will work with SLP authors on suitable notification support. -- iSCSI MIB status (Mark Bakke) Fitting into family of MIBs below SCSI MIB that is being developed - FCP MIB may be developed, no plans for parallel SCSI MIB. Details of how these fit together being worked out in SCSI MIB team. Will be looking at how to add usernames/cert identities to access control area of iSCSI MIB w/o large complexity. -- iSNS for iSSI status (Josh Tseng) See iSNS session on Monday. New informational material on how iSNS can be used to map iSCSI and FC devices in a hybrid installation. Final comments - Request to look at applying ISID-like structure to portal group tags for consistency and autoconfiguration reasons. ------=_NextPart_000_005B_01C18A1D.F7BD5670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Following are the DRAFT IPS meeting minutes from = IETF-52

Please send clarifications/additions/corrections, etc = to the list, David and I, no later than Jan 3.

 

Thanks,

 

Elizabeth & David

 

IETF IPS Meeting Minutes

 

December 10, 2001

 

Reference section in all documents must be split into = two sections – normative and non-normative.

 

Interim meeting in Feb. Announcement on IPS mailing = list & IETF announce. Need RSVPs.

Information at = www.ietf.org/IESG/IPS-Interim.txt

 

-- FC Encapsulation draft (Ralph = Weber)

 

Basically done.

SOFc4 will be going in, other minor (editorial) = fixes. 

Rev 5 will be candidate for last = call.

Last call will be in conjunction with FCIP and/or = iFCP

 

-- Security draft (Bernard Aboba)

 

Security documetn will go standards track, but all = protocol docs will be self contained.

Protocol documents will govern, in case of any discrepancies.

Note to this effect will be added to security = draft.

 

Cannot require sequence space extension is in ESPv3, = since will not be available for some time.

 

NAT traversal language will be non-normative due to = IPR issues

         =    and problems encountered in testing IPsec NAT traversal.

 

Dependencies

         =    - Protocol specs, need SLPv2 security update (2608bis), but may = be

         =             &= nbsp;  able to finesse needing a normative reference

         =    - IPsec transforms are in progress.

         =             &= nbsp;  See IPsec WG for more, for the AES drafts, MAC is in good = shape,

         =             &= nbsp;  CTR requires some attention in ipsec WG

         =    - SRP (RFC 2945)

         =    - DHCP-ipsec drafts.

 

Transforms

Currently specified

         =    Must: 3DES-CBC; HMAC-SHA1

         =    Should NOT: DES

         =    Should: AES-CTR and CBC-MAC w/ XCBC

 

Q: (William Dixon) – Why not AES-128CBC instead = of AES-CTR?  Much further along;

interoperable implementations are available.  = Will be discussed in ipsec wg. 

 

         =    Resolving issues off of the mailing list.

         =    Demoting 3DES will cause interoperability problems.

 

Transport vs. Tunnel mode

 

         =    Specified: iFCP, FCIP Tunnel mode MUST; transport MAY

 

         =    iSCSI, under discussion.

         =    Summary of pros/cons

 

         =    Transport mode:

         =             &= nbsp;  Pros: End to end security, Lower overhead, Larger MTU,

         =             &= nbsp;        Negotiation of connection specific selectors is common = practice

         =             &= nbsp;  Cons: Requires ipsec to be implemented on the IPS entities

         =             &= nbsp;        Greater difficulties with NAT traversal

 

         =    Tunnel mode:

 

         =    Pros: More compatible with existing VPN gateways,

         =          Don’t have to implement ipsec on IPS entity

         =          Easier to traverse NATs

 

         =    Cons: More overhead, Smaller MTU

 

         =    Tunnel problems - connection-specific selectors and dynamically = assigned

         =             &= nbsp;  addresses (problem is use of mode config which is non-standard -

         =             &= nbsp;  standards track documents exist, but not clear whether they will

         =             &= nbsp;  be widely implemented).

 

         =    Tunnel mode + connection-specific selectors are very difficult to = do.

         =    Many gateways do not do connection-specific selectors well.

 

         =    Need to look at these issues in more detail.  Implementors please = look

         =             &= nbsp;  into the security gateways you're planning to use.

 

 

IKE identifiers

         =    Both Main and Aggressive are MUST, Aggressive mode is there to = deal with

         =             &= nbsp;  dynamic addresses.

         =    Open issues in use of specific ID types.

 

Policy Distribution

         =    - Constraining IKE is a good first step.

         =    - Security policy gets tricky when

         =             &= nbsp;  - Not all nodes in an iSCSI network support security

         =             &= nbsp;  - IKE times out when trying to reach a non-IPsec entity

         =             &= nbsp;           &n= bsp;  (e.g., 60 sec).  Initiator needs to know whether to

         =             &= nbsp;           &n= bsp;  try IPsec or not to avoid this.

         =    Responder-controlled security [TCP SYN in clear, target sets up

         =             &= nbsp;  an SA if it supports IPsec] is an alternative.  = Currently

         =             &= nbsp;  a MUST NOT to avoid denial of service issues because TCP

         =             &= nbsp;  SYN causes IKE work (much worse than TCP SYN flood case).

         =             &= nbsp;  This limits need for security policy to target.

         =    Doesn't work well for target initiating IKE to initiator = behind

         =             &= nbsp;  a firewall or NAT.

         =    May use iSNS security policy distribution.

         =    Existing IPsec policy distribution mechanisms have been = problematic.

         =             &= nbsp;  iSNS could be better.

 

Certificates

         =    SHOULD: use IKE certificates

         =    SHOULD: check certificate revocation list

         =    MAY: use certificates to determine authorization

 

         =    Easiest enrollment solution is to have HBAs get/use host = certs.

         =    Long cert chains cause IP fragmentation in IKE, which can cause = problems.

         =    Allow any IKE certificate - use these for identity only, avoid = adding

         =             &= nbsp;  new OIDs to do iSCSI authorization.

 

         =    General, but inconclusive transport vs. tunnel mode discussion.

         =    Pros and Cons for making each the MUST implement brought = up.

         =    Neither mode will be prohibited.  Can make both MUST, but decision has not = been made.

         =   

         =    John Hufferd asks about transport vs. tunnel mode = resolution

         =    Needs to go to mailing list

         =    David Black will write something up.

 

 

-- iFCP (Charles Monia)

 

- iFCP N_Port address definition

         =    Currently IP address of gateway + N port ID behind it. Issue with = NAPTs.

         =    As of -08, adding TCP port to IP address (gateway address is the = pair). 

         =    No iSNS change required.

 

- FC Broadcast

         =    FC Broadcast is best-effort, IPFC and FC-VI use this to do = discovery.

         =    Not performance-critical.  Currently uses UDP/IP, may not be as = reliable

         =    as FC broadcast over fabric, and relying on IP fragmentation may be a = big

         =    problem.  Changing to a server-based TCP implementation of broadcast = -

         =    send broadcast frame to broadcast server who then sends it to all = gateways.

         =    Use 0xFF-FF-FF well known address as port ID for all of the iFCP = entities

         =    involved in this.  Discovery based on iSNS - need iSNS changes for = this.

         =    Need to look at issue of two broadcast servers in the same = domain.

- Stale Frame detection

         =    Currently optional.  Will change to MUST implement and MUST = use.

 

-- iFCP MIB (Charles Monia)

 

Minor changes, cleanup from review by Keith.  = Fairly stable, close to done.

 

-- iSNS (Josh Tseng)

 

- Change to support iFCP transparent = mode.

 

- Security Issues.  Use IPsec to protect iSNS = messages.

         =    MUST implement IPsec w/ESP in tunnel mode for iFCP and appropriate mode = for

         =             &= nbsp;  iSCSI.

         =    Use unicast for query and response message

         =    Use multicast for iSNS heartbeat used to discover iSNS = server

         =    iFCP gateways and iSCSI devices using iSNS SHOULD authenticate to the iSNS = server.

 

- Use of iSNS to distribute security = policy

         =    This is about centralization of security administration.

         =    Security bitmap to hold things not already negotiated by = ISAKMP.

         =    Parameters to be stored and distributed by iSNS - Use/non-use of:

         =             &= nbsp;  IPsec, IKE, Main Mode, Aggressive Mode, Perfect forward secrecy, =

         =             &= nbsp;  preshared key, tunnel & transport mode.

         =    Need to review this for what's necessary - work with security = draft

         =    authors (e.g., Bernard Aboba).

 

- DHCP option - make absolutely sure that a new one = is needed before asking for

         =    one.  DHCP name server option may not be appropriate (RFC = 2937).

 

-- iSNS MIB

 

No serious content changes - minor cleanups (similar = to iFCP MIB), stable, close

         =    to done.

 

-- FCIP (Ralph Weber)

 

At -07 draft.  Major open issue is WWN short = frame security.  A few other

minor changes will be made (e.g., add SOF and EOF for = class 4 FC service).

 

WWN Short Frame Security

 

- Prior to Irvine, FCIP = endpoint was IP address.  NAT/NAPT support makes this

         =    problematic.  Sending WWN across as identity.

 

Discussion of how to go about solving this problem - = authors would like to

         =    do this as part of FC-BB-2 rather than FCIP.  IETF IPS = oversight/check

         =    of this will be necessary.  FC-BB-2 - specific solution seems = to

         =    be preferred to a generic FC solution.  Expect to see proposal on = list

         =    soon, discussion at FC-BB-2 in Feb. and IPS interim that = week.

 

-- FCIP SLP

 

No known issues aside from coordination with security = draft updates.  Will

revise to match those and be ready for WG Last = Call.  FCIP-SLP draft tracks

security draft which tracks = 2608bis.

 

-- SCSI, FC Mgmt, and FCIP MIBs (Keith = McCloghrie)

 

FC Mgmt MIB has been transferred to IPS from = IPFC.  Keith is rearchitecting

         =    (e.g., consistency with IF and Entity MIBs, remove non-FC = objects),

         =    expect first ietf-ips-fcmgmt-mib draft soon.

 

SCSI MIB - design team nearing completion of UML model.  Internet-Draft will

         =    be forthcoming shortly.  T10 working session on SCSI MIB on Monday, =

         =    Jan 14 in Houston. Details available at www.t10.org/meeting.htm.

 

FCIP MIB - There are a bunch of work items - NAT, = BB-2 changes, dependent on

         =    rework of FC Mgmt MIB.

         =    Yaron: SCSI and iSCSI MIBs use "instance" abstraction so that = one

         =             &= nbsp;  MIB can represent multiple entities, FCIP should do = likewise.

 

         =    Security - SNMPv3 has security.  Get security boilerplate from = IETF

         =    OPS MIB site, and expand on it to add specific information = about

         =    risks involved in specific writable elements.  DO NOT say = "MUST

         =    use SNMPv3".

 

         =    Next draft will be coming in January.

 

End discussion of transport/tunnel mode and related = issues.

         =    Dynamic address support for tunnel mode is an interoperability issue = that

         =    weighs against use of tunnel mode.

 

 

---------- Tuesday Dec 11---------

 

-- Agenda rebashing

 

Framing requirements agenda item pulled due to = Transport AD/tsvwg issue.  Resolution

will be posted to the list, soon, we = hope.

 

-- SRP IPR requirements (David = Black)

 

         =    Note Well statement displayed.

         =    Key points –

         =             &= nbsp;  If know about IP, need to disclose. Further, if you should know about IP, =

         =             &= nbsp;  need to disclose (e.g. Company cannot keep you in the dark in order to =

         =             &= nbsp;  avoid disclosure). But, no patent search is required (e.g. if no way you =

         =             &= nbsp;  should know, don't need to go out of your way to find out if there are = claims).

 

         =    Should company own IP directly material to standard, IETF will ask Company to = publish statement,

         =    and request fair, reasonable and non-discriminatory terms for licensing of IP. 

         =    Company is not obligated to comply.

 

         =    IETF does not judge fairness

 

         =    Claims (rumors) against SRP

         =    1)         = Stanford.  Royalty free license available.  =            =

         =    2)         = Lucent.  May have IP that may be essential. 

         =             &= nbsp;  If essential, will be licensed under standard Lucent IP licensing = practices.

         =    3)         Speke patent.  No statement. May be owned by Phoenix = Technologies.

 

         =    MUST/SHOULD/MAY requirements discussion for SRP at February interim = meeting.

 

Closing warning from AD and WG chair about results of = Dell and Rambus situations

         =    in which hiding patents resulted in patents being unenforceable (FTC = consent

         =    decree for Dell, actual court decisions in Rambus).

 

-- UNH Plugfest report (Yamini = Shastry)

 

Held Oct 28 - Nov 3

Based on -08 draft

15 participated.  4 initiators, 1 initiator, 9 = both initiator & target. 1 neither initiator/target.

 

Reserved bits test did not match with "MUST be = zero on transmit/MUST be ignored

         =    on receive"

 

Summary of changes made to draft as a result of = plugfest - most are minor, see

         =    slides.

 

OOO issue is number 5 on this list - will come up in = main iSCSI section.

 

Areas not tested include

         =    - digests

         =    - multiple connections/session

         =    - discovery sessions

         =    - unsolicited and/or immediate data

         =    - command windows greater than 1

         =    - Security

         =    - No implementations of markers

         =    - No real error recovery

         =    - No serious parameter negotiation beyond defaults

 

Next plugfest [Feb 11-15] will look at these = areas.  Based on -09 draft.

Information from www.iol.unh.edu or from Yamini at yshastry@iol.unh.edu.

New scripts will be available 2 weeks prior to = plugfest.

Request for minimum conformance of participate = products made.

 

Markers - determining whether they're in/out has to = wait for resolution of

         =    status of tsvwg ULP Framing draft. 

 

-- iSCSI (Julian Satran)

 

Open issues

         =    - Security (tunnel vs. transport, and transforms)

         =    - Framing (tsvwg status)?

         =             &= nbsp;  - Constant overhead word stuffing (version of Constant Overhead = Byte

         =             &= nbsp;           &n= bsp;  Stuffing) as a possible alternative

         =    - Abort Task Set/Clear Task Set

         =    - OOO PDU handling

         =    - Serious issue: are NOPs allowed in a discovery = session.

 

* Abort and Clear Task set

         =    - Remove ordering discussion for Clear Task Set

         =    - Abort Task Set currently requires a SCSI response for = every

         =             &= nbsp;  aborted command.  Alternate - hold Abort Task Set = response

         =             &= nbsp;  until all outstanding responses are ACKed by the initiator.

         =             &= nbsp;  Avoids any need to create "fake" SCSI responses, = significantly

         =             &= nbsp;  reduces burden on Initiator.  This is slower, but much = simpler.

         =             &= nbsp;  Most of section 9.4 will vanish.

Sense of the room - follow this approach, modulo = working out details

         =    on the list.

 

* Out of Order Operation

         =    - This is a within-connection issue.  No ordering requirements = across

         =             &= nbsp;  connections.

         =    - Within-connection issue turned up on list in context of allowing = a

         =             &= nbsp;  DMA engine to reorder commands at its convenience.  Could = use

         =             &= nbsp;  multiple connections to do this.

Eddy Q: DMA flow-through to wire is a plausible = adapter design that increases

         =    the desireability of doing ordering.

Mallikarjun: Unsolicited non-immediate data provides additional ordering

         =    flexibility.

Sense of the room - this is the right = approach.

 

* NOP in Discovery Sessions

 

Underlying problem is whether to keep discovery = session around for

         =    detection/notification of configuration changes.

 

Mark Bakke: Want to know when new targets become available.  Multiple ways

         =    to do this.  Discovery session is an in-band way of doing this, = allows

         =    an async message to be sent to do this (won't need to poll).  = Wants

         =    both NOPs and async messages on on discovery session to keep it = alive

         =    long-term.

 

Resolution - N&D team to generate text describing applicability and use of

         =    the various mechanisms, along with requirements on implementations = to

         =    yield interoperability.  Will ship to list and use that to drive = closure

         =    on need for long-lived discovery sessions which in turn will = drive

         =    closure of NOP issues.

 

* Framing

         =    Word-stuffing version of COBS is an alternative to markers.  Has to = touch

         =             &= nbsp;  every byte of message.  CRC and ESP also have to, so this might = be

         =             &= nbsp;  a good alternative when those techniques are in use.

 

         =    COBS/COWS is the same class of mechanism as markers, similar = considerations.

         =             &= nbsp;  Comment that something is needed that doesn't require TCP = modifications

         =             &= nbsp;  - that would be either markers or COBS/COWS.  Hardware targets = talking

         =             &= nbsp;           &n= bsp;  to software initiators is the scenario of interest.

         =             &= nbsp;  Comment that TCP modification for framing is acceptable, hence = no

         =             &= nbsp;  need for COBS/COWS or markers.

 

         =    Discussion is not conclusive - Need to get tsvwg ULP issue resolved, = write

         =             &= nbsp;  COBS/COWS up in detail (sense of room is no serious objection to = doing

         =             &= nbsp;  so), and take this up on list, resolve at Feb. interim.

 

The -10 version will appear sufficiently prior to = interim meeting. 

 

-- iSCSI Boot draft

 

iSCSI usage of DHCP option is fine.  Will go = into next draft.

(DHC WG consulted, no need for DHC = draft).

 

-- iSCSI Naming and Discovery

 

         =    Will be informational.

         =    IQN format will use date codes

         =    New ISID format

         =    New username and Initiator name usage guidelines

         =    Stringprep approach to character normalization

 

ISID format change - ISID will contain vendor = ID.  Will now be 48 bits, use

         =    IEEE OUI or IANA OUI.  02 should be "Local Usage" rather than "Random".

         =    Note that this can be coped with at install time.

 

3 forms now acceptable

1) IEEE OUI

2) IANA Enterprise Number

3) Vendor unique -- locally unique; not globally = unique.

 

Recommendation: Double size to 128, so that you can = have a WW unique value

 

Response:  Not needed -- ISID is relative to = iSCSI node name, which is WW unique.

 

Three people support embedding the MAC into the = ISID.  Will take this to the

         =    list. 

 

John Hufferd: Embedding the MAC in this ISID binds = the session to a single HBA.

 

Conservative Reuse description.  Reuse ISIDs = across all targets.  Needed to

         =    deal with T10 changes in progress to persistent = reservations.

 

-- Stringprep (Mark Bakke)

 

IDN is close to done on the stringprep/nameprep drafts.  This draft is about how

         =    to use this for iSCSI names.

 

Q: What about unassigned = codepoints.

A: Whatever underlying stringprep draft = does.

 

Sense of room: adopted as WG draft.

 

-- SLP for iSCSI

 

Document is stable, unicast SLP usage is = ok.

Will coordinate security w/IPS Security = draft.

Will work with SLP authors on suitable notification = support.

 

-- iSCSI MIB status (Mark Bakke)

 

Fitting into family of MIBs below SCSI MIB that is = being developed -

         =    FCP MIB may be developed, no plans for parallel SCSI MIB.  = Details

         =    of how these fit together being worked out in SCSI MIB = team.

 

Will be looking at how to add usernames/cert = identities to access control

         =    area of iSCSI MIB w/o large complexity.

 

-- iSNS for iSSI status  (Josh = Tseng)

 

See iSNS session on Monday.  New informational = material on how iSNS can

         =    be used to map iSCSI and FC devices in a hybrid = installation.

 

Final comments

- Request to look at applying ISID-like structure to = portal group tags

         =    for consistency and autoconfiguration reasons.

 

------=_NextPart_000_005B_01C18A1D.F7BD5670-- From owner-ips@ece.cmu.edu Fri Dec 21 20:50:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06247 for ; Fri, 21 Dec 2001 20:50:26 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM13Lu26928 for ips-outgoing; Fri, 21 Dec 2001 20:03:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM13JZ26922 for ; Fri, 21 Dec 2001 20:03:19 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 20:04:34 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372C4@CORPMX14> From: Black_David@emc.com To: santoshr@cup.hp.com Cc: ips@ece.cmu.edu Subject: iSCSI: "conservative reuse" requirement Date: Fri, 21 Dec 2001 19:50:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh Rao writes: > I am opposed to the suggestion that "conservative re-use" of ISIDs be > made a MUST. This is really only required when initiators need to be > using the new T10 Reservation scheme that can be shared > across initiator ports. Those reservations are a Target feature. With this approach, the ability to use the target feature depends on details of the initiator implementation. More below ... > For those initiators that don't care about this type of reservation, > conservative re-use is of no use and initiators may like to assign > ISID's in a per-initiator node fashion, thereby, being able to use these > ISIDs as a lookup index for the sessions on that initiator node. > > Hence, I suggest that "conservative re-use" be worded as > "encouraged to use" or something to that effect, but not MUST USE. > > Comments ? The "initiator" is more than one entity. The iSCSI HBA/NIC and driver doesn't know whether shared persistent reservations are being used and shouldn't have to care - they're just more SCSI commands to transport. Some other entity (e.g., clustering software) will be generating the shared persistent reservations. This raise the possible scenario involving a target that supports the new shared persistent reservations and an entity that wants to use them. The entity detects (via SCSI means, e.g., something in a mode page) that the Target supports shared persistent reservations, tries to use them, only to discover that they don't work because the iSCSI HBA/NIC doesn't implement "conservative reuse". I'm worried about this causing both interoperability issues and possible T10 issues -- from a T10 viewpoint, if shared persistent reservations don't work, the initiating entity should have some SCSI-level means of determining this ... if that means exists only on the Target, the above scenario is iSCSI's problem (Target can't query Initiator to determine whether it does "conservative reuse"), and having a separate initiator side means that the entity has to check only for iSCSI (and not for any other SCSI transport) does not seem like the right approach. I think this is headed towards "conservative reuse" being a MUST if we're serious about support for shared persistent reservations. Comments? --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Dec 21 20:57:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06293 for ; Fri, 21 Dec 2001 20:57:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM1Uj628317 for ips-outgoing; Fri, 21 Dec 2001 20:30:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM1UhZ28310 for ; Fri, 21 Dec 2001 20:30:43 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 20:26:20 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372C5@CORPMX14> From: Black_David@emc.com To: roweber@acm.org, ips@ece.cmu.edu Subject: RE: FCIP: Short Frame Security Solution Proposal Date: Fri, 21 Dec 2001 20:19:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk I think this is a workable approach. A few comments: - There are a dependencies among a number of components on who supports what, some of which are under T11's control. If it turns out that the T11 aspects of this are not mandatory to implement, I think multiple TCP connections in a single FCIP session need to be disallowed if this authentication cannot be performed by the implementation (i.e., is not implemented) - putting in a note to this effect regardless of what T11 does might be a good idea to decouple FCIP from FC-BB-2 in this area. - Any nonce must be validated ("yes, that's my connection") at most once. If the FC Entity on the other end of the first connection is capable of saying "yes" twice to the same nonce, there's an obvious replay attack. - Some words will need to be added about a nasty race condition in which the attacker opens up a connection up to the point of sending the short frame, watches a real connection get set up to the point that the attacker sees the short frame on the real connection; the attacker extracts and uses the nonce, and TCP tricks (e.g., corrupt the TCP packet containing the nonce to cause a checksum failure, or send a well-timed RST). The short answer to dealing with this is "use IKE and also ESP encryption if warranted" when this sort of attack is a concern. - I think it's necessary to authentication the first TCP connection (up to FCAP or whatever) before sending the ILS that would authenticate a subsequent one, but details beyond that (e.g., can one send the SYN for the second TCP connection before the first connection authenticates) are probably up to implementations. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Thursday, December 20, 2001 8:55 AM > To: IPS Reflector > Subject: FCIP: Short Frame Security Solution Proposal > > > This message proposes a solution to the security > issues surrounding the FCIP Short Frame proposed as > a solution to the NAPTs problem. The security > issues and directions toward a solution were > discussed in Salt Lake and this message is an > attempt to follow the path charted in those > discussions. > > Solution Assumptions > > A) This matters a lot less if IPsec authentication > is in use and rigorously managed because IPsec solves > this authenticates TCP connections, substantially > reducing the opportunity for rogue end-points to > make TCP connections to FC/FCIP devices. > > B) Securing the first TCP connection in an FCIP Link > is handled outside the scope of this solution. In Fibre > Channel, securing the first TCP connection may be > accomplished using FCAP. At this time, it is not clear > whether FCAP authentication of the TCP connection > needs to be mandatory or recommended for configurations > exposed to security risks. > > C) Once authenticated, the first TCP connection is > allowed to carry F Class frames. > > D) The objective of this solution is to authenticate > the second to n-th TCP connections using a protocol > that has lower overhead than FCAP or IPsec. > > Solution Changes in FCIP > > The principle change in FCIP is to REQUIRE the FCIP > Entity to interact with the FC Entity to authenticate > the second through n-th TCP connections for a given > Link End Point (LEP). > > Upon receipt of an n-th TCP connect request and Short > Frame (SF), the FCIP Entity MUST request (from the FC > Entity) confirmation that the TCP connect request is > from the same FC/FCIP Entity as the first TCP connection. > The FCIP Entity MUST delay return of the SF until the FC > Entity provides the confirmation. > > In addition, a new 64-bit nonce field is needed in > the SF. Theoretically, the nonce field could overlay > the Destination FC Fabric Entity WWN field. However, > the current leaning is to add a new field, lengthening > the FCIP Short Frame to the point where it will have > to be called the FCIP Special Frame. > > The FCIP Entity shall communicate the newly defined > SF nonce plus other SF information to the FC Entity > in the interaction required to confirm the second > through n-th TCP connect requests. > > Solution Changes in FC-BB-2 > > The principle changes in FC-BB-2 are: > > a) Discussion of how the FC Entity may respond > to an FCIP Entity request for authentication > of a second through n-th TCP connect request; > b) Definition of a new SW_ILS to be used in > confirming the second through n-th TCP > connect requests; and > c) Description of how the new SW_ILS is exchanged > between the FC Entity where the TCP connect > request is received an authenticated FC Entity > over an existing F Class enabled TCP Connection. > > N.B. It is important that this negotiation be placed > in the FC Entity because the Fibre Channel elements > at each end of a link have in place protocol mechanisms > for negotiations and exchanges of this type. > > Solution Mechanics > > When an FC/FCIP Entity makes a TCP connect request > for what it knows to be the second to n-th TCP > connection in an FCIP Link, it places a randomly > generated 64-bit nonce in the SF. (Note: There needs > to be requirements on the nonce generation method to > ensure that predicting nonce values is sufficiently > difficult. The ULP Framing draft has been recommended > as a source for these requirements.) > > When an FCIP Entity receives a second to n-th > TCP connect request, it will delay returning the > SF until the SF nonce and other SF information is > authenticated by the FC Entity. If the FC Entity > reports that authentication failed, the FCIP > Entity SHALL close the TCP connection. > > Details of the mechanism by which the FC Entity > authenticates a second to n-th TCP Connect request > are to be specified by T11 in FC-BB-2 (along with > numerous other Fibre Channel protocol issues > related to FCIP). > > A proposal containing at least the following > will be made. > > The FC Entity may authenticate the TCP Connect request > based on configuration information that is outside the > scope of the standards. In situations where security > risks are possible, the FC Entity shall transmit > the information provided by the FCIP Entity via a new > SW_ILS on a previously authenticated TCP connection > (FCIP Data Engine) enabled for Class F frames. > > It can be assumed that an authenticated TCP connection > enabled for F Class frames exists because the absence > on such a connection prohibits basic Fibre Channel > link operation (i.e., the problem must be dealt with > as a general concern for FC-BB-2 operation over FCIP.) > > The response to the new SW_ILS will be one of: > > SW_ACC - indicating that the new TCP Connect > request is authenticated > SW_RJT - indicating that the new TCP Connect > request is not authenticated > > The response shall be communicated to the FCIP Entity > who shall act accordingly, as described above. > > An FC Entity that receives one of the new SW_ILSs shall > perform the requested authentication by verifying that it > initiated a TCP connect request and sent the SF nonce. > The results of the authentication shall be communicated > in the response to the SW_ILS as described above. > > To further increase the difficulty of snooping > TCP connections, an FCIP Entity that receives > a duplicate nonce shall close the connection > on which that nonce was received immediately > without causing the SW_ILS to be sent. > > Solution Pragmatics > > This solution binds the authentication of the > second through n-th TCP connections to the > authentication of the first TCP connection, > thus fitting the solution within the bounds > of the assumptions (but no more). > > Once the first TCP connection is properly > authenticated, it is reasonable to ask the > FC/FCIP Entity at the other end, "Did you > make this additional TCP connect request?" > The nonce (properly guaranteed for randomness) > represents the "this" aspect of the question > and renders nearly impossible nonce replay > attacks wherein the FC/FCIP Entity asked the > SW_ILS question is fooled into believing > that SW_ACC should be sent because a correct > nonce is presented. > > This solution slows down the process of > establishing TCP connections, but that seems > unavoidable. > > It may be desirable to require that there > be no attempts to establish the second through > n-th TCP connections until the first is > authenticated. This is another slow down in > the process, but one that will be imposed > anyway at a later step. > > It may be desirable to further slow down > the process by requiring FC/FCIP Entities > to process only one TCP connect request > at a time, rejecting all TCP connect > requests that arrive while another is > in process. This will further add to the > difficulty of mounting a replay attack. > > From owner-ips@ece.cmu.edu Sat Dec 22 00:27:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10027 for ; Sat, 22 Dec 2001 00:27:34 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM4fSp07340 for ips-outgoing; Fri, 21 Dec 2001 23:41:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM4fLZ07330; Fri, 21 Dec 2001 23:41:22 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id FAA248740; Sat, 22 Dec 2001 05:41:12 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM4fmG17722; Sat, 22 Dec 2001 05:41:48 +0100 To: "shaileshm" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Recovery Within Connection - Command Restart MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 06:41:44 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 06:41:47, Serialize complete at 22/12/2001 06:41:47 Content-Type: multipart/alternative; boundary="=_alternative 0019AC7CC2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0019AC7CC2256B2A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable owner-ips@ece.cmu.edu wrote on 20-12-2001 00:06:44: >=20 >=20 > 1. The draft says a) Requests not acknowledged for a long time?..=20 > Does the SCSI timeout?s introduce the notion of time, or does iscsi=20 > has to have timeout?s at the transport layer. Also for detecting=20 > connection failures don?t the NOP?s have to be timed. >=20 Timeouts here are iSCSI timeouts - by the time SCSI timeouts it is too=20 late > 2. Request not acknowledged would be most of the time due to a=20 > header digest errors at the target end. If the header is bad how=20 > would one know at the target, that this was a command PDU v/s a Data > PDU, since the target will have to implement a command scoreboard if > it is a command PDU. > You won't know but initiator sees that ExpCmdSN is not advancing =20 > 3. Usage of Reject PDU talks about Reject on Command PDU : however=20 > the error codes for Reject PDU do not indicate a command PDU error. ??? >=20 > 4. Is the recovery R2T different from the usual R2T. >=20 > No=20 >=20 > These things are not clear from the draft ! >=20 >=20 It is all in the eye of the reader :-) We heard already complaints that the text is too bulky and has things that = belong to a tutorial=20 >=20 > Shailesh Manjrekar. Julo --=_alternative 0019AC7CC2256B2A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

owner-ips@ece.cmu.edu wrote on 20-1= 2-2001 00:06:44:

>  
>
> 1. The draft says a) Requests = not acknowledged for a long time…..
> Does the SCSI timeout’s introduce the notion of time, or does is= csi
> has to have timeout’s at the transport layer. Also for detecting=
> connection failures don’t the NOP’s have to be timed.
>

Timeouts here are iSCSI timeouts - = by the time SCSI timeouts it is too late

> 2. Request not acknowledged wo= uld be most of the time due to a
> header digest errors at the target end. If the header is bad how
> would one know at the target, that this was a command PDU v/s a Data > PDU, since the target will have to implement a command scoreboard if > it is a command PDU.
>

You won't know but initiator sees t= hat ExpCmdSN is not advancing
 
> 3. Usage of Reject PDU talks a= bout Reject on Command PDU : however
> the error codes for Reject PDU do not indicate a command PDU error.

???
>
> 4. Is the recovery R2T differe= nt from the usual R2T.
>
>
No  
>
> These things are not clear fro= m the draft !
>
>
It is all in the eye of the reader = :-)
We heard already complaints that th= e text is too bulky and has things that belong to a tutorial
>
> Shailesh Manjrekar.

Julo --=_alternative 0019AC7CC2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 00:35:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10087 for ; Sat, 22 Dec 2001 00:35:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM5Cbl08801 for ips-outgoing; Sat, 22 Dec 2001 00:12:37 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM5CYZ08795; Sat, 22 Dec 2001 00:12:34 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id GAA12726; Sat, 22 Dec 2001 06:12:27 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM5D0t109340; Sat, 22 Dec 2001 06:13:00 +0100 To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu Subject: Re: iSCSI: MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 07:12:57 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 07:13:01, Serialize complete at 22/12/2001 07:13:01 Content-Type: multipart/alternative; boundary="=_alternative 001BBD0DC2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001BBD0DC2256B2A_= Content-Type: text/plain; charset="US-ASCII" markers - Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 19-12-01 22:00 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: This quote is from section 5.3. Can someone give an example of such a case? Whenever parameter action or acceptance is dependent on other parameters, the dependent parameters MUST be sent after the parameters they depend on. If they are sent within the same command a response for a parameter might imply responses for others. Eddy --=_alternative 001BBD0DC2256B2A_= Content-Type: text/html; charset="US-ASCII"
markers - Julo


"Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

19-12-01 22:00

       
        To:        "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI:



This quote is from section 5.3. Can someone give an example of such a case?

 

 Whenever parameter action or acceptance is dependent on other

 parameters, the dependent parameters MUST be sent after the

 parameters they depend on.  If they are sent within the same command

 a response for a parameter might imply responses for others.

 

Eddy

 

--=_alternative 001BBD0DC2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 02:51:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26279 for ; Sat, 22 Dec 2001 02:51:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM6vUx13564 for ips-outgoing; Sat, 22 Dec 2001 01:57:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM6vSZ13558 for ; Sat, 22 Dec 2001 01:57:28 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id HAA217530; Sat, 22 Dec 2001 07:57:21 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM6vs7104998; Sat, 22 Dec 2001 07:57:55 +0100 To: "Robert D. Russell" Cc: ips@ece.cmu.edu Subject: Re: iSCSI: enquiry key MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 08:57:52 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 08:57:55, Serialize complete at 22/12/2001 08:57:55 Content-Type: multipart/alternative; boundary="=_alternative 00260995C2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00260995C2256B2A_= Content-Type: text/plain; charset="US-ASCII" Bob, "Robert D. Russell" wrote on 20-12-2001 12:48:31: > Julian: > > A few questions: > > 1. Does the value of MaxOutstandingR2T include the implied initial R2T > when operating in unsolicited mode (as described in 2.2.5)? > > I believe the answer is "no", but would suggest a minor rewording > in Appendix D item 29 to remove any doubt: > "Initiator and target negotiate the maximum number of outstanding R2Ts > per task, excluding any implied initial R2T that might be part of that > task." > OK > > 2. I believe the upper limit for MaxRecvPDULength should be 2**24-1, > not 2**24 as is currently shown in Appendix D item 24. > The reason is that the Data Segment Length field in the header is only > 24 bits, so 2**24-1 is the largest number that can be stored in it > (i.e., a PDU with 2**24 bytes of data could never be sent). > To be consistent, if the limit for MaxRecvPDULength is changed to be > 2**24-1, perhaps we should also change the limit for MaxBurstSize and > FirstBurstSize to be the same 2**24-1. > OK > > 3. In section 2.2.4 it says: The value "?" with any key has the meaning > of enquiry and should be answered with the current value of > "NotUnderstood." > > 3a.It is not clear what this means when keys are "one-way". For example, > assume the initiator sends the target "MaxRecvPDULength=?". Should the > target send back the maximum PDU length it (the target) expects to > receive from the initiator, or should the target send back the maximum > PDU length it (the target) will ever send to the initiator? > The same question applies to "FMarker=?" and "RFMarkInt=?" and > "SFMarkInt=?". Regardless of what the answer to this question is, > another question immediately arises -- how does one side ask for the > other value? > Yes - I will clarify that both values have to sent and state how > 3b.It is not clear if the usual restrictions to LO, IO, and FFPO > should apply to these enquiries. For example, during a login for a > second (third, fourth, ...) connection in a session, can one side > send "MaxBurstSize=?" to the other side to obtain the current value > for the session, even though MaxBurstSize is an LO parameter and can > not be negotiated for the second (third, fourth, ...) connection? > Or in another example, can a text request from the initiator include > "MaxBurstSize=?" even though MaxBurstSize cannot be negotiated or > changed after the Leading Login? > will clarify > If the answer to these examples is "yes", then further clarification in > the standard is necessary to indicate that the "key=?" can be sent > at any time and is not restricted by the LO, IO, and FFPO labels. > > In the "yes" case, we also need to clarify whether it is possible to > send "key=?" enquiries for operational keys during security negotiation, > and vice versa. > > If the answer to these examples is "no", then the value of an enquiry > appears to be marginal, and I would suggest that it be eliminated > from the spec (when can it be used to any benefit?). > > My personal opinion is that "key=?" seems fairly useless -- if they are > to operate correctly, both sides of a connection really have to know the > values of all the keys at all times, and the rules for negotiation make > it clear how and when these values change. The only real "enquiry" > situation is when an initiator is attempting to discover targets, and > this is handled completely differently by the use of "SendTargets". > So when is there a use for either side to send "key=?". Unless there > is a clear example where this is useful, we should eliminate it and thus > remove another special case during parameter processing. > I am not sure that we have all the use scenarios to afford removing it > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > --=_alternative 00260995C2256B2A_= Content-Type: text/html; charset="US-ASCII"
Bob,

"Robert D. Russell" <rdr@io.iol.unh.edu> wrote on 20-12-2001 12:48:31:

> Julian:
>
> A few questions:
>
> 1. Does the value of MaxOutstandingR2T include the implied initial R2T
>    when operating in unsolicited mode (as described in 2.2.5)?
>
>    I believe the answer is "no", but would suggest a minor rewording
>    in Appendix D item 29 to remove any doubt:
>    "Initiator and target negotiate the maximum number of outstanding R2Ts
>    per task, excluding any implied initial R2T that might be part of that
>    task."
>
OK
>
> 2. I believe the upper limit for MaxRecvPDULength should be 2**24-1,
>    not 2**24 as is currently shown in Appendix D item 24.
>    The reason is that the Data Segment Length field in the header is only
>    24 bits, so 2**24-1 is the largest number that can be stored in it
>    (i.e., a PDU with 2**24 bytes of data could never be sent).
>    To be consistent, if the limit for MaxRecvPDULength is changed to be
>    2**24-1, perhaps we should also change the limit for MaxBurstSize and
>    FirstBurstSize to be the same 2**24-1.
>
OK
>
> 3. In section 2.2.4 it says: The value "?" with any key has the meaning
>    of enquiry and should be answered with the current value of
>    "NotUnderstood."
>
> 3a.It is not clear what this means when keys are "one-way".  For example,
>    assume the initiator sends the target "MaxRecvPDULength=?".  Should the
>    target send back the maximum PDU length it (the target) expects to
>    receive from the initiator, or should the target send back the maximum
>    PDU length it (the target) will ever send to the initiator?
>    The same question applies to "FMarker=?" and "RFMarkInt=?" and
>    "SFMarkInt=?".  Regardless of what the answer to this question is,
>    another question immediately arises -- how does one side ask for the
>    other value?
>
Yes - I will clarify that both values have to sent and state how

> 3b.It is not clear if the usual restrictions to LO, IO, and FFPO
>    should apply to these enquiries.  For example, during a login for a
>    second (third, fourth, ...) connection in a session, can one side
>    send "MaxBurstSize=?" to the other side to obtain the current value
>    for the session, even though MaxBurstSize is an LO parameter and can
>    not be negotiated for the second (third, fourth, ...) connection?
>    Or in another example, can a text request from the initiator include
>    "MaxBurstSize=?" even though MaxBurstSize cannot be negotiated or
>    changed after the Leading Login?
>
will clarify
>    If the answer to these examples is "yes", then further clarification in
>    the standard is necessary to indicate that the "key=?" can be sent
>    at any time and is not restricted by the LO, IO, and FFPO labels.
>
>    In the "yes" case, we also need to clarify whether it is possible to
>    send "key=?" enquiries for operational keys during security negotiation,
>    and vice versa.
>
>    If the answer to these examples is "no", then the value of an enquiry
>    appears to be marginal, and I would suggest that it be eliminated
>    from the spec (when can it be used to any benefit?).
>
>    My personal opinion is that "key=?" seems fairly useless -- if they are
>    to operate correctly, both sides of a connection really have to know the
>    values of all the keys at all times, and the rules for negotiation make
>    it clear how and when these values change.  The only real "enquiry"
>    situation is when an initiator is attempting to discover targets, and
>    this is handled completely differently by the use of "SendTargets".
>    So when is there a use for either side to send "key=?".  Unless there
>    is a clear example where this is useful, we should eliminate it and thus
>    remove another special case during parameter processing.
>
I am not sure that we have all the use scenarios to afford removing it
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
--=_alternative 00260995C2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 03:33:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27676 for ; Sat, 22 Dec 2001 03:33:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM7qeY16034 for ips-outgoing; Sat, 22 Dec 2001 02:52:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM7qaZ16022; Sat, 22 Dec 2001 02:52:37 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id IAA08922; Sat, 22 Dec 2001 08:52:30 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM7r37167940; Sat, 22 Dec 2001 08:53:03 +0100 Subject: Re: iSCSI: negotiated more than once To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 Message-ID: From: "Julian Satran" Date: Sat, 22 Dec 2001 09:26:38 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 09:53:04 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBM7qbZ16026 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit owner-ips@ece.cmu.edu wrote on 20-12-2001 20:13:05: > Section 5 says: > > > > Both initiator and target MUST NOT attempt to negotiate a parameter > > more than once during any login stage. Attempting to do so MUST > > result in the login (and connection) being terminated. > > > > But section 6 says: > > > > Both initiator and target MUST NOT attempt to negotiate a parameter > > more than once during any negotiation sequence without an intervening > > reset. If detected by the target this MUST result in a Reject with a > > reason of "protocol error". The initiator MUST reset the negotiation > > as outlined above. > > > > A reject could mean to terminate the connection but a "reset" > doesn't. So, are these statements consistent? Notice that section 6 > says "sequence" but section 5 says "login stage". Is that the difference? > > Negotiating a parameter twice in login is terminating the login and the connection. In a text exchange it resets the exchange. > > Eddy Julo From owner-ips@ece.cmu.edu Sat Dec 22 03:46:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27769 for ; Sat, 22 Dec 2001 03:46:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM8Fom17102 for ips-outgoing; Sat, 22 Dec 2001 03:15:50 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM8FlZ17096 for ; Sat, 22 Dec 2001 03:15:48 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id JAA55736; Sat, 22 Dec 2001 09:15:41 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM8GGA151996; Sat, 22 Dec 2001 09:16:17 +0100 To: Nitin Dhingra Cc: ips@ece.cmu.edu Subject: Re: Implicit Logout MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 10:16:13 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 10:16:15, Serialize complete at 22/12/2001 10:16:15 Content-Type: multipart/alternative; boundary="=_alternative 002C831FC2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002C831FC2256B2A_= Content-Type: text/plain; charset="US-ASCII" Nitin, Nitin Dhingra wrote on 21-12-2001 08:44:58: > Can in any case login response provide implicit logout? > > Like if you open up a session for discovery, you got your target names, > then why do u need to waste time on proper logout procedure, you could > have implicit logout in the login response? The discovery information comes after login response in FFP. Julo --=_alternative 002C831FC2256B2A_= Content-Type: text/html; charset="US-ASCII"
Nitin,

Nitin Dhingra <nitin.dhingra@dcmtech.co.in> wrote on 21-12-2001 08:44:58:

> Can in any case login response provide implicit logout?
>
> Like if you open up a session for discovery, you got your target names,
> then why do u need to waste time on proper logout procedure, you could
> have implicit logout in the login response?
The discovery information comes after login response in FFP.

Julo --=_alternative 002C831FC2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 04:08:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27891 for ; Sat, 22 Dec 2001 04:08:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM8avG18081 for ips-outgoing; Sat, 22 Dec 2001 03:36:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM8asZ18074; Sat, 22 Dec 2001 03:36:54 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA23592; Sat, 22 Dec 2001 09:36:44 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM8bJA210862; Sat, 22 Dec 2001 09:37:19 +0100 To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips@ece.cmu.edu Subject: Re: iSCSI: LUN in Data-out and NOP PDU's MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 10:37:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 10:37:17, Serialize complete at 22/12/2001 10:37:17 Content-Type: multipart/alternative; boundary="=_alternative 002F4AAEC2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002F4AAEC2256B2A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, It was felt that TTT management could be kept local to the LU or group of=20 LUs (no requirement to be unique on target). The combination LU and TTT is used instead. That enables groups of=20 entities to form a "virtual target". Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 21-12-01 22:38 =20 To: "ips@ece. cmu. edu \(E-mail\)" cc:=20 Subject: iSCSI: LUN in Data-out and NOP PDU's What is the LUN for in Data-out and NOP-out PDU?s? =20 I assume the LUN in Data-out could be used for steering but I don?t know=20 what the LUN in NOP-out PDU?s is for. =20 Eddy --=_alternative 002F4AAEC2256B2A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eddy,

It was felt that TTT management coul= d be kept local to the LU or group of LUs (no requirement to be unique on t= arget).
The combination LU and TTT is used i= nstead. That enables groups of entities to form a "virtual target"= ;.

Julo


"Eddy Quic= ksall" <Eddy=5FQuicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

21-12-01 22:38

      &n= bsp;
        To: &nbs= p;      "ips@ece. cmu. edu \(E-mail\)" <ips@ece= .cmu.edu>
        cc: &nbs= p;      
        Subject:=        iSCSI: LUN in Data-out and NOP PDU's



What is the LUN for in Data-out and NOP-o= ut PDU’s?

 

I assume the LUN in Data-out could be used= for steering but I don’t know what the LUN in NOP-out PDU’s is= for.

 

Eddy

--=_alternative 002F4AAEC2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 04:09:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27905 for ; Sat, 22 Dec 2001 04:09:56 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBM8QM617595 for ips-outgoing; Sat, 22 Dec 2001 03:26:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBM8QKZ17587; Sat, 22 Dec 2001 03:26:20 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id JAA63928; Sat, 22 Dec 2001 09:26:12 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBM8Qk755896; Sat, 22 Dec 2001 09:26:46 +0100 To: David Woolf Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu Subject: Re: Login Request/Response PDU Formats MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 10:26:43 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 10:26:46, Serialize complete at 22/12/2001 10:26:46 Content-Type: multipart/alternative; boundary="=_alternative 002E0F74C2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002E0F74C2256B2A_= Content-Type: text/plain; charset="US-ASCII" Thanks - You are right - no digests! Julo David Woolf Sent by: owner-ips@ece.cmu.edu 21-12-01 17:25 To: ips@ece.cmu.edu cc: Subject: Login Request/Response PDU Formats Hello, The tables describing both the Login Response and Login Request PDUs (3.12 and 3.13) indicate that at byte 48 a digest will appear if digests had been negotiated. This looks like a carry-over from when digests were negotiated in the Security phase, and would have been used in the Operational Parameter Negotiation. Perhaps the 'if any' statement in these tables should be removed. thank you, David Woolf ************************************************ University of New Hampshire Interoperability Lab iSCSI and Fibre Channel Consortiums Durham, NH 03824 (603) 862 0701 ************************************************ --=_alternative 002E0F74C2256B2A_= Content-Type: text/html; charset="US-ASCII"
Thanks - You are right - no digests! Julo


David Woolf <djwoolf@io.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu

21-12-01 17:25

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Login Request/Response PDU Formats



Hello,
The tables describing both the Login Response and Login Request
PDUs (3.12 and 3.13) indicate that at byte 48 a digest will appear if
digests had been negotiated. This looks like a carry-over from when
digests were negotiated in the Security phase, and would have been used in
the Operational Parameter Negotiation. Perhaps the 'if any' statement in
these tables should be removed.

thank you,

David Woolf
************************************************
University of New Hampshire Interoperability Lab
iSCSI and Fibre Channel Consortiums
Durham, NH 03824
(603) 862 0701
************************************************

--=_alternative 002E0F74C2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 12:47:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01385 for ; Sat, 22 Dec 2001 12:47:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBMGreQ21488 for ips-outgoing; Sat, 22 Dec 2001 11:53:40 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBMGrcZ21480 for ; Sat, 22 Dec 2001 11:53:38 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id RAA93198 for ; Sat, 22 Dec 2001 17:53:31 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBMGs57167066 for ; Sat, 22 Dec 2001 17:54:06 +0100 To: ips@ece.cmu.edu Subject: Fw: Re: iSCSI: negotiated more than once MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sat, 22 Dec 2001 18:54:03 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/12/2001 18:54:06, Serialize complete at 22/12/2001 18:54:06 Content-Type: multipart/alternative; boundary="=_alternative 005C884AC2256B2A_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005C884AC2256B2A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Eddy, Here is the answer. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 22-12-01 18:49 ----- Julian Satran 22-12-01 09:26 To: "Eddy Quicksall" cc: "ips@ece. cmu. edu \(E-mail\)" , owner-ips= @ece.cmu.edu Subject: Re: iSCSI: negotiated more than once owner-ips@ece.cmu.edu wrote on 20-12-2001 20:13:05: > Section 5 says: >=20 >=20 >=20 > Both initiator and target MUST NOT attempt to negotiate a parameter=20 >=20 > more than once during any login stage. Attempting to do so MUST=20 >=20 > result in the login (and connection) being terminated. >=20 >=20 >=20 > But section 6 says: >=20 >=20 >=20 > Both initiator and target MUST NOT attempt to negotiate a parameter=20 >=20 > more than once during any negotiation sequence without an intervening=20 >=20 > reset. If detected by the target this MUST result in a Reject with a=20 >=20 > reason of "protocol error". The initiator MUST reset the negotiation=20 >=20 > as outlined above. >=20 >=20 >=20 > A reject could mean to terminate the connection but a ?reset?=20 > doesn?t. So, are these statements consistent? Notice that section 6=20 > says ?sequence? but section 5 says ?login stage?. Is that the=20 difference? >=20 >=20 Negotiating a parameter twice in login is terminating the login and the=20 connection. In a text exchange it resets the exchange.=20 >=20 > Eddy Julo --=_alternative 005C884AC2256B2A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Eddy,

Here is the answer. Julo
----- Forwarded by J= ulian Satran/Haifa/IBM on 22-12-01 18:49 -----
Julian Satran

22-12-01 09:26


        To: &nbs= p;      "Eddy Quicksall" <Eddy=5FQuicksall@iviv= ity.com>
        cc: &nbs= p;      "ips@ece. cmu. edu \(E-mail\)" <ips@ece= .cmu.edu>, owner-ips@ece.cmu.edu
        Subject:=        Re: iSCSI: negotiated more than onceLink




owner-ips@ece.cmu.edu wrote on 20-1= 2-2001 20:13:05:

> Section 5 says:
>
>  
>
>  Both initiator and targe= t MUST NOT attempt to negotiate a parameter
>
>  more than once during an= y login stage. Attempting to do so MUST
>
>  result in the login (and= connection) being terminated.
>
>  
>
> But section 6 says:
>
>  
>
>  Both initiator and targe= t MUST NOT attempt to negotiate a parameter
>
>  more than once during an= y negotiation sequence without an intervening
>
>  reset. If detected by th= e target this MUST result in a Reject with a
>
>  reason of "protocol= error".  The initiator MUST reset the negotiation
>
>  as outlined above.
>
>  
>
> A reject could mean to termina= te the connection but a “reset”
> doesn’t. So, are these statements consistent? Notice that sectio= n 6
> says “sequence” but section 5 says “login stage̶= 1;. Is that the difference?
>
>

Negotiating a parameter twice in lo= gin is terminating the login and the connection.
In a text exchange it resets the ex= change.
>
> Eddy

Julo
--=_alternative 005C884AC2256B2A_=-- From owner-ips@ece.cmu.edu Sat Dec 22 21:55:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05114 for ; Sat, 22 Dec 2001 21:55:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBN28CO17012 for ips-outgoing; Sat, 22 Dec 2001 21:08:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBN28AZ17007 for ; Sat, 22 Dec 2001 21:08:10 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e34.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA244746; Sat, 22 Dec 2001 20:15:25 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBN1HVU164604; Sat, 22 Dec 2001 18:17:31 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: scope of keys To: "Eddy Quicksall" Cc: "Julian Satran" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 22 Dec 2001 17:16:48 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/22/2001 06:17:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, you read to much into my reply. The Requirement is stated elsewhere, I do not think all commentary can be included in that appendix. The important thing is it is consistent with the rest of the Draft. I understand your point, but I do not know what the right trade off is here. Each time we repeat, in a different way, what is said elsewhere, we increase the possibility of document errors and continue to extend the length of the document. As we push for Last Call, unless it is wrong, I say leave it alone. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/21/2001 06:13:29 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Julian Satran/Haifa/IBM@IBMIL, Subject: RE: iSCSI: scope of keys John, I think my point was missed. Now you have possibly pointed out another angle to my point. My point is that "use" does not contain enough information. In your response below, you have implied that IO now means "required" ... but it does not. I think that "use" has been overloaded and I think each key should have a list of properties (use is one, scope is another and now maybe required should be a third). Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, December 21, 2001 1:05 AM To: Eddy Quicksall Cc: Julian Satran; ips@ece.cmu.edu Subject: RE: iSCSI: scope of keys Eddy, It not only OK, it is required. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/18/2001 07:25:44 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI: scope of keys IO means "only during login". It does not mean "connection only". 13 TargetName Use: IO by initiator ALL by target, Declarative This key must be provided by the initiator of the TCP connection to the remote endpoint in the first login request ... So, here is a case where it is session wide ... so IO cannot mean "connection only" (I assume that since TargetName is not LO, then it must be ok to send this key for each connection). Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 14, 2001 3:50 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: scope of keys Eddy, I think the text says it - but if people love headers better I can add it (some voices needed). Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 14-12-01 22:12 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: scope of keys Would it make sense to add a "scope" to each key definition? The IO and LO "use:" labels almost do that but not in all cases. For example: SW = Session wide CO = Connection only Use: IO Who can send: Initiator Scope: SW Key= Eddy From owner-ips@ece.cmu.edu Sun Dec 23 15:29:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28176 for ; Sun, 23 Dec 2001 15:29:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBNJJGd11991 for ips-outgoing; Sun, 23 Dec 2001 14:19:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBNJJDZ11987 for ; Sun, 23 Dec 2001 14:19:13 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id UAA99214 for ; Sun, 23 Dec 2001 20:19:05 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBNJJTd152420 for ; Sun, 23 Dec 2001 20:19:39 +0100 To: ips@ece.cmu.edu Subject: iSCSI - Synch an Steering Appendix - Markers & COWS MIME-Version: 1.0 X-Mailer: Lotus Notes Build M11_11052001 Beta 4 November 05, 2001 From: "Julian Satran" Message-ID: Date: Sun, 23 Dec 2001 21:19:17 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/12/2001 21:19:40 Content-Type: multipart/mixed; boundary="=_mixed 0069BD07C2256B2B_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk --=_mixed 0069BD07C2256B2B_= Content-Type: multipart/alternative; boundary="=_alternative 0069BD0BC2256B2B_=" --=_alternative 0069BD0BC2256B2B_= Content-Type: text/plain; charset="US-ASCII" Dear colleagues, Attached are the two versions of the Synch and Steering appendix that we are considering. During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft. We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it). Any comments/questions are welcome. Happy holidays and a peaceful and prosperous 2002, Julo --=_alternative 0069BD0BC2256B2B_= Content-Type: text/html; charset="US-ASCII"
Dear colleagues,

Attached are the two versions of the Synch and Steering appendix that we are considering.

During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft.

We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it).

Any comments/questions are welcome.

Happy holidays and a peaceful and prosperous 2002,
Julo

--=_alternative 0069BD0BC2256B2B_=-- --=_mixed 0069BD07C2256B2B_= Content-Type: application/octet-stream; name="Appendix-Synch-and-Steering_0512_AS-Markers.pdf" Content-Disposition: attachment; filename="Appendix-Synch-and-Steering_0512_AS-Markers.pdf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjkgMCBvYmoNPDwgDS9MaW5lYXJpemVkIDEgDS9PIDExIA0vSCBbIDY1 NSAxODMgXSANL0wgMzEyMTUgDS9FIDI4MTQ1IA0vTiAyIA0vVCAzMDkxOCANPj4gDWVuZG9iag0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTkgMTEgDTAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMDU2NSAwMDAwMCBuDQowMDAw MDAwODM4IDAwMDAwIG4NCjAwMDAwMDA5OTEgMDAwMDAgbg0KMDAwMDAwMTA5NSAwMDAwMCBuDQow MDAwMDAxNTk1IDAwMDAwIG4NCjAwMDAwMDE4MjAgMDAwMDAgbg0KMDAwMDAwMzMwMyAwMDAwMCBu DQowMDAwMDI3OTE3IDAwMDAwIG4NCjAwMDAwMDA2NTUgMDAwMDAgbg0KMDAwMDAwMDgxOCAwMDAw MCBuDQp0cmFpbGVyDTw8DS9TaXplIDIwDS9JbmZvIDcgMCBSIA0vUm9vdCAxMCAwIFIgDS9QcmV2 IDMwOTA5IA0vSURbPDExNWNiZmE0NDI5M2I4MzQwOWVhZWMwMTA3MTJiNmM4PjxjZDZlMjg0YmUz YmQ1Yzg5NDFiZGFlNzY2NWM2MTBjND5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTEwIDAg b2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDYgMCBSIA0vTWV0YWRhdGEgOCAwIFIgDS9Q YWdlTGFiZWxzIDUgMCBSIA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IC9TIDQ1IC9MIDg0IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTkgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYOoHkaxq DPwMCABiA0UZOBpO3mNgAGEoEABidihmYPADKpzGkMFrwGmwfvs3qBIWBobCU0CaCYg9AAIMALOy Co4NZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag03MyANZW5kb2JqDTExIDAgb2JqDTw8IA0vVHlw ZSAvUGFnZSANL1BhcmVudCA2IDAgUiANL1Jlc291cmNlcyAxMiAwIFIgDS9Db250ZW50cyAxNSAw IFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSAN L1JvdGF0ZSAwIA0+PiANZW5kb2JqDTEyIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQg XSANL0ZvbnQgPDwgL1RUMiAxMyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSAxNyAwIFIgPj4g DT4+IA1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxMjQgDS9XaWR0aHMgWyA2MDAgMCAwIDYwMCAwIDAg MCAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgMCAwIDAgMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IA0wIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgNjAwIDYwMCA2MDAgMCA2 MDAgMCA2MDAgDTAgMCAwIDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCAwIDYwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250 IC9BREVQUEYrQ291cmllck5ldyANL0ZvbnREZXNjcmlwdG9yIDE0IDAgUiANPj4gDWVuZG9iag0x NCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDgzMiANL0NhcEhlaWdo dCA1NzggDS9EZXNjZW50IC0zMDAgDS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTIxIC02ODAgNjM4 IDEwMjEgXSANL0ZvbnROYW1lIC9BREVQUEYrQ291cmllck5ldyANL0l0YWxpY0FuZ2xlIDAgDS9T dGVtViA0MiANL1hIZWlnaHQgNDIxIA0vRm9udEZpbGUyIDE2IDAgUiANPj4gDWVuZG9iag0xNSAw IG9iag08PCAvTGVuZ3RoIDE0MDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIms V02P2zYQvftXDNCL3ay0kizbUW9ONi0SIGmAVQ9F0gMtUTa7EiWQ9Hod5Md3Zij5Y+1FWyDeg0Rq OHx8M284+yYf3eZ5AjHk1SiOwyzLIMK//jWZZ2GaLeawSNIwnqcZ5M0ogvXo9rf7GNZ2FERhFEW4 usDpfDf6Mlb3b+/fT4I4jqNonEyDO1nIZiVNEMWTv/IPoyBGl3MIZgvI72hRMRrDJP97FIXJDKY0 eeKUXlPv+MO2VkLDJI7G98IZfAUePH/cO6FLYUrL49yI4uEG4N1TR0NlpAX0tIckipJn6/kZLzJ6 Y6gMaRaHaQ+VYCy7TupSPbHxMoT7vS4Ad8R9pTRKr2Gn3AZ+VU+yhPdkpJ00j6KGj8I8SGPZdRy+ hiAht1/G+UZZEOiWjcl1hyildjgLVjVdLcEWG9lIqFrDWC1uujGtVt+EU62Gr+PPd3940BEEcRgv vOtVuyUu9gzWSGeURCRfJyG8d7C1yEXjQYHbCMdWShf1tpQXW5w4n3vnSiOcBr/SMrToalHgmdFP xYdX/cEtvoEjo42E/O1nsM5I0YSDxyScpt7jsueIgRSttsoiCW31y4np1Ju+2TsJt0PsIvC/7/0z fjYmo+TZ3HQYX9JG07fDOoBnC5+PT40ubC5pw8kFzGHG61KEQeqL+rmLMTt/yeYa8lcB/2hdMPxe Bee/YXxqdGHDzvOfyWn0HT7JJ8f2rO8A0y2wThgHXctxhgCKttvDT/EZZ/+Fjh+L+JyO9H8gT/4d uafjxyM+5nWOGmERsGJ73Vuv1U7s61aUsKLcZxGRUYPwt9pR5WER9wK2V8qBfJRYC3A5rZODYFd7 YGpYpicSJSPRgHwqZOeo9PDXoWBcRhK/NlbWj7zQconBtR4LVoEWqyRvLrnakJHjvRi+hdXWgTAS dOuuQG+NWistHDs/Yg6HsJxeJEdQJzfJBbUKS20hPBqJRaay0oFreaTlk8fniaHiupGilCYE8vIc Hm0z89dDX8Cwoku13rj+vMhsLfUa7wW6KbCyOaE0brxrYZoEK+WG/Ssl67In159qx8xyXEuutIQZ Nu0OI3HkswX7oDofQR/cY6Gl2dYgeDK7DFuFjvnQfP2gWF44tA88a4SzkcCjcJSkCu0dXERtkJjl K2KCS/kooncGthNaU+YKxttxVhQPSMTh5rKbdluXSJ94lHAUIXrBKevvrFZLwItGlV7JdF4tB1Qd NgBMibPhdb1hKPzBHKoB/WwlxQ9pkXTV40U8uGpYEj7A/eUWHiGRK2QGWrKq6LCDVtCbluvWKbGq pWdTacUqVMKhsCgrsCat8eAfl39yqINLNjnyiEP5BMbYlkpLy+E32GYpZAg93aJDbB+8UAYI5ZZ7 k7pFFeHXLjih0qBf7IgqptKAFMWGclTLgm5+j7eUldjWmBssbjrcp99R4hoKaSiZrySW1I8KG4jG 9zXOYlMYjW+opyFWfSaR2Heqrrl6YRJvO27TEM2hMcG6MZzOXEmxw+pDiomCC9bggAi126rC1ZVp G04YAdxdIAqKCHTScCuji9MUK+XaiPLQ34R9+8qd2yF/liH2GiR6TjHcbumG3m9ofy4avuXQIfl+ 67RL6svvscI3N8zTQTGcmJiumKoh3G3NlTQ5xHnCfOMtQcRjTJH2IZO9xFHGlno7lmcnC4Xlh97D ZOythtZVuCvx3W0UOlV922hP4zhk4/HCuMESBKWyxLc9mfd+3+XY/sdYQ9ejeBZmswzm8yTMFpBQ +x/0/40YOaqG77NsGkaIxBvMpmgwOzNIX0dhls56g/kizOL0zGCazfGZ9AYJTsavzw1mKT7nL2NI sow+vfw9RYzRAGGa4eTizCBO0cFs2hukeIsseoN/BgCPe6pDCmVuZHN0cmVhbQ1lbmRvYmoNMTYg MCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNDUyMyAvTGVuZ3RoMSA0MTEx NiA+PiANc3RyZWFtDQpIiVxVCVSU1xX+7ntvRmRRNCIiQWcYxIVBUYlBBYICBqsoRlCgRodVtEyE qNQdSxo1Yq1KaowY9cSlQVwGNSeJ5hipmJQKrhSico5pqrWRQ6ypts3R+V8voydp+v9n5r/vvvvu 8t3lgQD4YS0k0qbPHDGq4OXMKmBvH+ZOy3PmlHzvVZ0BvMdL2p9XtsRy4EDOA160A90qCkvmO0+1 /2cx4OUATCnzi5cXNuw8VAOE7gUKw4oKcvLrV/e+wvry+cyYImb4rBSxbPADXocVOZcsaz5YG83r JsA7tHhRXg51Xt0NbGgA+sQ6c5aVdJ/uuxTY85DlLa/lOAt23fnoDLCb92lEyaLFS9hvfnbv79ov eb2g5OGpNj8g8B+s76i6C6htCObvAJmLAYC+9ez3tbGG93jfcGst2vh0+rPf0yed3995/tMp9ekX +WiBE1vxDvNG00XUIAE9md8CSaBMxKIKv8SfkaEfMNeKfbgPO8aiSBvohXIYtBr7SEDwqRhcQwG2 iFgZoTpAGEZRspYqEMla0rEdgbjEGodpb16fECGMmWD+BTnPy66j9Hd0VjXqXLxPsaJVHUUTOilU wXhDV+pqvQs98FCGuM/pkdrJpzLgwFKsYg/WYjeaKUvEic/0W+xTJvtQjo9wgSIUlAO98QpL/xo7 8AnO4BK+xB0i6klDaC1doxYT3A1Gg56sc/UiJGMa0rCWd0NoEE0Q2TJbHpFt7r8aX+kBrDsdZViG lfgttqAWbbiOmySFt0gXGfIIghGHbOQymlXsUw0acYu8KJrGUQKto8OiTEl3A+dWIYARTPGgvxXV jOkBHEMDLuMK63zAmEoKogjKoDm0mt6kzfQ2HaDDdJQ6hEl8KaX8lfpcdRit2lvv1DVsNxjPw4Kh nJkYTOV8NuMexzeM7PQSXRURwi5J+boNY7R+WZfr87oNNgxm2TgkccypmM1eL8cbOI3P+WwzLuJv +DejJMmbejMWFrLRKzSTlrIXR+g+uUVfzl+MKBbHRYuMkM1qtjrqPmkEGMeN+4bWtdqlz+kmT37H sJ1EzsCrKMFiT8Y+ZDvncRvf4BHbMNNA9jWFpnC8O1j/LXrC5eQl1ojDQss4uUU2qiC1w5hmOI0d xgkdrVO5tiRMCEI0v+O4mjKQxborGM19OMSZOcHV04pvqR8NoCiaTLMokxxURIuohEppJa1iVGvo JJ2mVrpJ3wolzCKAcYoQeaJCVImTokG0itsScqbMlKVypaySJ+Vl+Xflr+wqSqUqh1quVphgkua+ Xk1PAp843bnune5zxnAjyfiFUWnUG63G19pHf6bvwIwo9jEL89nH1Rz/OmzGHq6PQ+zjX3AXHZzz 7xgLSd2pP3s80JO3RPY7lT2fTVlUyG8RLWT811ItHadP6SzVUyNdoKvUTvcFsffD+R3PXZAhCjmG naJWuMR1fh+J72W4tMtRcrSMlw6OZr3cwPG8I9vlHSVUgBqpZqpy9YVJmvJN203VpgbTH033zP7m nz+bET9OEH5kk6hX8bIYe5EmpLwnropYWi0e0+9FCNWztRCZJtNEohgPQae5yp3o063abDVbRR/4 d3N06RDvikg5W4VLXyzhfoPIFuuEAwfpUzwWKVxpZbJZ7BXzZLXapuKpDeVsE8KP/oUJmEDxnLtr KOUMRcpj6mKXRpOXfGJyCj+9Xt01CXmV52AcCfknyqZOShN9Ga3xYjNsvPanTv5O5g68zpX/Cc1G jPpKbhI/EzeZV4wqqucYT6NYnKb3OS8x3I+vUxrtkiOxhkoZjbFYKN5GqCgRoVzPGfgnVVAAd+5j zk2YKISSfiIPLSKLs36ZeovhtIbr1IlK2gg7ueksmsRWjKECeeZJkHuIoCedVCdTUEePVaNqFIo1 1TOaUTw9ErhC9vGMyODOtMpwrpoYmISd6/9VnoBT0Us8olWiGAtoh/yGDogJmI4CuVhMou3GIzVB jmbETvE0STSP9YIp1hSiojnjdxHP1TgfMBepW6aKLlpekw91lrYa80w9jHasYHRSeLpVci+l4Ab1 pbk0Q2kxRWk9C7XimGrXgeRLVlzR3GHGhxRLYdpCpdqHZnCFzzXXuN9VlepNtVSt4rvpMU/NddiG nfgD3yb7+d4azDhOZTTn8OxZwHdEFEbhBY4uHhN5Kk3mvTTM4nnq4ClZiNdQypP3PRxGHd9QUxiP uXyuEAuZv5hvqJVYw/2/Hpt4BmzHQVwRh8QeaRUbxHlRJhbgBm7IL2QCzUKLekuVYybCMIOeY8sv cpYG8rlN+hpbG4pgnv7R3KVc97pDt+oP3JdY30H2fZt5IjrMiUBCQsJL8XGx48eNjXnxhejRo0ZG jRgeaY8YNnTI4PBBYbZQq2XggJDng/sH9QvsG9Dnud69/Hv28PP18e7u1c1sUlIQ7Mm2SQ6LK9zh UuG2lJTIrrUthxk5/8NwuCzMmvRTGZfF4RGz/FQygSUL/08y4alkwg+S5G+JRWyk3ZJss7iak2yW jyl7RibTv0myZVlcnR461UNv8dB+TFutfMCS3K8oyeIihyXZNamsaGOyI4nV1fl4J9oSC7wj7ajz 9mHShylXoK2kjgLjyUOIwORxdQJefuyUq78tKdkVZEvq8sAlByXn5LvSZmQmJwVbrVmRdhcl5tly XbBNdPWM8Igg0WPGZU50dfOYsSzoigaVljr72Y2bPvZHriPCN9+WnzMn0yVzsrps9Ipgu0muwBW3 +/24ZOX/Zb18gKMurjj+3m/DfzAhIAOJ8S5zSQQSxIZRmXCaO0mCEC1/lTuschAyBjOOjK3in6FJ a2nrhRawWrDJANXWdqSjxyXWJGBNRxwcNGo7Uqe1U7WK7dT6ZwZpnVa9fnbvd0dia8fO9Pa++3bf 7u/t27dvd98WL459a2RrqUk2ztwctNVk8lvB1IGVsZGt5TaPx5HBt15lUyLZxNA7MGLz6iCjedvj sZRuZ8ignYmdVXZ+raFGy0ncEExNCF0WakvekGBpSpIpWXV7ebqkJDKQeU1KGoPJNbFQeaq+NBTf 0HDOoemSXHV776xIcNbolnk1h4qmZg176KxCvzB5yshCa77NlVx3W2pelbesWo1CS3GIVLAliCax EHNaaLPWhZJsWUg3fnHlq9QmVmRzasLiRLKozvLt96kxlUWhYPK04AGhd/46mrPB54ytLDottmj9 JO9qtOfKqerq1Ny51kXGLWZN0fFSV79wXs2t/d7m0JaiIATzyQpsuyFeNx/zl5fbBe7qj8hGKqnO lbFsPSgbS9MSmV8dT3kJ2zKUazn7KtvSmWvJf54I4cl9Yt8GZ6fGV+X/hUUzpjW21aV0xn9pbs22 N68ONa9cFws2JhO+bZvXjKpl2xfm2/xSatrimCn1/JJXalwrTvmlfGdbiU1OFVTyH+ucelP/uPF4 peNosClVlLg8m8cnlpd/zo/6M+/brxw585mvZqquenR90aj6KPUmJw0KF1R5zWvWJZMTR7U1cQIl k02hYFMykdzQn+ncGAoWhZIDxB1VyS2NidyK9mcGu0pTTTviTKJN6+ZZY9t7gtt6OPNS5tcF/3Tm HxVuFAzbe8r2sLm+rROJHt8En+jr3rU6T/4ou7SaO26YmPUkLQflKeKqo1rMa+RPOk2HdSE3Ravc y2n/MjH8Ws72fbwS9vNyaOeLg0RmnTJTzpc27ro2WgaI71dLkVRyA7XICe8SeUPDSBbik13cVAe5 azqRtY1b6AnpkyfR5mwih920ddL6AnfFNbKIu6yV99Y7eh8R0r30mepeTDE30moknUkH+S6bBv1k peXSNX76iJv1TSKOnXqT09qZhRi2nnGK0fVGJG2Ue8E6SUk1kfdP5HVi6yri/CKi77f0beZ5Nzfo YcZvQZdWp1MbKJbdvPB6ufE/1krkdKN5C5YfJ+3eGt5e04hJhrHza8iybyyLGNbLJkGGINOmQSKB 2aDOEz2kg7pIX8J6VzPmAJY5Ie944czH8jWk38d481i9s/RWYv8Wf8XtumxDpu3dwTwtvpo56R1l zF0O+6h/zOidDp1IzuF87GbRhtVifGdh5exkRSxWY0ULtHDoYIb2xfaYlvI+fFHuzJzkvVPKfD3e tT5sTtzVKvfzti2zDsrbp8zmWeR+RMFlrrf7fVb5s3/e9bkCqdDHI6x3FdGeQZOo9DNLj/nt10L0 niDTMqc81fPlMG2ebtbN8gi+YW2Us1zOSllLbcujHd9tJ9Y6iQePxEH8OY5H35O3ZycQ7Cm+TbP2 vCNvyxwq8Xe7pi+78YvxuBWyhV1p+TnQjn+F5dtoP5l+k6TUG49/HNbxEsl8hJdFM3+TuZmXiLvt Tm1lxBNul8axht2j32NtN+E3R9GhhRHKiN5OwtnIqnXx3lirBdJElEfc6hXiKVHiuGXaiO7H0Xst a9got+hsSrvBLc6TO0gDzo8PSoh5TiWerEGm1cCeFsskRvx6s8wmbaXHTDTKatGBFjVOjziRYwHJ rt1avHsG+u7CdnfiV+ug06nVkW6TBUSb7Yze7k6Sh9B/K/O8UpqknNSM9IeIZCvkLr76Ll/b8+QJ ToQ+WZB5lxW7jS/aGXkvO/wL0uZV6jJeiku9Cn2ctFf3Umr2KryL8Oq9Xth08cZ5Dt/exxvlQTmg W3n73CNt+mXWqk+GODW2s//O4d0whNX/IX+QB+Rp4uzneOHdIdtpfVL+zvr+mf73Of/k/YK9LF50 KSe5lZP2jNztTqaVmJenW1mRPjg/8xbrDoKECj2mx3jzsal4x+4Bv9cHwXF9RX+rmzjZPtAOXaMX 8xIap+fJ9+n9lrdMf6WndIqep1NZ2TP777hHaO0ZfUB/xEvsRl0Fr0c3agLfq3RdJslY17MIPexv F5a3e8v+JpLs72FOyvdlD3ifXvvYCyQ0sed0lr9H79ITaP5TPU7/MtahOk9z5f/DD9173A0nMp1d PlGexUJ78PwhPaIfOj3dYUHZn58+o9/IzzXH8+f6b3SfrrRwNrAYm7VNnn76N9m3j0+1hPUdQXO2 xXt/42gf+922j+eFZmla047/CV5t66fQ1f6Yj5vLw3Krq1/PHv26/FB6OEmAN4vVxi9kg1yBRV7B N6bgAQ9iiWslKGNYh+OkE6zGXbTaUXqkR/+ip/U0+7tdH9MP9A2t8lqwWop9E5UqfQ3OG/qu/hKJ x7DCPsZ6mbjheRnWG/QraDgsR9AxjC/fjQdOlXfx9iOkY7xgb9Fv6rWkX5CO6A/01TPWzlvBeoq1 c5nzB9ElpJickt/ph6zX8yLujuLcRIf72bVH9Vkd4hx8Gs8d0Gp2xky9ThvMNnnGfb9fn9Af61Nu j1e7NNulTD4dxQIj62fSZfQG+fvz82Lk3fGfcJJTyd4Zdib/Cz59c4xEi4s7srA62DE+4xudr9Pl NJCBzJAZSl+1INIPqXOk96yK2k5LJ01xND1hQX10vhmSLeBR8AIokPXkHT7HSIC8HljuTtd+wByW FBgCLwLLGYQzCGcQziCcetMvah43P09XBBi6r3dWRe170RLTKxngmd0cweXIvs6n6326EzoXusun 3zFd6UWBwugE6irvkWeAx9x60kuW1w64wsVhV+jOcbp74QSis0wPWvWgVQ9a9aDVe+SK1G743fC7 4Xc7freoE1U+xxflF3rShTN8DoXoRBM3V0stImI+XWuuTtcGnowmzFWIftTlB8wa8p0uX+/y5S7v cK0drnyTK9/kyvWuXO+XbT5/RB5weaHNzSqzmjs1YFaaZY6uMI3ssYBZTt3SL5qljl5pljh6BfyZ 0Gb6FUOXmSZXX0q9AXo5dUuXmKZ0Q+CC6Bbq62kjzjKW34AODejUgJEsZyc4AF51nPXkHeAFYFxP NQ2kxaSoifJFBBkRWiJiTIRUT7rUXErLJfS9hDxiwm6OYXqFGSmMrcJIDrM8YZYnLONMmDxoLpQL QASsAAkwBjk1fFeDXjWMUGPmESMETLm3g9giYII+DXhdci70XK8rfW4gEp3g9ckKkABbQKfXlx5T XBidTj/bdz5YDtaDDrAfPArGS322JTLJq/fqzXJvuSnAu+f0hsO1ji64KEvPKcvSySW1hdGbzRzM NEf2A4PKc1B5DlP9F+NFGxvFcZ2ZvbvdvQ/f7t75vvxxt3e2z3AYg+2zDRh7bZ8x9tXgACm+7hls kEWqivTjDEJUAtIKqQgcyI+iRqqEm4KgaS2fTWKd+XT7pwGprRpFJFIjBVUO/RCopbEQSu1z38yd YztBVfbt+9j33sy8ffN2ZnbpyQ9IoHTC6C7gnwA/AaQJD0MywpCMMLxgGNqHmZeJ+f0LcBGQgyIK Q/+rfYystR+wekUvVFsJmkp4qoQ2leBbCdpPgGLWgtp7Ac8D3s3bgqyYg6w4g9BXEKKtBtrCJDtQ PxecJKI9A/nFm+2tDZD3nYBgJCOQzRHI2witEEI/4mqwtOQ9zgOOAxq5aYA1AGGASoAggAoQAIAZ 5Eph9i4AnAd4HWAE4BzAWZgN53jkboTsj343ejJ6PnopOh69G+VvkkGAATKgmZHLBduFIgu+VokY UBLZ8OeMjjH6A0Y1Rt2aL2mbTdreS9reTNp+mrT1JW07krZtSVt10pbBBzR3xPaXiO1CxPbNiK0+ YotGbLUR25qIrVXGCbwX2dAdRtsYrWE0yGgJ3jtpQ+ItrCNVgIrH4XfU1/yfqhkDnvT/WM0IwH6U e9JzbAtVTvk3qIf863KaihwrU28boAf0Mv4N4nFEW8ff4/fzGr+JX89X8ZV8mA/xft4pKIIkFAhW wSwIgkkwCERAgjOz+FCD7Rcjp0mizGSg1MBkiVBK6N4KhygsEDjmpx1cnMR3t+F4euYgih8IpJ/t DmWw+aVvpY2hNpxW4ii+p82TbojEM/zirnRjJJ4We/W+CYxfT8BTmvwkg9GevgxepKrTRWmlvW8a Ybzu9EhRnicStE3fhAGPjCSQ62iLp0Vpljdti72ADORpZPnyRFY+QCQl6Yvx3X3pt0sS6RoqLJYk 4pC53YFk3zRpJPUdsWnSQFmib9p8ijR27KJ686lYYtkPBUAfm0YqZcwPBagfCnzJr5Q0UL9yynJ+ pcyvdJXfxFa1Izahqks+W5nP1tU+h1b7HGI+h/I+XM5HXeHDP0Qq81H5h1/xKf0aPuUv9FmRzaG2 yP+58DT8Rz6YaD/eMRTqGAh1DAEOpM8efcWTPnUgEJhG7fgBNQXSXMXAgYOvUD44lMEPQkOxdHso FpjoPv5Ve/o4NXeHYhPoeMeevonj2lBsslvr7ggNxhLXOwfXjq0a7szScBNrB1/Q2SDtbC0dq3Ps BeYxau6kY43RscboWJ1aJxuLVT2UpYDaEu3JHL9OLGYo4IEiNdHmkr7XzKp5i+o5UXTDgPA1ZIkk 0tZQW9oGSE1VrVWt1ARfGTUVgNqeN3lObFGLbuBreZMEajnUhjwd347BnUrlha95p1Kp4X2pfSnK 2Z0aPgJIpwmlUGoYwRu0Wtn+5ofVmK7NZwHPsTWaS6USw4jNaeoIor0NU7Lc+RfSEegZp1YWAUp9 +aKVAf98DKG71BEMXtTxSL5sUvSwDt0gGmSuE7reADECwE7Bo20TJj6Dre+A1migAofMJiMIUxxH fCJPdVMYeYWdP/REdkhzTT0LTTukZ0090gIcI5oWmihu3KDKqlwOBFY4NB/gZuY1I/ovChhm6E/i zcUTBtnYhjpRHLdptb2O3uJLzktF485x33gR34m2V5R3tWoN66rq9S7NEe2a2rhlI8HxUFm3ICol xQ69O7M4MxmMMlaWYyWMaTF3tHvKbXMbR3FsVFszWhUYLcN6HOnbNb2hRW9sbqjbXhevU8y6LOpy s6KtvVinaMGoork2g2CP7lewkiG9WlXPej1apdeX611lene0ub6uq663G3fXOYp05wXPqIcU673O C85RJ+dsdtChLdCV5LjgGHVwjlvkKfoGegp/tJ6INNcfedz/pF96AtLc3GPgOQA9XI+ZODc3v6Se zQGqrpYWqMNCE70kRplupWLjBvj342prXIVOUyjEmUyhcEU06liSGhyhYEW0rr62dlmor691uwp5 boWUa66GuFouoPyi1OcrvaoStyx71TsB4pEULw6MU+27ys/9Pp//LTWvvM28fFi9Tq3Zz2477pDZ 7HO3w+HOriv1GOw+O/7jskT1WGD0gxKvQfJI2ZplibV6Dlsg6c/Oc+OGv6Ei1KuF11jXSsToLnCY FZfJZJTcLkdhs8PYI4qO0YIyhCQoKG/x/RvYiDzYe5rWZH/PwlwTzSQUZEuTrGzahClhuapTlIZ6 9sK8iRQ6FTd79WC4glSQ/qa3w9YCxcu/um/fq7xXKbCWX9Pwf1KY4F0hi0c2W+9nM5evZDP3rGbZ awni7izso1XZeXIyH+0akYg+L/H6DDRiUTG5XZLRBNGazRA0xGuH4wNBvpLLN3DPUrzPaLyzEDAL d1W0TkJ4E5u5hnolWkfCbA5r3C7FRU6+MNqnqexidixo9UK09/D2y1fw9vsQrccSzE5BtPAX227Y auiBMHRto1f3+xGcTa5KuuGqYNdFUSj+GOmCW5dljy5JAtZ5Xvh4gxVbvQGh9zVPBFVjlmCWX0DK FmaRxNK9MAscJAhddrKwZTVXdapcx5Iuq7lSI294HIone46WDR6mMh6mMvFnk0x3mVXJW6ys9lEZ 6gJHsh+QP+P1SES1mud36H30EP0b1pcpA/6M/Ba9b4fDF+Fv4Z8hMzqMS+in96wfgkLVT1gyVZxP JZ7BcvbDogpviMPrFz6qCXnNVnr0ukF4g4OchHXQp1nRDMyTkXgNB39NF7pZ6RGq7qEdFapRg2P+ Kjl57BjE9IfFv3IYPYWDZrFmxpOCxfCRxVtweBqXIrY+9sCsQqvypU+U5YO8XNbY+1IDJU93Nm7e QRHGf7S4l/un8TCU9GFtsyi6sFfkGtEmcRvuEnXxO+JRfEw8I5wRL+I3xSv4V+IUmsK/x/fEB/gR /of4DD8X3RYRWzL4vXc5SzPSxQyehKB04XY1h7kP5Qy+OXGLLUgLT+ae5PPy/f5+/EVi6nOfBvdw ISkXyV4z+aXFWSB7jWWf95V77dZC4zV3gddugRL+FN777/9ju2pgmzjP8Ped7+zz//3Z54t/zz6f f/MDicGhueaqrB2DwSqNgkaaMjpFWafwk9EN0bHRjJGhbkwMNDpRlR+tpFo7Ng0IMY6gSGVSqwJi LW0naOnKIoZWgjYElNI63vvZMWzTPtnvvd/nO8t63ud93scMgxRgxMHDAuVIlKs3kKV681Azm3nI Dnm6ehOlqp8iP7x91U+Phjx2D+uhytU7iKveOBT2NJMnstUbZiLDhDxRT1xYxUZCAmrBKcYdT3hU Q8gbjMAw7iYDlajTR2dphkdp21/GVmid/JY6vNxtQLibKCc0DTQO31nvnp4N5nKqhdMDiqz4FZ8i KYw1FAwHI8FokLam9LSe0bM6bXW6HC67i3XZXIzVosd5zUQxscnEOWvSRM10q4kTXtXEQQWC7sqb qIWCUBuntQmahZUbRsWZhYv/uWD2mz4+IirdUoSXu3kS/JGI0B0vVT83TUhSUoiHEOQgKF4Isqc7 QUJK8rshg2CR4D5LRHB2Nzsg+EkWlhSVfMk1U4bEK8lR8lS0m3Jw/IMyCfj/+Ebys7+BfVxNU1K6 TmYFV5ND2Q8vWwecpPREnPL5JNjL/vbZQsFydbh/94LNLeGHvTJkC3/cEvkS51/Sk1XSnV/etq8n F0h3zv/5Puriuel/7dn4QEHdYSxddw5zJI/v6Fq6af0ZI6Ekpv968tj6s0Zc0bB6knTbJBiOq/Qd 0M0/HhLYYKl6x/TyVsTag2bwUeHRIG33lqnfIhd+wbRzLpeXO2FnKXLCwImAGYbCJ1glQARctAlB qUy9j3hqYBwxdtalUNIENYx4JFNn4Y/oAM/jAcRh7ji1FoXQfny2ziAQCJCwCgzgmvhOTYH0yp2I qxhCZ2sAc7dunvqvzaw21FerckPI7ukb05DpudR2HCO6VRmsKVls+rpk9yoOVqHvfP64DFIXEESZ bltqVXivm7UDEq8CEu9DL+XQ3WPQLpfMfFDrmO99xjOSGkmPZEbTo5kJ15Gs3S04/AVXMUtnEtlI TkpF0gmX5CQkcP9DmPLfFSp+Os02QPpgfAYj5jieBM10YjfoVe8Ru93hairhz45IRpxBE7gXQT/D OfsxbyQfclNrUDOS4TQC9zupVSiPf9loOO72TdJvEIiqTXUDdJPcFJ5BCNURgsYLRTUh4E/GdJ8a MJGY4E0sRyUTCxqEmcYZHq5DCQsN4aHcXLVQnxGgr9rcB6lCBxDRarPOzL8ZZbJabchWobaQkfHF eYxuDC2J/v4Hq19RrHYXx8tPHVv54mW99/vTfykvUQn839t45fqab38tPTj6o76AzSFzbS89ceG5 eSvXPT39wX7Cwterl2nACUFJDw8WMSqBHrXPnl3g52lf0RYke4rfRdZN6kjxV/TOwq7igcJo8ZhY lt8S35LOyBfFD+Vr4l252sqT58akONSNL0EBQ5BkWK8zl+YtrfBDAohJhJASiaX1vFLCvYdjMSFf wtsO60a7B65jgmFNGHNK2G06fIYlFOq0NM1rLUMFQtTwuFPpbGes7mtl/Gy9DiB4ZAwvmpxczF0B 6BdxUBNEilGZhO0UKCARwhqZ4cXX5TDUUdCSokQzyY6EiUXGZ2KtoJtYogUToVpZhmHBpdg3VETF IeyvmyP9nu1onz0H6qLPeEm5tqtVqcH+epEs4tPP3CoNXm3xyhwnvXBwx59WHu2LNCnK/KGduzcu 25HneCcfWLZh997TT1Kvdow9+fzfH2/jBC7gXTe+duH2r5Muwc/1PrG9q0Oyy1zaeOy1nyzZBVPn PdIp4LXCSEV/Nt0wqWNURGXC0ZAfYL1yNBw+4ff6hBL+pil4PCd8MVUdoCzgoiyUGo0B8OMWC82o EXcE8kPIA2MFJlE4RLrAj7xw5vdZStRm04sZz0A4HEXeCIZOiJSp1UjFvaYTWggrcZr2uWAOvQ3l 0O6VY2hR5XbfELHmlS6OeKIpklyvuSTi12HHdzI/bcn9kDsFzQJ9c+t8V+PqndU2hNUCbucbTqGR zEhMO88nsMVSeQe/84dHiAt/pBan3yDxxfz0MrxipSX1xWmC3fSths7gFdRHFRV4forwHJDLo0tm 3Bm0h+L2jDIvwDRnvppZkVmd+XXmTeVi4JMAqxAS+wmJRUiCsQQrcTHNH23C0bCKjgNQSSIjgMak aQ8bNO1AelIs4b+ZdtlwNBmcDdvK1BaUoQbH4M6BpFbCH45zSnOSdjQofB8zMJKA0VSlr05fYtZb p0CPCYVrNlhosDcQCDH2EAOTOWCHELSGTayw8n3mQgvncn1DmG9IBXH1/8PcRNw240vrd+BNC7Ya e97955H1qxebeoDjxecP7Tw5+uzmzTE3WOwFRELoHdP90eilsTfuFJJzVb+gCNvefPkXBx/mAn6q megQqKcA6DaBiiRQG37FdLXEJa0jHslF1Ihert5GqHrZ9BToB9geeiH7GL2ctSYB4MOAb2zmGq9d Ex1aqXredBD1gKc11l2CJzfRNM1KtMTqtM5mxXniQrFX/I64QdwqbtEmxDHtgvOC8IlbdGKGtcWs uuLVYkm1P/YtdYO6Ib2udW3b4fhE9j3XZccVl7CcBTvD8UJMlKK+iD8sK1zAHUea25V06g7c1kq1 5GGIZGy5LCNbPW5tFvTIgbFmw2KxB0v4kumPGhKTMuzuwMdWA2W5bCzblqWzx6kzaDbSsIZc1Oh4 3GjzYI8yawIX8fA9s9a3iIyOSh9Y8u4pmB+k1pOkykSnyLsuU8l8TKVFzst7Ba/F6nI73ZQ1T2dN HBPjJfw704d0B7i0pJZm4TDHNJtY9UbJJ06cdKdMlLGlarQgxOC6ah6N6NpQbd7UfFB98uTwfarU mAJjh3BlhjuJOPJJYIzuUwcPLj7QP3LuxMurjs/p6W7b9+7GJcWAn3cLGeP16dcU/Tdr1u7d179y eRclrlv90Uu7Phv52cG392x9am9/3Ptvyss+OIr6jOO/3+7dZe91d+9l7/0td7eX2729y11eDgLh lqrIi5BQEURIgqloCbQmggjaFhwGIgka24AdEQwoCBbwJS9MTLHQjmDHDiOttaXOOMCMFKRo6ZTp 0LFJ+vw2CSD9q7nZ3/32ud0/8nue5/t8vl672+QcefdS9PdHd729bdPh+wvQlZ+MjtB/gq50oY3v Gmkytw0gXRJlMNDUr4wWq/UxF3K6XMgFmGBxm10WRHOYesxs4lnOpOMs5iHoREwd7HcbvcLV28D4 i7ka0hQ14QHdcWvdRJqp3ZaRbUSB7hjbuCo6dhBVsMETgk4/O/wG0RKaHnmLEWx2j0G3StTaomfL N7/18R7OZAcVvgRu4JLmBhIoh9vVu+0HSj9CX6OvLTqfLuiSlUXyckpvtuk8fpvT0+HZjncyO83d yR55l/Imfj05QB03DVmG5NOmj2THerw/SuWcCoBNbyAWGhz9vLc8lhka/RxsxI1+nikri5OYVFY6 NHoVJUav9CZLo4SC7HKZysRqUylDsNahz9YarLFB/BeVS6UETqylL/hqi0KdQAmD+CvVXBGp5S6k a43e/B2GAkr0egOsRIr+qhUqqVOtNMuVnD/Mu3RMyB5RUcAJOpQpATdQrocxGuZBkfwuWBQmq6Ic WIdbNoEM1v/1CKgBN7ShNnAJ7yF59HIfcD78I5f7AP/Jt1oO9K/3wJ3eAztMdtijxZyWossDj7tI zEViLhL7FvQvvjm/QQMLE1IIoRJDQRvbAPlQ247b9rRjxcrze/acX9myVKr59KWf/7EmZd375Jq9 PWuf6nEf3rjx8JENG45QnRUHlu347LMdTQcqqybPb+74+OOO5vqaL1e9squlubt7pOTxfft++MTB g6CLDtBFN9RFAlXgelUpYXRSiYwyv4gPxQ0iEclYGhabBxarLZSvtJTCkhcq0sm0i5AYuyR30f7v 2D+l6xn9cYRzRCXJW4Mk6QLk/wrKwzkp8JbBOZD7IPdJTtfIWONItFmS5jKjBL4OdlYRAlYdG0/V mvREz1RTFgTNFK0VrOIQaJaVekM1xWtZX5XvQklt+n3qIKq8JV3c9WEArX9BaVxEY9XwRXHMKfCa 5xwXrmQyUxrTuaw2i40y8IAzDs7J6Qz6hGSEGikzQ40kxVJXnCiVA2d0xEYyKQjaYIlxUYgPIMWQ valdt4kXapCJYLXhmxoGe61Jx7Pq1vKq0fJtMw9VVSbFW+ktVNPHp/c1Lnp92fE9TxyrvGuy2L30 J889NNnn4S3uZMWnOO+s2r1i5WuvPTpldUWUOrV6zSO/btk5/EL7kYu9a+tfyhZLOQ/vNjtwxSXp 7O+6+5/f2qeqMuT5NPQ/ppuRFdxcTjWyvYKZ6UUG+y+xAJqgw8KA2ez1Bn7wHg4hD2mzqYCsmoko QmfhCeTRKtXxrTvqgfik+vmFby90c31hyjxyDXfVTaqZRy6gQx4h3XHdz5CEMvioKlfzIHj+aemC cq99lu++9AwFbKXQ5GtK1ys3JFZGkpTOYIpSTNwgtU8VrF3WHit1zoqtKd5q5figibfHUuQnmyhW SKKYkoIxKW2ktZDBUKHJdNBIKV6HFhKEhXZBcNiDXjtfGiChmWEU3hh+MUyfCeNwyh8OB/zBUr/P l5akkN/n9Pt9dp4PUQoQqhKPxUxGBuGQzGbCGSqTMXqVtOhziD4v5RvCD4IRm6Y6JdGvssYi4jHr D/vP+6/5dTCW00fLKZFXRPsQnob40RN9vKkIRuSEysGzLI8RX8f/nR/ldTw825e9Z5VncMzPAS/J MvFzY9thMjQ0biXq1wCTo0gGSLteg9b2jEdu/zGwKzM+OjD3j4a27PUPbg/8X7fa2yUwpMgFhdCA o/Qd2IvHzUYU3/EDTcdo+pnhs217yTgaOUXW6Xj1DfKND+Cd07XwhwSP93RfDl/A7SOnJ7CYvuJ2 ONzf/OYmJrdT3xveDeYCLYIaWgw1FEBJlMePqu+/LR2ST5lOmv9s0ndJHfLuyCuJHvmthOGZ+IbE avlJpcvU5eyMdyWYB7jl3AZTK9fKt9pbHSWzI3Ojs+Jz5C02fZ6dEqmJ1iSK0hT5HvZejjFmvZFA 1J/wS/5sjJVkZj13LP5hlp4RmZVYG9kS6SjfEdkfGYgwaQaMjYxQUKAYvYxxkCmP2OhYmS0fSQZT opAUmVAwlMvnBYYSmFiCtYQtWUvRUmdpsjxuKbEM4k1qSkkgnuMpln+RP8Gf4c/z13gD76tMloG1 QRyirgGIeCtmrx+rCcJpbVPnDk+dR0qCWBrCEZAvDdS5MW+pid+dFkYTwVA8bXeazA5RTkhORcEJ U0zBaXtKQXGzqGB0ax6itgbc1tbWAH8JfiLJ2njSxtbNRDui+UK1RmBRwPbqMQMaxaiN5Jfidp/c v+np+v0PD28j9ydxqqmu9u7tT4304Tfnr5u2+NXOkT8sGEv3wNM7m7K7Ghd0NpOUU9WxQEuhbvN/ hJktk9V10+AQNoye092nO4ImoXPqOsWJs6iI6hCtF1zCQvdy5yPCikyrc7XQ6ul3mwqB6vLZwuzq Je4lVS3u71dtDrycNVXk2Ii/FCOasQnuQj4SC7HgUe3mWL9sTxTMnbpQQi7QOko22kRmWVQUfTV+ kc2Fc9lcMafLeSe335aEuV+RmTM8TI6/SE5+7PS1oUPmjpYDMn9g+qA575jvn/NOfP5DQBIB4Cbe iQgcBUevDgiCO+ARxoljMQEO6PRxFJhA36SGt+QDIaRNinFSIPMkQ1dVVdohQp8l5+h28G5Kv3DN 9ocXquJ3kgHM9a86VM+77IL83dMrljTObNya33yp/YwuPIWk5Muwz+NfMH2xHFbmNc14sPvYyN8a m1wC784ubYj5Zx766aJDP8J0J+j3q9B7a6H3giB1FjX6gmmr+Tn7VsdW5zZXV7gr0hF9PtmR6pIs 5jKcjKQCgEjnVePLyYEodRfjDhK9NftSyOcLoqCboch9lT6F9XoK+obPsOGQIARDbkYOGY1UiKHi Istilo2wFOvLpEMhHPkv59Uf28ZZhr/v88Wxc07ufGc7Pt99d/51d3HvbGeJnaarNx81NFpHm6wS rAXcFE2qRBcpy9g/myjrQFAxKrpJIH6UruMPEAJB/9jUpipoY+q0AWItWjeYNikFrRlMCi1VVVHR uLzf2UmW9IcmJOvLve9dLvH7vO/zPC+gTZBSPIU34NDK1rIyDEywYAj8g/lptMxkYKFXBf4sVNLr euJ9Qq8QEXiBC1qmbQ6YBZMLylJMIsGMua4nX8LpeK6ETcEp4axklDrrLKj+Oqb6zC3OrJqPfib1 gFv3ChP6U8GU3vYng475FHh677HSeIE++o2HvtaqscxhfNfek00lvyl/8IHWmc5Q7Bid3Lv1S489 dflzm9hUPP27XT/Yds/OCfc+mIcdgEcZ8KhiyUtNGtPBJ4OBKN/nSBLls5pRzeWoFggHQWdeEPQ6 ++m5glIPfpaAKsZS/Y4s01SlxBqc3OVUq7RkF9nGSNY5lkWLsLJNebUUwRafy1upKrJMHSE+RfhQ 1hI0fFG7oRHtEwELhfFE+Pnw2fD58KVwV7hqWSVUFIukOAuKmDDNPIhmeLtcli5Kl6SApIxsmU52 kFtYrIGAXWFKJjZnFoDaOmwGcQ1kjn2AvRZgCWqeqy1fdBjNDx1n6cZyHgauiaOZzhBFl3BYRim6 tEitPNPJ4M+Qb7KyX/8iQ2TG57DAl1lm8We4mGzLUZJUW4avY60XV9SqNccyf2rdP+nf+Rc7JwGl o4DSY4BSBf3b27W7CwvhiCOKNJxR9Wo2S9XhojBoDJJBp1KhRZCRESYjkhJ3olGqWC4qiAVScEyT utmcpVSQmbcQUgCVsELCoYpZNC3kiu6EG3BZvd18PoewJWYtpKZVMqE+r571fUiXuj2aFjES94vP iJdETlSqV0+yOVqWFCi+2MEDJqjG1tPF2goWa6uPPopC8xYgYAbCalPQhmD9nTH4MU77JVSXMBB4 PXCEFX5x32oQVvmF3p5bQwAYPAwYTAMGDfyKF5F+kvh1+YXES2WubSz5XqfjJ1Np3yeKFFMnQ2k6 Q1PukJ9CZVwuDJfLQ8PUrW1iKVGoG3VSdxr1+qYGrbVdJx90OqazbTn5RKHjOB3Tf48wgAec/MCA mafOxipLNRDsm05ldLRaoRtzWR1hDDuv5bpO2kqZluO0HWZt48YesJ/Der6i5xueZlSONo41yKHG XIM0ZskpT/2UpGcyUX2QeOQZEhgnZwkRyCSZJgHyG3IKfRJtwW8D2AAu4MysAoDu1HyXz/CtMV/p Owh2RjuGYpkym6sItLmGTm8X3Om31r7D75fGF0Agy0BUYSFWT3hwlIG2TvTJEMDBrMlOnIkO36qr 4KKzmUQzN2XWmtOvL77pD3frPb9JKsyGXvP7jRQf0VOKcY1lKpNLzyjGI2Skpa82qP7Yfxq/uHR9 PbF0H3ruAtjVf0LPGegvXrHMlbpykXRvOpaOl7Wyfm/XcGQwNhiva3V9W1cj4sW8+P3aOB3X42HB 75zIiBiJCMATiuHH2gjSNANRpa2cPPBEWzmTEovt+Eg0HpeiNGlYimQpSUKskGCFwyG2skTHRSwq 6YNzyWXFZKgD2Az1hY8D5a3QWjPdmSWm7aTJs+1BXpzyBS/dOu9bwu+yk7t3pVgrxWSz+ktweceg bha67H3lq4En5Sdi3yIHA4fkp2P/SYTChI/x8cCPyJHuX3R/IF6IXUgEOXGPeFw8HuOGQlY6VwU7 nlYM7d1kkhrdgsTzXNogksmFk/06xsjrjdaRFxHr5xHeD38vNSDs6dNDoW52o5vd2N+NuxX7yEn8 VoccQfBrW8XF97d1FjIWQAGheFAPsHi3MtpZMUGC8UQMzmiXAFZECHbLgf4iFoNgTBJEKratBBs9 Z13HbkNJ244v2qbEQCIx7LvrNZUNHHv/uckTU4wG8dbvb9l+3/rPt06whiV72sVdTP3w/IMP4RG/ fS+PjQ3o33mAzC+XGaP9wIg7oMoZNOWNgmmoMtPAJAmqp4JpeLfjEarMIxCLV5nsC2EcToG66LKk ZH/6uF+ctvuab4JaQFkWPqoJNykFNA2M5u1Uuf3V8FukxCj++m72v7/+ut86F5ZaBm9jo9jataZt MErC93kZvs8osb27/07ndbIZbRl9GZ1Fb+K/an+mV9FVfJX2mMimtm6NjmkPaj/XT+rn0Dl8jn6I /0F7d+g44o+SfJTZTgNsZ0EWBEmmEcMnbxFlJ7IkW7CyWdOiRtmnb35oeGRoqDpCy3yXH4eGuVCo i6O8Gm+/LImFpJEkyUIsmYzHqFoaaCuKM+EQp2A7zoBNS7M3vu1pFKO0RqmOSQyzUx9FCNbHGKTQ LKEer5uWYei6Ri3M4i2apo6uJ4G4pZJS2R6xymWej3CyFQlZ9ugo1XW6fkS3PXQGG/akPW0fs1+y u2zPLlRsT6oK9iH7rH3evgS5WfI3L04NPInJIXwGE4w5TeMI4cC2P+4l5HSAi3H6uHxGnpMvypys bHil4+G2MquQUsSFZHRDuf1pzkDYdJyZpDifgklpZ5mh8J2Eb+pqdeY0/GDBz0HnHOgqOQf2nT4Q KiWdrn3iaSd5e/GY+f8UaMZnrkdnmmgG5/BNsrAsGxjfTjmiOfLc7tZvxcP+aP2BnWNVdr6B78Ub 3vBVYzM7W3/U1ZRxWMKTZG4t1y265NxqwQh8yLgP1gvuKehiF097iRDBYU3RyGsE8zioqjihcnzU b7K+gtTXF4WJNZ12M4GtKLgDA45LzR7Of6R7ONDdzQXA1MT8GNx+f38MhjmvszibGaaZjE5pXiVY wrqmxqCbsIpkxzJN3crnQWaeOK7GLJh8DS69Hsz39OAQ1XQ8i11PRcj1zKrgjruT7rR7yJ1zg26q RAK6pLLHZWlSnpYPyZdkTpCxrBTvfjg521nZZpjzF9tbGyPT+bYc1TpyVBOXFrgNB0oOWAJPwKHY QB3HohocolpnG9hOaJXkx1SrO9qO5gxqzmRy+PbNsIaichyZWvze4TbI7NzsW4n3yNRhxk5t1h3j +q/fsxr1/34QeHVF6QhCoHSI+xXqRQq+7t34vfCqQqT5xHzymnhNupK4ogRfS7wjviO9nfgf5+UC HEV9x/H//397l93kLre3e/u823vt3d4j5nXJJQGRLNgEK9iA0EqQM2l1ap1pJ2amLeo4o1W0RGxD R5nWQYERmIIdJCRVDyiP0nas0g51OsqMtmpbBsExwXYA8ZFcf/+9BAjWcaZ7d/v7v/Yu+f9/j8/3 hHqGPyNU6bwuSLKsMi8Ln/gviK5nuI3e7WSXexe33fuq51WWfZg87v4J+6B3SBySniSb3Gy7p51t 4eZ55/ItQos8V2VzpM7byKeElNyoXkuqfuM/zI8Ko+KoNCIfVvdr7G7/8/wO4Vlxm7Rd3qM+p7G3 iMvkorqF3yg+IT+tPqWxXWKX1CXfqC7RVvlX8TcLbFad628T26U56tf8N/JdAlvjqWZDnhCb9afF tFTlkTTMsKLfx6AqBcpwIFXtqk0hxKMYakJbkRutCaaqtDH9+vuclAKisDhOqyt1AWWOMgcidtC5 ivSCQlkEn3hBrg4HOoVS+cIYWL5UvjgmqJ0yWLs2GOqUVdnoVOmNK5XfHQPZC1PvU+suld+41K8R aP8otdy0FakFFJDocxV7zq4FLJBiPmG+GIEbLpVPj4lap2/aEmp5qdM7bdVS+T9AE+J8XAs3b4K2 6j53oYrpBa0aJFD1UYBH4IJCVSsxE0QKQkdg0LqzQ8emjuHCsaGJoa9PHNz7Ka7acXCCdO+c+sdW 3ItrsR+v3Dr1z11/xt1Tr/zt/akTuIv61hhkklshk5ioHn1oq4zOhKoiKCqGhGgqVAh1hfbVVeeE dKk8YfM/0NfqJM3m2Cf0jVEyw5910/z5v3mzGfRphTevcWjTRJGU4E92JkkyqQJ0ZlP+MA7rjfUA n7zWcOHeS8FfAYYLUDiQw09F5ER40oa9TwL3w63GT0m/FwRI5ywR8mVA2tGBBjs68OAXyM6ZAK6C l5mK54GrWi0zjkeu1ptAHKd3v7Uov3jp3G9MfYy9xW2Ln3to6nX87tT3Z0f0n4aWPZTq0MUVy++Z f/tmmsH3QUwHIaa/gt6yc9e1LAn1tBRb1siPyj/Wh0KPz3lqYfVXY90LyM+iz0Z3Ldi58HXllHJe qQqBG4+Kalup/LbdW2dnr7tWV/3uIMLttfkm09XQ6vchV6BGs+bNaw2krq9ZzzSsT7em4te7GDi4 OFdrsf3tqb7IQIRE9O5gym62TMteMJB9IDuc3ZLdk3Vnta5n9uMoUqdPoXjTyXFItc5BTE7CUcDl iD/Iy1Csx2nk0Y+ThZ02hCHqgN2lAYgLFYiTKrRqWWbCIwUjRJEV2dn4RLoyVagsVCjH0t1OOy9n 0PVEJRcKCnZvW7t+e8OS/m//asEtvad+99bDdJcrMwc2b36pu6vpF6+tXv3X3SPM/DA9nTciuhpa 8ejwN/M3t0QDYSP92G0bjg010anTUZha/fPN3114Z0TSzRtueGTtIXouwxAP85x4+Kmd83PeAg+u nQhH20zTCBPWXcDg2qImtwEHa6YApZuAF2slPPAizwci8BXQtGN8uDHcHz4eZvzhznBPuC98d3g4 vCf8TpgNn0lRJKIK4ZxDOCfBvan74tksPLtHifjqshOvaIDC5QbZ8Kajoz6i9zendtLtce2m2zdb Rk39nVYjvGZqyLFA6mg5+OP98H834cQBFC5fRNHyxdEoH94PzRDkysSa0EnPqfD70Y/Jec/50MXo pzGuhjAeHKqJPhLa5PEIaoV9JV4iUosmSapmCLmmCnbU4/osqq9vQkYuUO2kCV+W8/mqOSOQNWl/ kdWSoN5hZJusXM60slnVEqotIUAMqASJOAiyATgb4kc9qA+5kJ7XdNBiPVwfN8A9wA1zbk5rvoIc io70ol5bvCzCLiHD/wGETuIYhMzRAc49rb5gx5180X654geC1IHbCleRgGvyg1/e/fx9iyJ6rTdS qfubDj20fOhOhw4rAyDGFu798Fsv30MOwYn5qh3+W7j+6JLNtzsjMwoGKiKzHU4qQw7Yywf0gdBA eMBYJz+qHHEfCZ6WuX6+P9Av9IvMcYJ5mVds2VYYlYSUiBY1Ipms0kba5Galm3TLC5RefKu8Ulmn 7FReIX+U31SCPpEeR4BfymO+EOR5MWj4glI8TUcjyVjy7iRBST65NHkk+ZekO7khk0ymM0Y8g7we Zwnn56Ic8XOHuXe4s1wZzmWDm+M8bsPrZmI6XRI0+gxsFDTD0DUjpqmIyEqsNPWJ3SoxrljQzTAR KRiElJEBVaNqoIY0gokLR1QF2gpxEeyKSDKskImllMgP7YhqIYxB3rgYNm3FdfqOxUTL57F8XoIP 4WsQgoRWRBqEZ9HOH9dwVMOanStodmtbq/ZgIzTMZKtmW+lWzbL9mWimL/NAZjizJXM8czbDZg6Q e6FWKoCzigyPyXYjfOBR2dYLfvmsTOQSXvlrYlsFKIL3jrpj0kH4uSBywU8zuN6WokF8JIiDFu/G yN3jHnYfdzPugzCbRV14BfxxdzzipIRxyAoTGn8S5FDd5CAt++opjZ8c1NVxBwIGiydhVuUn0CV3 Hq/QMGDx+KQjjViQRGDVyw1qwQAIw/ch9pJb/7vYCF5+ZX/wSwcanUhYPGItXzySW7Zq5UvkQaIr uqw7odELMzrMJGFmHyLlD0YJq5TKH+6V+el5CtG4WIybLpfpuoqXRbFFFK8ac51YO3Fm7f1RJ1A6 aL76/cC/fnTme3+oRA4diLo6P/stM38mRj5LuBo/e8319hUxczvEzHcgZvL46X0oUX5vTIl2Jkrl 9+wCUNmLCcyZXF4ztfxd5l15zyrhNrnPWBVn2PgdiScTOxLMR/GLJvHEOVOKayYzAz6FafDRY7Tv M+rihhGLG3o8UdcMI2N8A24okaN2Tb6hoTlv1OXRDCIVphFJE/eT7UimawRZFqGiCIFckq5pSdeZ 6XTSNHJmIoH5RAC5NC5vis1WXdKqy8WsnB4XBNHSNVp+TGtpHudL5PAL4OBWgIeW7Y9bSOgRhgWX oLVcmRlvGj9HYekcZecKN1HXoW+4zZup5Vec+flZHvC5lMnOzplfvNJJoGgQLR7R/st3tQdFcd/x 32/vtXvPPdi7vd077nbvuPfBcRyHGGi4mDjWKNVaH9UBnYq1xkeBpJairTmm7aipJlZ8VKP1Jmrb qPEBgofamjo+UGI0E6yEIQOZos7YXMe2JO0Ugf5+e0DQTntz+/jt7l+/z+P7+SCGuBFDWoDFaClB pEDVqg7F3P+ecXC8W42xAT77gGiaGHmco2fkrUK8eohP34LPweg8zI8HeFlI0CMvjY9AeJHIH6fH iBd+Mrlt7UCTcKEsAXygGC6Pf/OY6ojjWL7Mo3I7SuU/yK7nf2hNMD/ndzK7+eOqJHOEPxluVV3U n2HO8u32Tv1gxKSGHAxA2X7jLp7YmP9G/tv5x/TH869G7kbuR0ifM0WcjPPusOh2O0WnLysnm/UX i6DYD2VRLRUqTsH++BK4xQfUUVGmoUQQokO1IVnIX6rV+pgDtJijwi90QBDEuM5cbhBhWCwX54jL xEPiKfGS2CeSIl/CvlUgKvH7GuUh5SVln1Ku5KYELnxFAxisGH6AB2QdDOKoLRWpNAIrHa5K42k5 iLLd1IlkN9U49Rkwx3DESr8EVCgmFI0+BjF0cKODLVlkPlki/VBtwZBr0KcM+vQCsKNPskffx29Q QKwSY8oxSFH8wznbqVKOTdUpUnYc54TMI70zSRN2iuzb5+7sPdZ/77ktcxKJ5WcEimbV+uoDcw81 12LIr5b+bOa5732j/tV1F6ob9u+r2dBmoLdMXzlVbckyqg184GD1cBcmA3zHSM8pnTd71aJlGPs8 hP0i+UNgAz6YewbPwpNxDR2W5qBTZzPjdTYXNnGc2eS02VUyqBE82ipNCla3ekRKEFH6q44HZDYA ZCpKkyMa0M4TSj7gmg+0gomJG6hyA1PD9DEyhvMvfXMyHBiEgfHCU15ehn0eaZIbsAxgBNDxf5SF dlg7BkZ8/moKFmgKcmf4FvpW+N51Hs09B9s1F+1t3iuKTrJL3ksOKB6RRrM8AgsVX9O8COdoZtoX wgWKKlWVZgVcqVirWU9sVG+0Nzi22s87fu9sdZtRk33crKF9qdFHZ+xmjCsGr24xNCKMAOqgOMm7 nmlRsCiT9zFgMPCreymoHPlna2/T1a/6k+zXPTt39uBD/nD442sjX1y+MvL42lGsUfnzFgTQk45D n356CB3IxY8jdGYhZQbA41ZRjcqfCdWheAjdXDf1uj/x9jv6xb+4H3lVuSav+SWhwl3hXSBUuZd4 VxtWc6+4t3Jac2r07/HXspnF2QtNa9wrvV/yCiXP0SbeT/uz3Pwb9Nv0Hstu/qjpKPrWheKngWOs EMhIPWdjM90KbDGKfpWmRa60vcOKLo2+lFycdMAdjvcdhIMPMaIHg5z0QIPH4dnhkXm44JVJOCO1 VUhtqq5iEOGcxlJLD2RaFJYaOxVjPVajcN5EngmRM44XKeXkIiUpQXrOYNGAWBFAfekq2j0LZLON LKE8tevC5T8dW945z0Qb2e8e7ugcGYKazj/KdDaskj84eNY6I/Fo7+Gur89lWGNw2hoou94JtVgL m9BuH0dasKP9/qxtZmBVgMDz6ySK8wqoCEsjzEnaLfgRbQ2zVquFddrVZqePqlIjGbT4RLTfSA6C U2TsQKthVCiGQdZBCQkIDRBCPuQWEyhnpuC2lmAgkdkk+su6sf0ZLkODCUsBDaj0APoPYh3877ge KZh12jwmghY9mUVii/lKF+0ggOKIwHhxpfGgDOAic7kJj5oYPa5YJtoXFaONZcepnD2JynIiYzE7 P3v1o4aGj17r3SOta7t37+nu3rO7W/5waB32lt92NPTX/6hvQwfsyTA52dubxEwmQALtbRgxmQMC uBN/RW3eZyIKiWnEPKKauEZcy77J9WT1cL3WP1vuO/5t1nG2gK2IKLG/bJ3tqLQucdRY1zo2WbdZ 99n22c8pDOvN521XZFeybthu2JXkVSMvCCgPG3NEViUXjRrtfL40CWAtUlAK3o+zTqEUliYZWMNc Ym4jK5IznBg4MYmiFem0lEUHpJmANhiHhPRTJtNsZpTIEs5aGYedSI1+PmH1aJRD0fwUMSeYCVQS b1XyvCe/M99/d+mHL2TraQtd8EVj90gfNHR8CNWLuLtNTV08PHj4+vNRA2c00oWLoPXGOeQc/2j8 xckT2xGDwD2U5pYgZhaBzrg7rp2rSCh+qm2MJLXN2rPBy8GuoJolDZS2g6adVFE+iEAUx+RtADjz CVKRgvE4DxFzc31O4K7yizkAZAlcfp5FSZFqJ+JiXF0MQlDgb0vU3B3XhU1xU63pjklu4mLr2+EH wJIJUqhlYo4+kHJUGbovHx6QpiWg04iSXWWZa9X4TVdZpODFhrg+ELQiQEMOELT6HRAEYbCxESIG is+En3E/lbTPmqWXTq9ERNPYt0QYSj46XIPPnW343HbizfrNUZOFIbP3rvp+PdwqGa1ueMZ4+iHa MR9fX33ATJqzslgZu3b66/gJVv1PRjbJNyFmekEU2uOR6UwtQ/SKH7s/FwfcQ+JgrnKNf11edbg6 ukH3Y39ddJs/ET3o/2X0uD8ZPW/XEyR2g+WSQVAKBUk5CWAPRiwCzQoIS729KSIK6qAImjwqspRQ QiX05QhQUKtpKkmdpmQGag61jDpF3UbFkY/liwnXDlfSddolv+S67ep3PXbJXVxR4DtPkVVyi7IK Oo3AQHaRLh/AllqOKEunn3aMqmdG5QVgHR0E/Ohgc4AsTI3+q9lOghRahcgCfPFro/hhnjmMxl7J pF8mucDYuGUYGZWecI3BxWLqx7CLELGirGjhZOuQNWZmX66ltrLir/j2by/Xe82b7743NPTe3c2d 27ffvLl9eyfRsV9yjPb500JLfSiYWuDsmYEXnrRD2NoKwcisXR/catp16xbSwgKkhXVICyVwUTxv Hz8kEHJogiuU65U74C4iCY8Qp2ELoT6q/I3qrKJVdU3VrerjVTxpZCXfNjAOhmAqLQzDWpxGf1gK PKHKglAoXOD00+qM3+ugrpLS6dSUk87kV427ciy/lhTitSsWjsRihRFnCRT8NlHu9/kQ3CVArqLV JCVwfRaI5sTh+H8YL//YJs4zjr/v2b7zb5/PZ8cX/zj7nEviOE6c2E5CbOJDWZyt2xroFkFKwo9A mAhMNIWuWmlFtG5C3aoORDvGOjakafuH7kcT2LKwKqxLpVaaFDTgjzC1AaRNk0ZoihibCrb3vHfO D0KD6uje973XbxKfn+f7fT6PpR2FQ01TiZkElZjA/x5f171z0fUHtKYkW1i0fPIz71zT8Fe7/2Pe UlXHVvoMDC37DIKIKxm/pjsQHqQDt1Qh6NLd8yGryGuIA30JCbSTVALPMogu6VODVeaR/UX8eWrj ia2Dr/RvEwVBLH5MasS2l5/r39C4fzuJfFGN/3ZVvgA/9zd3d/2wp/DfJZHqtr4QDz1fuLW4ofEQ 0eg7EHOPAVpC4NQjSp0kNAuK8JSwSzgkfFdgXDZ2Cw+0SltNWwwGyerxC2+4gVZ171ET+PXf+2mb 1YzwBbwdfp+CZsOu1xtC7h4e80Jg0xHN2giLsgU1FtncvfmH7Gylm4EI3JG0a5VzhRe/AerYi0fw E+TBC17ymPiJ/wR9laLBOTtb3PTgzgo/AmIhzj4FT3YCsjlNvf5HFC1dHPfYctEJmHmrOis9nCX3 DdevXNR0CtfxdXJDtC5Vm15XlZPXR3OpYX44YtnjwhFXi4uK8T3RWXk2dUu+lbov308Z2+X21HDV cPosfzZCV6UjEaTZlWXJq/wkuc8hEYsi+adWNkdmhQXCFPsjoihFJH8ExZOqKhKJfCqRSKakeCrt tKh/yN5ottstZsnpc6udgsMreimv9xTv9bp5yce76qvJfnc02i9Ho9WyVC9XyVVVoXSKT6dTEd7F uUIowiMUQa50FW+IYCnj97szPro6U5/MxOP19ZQlwzmRMYMpM09aRdOBCI78RK7qTU/iM0iGHdsz qdEUFUolUjtSuhRRXaDVBTUOXPYZ06iJYk0hUwIWxG9pk9ByAZ9Go8iLd5cNNauBF1nO352HCTA1 C/3gvKZIFswVJhVVj+obYp39oBtX6cp4MJtzTcDsb9VmoVmbK+LqPMbX5lCMvPrwUcNL00ftDd6Y 4SV22ouMS2r9pBG0u/L2EWGvfRbU/Mhxxs5mSZqupMAIUCBvlCdLd6BjvafpfGSAoAucgFMby6f+ Ny4LqZBmAyOIQHgMO1e3OEknLq/KEohgvMoOMP7TiobnPTwUU6VgI7LYWZzAP99JVsUFspspnsTf Kn5/RfvzKa4n4iDr4u1i36Jk8EFQywVQCw9q8aIBJTXoPuh+2Q0F1LqFcA+QzhZCOZzX/YbTKXkR wA3CISfL9rBTrI4VhJVaJzJ/jMbX1Pfxh9V9h6h7EX9XehZGbvisU8AVeYpWso5WR5t9naPdkXWs dyiOTkeXiau2tljP+cbq9TW4BVO9/kFm0H+IOeQ3tDDN/i6my9/LGBLG1vWq9ubacXu+o719fYfU 6naQrWCIwxu5S9x1boHTI47lFE7H5e0c57BLbllUix2SWImS8kFJEoOS3JLQNpNskkrmG5PJRKPU klfI5tBcJ+7M5zo7lZwUb6SD1Q3x2oCfxkxdq5JBebourKsMm0w6prWlRZbdZps9VOFRxHTCM+qh PA+qA8FQTTW5rx6tpqofdKDGUK5DsXlyqGOqY6ZD1yF01/1a+/ZxTPXauwOx7NIE0SBa0wgGhEek RriSW4fWqHiPvRsY+cyCGKqNegWzVW+wyFF9jYgNtGCuEHGtoU7EXmslKZBQIdksKZJQJgcGoFL6 yiraYEbm0m2kh4spXYOyeQ3h0uVFNsIjqikwxL8rO+gJbcYwj8GMVAsYcLlJVa1Qu6zl2hpRi+py TY2sLrKrBfivffs3DIbbDrZvbenuJln45pPJhj0b8uqypylev75T3b5JBu2EbrD3YFc+35X5ytOF 8yRTqZPK17uGCpfV9fHOzYHobu1mGZYhg/dDBm+GDG7D+5XWq/RVIzVNTxupXxjH6DGjboQZZahd zG7jbp/uTd8vaeqwOI7PUTq/OCxSCOspKgha1JjLLbopd15wu72CxK1mLq2U2JEd2/PlaqIxF4tk VqZWgZctndfAqznTRuNJfB2F8C7FFQjrGWAwjnOaTeZQ5ZyABVIIWBW/jiXOAH4JhL2Wi32ZvLTE K9wFk/88pPU5uIv3+Q1GxkgbKdpvgKzyGQMae9Wp7LWYUWMiDwny0ds+XsuhEQAvuAYAMFrK3c8j KfBwqjyCX5u3vNa3o6dtqxr0G8Sn8t/55tdeGFlJX+WEONL3hWjwB18qfLxMX32HO79X+GRVFlDo eGlOn4UssKAK/EWljfPoPXyFR/cB/sBylfq74UPmqoXex+x1UkPUkH6vca952LbfOeTaU2F0h3WO sElnMTHWMCKacAg5dbZXqLNic6d/hzCLEmgHoNkEdVTxcmFagWO0AmcO0FP0DH2dXqAN9AS+Oe4F C1lkZyhO84WBEUK0UK1zxDfURsey1Oh4oNHhS3fPsbydr5gs3YSSfXPcFnQGl3uaAVIGiXQVi4dn fTmeDM6J0j0AmWDOwsNgNMPAkAH2bykBoDGGt3DwJgwe3lnRwZPBxTt4cmJa4WBhNgNIGclA6Rxi Fsc0DFh+9WEeRSSUTqFkM2JWtEv6bHH+3enibcxNv4tdvTfOnLlBLvzbi8UF7Jy6iJ3FhT//7KO5 0z+9PgexiUPvShQqoyYcV3JNZse6GrjS8U24lxqw7cYQE3qf7RA+XPdsg+Uv9EXzLDNrulYz2/RP +h9mo6Cr1x1mXtWd0r2loz1+VZZCY0AQ/AHJo1UZC/f+QyVlg9RYribYFm10ZNz+DCSqvTFsMUfD +ISeQWJGpqvDDiM2VibrkT0UdAR6AtsDBwL6gNC87bXlRlbFLtLKfhUiOJ9Vm9jP6mHXVtyq5nas 1pqYhKjHIeoxqy2ESdSbSh++XRNZirkacUgaTWTw0UkgatZU1IrQ4Lovv/Xci387WCy8c+PVv6qK OrBMObrTl3986sqVUyev6AZPbe0/NPPs+WLpD0WayAna2Qp9RgWavcdnLh07fmkG3PUsuOvTuudR DH2q8C/acb2pxzzMfZt7hfsRfdrF+LW2U3y/TOE+9yT1G4BWRTGV4TomkxM9tU9W1dbKVVLMYuet FrPJaGBs2IV4O2uukjMoRptzLJgjMDVBa5/ZwSwwFFP5f8arNTaK6wrPvTO73tmHd96P3fXOzM7Y u9YarzFjvM4s9sR2KG2DSSgUaLOFovAyjYyjUFWQFPoHk5BABCEKpT9cBUIbKEYBi02BIkEKQaWQ qog/qUoUuYQqsZJUVouULO69s2tsQVtVts6de+fuWj7f+b7znVmEoFtR8wlzu/mqOWx+YfpNtam8 e1og+5jbRSSPCysGGCFTLiBcMDSV7tzR8d9heRgjtorRKC/USlxiqm1WYcC5TzWkGyryZvxnMCA8 9OZj3/6ZygdredNW2w+eB895XuyZZEzV/nAQR3L1jdeWronxaCg0Y8uP3rO9/HOsDM9O+bLrk7fI e4gzveBLd6fQlXgUco8TK4gNvcf0Y+2/zF/lr3T/lb8p3ez8sPtTfsy+0/01P2Hf7eZCvF/yddLd Gi9KYme8e1dqv30mGlrGfy+/Id/vbMn/1Hkx/6JzWHhHCO52RjX4ZCDbaDbMducV7JgSra0Rwx2E 3dpiUs1zo7VhMkiQrOrMm2ewRk+wBNpOkXozaC6B191Ew1zDIJyapR3GouTK5ECSTMbmz15iOo2i 4WLdlJBCuisGGkGj+lhPDelvCBqhH2yvMAuJYVcXwCAunADZcaY85lGsXB4nMJJFFMpsRw5zDMF4 32jJHrJch9fB8u3dnJ6o5+vlTlEjnHiHBtp1FLhutJW6FI2Qlc55j9QVUHOLOYW8NlcjhEdZz0Dh dloJoKJ1XtObgv+UI9jBxNnJTwh58jOiFw0mnUI7EtaTKamQyE+zFM0fg0XPU+WR6tLISDoCCnms wQojoh0KvVh0ewUks70CGlgT+HtQZvCl07jVCDjMEF2k97ZXbVPllvaclojaGf6pVGFa8OOXbW2V q+gdJn+bnW6wGrwybCWfr8wnqKj8+cVDr/Q581t2jPT+cOW1y5e3BcQIJjynyuaBgUPDTy6+d3nn 4zf2HSezdahUX03GJLWQzndk2wqZRJRXzOcXbDyyJiXUxpK/QfUrNmstXVt6+3I53V5f+NE2XK97 Uf91qL1EE3HFtb6Kg0g8FoeHgqPBC8E/B8eCvh/X7qjdX/tW7aXQzZBfDoAarBMUeNYVAxRVE0gB RqBFNsqwnOBTw40l8KbLJh3LqnEAIPxhQw0JO6kS+LUrNDUFaL3BuEQkmISe2JQ4n/ChnvC3k7Ow dUdFNIYkAPmmMaKi0wWm7Bl1zqugByiPqqg2Fg+GQjFaI4LxsEZgB4RqAbucIpiiOOtJa3sl1TWV zN+fNKsQIJP3vie3+c2DSy+1CxFGiej/Gtx3/KBneTEY5GrM7vKfvrl6jh5R2WjEWPjSZpjDh3fx JZzH76M8riBXE2li0g0HqVEJZiQQC0RpT2fDuUA4TAdS0aRnWUPxPjkeV+RUMm3g/SzCAtZ83bIM PZUGUlTQDYdIB2XF0ZLJaIB2mKhfMMiQrhOELGHnSTcyrB64XgNqSuDTkxlkPaesizf2oESOe3ks ewa0XKjqa8f/ZTWrGWY4nvL76nmK1QjOL1RyXCEcXyXcOUJERJNQI+QmP66YnkGjDdf5jER7KLRP b6uKTO449v5W9ztef/v9+r4/HvUS/rnnILf+omf5Zpj00v7K4v6zlcev/yFXVdZB3W0vyrYJVrqz j4Kj3DGe1IN6SA/rEb1Wj+rImTsgzz3Cr4Xr2A3CBnMEXXqb51wNBBmccjFCRJhILkJG+thIhGFT QZarNEX032pAe6raGE2CJr0Bwu9/Cvr9JEzREMRFfNSlRBVNgUpftWMKPAsB0DlWQHOCYBKEzgsC zws8B4gg7o6oScYZJ0g6QdpvOkIJ9LshHjo5tosdYUn2t6Cf4AHtRlwOtHAD3DD3AUdx58AIqo56 YKDu/DRCeKI4eHuiOM5MIIAL45gn+LerkMsN+ZqzQy+8N9Ss4EUhAvcR/bKYQwDP2D+wffA13s9u wWamaJigClyVVCaY8+AJPLH73pHvYtyAg+MuYNeD5pe9g4KmqtpSMoLx8+D8RsX6T/XL/OQk9RpC MkM2uYczUlreQb4tHZZL8F3plBwgIAO3SXukEel30i3pnhQYhifgdUgGqICoUIqYgY1URkzLeSov LqAWiMuoZcJycbm6PLMWbKTWi+vkdeq6zFbqJ+Ib0uvyW/Ao9StxWB6FZ6iSeEI+rZ7OXJEuyx9K N+S/S2NyNiTFpSzMSll5SB3KHJPOSJd8l4S/SHfAHfku/Eq6K7MR3qsGhskJDMMLqYggGml81LTJ AoSlW65FfoGfhq0PLHKTtd2CjPWEBS3rQMay0pmUkSHCfvyBxpX0NnoPTUZpjV5Ek5/TYIQ+T9/C B4CmD/ho2u9LhX2UHvOqsq4up9bVxdSUrir7oSTrpclvua0iReqCj6J0URBQ48mgolNUVI8qBJAE uiKjZzR8QUDqooRuSPA8mmll8Byqpo9Q+kXwkWtSxBIAyCVUMO0YMUfnnYjfCRu6HomE/QMKUC6q oARedhuIfarb0qa6maytuvVpFOqSKKgxFKKsrTruqgzInAFH0Owgg12uLC2F7uwOG+J7EN+DLsPa sASOuBGfvkoE4kWB2ic4PmQ73mlpw8vJfIftbbOVLfoz3oq+wVvR570VfRleXU6SbZ8rtm3z7fFB wrfIB33nwMdE4wzG/LNYvN+lx8dUZqwYY8p4U1Zuq0y5GFPGKy8nbuOXhNLliSb2M547nSgwY/ih PI4ZFniBeQ+tyvQDXiucy2aV/8GyXLFYHBx8+OzhQ49909PmaCagBihm2rqAZ40akkyTU5Ja5SHP z+H5B87InevfLa0/3ojJ+AkOG/effLq0pz8Zj2m3sb/NAJgoj4EZDF0LhfJn8OczWboG6W0/YmkP 3OLu11iNg1yeXcbCOAEYQkutAs9wA8aAuarnIrjIXOOuGVfNq60X7As90QChEG+kSKIVcD0s12My KZMx7DmtwLBbTYZjdNAqANBq93Acpxu2YBg2dIATdZBQ8g7nGM6/2a+62DiuKvzd2R3v7nh/5mez sztrT3Znt97Em+7Gs3bisIt3k7VNYteOkzZN3WKiQhwaUeTEIrREFUqFUCL1gfQBRKyqQuIBqKpK xBVKQstDRWmFEE8V9AGhqDjhR3UboRJBi3c5d2YS6pQmfQCJh72j75wz93fumXPPPSdTNQaqdjVf zVX7d1Wb1aHqYLXaaDbrw8P1XK5QKhXqs+LgBVZ6MdNcqssXyKLTjInhbDYRDotIsESily3FxAUy DWPMpvbl3FJBdfpllwqzsd6yl0KKvalRSTKk/q5q19VLLED2sz7kXUm9l1xNyUR41JuaWknSH5uj eDdFUPjfo9YVYzUpr/BKXuFxA0l5lcotRDxdKjpxqNr+5XLKrqsX2m8s63dz/vxyfBPn15fVHOdv LUd1zn9/Pl0b8UJOz9vTDI2cvI3Gy1tosNygkbJEw2STxsgmhbaydXOUMyxGxfPwx50PqLTfaoTU 7rpidqv1Ci3XmCBBkRL6iEJX40hzp6nWGSfN7T1KnXHS3J6WSSLSjKdidcZJVurNjAzGiNjxVHpE 5pG0zUNn4qrHmxfaP1+W4yOMeCNCQq5GJMsJK36k4GZ4zezEutSNscqHc7ltVGH1rbN+xtYdh66c 8D32ZF88Zmxs/ZUb/1Oti62fOhdV613TiGl97MnWc3mN2q/we+swS7Pew/yoXOGtefZq61uBBIXg FBXqbEfrNR6PJNVIIkC55u6g00I1rXeZ4p6ecCJIp+fbra/7v0unx2YvUdCApJq0ipGsPsSGlL2R hv6B9g+rO6RNahPWI+wR5XHtceuMdsa6qLysXbJ+Yf3WitIRVG1VsTU3djEjkfLNoCVtmadMZp6z TNOy0lauOEBdXixtdbI9vdFtl0oDtlW0tZDg3FyieI6JosCsEIMRd64WfavO9LKm63HNMjS7P89r v1wolHOFQj5n9ecszbYzOSuey1kKHVOwOFQNzKYGVWEImqIa4iFOOh2vGgadXIGHOPlq/0C1WOyP wpwxhWPmZfMazzUHZ0QGURYz4jHxsnhN7BJTlf5Ljrem0zZNHvi4fJXcXL025bjfDwU5Ti6g7zgd LBVFz+sSu53P/aSBz41X+dbegaBcC9aco5L1jOk25rXeICtZ4dHWyZRpRDYkrnIjO84Osv1OwHtl oyHHS2tvf8OxvR4nVAqQD1YjG0KOE94r/Ng1ITKuD17ldqZrms598Srge4esScefG1JUovyUBaOS 8HL7OiLtv0OCn2cYgbIvEPD7LCnhmMyoVo5pmhyzElEmqEImEo1HItFIWIiyREQIs2gsA52i20x3 WGJz/mpMqksLkk8yUom5hTALp5InTrkphusIuf+bWqVczcstdihunkbpGrk05rgUgXwZ+SSBX9fk lhxOnon4m+fJL91wRaRoV+Hgmce6F1I7XXrDrMg2sKyXrwWyQyzLdUwqHvL9Zu0pYZg0k2RrEBbX rrvp2uTap7/CVfr6pPDKIhdeAxNqrTXhaf8fEUH2Iumo0oh0gw0iHwimovM/SvKN1abWePpJy/rc BRRnTeFp5h50Lel/4f3TfELxa+Q+4JVj/xnC2Y/CN0J424X/h4AYJNQIZ4CuQSD4VSB0CpD+CYSf AyIrQGwXoJwEVOLxB4EE8cTrH49UGEjTvD00p0nX98afAdldLnI/AfLvAH33uSjkgc1/oczuTaBE 65ef/zcGRgGbvq1y1cV2w8WO8dujSuvULgMj00Cd9tD4E7CL5mq+B4yRPP6Kiz3XgIlngKnPAXsP A/tIbftfcnEffcv9tPcHtgCzS8BD1H5IAj6/Gzj8HWD+1y6O5DvooIMOOuiggw466KCDDjrooIMO Oujg/xMQwMBLHD4uMYPQhTsWH+D06g4jGpMVVYtvSOjJlJHu6XU75O/qK2zajOKWu1HeOmBXgG3b h/Ep1LwJRsfGP7N7z8TkPZjeO7Nv/704cP/BB2YffOizczh05+X/98WPs0RNyLTVKDLIYTN9/Tgm MIMDOIhZHMUxnMQT7Tb14+2bUMRO7MY9uNdpfxhfwiJvb//h4x9P+7crvjv2COKIN48PClHm7UCh x5W7SLL4H/aHqMZCxZMF2tsBT/ZR/Rc82U/yNz25i+Qf7Bwdm5kZLzYXTiwenV+cnn/szhWkjFGM kbpmSG1FNLGAE6SQo5gnOk30Mewn+kWqfZSUtfgJ+v83enCNiFFmYQ9ViaQBGWUaBt+z0gu0Y4Er jp2llqCfJP52g+OIoNLwm+XW31CnggbZwhNBPs2vgsWuBe9vCOeWWnO/axyK1f4WDAWd3t+/a9/D nJ+fvNzTfuP9s6IRLNIr/z/OzP8aABVN92EKZW5kc3RyZWFtDWVuZG9iag0xNyAwIG9iag08PCAN L1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL1RSMiAvRGVmYXVsdCANPj4g DWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA2IDAgUiANL1Jlc291cmNl cyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0v UHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL1RUMiAxMyAwIFIgPj4gDS9FeHRHU3Rh dGUgPDwgL0dTMSAxNyAwIFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3RoIDk5MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiWxVTW/jNhC961fM0S4irqgPOzpuN4tu Ft02gBX0sOmBliibjUQaIh2v/31nSMlR4siAIdPz9ea9Gf5eRZ+qKgUOVRtxzsqyhAQ/42u6Klm5 Xq9gneaMr/ISqj5KYBd9+mPDYWejOGFJkqB3jcfVKfq5UJsvm/tlzPFJFmkW38la9ls5xAlf/lt9 j2JesgLiYg3VHfnU0QKW1X9RwtICUnab0/ksLL2mIfT3Y6eEho1wg9BLDA+YB78vz8YJ3YihsVAN on6+Afj666AGaQFdz5AmGMk/ox+/TegHlcVZUUDB2aoc66KEonNmJ91eUrKBwX0LAgYEpF7kAEo3 qhYOo7u9cKDIyC0xbiOtTyqgF8OzHG7QQIY0CcSc8fWIkfOQx0rdYMDNt78f/7wDsRukhKdFcxyU 3oGWO+OUcMropyUgQDgM5kU10kcNGQIg4V6bcslY/TahCWU1oVDt5PAiOjZVlbIso6p+LqopqgeN KIOlz0xRlVZYTjdmJqO4k9bODAcJtTniz+YKNOpDA9r1FsjTtD7k9kxdPHSipvK0P6u+PID1gAYp emiEE2gHXl4Mrsv+Zy81ctMcyYXiOBOMQ7qbsV4LPx43lU8+8efTmba10pGTgDy+LptKhJMZGt/i LcJDoZ2nYq2jIhlQ7zph5zycDGx9NmcxCUhR7y+kvWZZhSyUwPcv4LbYUERCnQ9N1RZ5Jw4TaI3v /VR4bfrD0XmVzDnNQ9wH0TSkJU+9b8rD3SMcxLkzAqcFUefxBaFPPiJUyItV/aFTLb1eVzxC6YUX lTocu1kNaHc7L+Mzw/m7R/34hqBUfnjvoJ/7UT/jOJLjtApWJOBFZUBqse0CYdgMLWvKBYj/eEAq 6u7oUdLfndkhN4e9sHI+QTdh17wiGGeDYJDr08KXhnOuzzhtCtE7MZCSjcYNgmNOwVvfx8G6iclX 7bfuLbGjfMgLhxwMOba0JN4VyeCbOckXWhZ4FLilneDegJ4LBwebpglBWwTmtUBCkb/GE+hlvRda 2Z6CILHPntiTcntzdPCszamTzY6k/34/jdx2Uu/cHv/3wecdDU2YNeCkOjLqYCs/mOPrfoSBAWF9 aBUqmKvh0tG9aMZpJXox7jjHH6j8M65cjQ3wWkTNyinwe5aQ1oKTUXrZagEd7eGGWL5uhh8PniSZ r/hpEeCHDTMi9iYYO0HleIl/0CXfoY+2Is66X5i0x72IxoQZf79k3o5WNo1WBvAXCt3fQkHs3vBr hVcrTwq8tHnByqKEVZayvMzwsk1yvIgzvOkL3JxROxnkRc6KfD0a8OwW/W+Dxf8CDACTb2TBCmVu ZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNNSAwIG9iag08PCAN L051bXMgWyAwIDQgMCBSIF0gDT4+IA1lbmRvYmoNNiAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0v S2lkcyBbIDExIDAgUiAxIDAgUiBdIA0vQ291bnQgMiANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0v Q3JlYXRpb25EYXRlIChEOjIwMDExMjIzMjEwMjQ5KzAyJzAwJykNL01vZERhdGUgKEQ6MjAwMTEy MjMyMTAyNDkrMDInMDAnKQ0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDUuMCBcKFdpbmRv d3NcKSkNL0F1dGhvciAoc2F0cmFuKQ0vQ3JlYXRvciAoUHNjcmlwdC5kbGwgVmVyc2lvbiA1LjAp DS9UaXRsZSAoQXBwZW5kaXgtU3luY2gtYW5kLVN0ZWVyaW5nXzA1MTJfQVMtTWFya2Vycy5mbSkN Pj4gDWVuZG9iag04IDAgb2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5n dGggMTExOCA+PiANc3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJl U3pOVGN6a2M5ZCcgYnl0ZXM9JzExMTcnPz48cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cu dzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRv YmUuY29tL2lYLzEuMC8nPjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9u cy5hZG9iZS5jb20vcGRmLzEuMy8nIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYv MS4zLycgcGRmOkNyZWF0aW9uRGF0ZT0nMjAwMS0xMi0yM1QxOTowMjo0OVonIHBkZjpNb2REYXRl PScyMDAxLTEyLTIzVDE5OjAyOjQ5WicgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERpc3RpbGxlciA1 LjAgKFdpbmRvd3MpJyBwZGY6QXV0aG9yPSdzYXRyYW4nIHBkZjpDcmVhdG9yPSdQc2NyaXB0LmRs bCBWZXJzaW9uIDUuMCcgcGRmOlRpdGxlPSdBcHBlbmRpeC1TeW5jaC1hbmQtU3RlZXJpbmdfMDUx Ml9BUy1NYXJrZXJzLmZtJy8+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6 Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhtbG5zOnhhcD0naHR0cDovL25zLmFkb2JlLmNvbS94 YXAvMS4wLycgeGFwOkNyZWF0ZURhdGU9JzIwMDEtMTItMjNUMTk6MDI6NDlaJyB4YXA6TW9kaWZ5 RGF0ZT0nMjAwMS0xMi0yM1QxOTowMjo0OVonIHhhcDpBdXRob3I9J3NhdHJhbicgeGFwOk1ldGFk YXRhRGF0ZT0nMjAwMS0xMi0yM1QxOTowMjo0OVonPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjps aSB4bWw6bGFuZz0neC1kZWZhdWx0Jz5BcHBlbmRpeC1TeW5jaC1hbmQtU3RlZXJpbmdfMDUxMl9B Uy1NYXJrZXJzLmZtPC9yZGY6bGk+PC9yZGY6QWx0PjwveGFwOlRpdGxlPjwvcmRmOkRlc2NyaXB0 aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vcHVybC5vcmcvZGMv ZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv JyBkYzpjcmVhdG9yPSdzYXRyYW4nIGRjOnRpdGxlPSdBcHBlbmRpeC1TeW5jaC1hbmQtU3RlZXJp bmdfMDUxMl9BUy1NYXJrZXJzLmZtJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVu ZHN0cmVhbQ1lbmRvYmoNeHJlZg0wIDkgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAyNzk5NSAw MDAwMCBuDQowMDAwMDI4MTQ1IDAwMDAwIG4NCjAwMDAwMjgyNDggMDAwMDAgbg0KMDAwMDAyOTMx MyAwMDAwMCBuDQowMDAwMDI5MzQzIDAwMDAwIG4NCjAwMDAwMjkzODUgMDAwMDAgbg0KMDAwMDAy OTQ1NiAwMDAwMCBuDQowMDAwMDI5NzA4IDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgOQ0vSURb PDExNWNiZmE0NDI5M2I4MzQwOWVhZWMwMTA3MTJiNmM4PjxjZDZlMjg0YmUzYmQ1Yzg5NDFiZGFl NzY2NWM2MTBjND5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN --=_mixed 0069BD07C2256B2B_= Content-Type: application/octet-stream; name="Appendix-Synch-and-Steering_0512_AS-COWS.pdf" Content-Disposition: attachment; filename="Appendix-Synch-and-Steering_0512_AS-COWS.pdf" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjE1IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAxNyANL0ggWyA2 NjAgMTg3IF0gDS9MIDM0MDgxIA0vRSAyODk3NSANL04gNCANL1QgMzM2NjMgDT4+IA1lbmRvYmoN ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTE1IDExIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA1NjcgMDAwMDAgbg0KMDAw MDAwMDg0NyAwMDAwMCBuDQowMDAwMDAxMDAxIDAwMDAwIG4NCjAwMDAwMDExMDUgMDAwMDAgbg0K MDAwMDAwMTYxNSAwMDAwMCBuDQowMDAwMDAxODQwIDAwMDAwIG4NCjAwMDAwMDMzMDIgMDAwMDAg bg0KMDAwMDAyODc0NiAwMDAwMCBuDQowMDAwMDAwNjYwIDAwMDAwIG4NCjAwMDAwMDA4MjcgMDAw MDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAyNg0vSW5mbyAxMyAwIFIgDS9Sb290IDE2IDAgUiANL1By ZXYgMzM2NTMgDS9JRFs8NjExMDRkM2YwZTc5OGFiNTUwZGNhNGU5NDQyYzc3ZTA+PDU1NDIwMGVh MjIxMGU3NTliMjZmZmEwZjcyMjRkMTVhPl0NPj4Nc3RhcnR4cmVmDTANJSVFT0YNICAgICANMTYg MCBvYmoNPDwgDS9UeXBlIC9DYXRhbG9nIA0vUGFnZXMgMTIgMCBSIA0vTWV0YWRhdGEgMTQgMCBS IA0vUGFnZUxhYmVscyAxMSAwIFIgDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgL1MgNTQgL0wgOTMg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNSAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBg mgImWxn4GRAAxAaKMnA0MFzt4FERkGCA01AgAMTsUMzA4AfUMYMhg7eB02CtxNEGiBIuBoaaCiDN BMTeAAEGAPyxCs0NZW5kc3RyZWFtDWVuZG9iag0yNSAwIG9iag03NyANZW5kb2JqDTE3IDAgb2Jq DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxMiAwIFIgDS9SZXNvdXJjZXMgMTggMCBSIA0vQ29u dGVudHMgMjEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xOCAwIG9iag08PCANL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTkgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg MjMgMCBSID4+IA0+PiANZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTI0IA0vV2lkdGhzIFsgNjAwIDAg NjAwIDAgMCAwIDAgMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDAgMCAwIDYwMCAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIA0wIDYwMCA2MDAgNjAwIDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2 MDAgNjAwIDYwMCAwIDYwMCAwIDYwMCANMCA2MDAgMCA2MDAgMCAwIDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDAgNjAwIF0gDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nIA0vQmFzZUZvbnQgL0JHT05GSCtDb3VyaWVyTmV3IA0vRm9udERlc2NyaXB0b3Ig MjAgMCBSIA0+PiANZW5kb2JqDTIwIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B c2NlbnQgODMyIA0vQ2FwSGVpZ2h0IDU3OCANL0Rlc2NlbnQgLTMwMCANL0ZsYWdzIDM0IA0vRm9u dEJCb3ggWyAtMjEgLTY4MCA2MzggMTAyMSBdIA0vRm9udE5hbWUgL0JHT05GSCtDb3VyaWVyTmV3 IA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDQyIA0vWEhlaWdodCA0MjEgDS9Gb250RmlsZTIgMjIg MCBSIA0+PiANZW5kb2JqDTIxIDAgb2JqDTw8IC9MZW5ndGggMTM4NyAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIibRWTXPbNhC961fs5CQ1JU3KsmTlJstO04wn1lTM+GDnAJGQiJoi WQKMrIx+fHcXIPXlZnpomYxFYha7b9++XeAm6lxEUR9CiJadMPTH4zEE+M+99odjfzAeDWHUH/jh cDCGaN0JYNW5+G0ewkp3vMAPggB3x7gcbTpPXTWfzn/veWEYBkE3HHu3Mpbrhay8IOx9iz53vBBd DsG7GkF0S5viThd60Z+dwO9fwSUtHjil14F1/LnOlMihFwbduTAVvgJ/nP7MjcgTUSWav6NKxC+/ Aty9lvSpKqkBPW2hHwT9k/38G47G9MZQGdJV6A8aVEOC0p2UpcwT9QoTH+bbPAYMiGGlrFS+go0y KUyLXCMOAw/fZZVKkcBjUZFRvVyS0XN3+vA4f+5R4qF/DV7fsUGZRqnSIDAI4eFAJcKWucFV0Gpd ZhJ0nMq1hGVRMXiNMNKqyNUPYVSRo//Z7VebRQBe6IfM9lN3UdREzpZTraSplPwusueeD1EqYSG0 imEt41TkSq8hISup40otZAIISuW6RAoTWGwPnQ8bfq5sAk/Th5v5N5+DfCo2EjmAOs/Ui+Qlg6H2 QWilqE2mcoqRw9OUVsgBoGEl6S8bvZWRY0y+GqwI7ic7xNaHokItDRCnkbApSA2VXKEqMqk1M1Ys 2TE5zWS+MqkPj1Q5jhD90uECfbD1GWF9/MtLS6EHhhzgXpY6e0Bq3mGNlupVJu+IHAHXHIXjkycg ESANWPhPzz0bBZPATBruxq5/8jirE9KIOMBPzjA7D39ExkJeEV3seVmJNdmXwhhZUe2nH2cYg1TZ ZON4al1ajnEz0v4CWAokXmaoKJQs7r+f3jUgvWOUrhk99L5ljQrsxFg2dDYYGCl2AjOl3HfDt6Ji lJmInZA4q1NKHGIU+AbLBk7nz7QAWcHpbrNCJJoyReXGL2xHVpyTKRhQjtJoWaAErh0TLfRDNbTw SZNV40Pmln4bvEGUKW7PFwKAy6dMI5/IP/olK0sw/09ULIx1s6ZoCQg7qQQQ7f4Z628rbi22sKD+ zzJsMOaRjSqhMpRZjPNHaUOyQAg0NXLvhODuCscIhSSNo75pCLVzYpJlmHqhLTtOGZpBozeW3V3T c7NbMvpKurlDaDjUXJPue4Y31Fra1nMFb3RLaw3xCfZQ7tJJbXBNUSpWM+ZRyliJDHCieOfTTdPo w3xbdZtUGEgKnPl5YVB0f9U4vZoqs3cnRBb+om5t9M/GG2nCobK6LvZprWpSFZ4FNrZLdfqp6Qjk VWQbsdWueZyFsVOO3hdypXIGx+S8PfC4qNF0xuRpuWL8ThPIMxPouFI/pJWvLpYGlYvYDXaLJkYv DoR7kGCK+mZL1mUiSqRL23lCsFAIGIPD8bylLlsVRgnjJrA9fSYZDikGxuUo+WA6pZXzQYXPJg90 CvFFgJUzsCWlYwnZWzLF1DE4PT6cCwzgBsfaRXuUB2CfnfsNj76tUf/E5rL5PhcWr18c3BROth5/ Hxud2ZxSYN3vRjDknVc4oy+BrmQBr519s/t/tnkb/XsPH9rp7Z/33vFjv4+NzmwauaBbPGZ29MdN Zm7yj66pZ7bHcDa2zwl3/46W/xb3ES00+3ZfdvCHveX4BwW7pxPk+PkJ+t19tDug5X9CPTy9L+9z ObgwP9HhTyesOJqrGkd4bNrBuh+qdjTExXpd53QyoYk79fYZVXiFV3SHY+Oab7lkkRU4qaBMhZY+ TEgJgO9MFPrAscATaKn2Yc9r7IC4/gYp4hQSHMAxTQv/oNHdPLh7jWVpWnu+UkwegK6YWyjiuK4q 6e4jjTLpQo447fnOdwbi5xxKeydxl8ijA/ku6vw9AHF3eAAKZW5kc3RyZWFtDWVuZG9iag0yMiAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI1MzUzIC9MZW5ndGgxIDQyMzg0 ID4+IA1zdHJlYW0NCkiJXFULdI1XFv72PudekUiFiggNNy7xyA0hqQaRhiQaQ4gSkoxyExKhSUWR 8WbSKa2oQYymmKmpMiUeN+gaxWplRDsZiWcmKbKWTofRylLDMI/F/c/sXFY7nf+s///P2Wef/fj2 44AABGI1FNInTBo4OO+lzHJgt59Qx88syimOad6RCfz2BkBHZ5YsdOzenXNP9pqBNqX5xbOLjjf/ ewHg5wZsqbMLl+RvKU+oBHruBF71K8jLmVW9ouNFkScyMKRACAHLOF4UfiTrXgVFCxfX76mMlXUd 4N+zcN7MHLaF7gPekf1O8UU5i4vbTmi3CPjwG+F3vJZTlLf//sljwC55aWDxvAULxW55dlW07he/ nlf84HhTIBDyd5F3UN8C9GZ0k393lYvugLn+9P3aWil7sm95jeEmOT356fvkmSzjV77vZEp78scs NKAIm/Cu0GLoHPYiEe2F3gBFoEzEoxw/w5+RYe4JNRy7cBcuDEWBsdABq2DRCuwiBsupOFxGHjZy vIrULSD0p2hVSaWIEimTsRUhOC8S+xt/WR/hMMGMhX5WzfBzmWhzn07pWpOLDyieG/VB1OEO9dSw 3jBlZrvZgWfwQIV5T5tBpkhOZcCNRVguFqzGb1BPWTyCPzNvi02ZYsMq/B5nKVJDu9ERLwv3L1CB T/ApzuNL3CSi9tSXVtNlarDBW2PVmDEm18xDCsYjHatlN4x600jOVtnqgGry/tX6ynQX2ZNRgsVY hl9iIyrRhCu4Ror9eTJnqAPohhHIRq6gWS427UUtrpMfxdIwSqQ1tJ9LtPLWSGw1ggXBVB/6m7Bd MN2NQ6jBBVwUmfcEU0WhFEkZNI1W0Ju0gbbQbtpPB6mFbfylUurn+nPdYjUaf7PN7BW93fAcHOgn kYnDOIlnPW6Lf/3JRS/SJY5klyLdzmtZMeYls8qcMU1woo/wjkCy+JyGqWL1EryBE/hcztbjHP6G fwlKivypo2DhICe9TJNokVhxgO6SlztL/OK4kA9zg4pU9XqqPug9agVbh627ljGVxmNOmzpffIeI niSJwCsoxgJfxD4WPWdwA9/ioeiwUw+xNZXGir8VIv86PZZ08uOVvJ+NGqE2qlodqius8VaRVWEd MbEmTXJLwYZQxMoYJtmUgSyRXSpo7sI+icwRyZ5GfEddqDtF0xiaQpnkpgKaR8U0n5bRckF1Lx2l E9RI1+g71mznYMEpkmdyKZfzUa7hRr6hoCapTDVfLVPl6qi6oL7RQdqlo3WadusleqkNNmXv7Ff3 OORxkTfXu8172hpgJVuvWmVWtdVofW0CzGfmJuyIFhuzMFtsXCH+r8EGvC/5sU9s/AtuoUVifl+w UNSWuorFPXxxSxK708TyqZRF+TIKaK7gv5oq6TCdpFNUTbV0li5RM91lEusHyBguVZDB+eLDNq5k D1+R8ZD/oyKUSw1WMSpBucWbteot8edd1axuatbBepCepFfpL2zKNsu21bbdVmP7o+22Pcj+06c9 4ocOIo+q42qdoAqxE+ms1G2+xPG0gh/R7ziMqkVbmEpX6ZzEw8F0QrK8CJ3abLeH28O5E4LauFtl 8HscpabqCNUOC6XewNm8ht3YQyfxiFMl00pUPe/kGWq73qwTqAmrRCc4kP6JkRhJCRK7y5gvEYpS h/S5Vok2P/XYVsSBZq2+ZWN1SfrgCGL1J8qmO5TOnQWt4bwBTlkH0R35j5EKvCKZ/wlNRZz+Sq3n n/A1oRWinKrFxxMo5BP0gcQlTurxdUqnHWoQVtJ8QWMo5vIW9ORi7in5nIF/UCkFS+U+ktj04nxo Fcgz0cBZEvUL1JEH0ErJ0yKU0Tq4yEunUMebMITy1KePQ719mR7foSqViip6pGt1LWuRVC1oRkv3 SJQM2SU9IkMqM1xFSNbEwcYuyf9XpAOOQwd+SMu5EHOoQn1Lu3kkJiBPLeDRtNV6qEeqGEHsuHST JPtQP9jibWE6ViJ+CwmSjbMBe4G+bittnavL6oHJMuHWDNszVjOWCjqp0t3KpJZScZU603SaqA2P 1cZMQSUf0s0mhNpROC4aqTDrY4qnXsZB800ATZQMn27f631Pl+k39SK9XO6mR9I112AztuEPcpt8 KPdWH8FxnKA5TXrPHLkjojEYz4t3CRglXWmM7KVjivRTt3TJfLyG+dJ5f439qJIbaqzgMV3O5WOu 0BfIDbUMK6X+12K99ICt2IOLvI/fV+H8Fp/hEp6Dq7iqvlCJNAUN+m29CpPQCxPpWdH8gkSph5xb by6Ltn7oJt0/VqpU8t60mEbzkfe8yNsjtm+2j0KLPQlITEx8MWFE/PBhQ+NeeD42ZvCg6IEDolyR /fv17RPRu5ezZ7ijR/ew57p1De0S0jm407MdOwS1fyawXYB/W782dptWTHClOEe7HZ4It0dHOFNT o1rXzhwh5PwPwe1xCGn0j3k8DrePzfFjzkThzP8/zsQnnInfc1KQIx7xUS5HitPhqU92Oo5R9sRM mb+T7MxyeO745mm++UbfPFDm4eFywJHSpSDZ4SG3I8UzuqRgXYo7WcRVBfgnOZPy/KNcqPIPkGmA zDwhzuIqCkkg34RDUoZVMfwCxShPV2dyiifUmdxqgUf1TsmZ5UmfmJmS3C08PCvK5aGkmc5cD5yj PO0jfSxI8qnx2JM8bXxqHHNavUGZo8p1at36Y0HIdUe2m+WclTMt06Nyslp1dIgUvcmekKU3uvyw FOH/Zb18gKMurjj+3m/DfzAhIAOJ8S5zSQSSiA2jMuE0d5IEIVr+ywWrHISMwYwjY6v4ZzRpLbVe aAGrBZsMUG1tRzp6XGJNAtZ0xMFBo7YjZVo7VavYTq1/ZpDWadXrZ/d+dyS2duxMf/v77tt9++/t 27e7bwsXxe4ZWVpsEg0zNwdtNpG4J5jcvyI2srTUxs3N9EFbr7wxnmhk6O0osWlVkNG8bc2xpG5j yKCdiZ1VZn6toQbLiV8fTE4IXRZqS1wfZ2mKEklZeVtpqqgoMpB+XYoagonVsVBpsq441Lyh/pyD 0yWx8rbeWZHgrNEl1VUHC6ZmFHvwrHw/MXnKyERrrsylXHWbalqZ06xaiUJLMIhksCWIJLEQc1pg o9YFkmhZQDW+ZqVVchMrsjk5YVE8UVBr+bZ9ckx5QSiYOC1YQOjdv47mbPA5Y8sLTotNWjvJmRrl 2XSysjI5d641kXGLWFNkvNTlL6yuuqXf2xzaUhCEoD5Zjm43NNfOQ/2lpXaBu/ojspFMsnNFLJMP ysbilETmVTYnvbgtGcqWnL3GlnRmS3LN4yEsuU/s2+Ds5PiK3J9fMGNaQ1ttUmf8l+LWTHnTqlDT inWxYEMi7uu2afWoXKZ8Qa7MTyWnLYqZYs9PecXGlWKUX8lVtpnY5GReOf9YZ9Sb+seNxyodR4ON yYL45Zm4eWJp6Rds1J/+wLZy5EwzX8xkbeXo/MJR+VHiTU4YBM6r8JpWr0skJo4qa+QESiQaQ8HG RDyxoT/duTEULAglBvA7KhJbGuLZFe1PD3YVJxu3NzOJNq2ttsq29wS39XD6lfSv8/7p1D/K3cgb tveUrWFjfUcn4j2+BT7VN7xrtFr+KDu1kjtuGJ/1JCUH5Bn8qiNayGvkTzpNh3UBN0Wr3M9pfwIf fi1n+15eCft4ObTT4gCeWafMlPOljbuujZIB/PtVUiDl3EAtcty7RN7UsNjX4mH8/mpa3EWLE/hy a+Qp6ZOnkeZsPIddlHVS+hJ3xdWykLuslffWu/oAHtL91JnqXkwxN9IqejoTDtAuEwb9YHvLhqv9 8DE361t4HDv0Rie1Uws+bB3jFCLrDfS0Ue4H6yQplXjeP5E38K0r8PML8L7f1neY573coIcYvwVZ Wp1MbaBQdvHC6+XG/0TL6acbyVvQ/Dhp91bz9pqGTzKMnl+nL/vGsoihvUwQ+hD6tGEQT2A2qPVE D+qgLtRX0N5VjDmAZo7Lu144/Yl8nd4fYLxqVu8svQXfv8Vfcbsud9Knrd3BPC3uSp/0jjDmToe9 5D9h9E6HTnrO4nz0ZtGG1mK0s7D97GBFLFahRQukcOhghvbF9oQW8z58We5In+S9U8x8Pd61PmyM 39UqD/K2LbEGytunxMYZZD+84BJX232fl/78z7sumyDk+3iM9a7A2zNIEpV+Zukxv32aj9wTZFr6 lKd6vhyizNPNulkewzasjrKay2opo6k7c2jHdtvxtU5iwSNxAHtuxqLvy+mzEwj6FF+nGX3entNl FuXYu13TE278QixuuWxhV1p+FpRjX2H5NtJPpt4kKfbGYx+HdLxE0h9jZdH032Ru+hX8brtTWxnx uNulzWjD7tHvsbabsJsjyNDCCCV4byfhbGTVunhvrNU8acTLw2/18rGUKH7cUm1A9mPIvZY1bJCb dTapXeBmZ8kdhAFnxwckxDyn4k9W0aeVwJ4WSyWG/3qTzCZspcZMJMpI0YEUVU6OZjzHPIJdu7VY 9wzk3Ynu7sCu1kGnk6sl3Crz8TbbGb3dnSSPIP9W5nmlNEopoYneH8GTLZO7afVdWtvz5ClOhD6Z n36PFbuVFu2MvIcd/iVp88p1KS/FJV6ZPknYo3tINXll3kVY9R4vbLp447yAbe/ljfKw7NetvH3u kzb9KmvVJ0OcGtvYf+fwbhhC6/+QP8hD8ix+9gu88G6XbZQ+LX9nff9M/QecffJ+QV8WL7uQ7bmV k/ZMv9tcn7bHXH+6lRXpg/Mzb5Fux0ko06N6lDcfm4p37G7we30YHNNX9be6iZPtQ+3Q1XoxL6Fx ep58n9pve0v1V3pKp+h5OpWVPbP/jnm41p7Rh/RHvMRu0JXwenSjxrG9cldlkox1NQuQw3470bzd W/abSLDfo5yUH8hu8AG19rIXCEhiz+kMf7ferceR/Kd6jPolrENljmbT/4cP2XvcDScynV0+UZ5H Q7ux/CE9rB85Od1hQdqfnz6n38zNNcvz5/pvdK+usHA6sBib0U2Ofvab7OvHp1rE+o6gWd1ivb9x tI/9bsvH80KzNKUpx/8Uq7b5U8hqP+bj5vKo3OLy17FHvyE/lB5OEuDNYrWxC9kgV6CRV7GNKVjA w2jiGgnKGNbhGOE4q3E3pXaUHunRv+hpPc3+btcn9EN9Uyu8FrSWZN9EpUJfh/Omvqe/pMejaGEv Y53Ab3hRhvV6/RoSDsthZAxjy/digVPlPaz9MOEoL9ib9Vt6DeEXhMP6A33tjLZzWrCWYvVc4uxB dDEhJqfkd/oR6/WiiLujODeR4UF27RF9Xoc4B5/Fcge0kp0xU6/VenOnPOfa79On9Mf6jNvjlS7M diGdC0fQwMj8mXAZtUHu/vyiGHl3/Cec5FSyd4adyf+Cz94cI9Hi/I4MrAx2jM9po/N0upwGMpAe MkOpNfMj/ZBaR3rPKqvptHTSFEdTE+bXReeZIdkCHgcvgTxZT9zhc4wEiOuA5e5w5fvNIUmCIfAy sJxBOINwBuEMwqkz/aLmSfPzVFmAoft6Z5XVvB8tMr2SBp7ZxRFcSt/X+nS9T3dA50J3+vQ7piu1 MJAfnUBe5X3iNPCYW09q8bKaAZe4OOwS3VlOdy+cQHSW6UGqHqTqQaoepHqfWOm1G343/G743Y7f Leq6Kp3jd+UnelL5M3wOiehE02yukhq6iPl0rbkqVRN4Oho3a+j6cRfvN6uJd7h4vYuXubjDlXa4 9I0ufaNL17l0nZ+28bwRccDF+TY2K80q7tSAWWGWOrrcNLDHAmYZeUu/bJY4eqVZ7OgV8GdCm6hX CF1qGl1+Cfl66OXkLV1sGlP1gQuiW8ivpww/y1h+PTLUI1M9SrKcHWA/eM1x1hN3gJeAcTXV1BMW EaImSosIfUQoiYgxEUId4VJzKSWXUPcS4ogJuzmGqRVmpDC6CtNzmOUJszxhGWfCxEFzoVwAImA5 iIMx9FNFuyrkqmKEKlONjxAwpd52fIuACfo04HXJudBzva7UuYFIdILXJ8tBHGwBnV5fakxhfnQ6 9WzdeWAZWA86wD7wOBgvdZmSyCSvzqszy7xlJg/rntMbDtc4Ov+iDD2nJEMnF9XkR28yc1DTHNkH DCLPQeQ5/2K86mObuq74vfe95/ee7ee85yS2n53EfnZiJ3n54iNfkJCXxAkdUSAFOuLaoQkootNE u80BMSYV2MQ0BCntH6vGX/sKgnWLsEMbOSkFun9W0KZqaIJKqwSaUvYhRR0sSquO2Dv32ZSkRVPf 8Tn3vHvOvff3zj33w/Cpj9/8wARSJ4KuAX8AfBeYBjwCwYhAMCLwgRFoHzG9LKbfJ8A5YAaSKAL9 r/XhzNZ+4MZVvdDaaqiphrdqaFMNvtVQexckNltQ+xDwWeBrBVvQTOagmZxB6CsIaBtBdplaEUg/ E5whYlEG4os3FXW3Qtx3AIORTEI0JyFukzRDCF3EjWDpKnicBb4EzDFzQDVAEaBqoCCQBhQAghlk KmD2XgM6C/Qq0CTQGaDTMBsll/RrOnmh+eXmY81nm3/efKn5WjP/DhkDGiWjhhW5XHBcOBXB2y0T FiWQhD835bQpv2dKw5Ruw5uQFhLS+wnpXEL6aUIaTkjbE1J/QmpMSBm8z3Dr0l916TVd+qYutehS sy5t0KUaXepWcAzvQRK6asoeU643ZdCU5XjPjITEKziONAEyHkfe0k74P9YyLJ7x/0jLCFD8MP8W zxebaeWsv0k74K/L14TzRaX2Lgs9oOfw7xCPdaOOv8G/wBt8O9/A1/PVfIQP8X6+RHAKsuAQ7IJV EASLwApEQEJJJnfPgOMXoxKLTAsLSyVr6jKhktCzFS5RWCBwzU8VMwNkYFcPHkhd348G9gVSy7tC GWx99vkUF+rBKecAGtjd40m16gMZPrcz1aYPpMSh+HAa41dj8JYiP8lgtHs4g3O06qQv5ewdnkMY 152c9BXKWIy2GU6zeHIyhlyHuzxdzi1Ke3/0KWK0IPUnj0df/QJIylNvDOwaTr1ZHkutp0quPDYA kdsVSAzPkTbS0hedI620iA3PWY+Ttr6dtN56PBp74ocCUB+dQxotTD8UoH4o8CW/CtJK/apokfer MP0q1vilO7W+aFrTHvt0mj6da30OrPU5YPocKPgweR9tlQ9/D2mmj8bf+4pPxdfwqXqqz6pojvfo /+fBc/A/8na692jfeKhvNNQ3DjyaOn34RU/q+L5AYA714tvUFEgx4dF9+1+k5dh4Bt8OjUdTvaFo IL3t6FftqaPUvC0UTaOjfbuH00eN8ejMNmNbX2gsGru8dax2es1wpx4Pl64de0pnY7SzWjrW1umn mKepeSsda5qONU3H2mpsNccysx7SUkA9sd5EvrxMbFZI4FGfFutxyd/ZYmbzZs3zim+eRfgisumx lD3Uk5KAqam+u76bmmCVUZMDqosKJs8rmzXfPL5YMMlQrYR6kKfvW1H4JZMF5Wv+ksnkxN7k3iQt zV9y4hAwnSaURMkJBF/QbTfPNz/sxnRvPg18xtyjmWQyNoHMOU0eQrS3CSqedP6Fdgh6xsnVSYCS X35oZsB/PpOhu+QhDF7U8VAhbZL0sg7dIAoy3wndb0BwQHBS8Kg/beEz2P4W1HIsVRhktXCgzDIM 8Yo8rZvFSBV2/MCjb5eXOgZXOrbLyx2D8gpcIzpWOiiva9IUTakCATscehRgrj8yOPRfFGCv0/Gs 5ALzHnsLznUFjaYdXIb82LBiqyjC9me9I86TKWQjVw17QLmmfKDcVT5ROGUeuxAhVy8L+A7KkKm3 m4SXYV+9Qs7B/eoBHkIeXV4eWVqUV5ZHFpcWAUmH3AHo1jVhjbFYQsFw5IkCY/VbAqoasOADpurx Bjj2VtYb9vvD+H6+RJiMZB8xl9i/Ix8aMiI19lqZcG5HsdXpslg42e0qLt1SzA2KYvEvHJUIyTC1 atnNecwhD1ZP0tiMDK4sdciL8gLA6epQnO3tmArANII3Op2tLRvWu0pLeAspLXG6QQN0kTAJk5GO NyN2h1PlX9q79yVedTrsVRcN/DCJCd4ZsnkUq/1mNjN1Ppu5Ybcqqi2It2VhP6/PPiLHCmhrRCJ6 VaJ6WYpYdFrcLpmzAFqrFUAD3iI4xgjylk/N48HHeJcp3gUAbMJdg7aEEJ7Grnlja4uzeSOJgAbo 3S6nixx7KtoHyWwuOx20q4D2Bn5m6jx+5iag9diC2VlAC/+metlOdhBgxI11atzvR3BGXpDj7AWh KC6KQtlHKC6444riicuygOM8L3zUZMd2NSAMnfDoqBGbATbjC0yLlQUkm+FeWZDp7C8CdKXEhK1o QROxpmw0g65o6814k9c9xU5P9kyF11uBJ6iOJ6hO/NmEWTflLi52419RPbuX6nBEYz37F/Jn3IBE tMHw/B7dQvfQvyHPZ1n8H/IeulUElwDCX8E/Q1Z0EJfnUxNAocZFM5gaLoQSX8dK9o4vrIYY3LDy 4fqQarXTK8A84dlicgzWo9ewo+swTxxR2f2/pQtuQb6PGgdpR6VaM1v86AI5duQIYPpT7m8MRg/g wlMGa2lGsLEf2lTHwTlcgcx1OgizCq2qNuQ/3ATQQp6rbBt6tpWKBzvaNm2nDOPfz+1h/sUdhJQ+ aGwSRRdWRaYNtYv9+BtiXPy2eBgfEU8Jp8Q38DnxPP6NOItm8R/wDfE2vo//KS7jz0S3TcS2DH7/ bca2BcXFDJ4BUHHh3UYGM3eUDH4nfQWisjSyAmu1EJfvjozgLwLTkl8azL2VhOJTVCv5ta3Eoahc 5efDVWqRvZS76HaoRTZI4Y/hu//BcUiFjJi+7CTW0HzuIWJySzP1Qk23CHp1bglFcp8iF3Bp7tPZ MofoEBxkPvcZknMPZ8od9bRFbe6hEarhyhx+R9B5UKgoc6IGHOGkYMihdTrrOjknx0neTth7/ji7 rrLToTb9ch5bYOnUncyHV16GCHdB+i3CooGFo7TnV0/v943nSYMc9qhu1aWWqiUqZynzlfsqfH4f a4mEq8M14dowa7HZrXbRLth5O2dhwkGl0kCBYq+BdUuVgerZRgOHijQD+1QQYXudgRoICHNbN3fy Wnj0E6it8OC21Q+cQUapUvE/tqsENorrDL83M7s7e8+1OzPec/Y+fGIv2MQbT0WSUig0UgioOA4l leWmcgCXtIiUFlyKQSRUFFpSkQSIEkxzkIjDeFkLgxQqkQNEAiEVBNJQC1CDUVuFiEB23f/NeqGN uhr/8+btjLX6/+8aUe2QgrzcwZPiDQaFjkhh4o6uwyIp+XkoPg6K6oYiuzqipCQlrxNWUGgJ7qOD gr2jzgbFS1YBSdXIP7muy7BwS3KIPBXqoGwcf79MCv4/+YX87B9iD2doSjIBRy7HGXIoe+GwtMBO MhGNUB6PBNeyt3mKkKOv9Xdvn7W2PvCgW4bV7N/UBx/gvPNmZNRU23c37ZqRVVJtM5/bRV04Xf7X jlX35bQt+fnLT2OOrCNb2uevXnEyH1Wj5b8dO7ziVD6ixrB2jLBtDIzvGnMLdHPffoH1FSZu6W7e jFirT/c9LDzsY6zuIvUacuAXdCvncLi5UStLkR0T7AjYZKLwKKsqRMBFi+CTitQniKd6hpHJyjpU Shqh+sHnZOoUvBD18DzuQRzmjlDLkB+9jE9VEAQCARJWGucM6+oYHwfpldsQV8oLbQ0K5m5+efx/ LpoaUZcx5aqQ3dU3U1Wmp1GbcZjoVqnXULJw+YZkdas2VmVu3XlMBqlTBFFmGuebVd7tZIn3vgGd +AS4lEW3DwNdLum1vljLTPczroHkQGogPZgaTI84DmasTsHmzTlaM0w6mglmpWQwFXVIdgIC5z+E ce9toeRlUmy1SZ8OT/bIdASPgWbasRP0qvOg1Wpz1BTw1welfMSERuD9DPgM++znfD7+HSe1FNUh GXaDcL+degrV4t9XCcd99SXhGxSiauMd0LoxbhxPdghVOgTE84diguKNhxMeTdGRGOV1LIckHQsx KJPE6e+vtBI+qA/3ZadpuYpHgL7Gpt1P5VoAiGaLedL/JpXJbLYgS4laRyzjm7MY/btvXuitXy55 XTVbHRwvP3l48UuXE52/KP+1OE8j7f/5qis3lv7kB6newV93KRabzDW++vj5jdMXL3+6/OnLBIXv TFxmoE8IRnqgtxWjAuhR85QpOX567HuxWfEZrT9D5tXaQOsfma25ba27c4Oth8Wi/L74vnRSviBe lK+Lt+WJBp48NyRFYG58AQboh0WadduzKZ5ugB+iIFPUj9RgOJWoVQu480A4LNQW8KYDiXyzC85D Qt4czU8tYKdu8+Rpv7+NrpneUIQJ+Kn+Ybva1mwyO68X8ZrKHEDwiA3PGRuby12B1s/hSPYiwyiN weU4KCARQgPMcPAVOfS35GJxUWJM8ZaojkWTR8exXELHEiPoCBlj6YcPnFq7+lpRax/2VsJR4m7s aJ4yFeaSqEykWTaujClV0V8ZEi0+/czNQu+1erfMcdILe7f8ZfGhrmCNqs7s27p91YIttRxv55UF K7fv/OAJ6o2WoSeev/pYIydwinv58LLZmx8hLMEbOx/f3N4iWWUulX/06G/nbQPXOUeYAlkrgDT0 oe4Epw5TQc0UCPm90NYrhwKBUa/bIxTwj3TB5Rr1hDWth6IhRdGUFgpD44dpmjFpQWcQ1vuRC2wF nCjgJyzwIjfseT10gVqru7HJ1RMIhJA7iIEJwSK1BGm4U7cDhbAaYRiPA3zoIxhH7O44+uZACO5r hwRcaudIJhonixtGSjJicamdbzOtr8/+ijsOZAHe3DzbXj27mxr7sJbDzXw1KVQXkxLTzPNRTNOl M/jM2w+FampCDxm1fILUl2rLC/CixXTymw9I78o3qzqDF1GflTTA+XGCc+hcLbqkR+w+qz9iTavT FVNd+vvpRekl6T+l31UvKF8orEpA7CUgFmHhC0dZiQvHvKEaHApo6Ag0Kk5kBLoxplsDeYaxoURc LOC/61Y5b6vJcxZsKVLrUJrqHYI7e+KxAr44zKl1ccZWhfC9nkGQhB6Nl7oq8CVhvWEc9JhA2IjB QhW9iuI3Wf0mcGbFCsVnDuhYZeV7yAUKZ7NdfZivSgVJ9d9CbjRimcyllTvw6lkb8js+/ufBFUvm 6gmF48Xn9289Nrhm7dqwEyL2LCIhzJZydyh0aejErVx8muYVVGHTu3t+t/dBTvFSdUSHQD0F6G4N qEgUNeLXdUd9RIq1RILZoBZMFCe+Qmjisu7KMfexM5jZ7KPMQtYchwYfgP6GJ88R4xxtiRUmzuo2 oh7wdIx1FuDJ1QzDsBIjsQkmwWbE6eJssVP8qbhS3CCui42IQ7Hz9vPCF07Rjk2sJWxOqO5YOK51 h3+srdRWppY3LGs8EBnJnHNctl1xCAtZiDMcL4RFKeQJegOyyinOCIo5HXF7woYbG6j6WjCRtCWb MclmlzPWBBzZPVSXp2mrr4Av6d5QXjIl81an8rk5jzJcJpxpzDCZI9RJNAXFcAw5qMHhSL7RhV1q 0whuxf13w1rXHGIdpS6I5B3j4B9k1mNkykSnyF9FpuK1YY0ROTfvFty02eG0OylzLZPRcViMFPCb ugclbJDS4rEUC5tZU52ONXeIfGPHcWdSR2lL0oAFAQbXbmQ0omt9ht8YOajiPFl8DyoGUsB2CFYm sRONII8EwegedHDv3N3dA6dH9zx1ZOqMjsZdH6+a16p4eaeQzr9TPqomXlm6bOeu7sUL2ylx+ZLP Xt329cCzez/aseHJnd0RtyrINqm876r24aEX335u7ZuPTANWnpko0+eAlR60Zp+VJr5tBunKUGYz TY1aHU5njwdJHg/yQExwyHaPA9EcpnrsNt7N2RjOYS8CEzH154OyVfVe/69gPDbHiDQdhvCA7sgG mwiZ1rvqsy6iQN+ybZzTKo3IwQJXBZ3uLw0SLaHp8lus1yUoZqY3YdBi58CdEzW8wtkEUOGr8DZw 1XgbiKMmvF5/QNgTeQ/dQDccTA0T8GTrFmS7KZPdxSg+l6RsVP6At7Pb7VuTO7Mv1r2GX0kOUUdt RUcxe9L2XlZciXdrVJNUB8Fmvz8aLExc3N8Yrf8P5VUe3MR1xt9bHV6dq9WxknXLklbWrlayJB/4 EFoSIByJLacGQoxt4pJMMbSxwxGStIUkJQ52iJM6pMNpCFBoCQ2DccZxSKGdQDqTMmHaZkrT6QAz pSE0TOmU6dBpbfd7axsb+let2ae3n3b/8Pt+3+8YGf8TxIg7p1i6tDRCakJpycj41yg6fuNkrCRE XJBVLJXpcC4e1/pyNk0qpzWFh/EfZEs8zln4nOqqO5fnGjiKG8Y3ZUM2mLNcTeR0xZn7AgVA9HYL rISK/qIAleBUgWaZlPYEWIea9luDMvLagYeSRZAGyjQgowEWGMnjgEWiUzJKQ3SYjglEWP83I6AW 3NKFuiAlfIDE8euD4PPhH7k+CPaffMtl4P41LrjTuGCHyQ67lJrdmHe44HEHqTlIzUFq95j+5Xf1 GziwaooKoVSkrVJkG0w+YNs2Y6+yrV5zZf/+K2s6Vgg1n7/9o9/VxE0HNqw/MLDx2QHnu1u2vHt8 8+bjVG/2yModX3yxo+1IeUV1Y3vPZ5/1tBdqvlq7e09He3//WNHThw5955mjR4EXbcCLTsBFFGVx QZaKaLVQJKLkTyMjES1PSDKcgMXsgsVk9mfKjSWwZLhsIpZwECfGNKevWf8V/odwO6k5g3CasCR5 a5g0nYP+30AZOCcJ3tLah9Ifp3+bVrfSpgjizcaYoVQnQK6DnYmHgknNROI5vYbwmaxPAaHpQznO xI8AZ5moH8v6SI5xV7ivFuUSH1FHUfk0dVluj4LR+idA4xqaQMOf8xNJgVUy5yRxxWLJkrDaYTIb zZSWBTtjs9gtaq0mKugAI6UGwEiML3FECFPZcFJNYiQdh6IZlrAlBPUhJGlTd7lrBnmhFpEQVhe+ y2GwV4Z0sqtOpa+KW56heaiiPMZPt7eqUnVmzmDrsoMrz+x/5nT5g9V8/4rvv/p4tdvFGp2x7Oc4 Y6/Yu3rNO+88VbsuG6LOr1u/6hcdu0Zf7z5+7eTGwtupfInFxToNNpz9Urj0af+p7dsGZVmEPl+A +ceqdmSCNJeWdcxJzkCfRFrrh5gDTlBjbshgKC72fvsD7EcuMmZ1YFmVEJGHycJTlkdBqu2eO2pJ ZFahsereRdVeqKqtJ9doX8OsmnpygTsEmaUuqU+ACqfRz+U5c2m817yPpUzmAf1ukyqmi4ZfCr9n Vks0jcKqAtghq5vhousTBm4/k2D8KT/lV6sTftxcAA9TRJcO41rZlvoBTWeyxkTInbU1u4ozB0+7 hvGqSa5QUEGIAkijzgImhuxTIHD5m4p5aZmEht8TNLFe3uKzxuARj9scMJZi1sPEsCnIlOIJoSLd BpkijNCCp7gYejbpsWdUJk7o3mPDL4Lfc/2xIB186YENTYSz9yTr6498+tzYr5sSubzQJOZmU9QS Qt3bGxuluZ0D/vhS5W6e0farna1vjj2aExN1OUGqQ3CWLELqM+ofIgEl8fuyWMmCeHhmJ6qkh6wL 3Q8n5ksFa4Frc7clCtIdgRGRICSSmKIkvWWYOiRzpj7TgIm6bMKmOGsyWVifnrWG4+QnM89nBZ6P C76wkNCplJJWm1Ukz6ejpGKbUuK4pVaOs1l9xVa2xEtKCwIosCXwRkB1MYADcU8g4PX4Sjxud0IQ /B633eNxW1nWT0ng9qVIOKzX0Qj7RSYZSFLJpK5YSvBuG+8uptwj+DEItbNlu8B7ZEaXRyxmPAHP Fc8tjxosTuL9MopnJd46gmcjdvzsIKvPQ6g7K1vgWYbFiG1g/8aOs2oWnh1MzVsLeCAkAd4fGglA uDmxHSUCrGQAAooWUOE8EeNujRIAupMusft7kAPoSRnGlr+3dKVufzyz8H/dKm8XgeCTC4aqBYdU 90UIPBncQvi+H1SqsEr1wuilrgMEEWPnyToHr7tDvvERvGuOUv6ERI39/dcDV3H32IWpiKG64bTZ nP/+5d3I0U19c3QvBDW0DDC0HDDkRTGUwU/JH70nHBPP688Zfq/X9Ak94t7g7uiA+LOo9oXI5ug6 cYPUp++z90b6ovQSy5OWzfpOSyfbae20FS0KPhJaGFksvmLWZJjaYE2oJpoXasV5zEMWWpcqDnpD nqhH8KTCjCDSz1lORz5JqeYHF0Y3Bl8J9pTtCB4ODgXpBA0hUUTIx1G0RsTYR5cFzapwqTkTjPni PBfjab/Pn85kOJri6HCUMQaMKWPe2GBsMz5tLDIO45fluBRFrIWlGPYN9ix7kb3C3mK1rLs8Vgox EVkQdQtMXXF20XMTmCCet6vukdG6egIJEg+JJ4N+KaFHCTlKzHFW3x8HJ1gjkrDa9QYbL0YFuyTh qD4s4YQ1LqGIgZcwmvYWhDG6urpa4C/KTjVZkXrFAtxttC2UqapUCCUEEUjZwRajLtJfyrL33OGX ny8cfmL0NXJ/DsfbGnJz33p2bBD/pHHT7OX7esd+0zTR7qHnd7Wl9rQ29baTllOVYW9HVcPW/3AL OqrlTbPhEDaPX1Y/rD6OZqHL8ibJjlMojxqQSsM5uKXOJ+2ruNXJTvs6rtN1yqmv8laWLeIWVTY7 mys6nN+q2OrdmdJn00zQU4KRijZzzqpMMOxnTEhlNYRPidZolaFX7Y+KVSo1JerMPL0yxPPuGg/P pAPpVDqfVqeLq7tnNGGCqUdHyfHnyclPnL4i4ISolR4QLQe6RotPGL6x+ESk8XFwZV7woKwdEaPp G/96iOOcXhc36d6WE6qGSZ+0VVMxIqZEBfKBElJUd9J1EW1Oqioqyq1QUV0i5+i0sU5Ks3T9W08s lfkHYl5sObX2WIF1WDnx0Qurm1sXtG7LbP2y+6I6UEta8lXA7fI0zVkuBqT6tvmP9Z8e+2trm4Nj nakVLWHPgmNvLjv2XazqBf7eB7O3EWbPB1RnlEOv67cZXrVus22zv+boC/QFe0LbYz3xPsFoKMWx YNwLdvOKrNsZGwpRD9JOH+FbgzuO3G4f8jlpitxXaOJYo6FgbtgkE/BznM/vpEW/Tkf5aSrCMwxm mCBDMe5kwu/HQeg2hYqlD3E1pqcT4PQwEPGHIVCW/3JerbFxXFX43ruzL8/aMzuzu57ZmTuzr5nx emZ3XXvX2TTb7JCFWE1J7EaCJsDGQZUikVpyXfqnFaEpCCJKRFoJxCOkKT9ACAT50SpxVFBLlaoF RBPUtKVqJQfUuKSSSaiiiIh4w70zazt2HqqQVtdzzozH3vOd833fobsJWGYyso6sCrxZqGYGe5J9 XC8X41iOCZmGZQwYRYMJiUJCQKGsMdhTKMNMMl+GBmeXYU7Qy6A7IYPUQnk7H9kBb5yPfmqbCG7h FSb0poK6JsubDDzmUeCpvcfK40X8yLce/EanQTOH4V17T7blwqbCwfs7p7tDsaM+uXfrVx598uMv bKJT8dQfdv1o2z07J5x7yTzsIHhUCB41KLjpSX069EQoEGf7bEHAbE7Va/k8VgPRENGZ5zmtSX+6 Dic3Q59HRBUT6X5bFHG6WqYNju6yazVctkpgkB9Eg7Zp4pI+C6fcRhpBk80XzHQNmIYGAJtGbCRn ciq8qF5XkfqpgAmicCL6XPRM9Fz0UjQYrZlmGZT4EirNEkVMGUaBiGZ0u1gRLgqXhIAgj26ZlrrI LSw2iIBdpkrGt2cWCLV12YzEDSJz9EPYa4EslO2zjeWLLqN5oW0v3VjOk4Frw3i2O0TxJRyWUYov LaUrz3Qz8HPo27Ts175MEZnxOCzwVZpZ/AUsSb4cSajW0T0d67ywoladOZr5S+e+Se/Ov+g5SVA6 SlB6lKBUBf92d+0OQi4as3keR7OKVsvlsDJS4ob0ITRkV6u4RGRklMqIICfteBzLpgOKfBEVbcPA Ti5vylVgFEwAZIJKVEbRSNUoGSZweGfCCTi03k6hkAfQ5HMmUDIKmlCeU854PiSobI9neAj4/fzT /CWe4eXalZN0jpYlhRSf7+JBJqhBgCDhChZrqw9uRKF9CxAgBWG1KfAhWHdnDH4KM14JlSUMOFYL HKGFX9y3GoRVfqG359YQEAweIhhMEwxa8BU3Jvws9dvK86mXKoxvLNleu+sn0xnPJ/IYYjuLcSaL 086wlwIVWCmOVCrDI9hpbKIpnmvqTdS0W83mphZu+K6TDdld0+lbTjZV7DpO2/DeQ4z5gF0YGDAK 2N5Qo6kWqMO6Xa3Xa1W8IZ/TAIRRedh0HDtjpg3Ttn2H2diwoYfYzxGtUNUKLVfVq0dbx1roUGuu hVqz6EVX+YygZbNxbQi56GkUGEdnEOLQJJpGAfQ79CL4NNgC3yZgE3AJztQqENDthrcxUXwb1Fd6 DoKe8a6hWKbM9ioCba+h09sFd/qtte/w+qX1JSKQFUJUUS7RTLnkqBDaOtEnkoAc1JrshNn4yK26 ilx0l5d49qbMWnP6zcU3veHuvO81SZXa0Ktev6HSw1pa1q/STHVy6RlZfxiNdrTVBtUb+8/CF5au r6WW7pOeO0/s6gXSczp4xy1VmHIwH8v0ZhKZZEWtaBuDI7GhxFCyqTa1bcFWzE24yfvUcTyuJaOc 1zmxUT4W4whPyLoXq6NAVXWAZV85WcITvnJKAo2t5Gg8mRTiWNJNWTBlCSEzwpnRaISuLPFxHvJy 5uCctKyYFHUCNkV94ZNAeSu01kx3dolpu2n0jD/Ii1Oe4GU65zxL+H16MhtXirVSTDqrvyYu7xip mwk+dr/29cAT4uOJ76CDgUPiU4n/pCJRxCbYZOAn6Ej4V+EP+fOJ86kQw+/hj/PHE8xwxMzka8SO Z2RdfU+SsB7mBJZlMjoSDCYq9WsQArc33gRujG+eA3A/+XvpAW5PnxaJhOmNML2xPwzDsnXkJHyr S45E8Btb+cUPtnUXMhqQApLikXoQi3cro53jUyiUTCXIGQ9yxIpwobAY6C9BPkSMSQoJJd9K0NGz B7t2m5TUd3xxnxIDqdSI567XVDZw7INnJ09MURqEW3+4Zfu9677YOUEbFu3xi7uY/vG5Bx6Eo177 fjw2NqB97340v1xmCPYTRtxBqpwFU26dmIYaNQ1Ukkj1FGIa3ut6hBr1CMhkFSr7XBRG00RdNFGQ cz9/zCuO777m20QtSFkWbtSEm5SCNA0Zzdupsv/V4FuoTCn+2m76v7/+utc655daBm6jo9jZtaZt IJDI93mZfJ86sty7/4HnNbQZbKm/DM6AN+Hf1L/iK+AKvIJ7DGBhSzPrY+oD6i+1k9pZcBaexR/B f+LeHRqMeaMkHqW2Uye2syhynCDimO6RNw9yEzmUK5q5nGFiveLRNzs8Mjo8XBvFFTboxZERJhIJ MphVkv7LJMhJuoSkYkKSkgmslAd8RbEnbGQXLdsesHB59vp3XRVDkFEx1iBKQHpqdQDI+pggKTCL sMtqhqnrmqZiE9J4i6oq9XUokDQVVK5Yo2alwrIxRjRjEdOq17Gm4XWjmuWC01C3Jq1p65j1khW0 XKtYtVyhxlmHrDPWOesSyc2iv7tJrMNJiA7B0xBByKgqgxBDbPtjbkrMBJgEo42Lp8U58aLIiPL6 V7oebiu1CmmZX5Di6yv+pz1DwrZtz0j8fJpMip+lhsJzEp6pazSp0/CCBS9HOudAsGwf2HfqQKQs 2cF9/Clbur14zPx/CjTjMdcjM20wA/PwJllYlg0Ib6cc8Tx6dnfn9/xhb7T+RM+xGj3fgBvh+jc8 1dhMz86fNSWtHxbgJJpby3WLDjq7WjACH1HuI+sF8yTpYgdOu6kIglFVVtFrCLIwpCgwpTBs3Guy vqLQ1xcnE2vYfjMRW1F0BgZsBxs9jPdIeCQQDjMBYmoSXkzcfn9/ggxzQaNxLjuCs1kN44KCoAA1 VUmQboIKEG3TMDSzUCAy8/hxJWGSyVfJpdsD2Z4eGMGqBmeh4yoAOK5R45xxZ9KZdg45c07ISZdR QBMU+rgoTIrT4iHxkshwIhTl0t0PSbPdlW2GOn/e39oomc77ctToylGDX1rg1h8o28QSuByMJAaa MBFXycErTbqB7SStIn1Ctbqj7WjPgPZMNg9v3wxrKCrPoKnFHxz2QabnZs9KvI+mDlN28ll3jOm/ ds9q1P/7YeDVFaVDABClA8xvQC+Q4TX3+h+5V2UkzKfmpav8VeFy6rIcei31Lv+u8HbqHekCf0EI p/n/cV7tsU3cd/z3+/mRu8SOz2ffyz7f+Xm28w6Jk/BocsASOmAFCl2TgEe2Tu0/aCESHQ+tAlGg pJSGiaG14rkCGg9RaNJuBsZDXSVK2USnilaCbXRThhhaAFXAaLvY+/7OAQprtWln+76/x53t+z4+ 388nwAuiKNvP8F947vhs29ktrj1kv2M/u8f1gfMDhnmRvOLYyKxy9fv6hZ+RrQ6m2dnMNLCTXBO4 Br5BnCAzFaTSVcsl+IRYK08kJb/xnOIG+UHfoHBEPCUfU5hDnje5vfwbvt3CHvGwfEBhnvbNEbPy Tm6Lb7O4TX5dYdp97UK7OF2eqXR7urkneSYtT/A0+ZqF8fITnulcO8+UOUuZoDPIpD1JX1IocQoK tjM+j9uOSiRow95Eqa08gRCHwqgO7UIOtNSfKFGGAlNXWJACojA7QrsrTQFpvDQeKrbPOrL0gEaZ hZx4RyxVvW18rnBnCCyXK9wd4uU2EaxZ7g+2ibIYapPpic0VPh0C2Qtb16h15Aof35+X8XT+LrXs mPVRC1RAoPcV7S2zHGiBEHbzrT4NTjhXuDrkU9rcY5ZQywltrjEr5wqfAZvwteJyOLmidFT5Hwcq mi7Qqn4CXR95OQQpyJc0kliUCH6Y8Ha0/kb/ufw5nDnXf73/qesn3voSl+w9cZ107Mv/ZRfuwuXY gzt35f+6//e4I3/2j9fyn+B2mltDgCTzAUliqBrdNGV7wB4s0ZDuC/J6IpgJtgePVpZW8Mlc4brJ PR9YEyBJpoLZHNiik3v8s3KMf34936wHfVrkm1UW24whLcF74m1xEo/LQDrTCY+K1UBtNZBPTqm5 s/x+8RcJwx1oHMjiT1lkVXjcBN/HgffDqcxDmX4XCJC2h0TIfyOkLS2or6UF932D7LxXwCXwiiUi 44BXNRqxCD7yqN4ExnH10KVp42bMnvDd/OfYld0948Dq/AX8aX7JwxX9u/45qxMtAd+8uctan9lB /d4Jfj8Jfq9GzfgXR1Gk8J75RDjSWumX5Nb5mWfrn6+3lVROqJ9e3x3orF8SXlK1LLMxs7fiQP15 44L+UfiycaH6huEF4l7frndEllWt1V+u+qn+hn6w6v3w2ciVSrd2vHAXscjztTFqeChGEx/ESA9X VEac0eqqmF6DmgwFJIJMqpFWW0PdXkM9XlPDyOmYUVFBNYN+jKxA1WSX6UbwIBrXkFCRgY0czr6z Uh1QoSPgFOxF8ezoruiH0ZtRe5QyEo/X5HAtd5MjnNIyfdH9mGf7IOrZvuHscJaqDej7d8Zk58gk KjWhFGiwR4rKkx9vFf7/rkRa0Iwj/NwZR+JzujsHdVf4WOEWeP7W25WujKgDQgw2huuh2luKB2rp AqaNKKv/RswfSxRRlO7xAGIkEw33U+apIvrv+krG/Gv7J2u3da/aaNLZ4m0He/O3//ajoTn7l+fP kdL89IcT58wL3Tszrds+o6tYOpmZN3tRy7zXgAEchZ7gh57wLXTJrHisYWZwVkO2Yam4Tnwp0B98 ZfzrU0q/He6YTGhK7J+8b8oF6Yp0WyoJ0of0yU25wp/Nrkoz/djEgOxx+BFuLh9XF7PVNHrcyOYt U4xJkxq9iallG+w1G5KNichUmx0KP8KWG0xPc2Kh1qsRLdDhT5j1RswwJ/emV6YH0jvTh9OOtNK+ /RjWkXwvot8ZHoFWbRXy6CgEEw7K4Wh4geyN0ADSj9XFrTHAOALvYwrgOFMUAUJR7RhGLOoU/BqR REm03B1NFrcyxQslqoOo65PWy1q0bS72Ul7Cjt1rNuypmdnz7MHJT3dd+e2lF6lbizvHd+z4dUd7 3Wt/WLDgo0NH7K0qjc7HWkAOzls38P1xTzboXjWUfPl7m87119GtqzpsLfj5jkVTntOEQOzxx9eu OUmZ2QDU9SQLT181KzysK8NB2UVVvSkWC6mEcWQwlJ1PEZtARykxHqgfgTJScrj3Vxzn1eArYGiG ObVW7VHPq3aP2qbOUheqi6GaDquXVUb9e4JSaqowb1kMeRgKhMIfflhLPTyjiurRFI4UNWTmwYBs ukifbfSf9Hwxv4+6x3aIuo9qqgeZmf8TzWq8NN9vWVB6aC7k40/guetw9DhSAXr0wt1BnVOPwTAI vTa6NDjsvKJe0z8nt523g3f1L8NsGbE7cbBMXxvc6nTyclE7CZxAhAZFEGQlxFfUFWlrNa5Oo+rq OhSq8JZaEOZOs253KRvypmN0Ps1oiNLsCKXrAJliRjotG3ypwXtJCJhENKJh3AuxIR40Cy1ENhQY pwQ0hpnFLmR72ZXsAOtglfqvME8gnmO8sziiNOMB5fw/BIWFP31ZC1ZacNHh4HELRpofMEavX7TA 4xEmaRv9xy8Xv7limhYod2lF3rj15Oq5/c9Z6qK4YG8dnfLWzR+cWUZOQsTcpZZ+mLLh3Zk7nrFW inQSI2BU9j0QqRQ5bs7tDfQGe9Xe0HpxnXTacdp/VWR7uB5vD9/js58nmBM5yRRNyS6ToKQpekhL paUm0iTWSx2kQ5wsdeH5Yqe0XtonnSXvixclv9tHw+HlZnOYy/g5zucPuf1CJElXtXg4vjhOUJyL z46fjn8Yd8Q3peLxZCoUSSGX07qE9bA6SzzsKfYye4MtQFw2OVjW6Qi5HPZwgF7iDy0M4VBGCYUC SiisyIiIUjiX/8JsFOy2sN9ht2uC3w+QkUJIkxW/LCsEExvWZAnGErERbNMEEa4QiSHlyI9NTTYQ xjbBsNmZpBEJ0Hc47DPcTsPtIvgkrkIIAC2LFCjPrDnuvIJ1BStmRUYxG5salVW1MIjFGxXTSDYq hulJ6amFqZWpgdTO1PnUjRSTOk6WQ8+XQA5JItwmmrXwgVtFM5DxiDdEIuZw59vENDLQoJcPOsLC Cfg5P7LBT9txtSnofnzaj/0G58DIMcsx4DjvsDtOwG4ateN58Od+uNaChBFAhesKNxzgRitH+yht lK8o3GhfQB6xSGRfdhh2Ze46up/OI0U1BU12ZHTkJUdNJfMC9x5Y+cGAWjAgpOD7EHM/rf9NeLUA N3Fd0fd29V/ZWkmrXe1KlrQr62PJSJb8AWKKN79SSlwoJRA8FcxgQoFAjZNS6tASe0qnkKaB4VsS UjwBpuUz/IxtGWidMDaYOpPAlBTicYozMXhCow6lJukQf/reSjK227Qz2vXu2zez63vPueecfySi COXj72v/70JUYcKcU36kwyGkw61EPSFwAitkFHfOKSGj0G2AGP38DKHjkqP3TrN0VpFRCIOJhOgl SS85KW9ZrcVW66Q18sbmv3+2+aduhSjT8LzqqPm04bO1nWnm4AU3WTH0rmpmliNDEhkdukb+dRxn qhFnViLOxOH+NiCNDjRx7gopOToglyJX3yJBvVcf5718fJV3VVxTZVnCLs2rElU6cbm0Szosqb4U /+UlNKLeaxN5ryprnEszpkzw4PucvLCYl+cR8wRRCsfQShMdgZEkcVGm4pFILJ4XjoOsfSvN2Dfe eo44BFi8x8KyVqQoFnMoH+8pDoS9gUC+Ny/klSRIS2ZA8vq41xrzh/P94ZDHHxJEi8XqF3gsP17/ vDiMJ4n2ZgRwv5lGV7JJ9APLXMs2C2nhi8dPxsrUIDbbgzh7pX03hg7+odOMrJaP6/mDCQj4j5Gp mzgzv36nMkBBLfJwPEKIDyGkCdjN9mkIFIlatP7fbBrMoCHrzuDkBWLnmOTx7p6RbXF8N4BP34OP weL5GB938G2coEeeykogvEBEsvAYCcCPxqCCsAJGhuFzqgFgBt+U/WYq9z4AcQop/30I4zrKQOss AObraUORYZ6BNPCW54/YM4qDZaYiq9hgTLmtY/9VNq4seE/JIX3pPKLa8bAdv1x9144+b8IXzJQ9 k7+Apix6Qz6sQPuy7x7Kvnvym9VjMmTOVBSS3QpvPCN9+O9J9eOoHPaHijdAE247cgELyXoQBGVw mfzdo9pD7qMR0q/1uctVP7JuEH7sqGd+IexgdgvHtI3MIeFEtFl7Ifc0c1Zoc3XnDsZsBsjDECTf MO8SiI2RVyNvRo7mHot0xj6M3Y7pgig7nJAFX1T0+SRRClryrFxBmQjKCiBZbNQXliVhn1wFtwSB oVgkKb0ICunCdYVkYUG50Rhk9tNinhY/yAEejyjnsBUmEUbFCnGuuFQ8IJ4U28Vbok4UpnHbikQN fl6jOaBp19zSqDT81ND5RxSA4crhO9gc1MJwunSpilQKATUVTaSwUxhU4knW1U43T58E5AyG8ZRr B1pkkUpG74FSdPCjg00WXUSXTiCL0axDWym0lUFbzwMX2mIdfQc/QeY4IZZqMg1C1hcHDkmryTiK qYpvziKH9CvPbIq7mEo+13p179G+G49tmVtfv+y0R09zhtzq/fMOnFmH4d5Zvnl26w++s+HFteer 697YV/Nyi4ne8vSK6Qa7xWwwCaG3qoevK3nkbTM9t3z+MysXLcWJdgrq/SKEOicIwvzT2AeckCk6 qngAKcfJ4nsrH7XxPGuTnC4tCSmP35igkrC62S/qPSJyvtVyiHQCQGr1VJ5oQpUnNELIuwAYPTZG NukrTEwNc4shGb5gyevj24Gb0K9kDCVhzMAah+YR32/vxx1Ax/+YKqjCxkwz5AWr9bCIKsqfFVwY XB48Ih3Ob4Vt1AVXS6BD3a27rurV9avv6sysKgbj6m9QT8K51GzXQvisOqFNUMvhCvUaaj2x0bDR Vefe6jrn/oPU7GMh0q8zFB1EyfK0i1WSJWpe7WJoRj0CNgbgFOOdFCxhSTrr4IbB0G9uJKFm5Mvm 3p2dj5Ik+dueHTt68KEaGP7zpZEHFztG7l06jOeTaiYeBUNdBz7++AA6ENePoe7MQcwMgXvNooEy VdhQFJQL0cVlW6/vo0Cfu0/8m+9uQJtvC7BPeSp9lYFnPQlfVWC1aTW/yreVN7LJ0fvyS1ZmsXWh 7QXfisAXgloj8LRNKKALLD7hVfpNeo99t3DYdhjt9SLrbeIZBwSkLpd3culcCbaYxQIt1aTSON/m RC+VW65b3OiG293vuAm3UMiIftzkRj80+d3+7X7Sz4c7xvUZsa1SSZK1lYOozylMtVR/OkFiqnHT ca8zERJ7baQXEKlCNkRqxodIhQnKOoNJA0pLAMqKnXicQc5q5gjNyV3nL/7l6LLu+TbazD1/sKt7 5CtIdb9L5jgxS/7oFjjHrPq7ew9e/9Y8hjOHn3gBkpe7oRFzYROq9jHEBReq9ycts0MrQwTW7hMo yqihOqrIt6Rz2fES7YhyDoedk1wGVgrqEwZEg6agiOqN6OCRRMYFjBSjRRYUcm69px5CE4RQKPSJ 9chjJ+FrTeFQfbpI9Be1mfoMz0CijKmAxDnVj36DmAdfH1ViRXNOsRkSNOXqLDo8Yh7xog2EkBXz MAEc5/zI/3h1+fzYjBqTXW9pOtaUlKHCclkoW8dBWUWkR8yOT168Vld37aXePcr9upu799y8uWf3 TdXAV2vxbPldV13fhp/cerkL9qSR3Njb24iRTIB6VNsoQjIPPOCqvMrA7rMRceIJYj5RTVwiLln/ xPdYevhex6f22+6HbA7vDDlLiGmubzuecX/fUeWucaxxb3K85tjn3OdqVZvWs+ecHWSH5Yrzikuj 6zQLHg/KAuY8kdOqRDNlXCCUNwK4DjEoCW/LnOQph+WNDKxh2pkP0ChSMbwYOj4OopWplOLD+xVN QAXGBik1YcicYRkNGglnHYzbRSRHPx8b9cjGQJGdAMwxZAKtglutasrQ79nbR5a8/7g1l7bTRQ8a bo7cgqau96FhEf/hzp3XBfjWwcszi0282UzHF0HHlVY0Of7Z8KsTx3+N3ckN5GSrEDJLQLfsk43z 1PXqnxsbYo3GM8az4Yvh62EDpzPpjV00LelLIiAGkRVVtQAgRZCBSEJZFiBCbn5QAr5EgZgHgMXD R6bYNXqdQUJYlA1loBB6hA8UaO6Wc6I22bbOdtWmsvGl69vgeyBtdiqR38EYvaN4yBnoumK4X1FL MMH/JMbbkSfr5NxQ2IEaWugGYUeBG4IwDDc0QIRAcZLxy85ThfscqzyUAgoQbZm9RBQqc3S4Bp+7 W/C55fjrG35ZbLMzOuvelT/cALcqgzZneFbW+RFtGI+vrN7P6liLhSO5NU+/otguhMyfjWxSbULI DIBi6JJj/2a87GObOO84/jxn+178ej6f7Tvb8Z3vciF27NiJ7SQkJr4si7OydqFdETBiXgJhIoBK BF0l2ops3RR1GxsIqqqtqkXq2n8QGktgCrAp+4NOazvEJBZpdC9hqH9MGqGAMlYtJN7z3OWNMFAd 5X53T568OM/v+/1+fl38QZ74a+yadiv2mTYbm6km98UPpHald2WPuF6JD2Z/HB/Kvhs/kT0dH8le jLoJGrtBn2EQjM1GMwoBonUNgswGZXSW7ujJhphsr4uBkzUU3UaQkIS1VTKU7XaWGWHOMhYP08Ns Z37BXGVsTChfHxtSj6sj6lnVOqFeVW+od1SrKuYSOx9qVsMtCs+w0+gwMAAWP8OWiiGUnX7YMcqr ovISCFdmQKgyM5qgG8crX4xGaTCOnpJ0Bpe4M4sXU4E0ir2WFS+TXGB+0TK8POUm1IXjCuLWz2MX IfI5Ltu40jos3zWzr1o42PvMbXx7d/1LawLDk2dmZ89MDn9y7NjHHx879gnx+7cNx7jw/FeS22oR Fwvw6acSHQ8uQHj+PATzXz/1hysnT125grSwEWnhANJCC9ykp94KzcqEFfrhbvJF8jg8RYzAnxNn 4Rhhf5/8gDpnO0/9jvozNRWiQrQ3aPi2h5d4gu8VeD4oKN542gCeZG8mmUxnlDhrN/3eBV29jMtl ZxTW5FeH1rvAry2N+FnNpxvy+cYGpQXK8UjMGq+tRcfdAqwUa6cZWZwSIMqJ93RHK4jJDROZqxki Mw7/Nba2e+ei65fNgawwt2j5+GPa+1jDX+3+T/iSoTo2FLZRpBa2iRIMURFTd0h4qB24pYQgKzPn ZafEm4iDZjJ80F6cBIFlEF3Spwmr1CPri/jz3IaTW/te790miaI0/znOiG2vvdjbkd6/3Rh9jPPf bsgXwc/spu6un/bM/WdJpJatR1LyS3O3FhdMHsIa/Q0684DNCyyIU4/qCUVsFHXxOXGXeFj8vkj5 XOxmHtEq6WQ222yKMxAR3/AjWrV8SIzDU7+KkC6nHcBLcDv6fgING26r1Sb7e3jIi1XPHl2e49g5 4ywKxfvTq8a5ZTdDIvCred8q54ot/geI468chevxG58TjJFr/b+j4ZBk816/Pv/sg3sr/AgRC3b2 CfTOTqJuzhOnLoB45bdjAVcxPo4q7zSq3sM5it/2feAjLudggk9o9fFErja/trqorYsXcwP8gOrY 44Oqr8lH1PE98eva9dwt7VZuVpvN0a1aa26geiB/mj+tktV5VQWmXTmWvCqCm/sckKAk4V/qZIu4 6iwiTKlXlSRFVSIqSGUNVWQypVwmk80pqVze6zB+kDttd7sddsUb9huTgkeQBEIQ3uIFwc8rYd6X rMHr3fF4rxaP12hKUqvWqqvlfI7P53Mq7+N8MlB5AFTgy1fzNhUqbZGIvy1M1rQls22pVDJJONo4 L6DbIGHn8ajIvKBC9W2temP+IhwBGlpxHcwN5Qg5l8ntyFlyWHVVzT6UcchlDzJDDMEyMpNBN9hv SUZsugTfBUNAgLsXDLVgghe+nZ6ZRgVhagHNg9OmIllkrqgYqDpsra/r7EW68VX+NBYtFH3jqEaa zSo2mjWYMuooX1sEdfi1BQ7bXr087K4X6myvspcFQC+p9W4aaXfl4yPCfvxepOZHtlNutoDbdCUF qogCeVq7WLmHJtb7ps4Hyxhd0A60a8PCri/GNDEnmzYwCDCE10Hv6hEn64ULdwsSUCFcZQcQ/nrF wPMh7K8zpODCstg5Pw5/thPfzd/Bq23zb8LvzP9wxfjzX5jE4sD387fntyxKBh5CarmE1MIjtQig rOf6/If8r/lRgDo3Y+5BpLMZUw4n+N/wehUBILgBUPaybA87wVpYUVypdSzzJ2j8sfo+8bC672F1 L+LvSs+CwI/+1gnEFSWC1AueZk+Le62n1VPwrPPonk5PF8PVOJuc58KjSesa2ASJjZE+qi9ymDoc sTVRjZEuqiuykbJl6OZ1hvamWmFrqb21dV270uz34KWozMEN3B+5G9wdzgo4ltM5C1dyc5zHrfg1 yQg7oLAKoZSiiiJFFa0pYy5m2SyRLaWz2UxaaSrpeLF/qhN2loqdnXpRSaXJaE19qrYqQkIq0ay3 gRKZiFlCMYaxUM1NTZrmt7vccjCgS/lMYChABB7UVEXlNTX4uWaohqh50A7ScrFddwWKoH2i/Wq7 pV3sTpwx//uwzvDamXJdYamg08BaMwkGCQ9LDXMltxY8JvGe+FQe/L+BKNfGBdHutNocWty6RoI2 UrQHJVhrS0hQcIZwQKKEZAs4JFFMlssoKcMLKuqwA3vlNrCiT6ryKYrNTwGsXFtkIzhomAKF/TvU To6bFaI6iiowLKDs8+NUDRpT1nK2qkaoLmequjpkVwvwn/v2d/TFWg61bm3q7sZd+M43svV7OkrG bU9DKrmu01i+iS/mDkvfxkNdpVJX29PfmjuPO5V4U3++q3/umnF/onNTVXy3+bAMy6iD96MO3oQ6 uAXu15snyUmauExepon36FFylLYMUkMUsYvaTe8OW94Jv08SL0tj8BxhiUgDEgGglSCiSIsmc/kl P+EviX6/ICrcauYyo8QN3NBdWkgTk7lYoLEasQq8XPmSCV6NbS0kvAhvABnu0n1VMSuFGIzjvHbG LoemRCjiIGAN/DqeGUH4JWL2Wg77BfIyG29uBpn8lyGtL8FdfDhioymapAkyYkNdFaarTPZKGOy1 2FGjEo8a5O+/DPNmDw0i8EKfZQQYTQvTzyMt8HCrPIJfmzb/ZMuOnpatxqH/A/tU6XsHvnlkcCV9 LTTE0S1fjUd/9NTc58v0teXlzh/M3V3VBQQ4UZmyFlAXOEAQfk1v4QLWAB8MWD6CHzkmib/Y/kZN Osh91F4v0U/0W/fSe+0Drv3eft+eIO2PWTwxxuJgKGcMYE14xKJR3UGj6i5//iyALMiAHQjNxolh XeBipI62kTra8wI5QV4lb5B3SBs5Dm+OCchCFtkZhdP0XHkQEy1K6yL2DWPQcSwNOgE06PCVmXMs 7+aDFys3UWTfHHNFvdHlmaaMYxBLV3cEeDZc5PHFO165j0AmWnTw6ELb0YXCF7R+S69CNEbxDg59 8X+MVw1sE+cZ/r4752yff8734/NvfHc+O7ZxYifEIU7PJCakjAkIgy0DWlI0RLsC2wIUOq2wwTSJ n/IzfvpDBEyZCkUlGWFARsqgMMav2i1sjZDYtAIVZZO6bOmEtqqtnX3fnUOyrNUW6z77u/tkOe/z Pu/zPGgRBdbTKOCFFxgBn7ic59AHmkZGyoIXgmSkHEwaNmDsbxEUgBoGdRlQOxmYx8UlU644dOly 8W+Qu3wJ8m33urru4Qv2XiwOQ/bCRcgWh3/1k/fuHDp49w7CpgplV8zQKKiBVfmmGpppiKGrrmoe bCPaHcsgwoRa6VgL109ak7L9mrpI3zbftv4hdrvmAfUBbfGRleR68w6yk+whKTGo09KXLvf5guVh 0VAZG3f9PyRlWjhdUhPoSKQZzR3UUKM604qNTihwn8kMJC1KVSiMBVr8tZXAKYeY8rnlS8o7yk3l vslP7RoLsrrtwlF2DkJwKKeH2M/LsF/MuAnh9mTcXn0WoV6FUE/aHTLEqNeM/OnnMfUR5jriqGkM kqGfjoGIfSGjxkEDJ83qWbfh988VC+fv7XhHZ1THmMshD727v3NwsPPVQXJp55OL1w6s6SuOnClS mE4oznpMmm5olu8ZuLl7z80BhN0mhN0xhJ0K0nD2myA58s+TTEMCN1+WaTgOjgaOR8n5YIl/GfiO f4XyHNjgfz71I7DTvznVWXGw8tXUGxU9la+n2MMqPJDolrsTpOHtnaAMPrL3xvy1ua+XRq8xaufj UTtq3IE/VuXVOGyynVVKkLZaNIKKKWBf2ByBPqtP3kRDhr5LD9Mk7a+ZpGySdktd0gnJNCDdlYYl UvJVT9o0BurqOUMYUvSGxioarwjUQq5JN9MTYP1fk3Q8sH4BnB35K0gjIxsVKhERT8aFZD9CNjEB WTwXYN0jKZ0IK6WTLlI7mR8HLNlzBY/KVat0V7oKo/n29vfPFQuQfOvu9sH9+wfxRdzoxAh+emUU UfjJGQj7fjFSnLVnYGDPnps3kWJ2I8V8gvwuSIJP8sIGJ6y0zqVXcN/jtnGvUId4s5628jbpeilZ BdxnieMoiOTz1lJgSkbxibnx1kg8Ho2EkzanYLchTMrMDsgDwemiI1ENJCm6yYUED+UkHJcCNGMe NhNmfxUQ5AijfkXdpO5Wu9RhlVJ9lYVdY6LX6nrQjiRvjhFqECqFHAIF42I4roaGL6baf/OOLcHT xwtOkQuOWqEStXDhwxWxCkOylM8nGEEcfu3xWT/08bSTVzO++gMX4FrdX3875PdJbx/AK7l08KW2 p/28z8yr/oXdxYyOAMd6iHOjXntg5A5ZRFxqgR/ltwpNwWkENxssAstbeuSe+p9m3+FvNL/H3xJv Nf6x+UP+fuYvzZ/xDzMfN3M2nhLLGq3NEu8W3Y2B5u3hlzO/ZGwL+Ceyy7MrtBeyP9C2ZbdpR4ST Ar1L65OIeZZkQq2oyU/NZfxexml22xtAZnK1akpNYZx2kgYk69OmTlVYZTrdD+tOk3IKpvrhK/lg xRRFAZq5rUGZG1oS6giRIf+Mmq+pWsKt5LEWikj18os6EjDhe3y6maQqaMX2VIlYSOCamiAGcc5D mBxyFe7rY7NQGAIYyXa0FNiGNCYYgvGRefboyHINuivJ1jdzcjDKRz2NbglogQYJ1sto4ZrRVmzy SsDjbZz6WHkOGRa/lstKUyQgTGN1U4wtkrFAQ790IzMK/2lNyNDBcyN/Bh7E0RZEzkahHnH0VFjM BbNj/ESZcnW77pOzSEmtKBxoAlqyWFe9LjfaoaUFC2mLgKSzRbAxTUH8Pagy+NAZbB8EvIwTUqTh Gb3bRtstprtnN7Io+GV0YUyg8MO6OuMoeoZ5X5eJVUQq9DacTG4wMidqKio7f8vOVm1G9ebelm8s +e21axstbgemPOfzqJ0dh7vmzS9e2zp7cN9xMlmOWnV3yC/6crFsQ7IuFw8yvFfdMHPl0afDgtMf +hnqX3dKqm56oaU1nZYzz+a+tRH3617kqTTTXlAJbuQjnwagI+APEIfpPvoS/S59ny573rnZ+bLz dedV2y0b5bFAM54TJrgm77aYTGZLGLoEq5tlXCwnlPnsiX74Wp4NaZGIWYMQUHbFZxO2mvrhG3mh stJilSuUqyDoCsrBVcELwTKk8x+cqsJxDDXRfTQCkBe+DwztzbkKevji9A6aQHnURU5/gLbZ/FYJ 0AG7BLCrRb2AnWs7HKU4q0/VeqPUZqPyo3yvLUGAjPt1XUKz61a3Xa0XHC6vQ/7X6n3HD+gxBoNB LsXsLvzuy0trZYePZRzKnBfXEWl882N8CNfxSVTHReRSEAMjeTtt6hOJuAj9Fsaqz1l72mK3Wy1h JmTIYKDVEwh4PeFQTMH7KhCBkRlyJKLI4RgUGUFWNBCjPV5NCoUYi1VzMZSgkDZZBsAj4jRhTbhY 2TJghuZ++OGpOIoTo3ZUj7KokEN6HQt6qEC6Z8zX/0/0ShV2cbyJKovyJlYCHCUYNTYIx5cIdx64 EdFEZG64kfcNI7taqcN9Pq7QOgr1Y9vSRCY391xfn/+q7lmuPNv6m2694H/XU8H6g9MXriNCetl3 zl9xzvj42T88pSmrIXXbi6qtwiX5mm7YzfXwpEzLNtkuO2SnzMgobWkwyz3GP0N8k10uLFd70aFj PJeXIO3CJXc7gMPlSDtIRyvrcLjYMM1yhiii/1aC0uKSMKrASupmhqIWExRFEmErAQNufKvJy3gl L+FtLSmmwLMEhDLHCij7CSoAMi8IPC/wHAQ0VkckkgGXRpMabaVUTeiHK/I2ntDSbBPby5LsWbgC 8NCad+Q5WM11cF3cTc7EnYe9qDuiUEHqvAwhjIzNg4ftQ66HCGBsZXSqIKTT6S1lqeSW71/ekvLi Ny+wPEL0o/Y0AnjcfsJ24mO8r6nGNqZdUWEJuBKpVFg78Q5xYlfx6NcxblDD63aYicLUDv1GTvL5 pDbSgfHT4fySEedG9TI7MmJ6CSEZJyvzR+JizLOZPCYe8fQTb4qnPRZAuIiN4o/FXvEt8Y5YFC1d xAligCAtJovba/K640TCFHfHPFlT1j3TNNO9wLRAWOhe6FsYfwau/Df71RrjxHWFz7327NpeP8Yz 43kZez1jZ+1dk33MemG3s11PYkgIdLNbCiGEOCCVFEKSLiAqUdomRK0ECpVoGlEB6g9+NX2gNGVT ZYHQVEAgjVBUVVFbqahdoWWTSGxAFUI0yN6eOzaEBZX0T6X+8JW+c+7cx1z7zDnnfse7MbZB2aBt yH3Huz22X/6J8jP6K+/PY4eU39Lj3onYG8pb2lu5P8hnlb/JHyqfyFNKvkWOy3mal/PKLm1X7rB8 XD7DnZHOyx+Tj5Xr9IZ8XYmGRNcbeL5L4nlRMkNSzMiyofmbMwQyqYyT8VxhvUOZP2Y8mzM7M5TP jGZoJnMgl8lkc6aRg2AT29C+1v+if6/fE/G3+kf8nst+8mv/O/5/sAHi9x/g/P4mzgxy3pTuemUi 0aUlErpmpjR1H5WV1MTsUseKeT0pifN6UzFJwosnh06nauiPGiXUQ1Kqgn2FeijxpGIyrpDpO2QS FLINvWkSzR8jk07aCysI8azwBrK2odsp0Q412UEjlQqFgk1jKlFPaWSC/NBpg1c1p7tPc3L5gubc l0WRSKLQdBSRaEGznXU5kjtOXsOaQiF7HEVeSZ2egQJl6yhbRx0+WqAT5DUnxKXWxUjslOR9VbI5 pB1HuvuYGu8fKLiP+dojHuNqfIOrcb+r8WVMO4KsFDgn1vcit5ejwI1wlDtBLkD7bRFzrVy+dUvP TGn8VFnnK+yhok5rfKWsqzO1yavTbBLUops0GZ9x2enVQX6KdSozLMJ83+NPo1Y/7zBdi7l8Xr1H lHWVy+UtW+4eu3vQjb5lb7TcZLU5n+bz8p9TF7LVaPZ4sp6bKbUeh6LYK4p3jHl2bzw6sfH1dhaM HzHx7L7x9RN7NyXjeus047c5QudVpshtEfoNKlUu0YO3R+nTmG83YZSW6A5nX2u0VaBCf3RVlMaB 8NBqriPPC2PGWHpd6RQ5xX8gfGCcS5+zThZOliI+UGG/6QGLCKWoUErzZpo3Cr0WMQpWmhf4FLEk QqxCSRCElFGQDKNAbWJHbEyUoi3Yhp2y9R7bsjN22u540C7ZfXbBtp1SqdjfX0yns52d2eJqrjBB Ot9MlQ4W+Qn06DghXNAw5GCQA5nIcoIcjHBj6Br6Ygvnx9MHs4K7zjiYXR1JdCVGEmsTYwkuoS0K BPRAR5PdNH2MNKP/zKW8U9pVdUbjUTDWqw1PqfjFysh3NUSUfT2cndJnVH6KDbKButZB5Wew3SG4 XZ15l4cKs++Pa1ZRmJj9cFy5n+nD41KO6WvjQprpC+Nhhem/H4kPDtUpZz3b4xucNL8A9/PzcTPv 4E4+gNv4JO7hk0htefPWLndbBFs9w29xf0Dv7AXHL7QUo8kWodiLxzlLsRMNyMpQFK/GodIDSaFI mCgtnBctEiZKC+M89lCUJC1SJEwYgURqqBBBYUlafIhnTNpi1Bm1UNelidnT47w0RFA7IeykB1EY TJD8XQ1u0WtiyXNKN0J6b6/lFuCA2TbH+wmZEw5NaXqIvNQmRfTW6j+Z8++pHq0edy+q6uWkHhHb yEvVX2ZEnL/I7q31JE4S61moXGSzGfJudW+zjBQcWaFCBqpnGR9RhZDcjLXmEp87gyPVyyRai56g 7MPo2Vd9wbsfo8cibyNpAFVQzXzIUPpIX3Qk5Cg3xH+ZLX5xmbjU3Eg2RreL283d4m7zaPSEeMw8 Y/7FDGMICpYQtcQad0mGQl23SEvcTO5MkuQBM5k0zbiZzvfgkjc7u91qT3FarM7OHsvMW6KfujcX xx0gHEeJ6SegS+7VonQrROkSFUUSTV20OjJs9PlstiudzWbSZkfaFC0rlTaldNqMYpgCkUAQgVg4 IUQJ+JKc4GcUJx6XbF3HyKWM4mTsjh47n+8IQ3I0STcnJ5NXWK1ZGOUIcDyX4jZzk9wVronTejuO udkao+1RzMBb+GlMc8XBYTf93kZy3FpAGdjl68xz9ayL6l45978lPjcf+TtXN/v4Qd+gGypG3Znu 4V5zHbLXoM9Vd2hJPRSTp5mTbSGryHKX8F5s1Xmps3Lp+67vzXOpUjPmYCEU87tJeIT+puZC6Fw3 3mV+poiiwnLxDIDnU/QmBT5xAuEA1qfEFw7QE7PXIDR7HQLgZRVGc5enudnrMQOy6zKLxK6IKPIR Uw4TKtBUKCyFQuFQkIaJHKJBEo6kQEF2m2oJBkjZa0cCxcBYwBPQNbk8FiRBTf3WzlqJUUuELP8N z2CtVq8tBqK1Og3LNUxpxE0pFHMZ5iTKrmtMS67GzIT6r0cwL91MRWjomsGBVR5zHtDseOn1kzyJ EaNerzUbfcRgNkYT93n+XNlD+9EyKqkA3Vq5VivXllW+vI2Z9L1l9ORW1jkLhA5WK/QV70cQAuMo 2qjXCbUAKUCm2aeFn/6Fyv7Y4HCFlZ94rKd2QNQ9k75CaoEuqt7XP9vFXsh9G9MH1Nvmu0HU/4Az AHRbDZ5uxI8Qp/F25RFvAzRVAXw+AP8PAFosgOBzAKH3AXiKQC1cAJBQx0bvhvzTGtRJAP08wLwn ARKXAFp/DGDINaRfBsicBGjL1XEdoP13WNkdBujEc7t21tDze4DexwEK+N6+z2oY6KzBfqKO8zUM PjYXQ8sBilcAHngK4MFjACU8Y/EKgIe9AEuw/8ifahhGUw3juaPfBFiO9liBNlh5DmDVIYDVaKs1 7wGUceypFwDWLQH4+qcAG+YDPLMDYNORGp71NdBAAw000EADDTTQQAMNNNBAAw000MD/J4ACAdYk 8LAe0RFN8IXNA5yrW4IQjvBRQZRisqJqenxegg2bkLmvLZtrh/z8+6Gru8fqhb4FC/vhSzAIQ+Dg ikWLH3p4ySNLl30FHh0Z/eryr61Y+diqx1c/sebJMqz94uP/980Lh4D9jxT2KEoT2vHXF+EhWAqj sBJWwWpYA2V4BnbAd2dncS1bk4P8vwdU48jgweDDEARXk8iQDVLz/zF+CI0JQoCZoAoOhjSoWcwM gkCSEeojQSCEsNmALCVQjLNwAkWUGIyhbCYGPqDfIGxmoHgylM0CZLdC2WxA9nInd38/Nw9t5/zS oszUIr/UcsICDE4M7gz+DH7AIPQABpMzQz5DKUMRMABTgaQfkCwHBlkqQzpQNAcYZEVEqKeGClCI sPIxKjF4AoVYgSEgwKAPjEEG5nlc64A+ZgIFHOMEoAwHC5AF4sFohjQmIaB2OECPBnsgAKZ1BYYa DpAxZzi02fKhscE0c9aJ6k+r4vltvnJwcoBVL1YNTATRm7wfyPy/8msCqxSHNpALih+wyQB+M9Hh CmVuZHN0cmVhbQ1lbmRvYmoNMjMgMCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxz ZSANL1NNIDAuMDIgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUg L1BhZ2UgDS9QYXJlbnQgMTIgMCBSIA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29udGVudHMgMyAwIFIg DS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1Jv dGF0ZSAwIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0v Rm9udCA8PCAvVFQyIDE5IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIzIDAgUiA+PiANPj4g DWVuZG9iag0zIDAgb2JqDTw8IC9MZW5ndGggMTA5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN c3RyZWFtDQpIiZxWTW/jRgy9+1cQOclFR5H8GffWdZLuLpxNACsoFnEPI2kcTyPNGNLYXv/7JTmS LCQtUNQBAkoeko+Pjxx/SgbXSTKCGJLtII7DxWIBEf415mi2CBfz+Qzmo0kYzyYLSMpBBK+D6z/W MbzWAxGFURShd4avk9PgJdDr5frLUMT4iYJ4IW5VpspUVSKKh38lXwciXoRTENM5JLfkkw0CGCZ/ D6JwNIVReDOh972wZI586K+HQksDa+kqaYYYHjAP/u8+aydNLqu8hqSS2duvAHc/9rpSNaDrGUYR RuJP4xffRPRAsOJwOoVpFE5HDS5KmOwULFfLO6BkuobMlntbqxzs9rfGaw5iFI7HLeiJdxTwDSSk 2vlM6FqrQmUOXZ2FVIHDyPwVhqTg+0KVyjTH7Za/z2yF0PfW5Nq8tihjEHEPIaXQho4zH/eVLOnw XjqnKtMQ3jkRsBXXYt5AgDlQY7AYMNaIgl5OID07BSc6ZIlIhEtYjPrhrveVOmp7qN9jCdiVmvhP uZIhAhPAZ9x5T3XlyIOsYWuLwp5qT+WYqET3eUvlTUslBYki8Ma9rU7YYVjJ2nHJK86NFtZj2Sht pThdzY8+S+NOtXQMcN6Iso57lG61KnLAlnF8qr2j6dSnRBnSAUd9un32wZJfGDEqVwAipe8Y7QNB WjEkwc7Mhs/UaMtdMl1CXXJyQ4jJthscop80Joo+yYxOvnUceX7+LWnUBiDCpy3hcex1yOHeLgXw y7YKfngfVVxqYZsKolRtUUz2aNFju6twS+cqW7IzKi1TLPsmMAt5Gk542lqFjC9TSs6rpF+c8SjQ XH6Gh+d1wjaOHkrJq5vaRBbuDJBF4c/StJ+022l68jHYpK3Wq+GDTHdK5ljlJtBbX7o0582wSUzP O3lUgNvLk5j0GUMOCJS4oCJzw+xqn5gj+BS67gTScKiMH6lHAvpt9Z0LwOnyk8KTsBmGLfh2XXni Uuows9AcJdJLle2k0XUJD79/p3V1wKXH05aemZIaxY9QcBLk0er8AzEvQe1sRaGOvv1nKCw+5dJJ XE7nwkpseaq2JCsMRoe43Ri8BGoIE5eSEqzoRZ/56JmqaQ2nZwZFiEgw+qiqfpndVcLKDr5ssQ5K kraqbuvtlcR5tcmKQ66azQp3SxpwCU7qQvBd1a+UAvhLQjRiIh86y2tbtKqivrUzs9VV3Sz7JUu3 dW9lS/YV4RSObjKv6Fd4zwQVt/AiwI5pcwWSdXvhj0psbp1ztwELWgwelM935RclC8ZnfJdt3o1s kyhseLioafn455qpoljPkKHWm9VrjYLmTvNvMDg3zh4c4lPdDTC7tO0lkDg+8Gjw3r7388ote7La uN59eEMusxbCZxzAkn4D+H1Z4Qh+XPL4i4PR4wAFYddOv5V6PzxeurvmyXr+XdfqTWD3Tlsji/+U oG/83wx+3NvQd8ng5wCDXqZCCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1Bh Z2UgDS9QYXJlbnQgMTIgMCBSIA0vUmVzb3VyY2VzIDUgMCBSIA0vQ29udGVudHMgNiAwIFIgDS9N ZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0 ZSAwIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9u dCA8PCAvVFQyIDE5IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDIzIDAgUiA+PiANPj4gDWVu ZG9iag02IDAgb2JqDTw8IC9MZW5ndGggODMzIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJl YW0NCkiJpJVNb5tAEIbv/Io54ipsAH9yiho7aVJFlVVT9WD3sIa1vQ0GtLvEdX99ZxYciOuqUosl C693Zp733Rm4jZ3rOA4hgHjjBAGLogh8/DS34Shi0Xg8gnE4YMFoEEG8d3zYOtcfFgFsteP5zPd9 jE5wOT44S1cupovHnhfg5btB5M1EIvZroTw/6H2LPzpeELEheMMxxDOKSRwXevF3x2fhEEI2GdB6 Jy3dhnXqj1UmeQ4LbhTPe5gesA5+v14Lw/OUq1RDrHjyfAVw96OUSmjA0COEPmayVxMXTAL6QVgj Fg1hGLBh+MplBbnMwoEXsP4Z2dJ94trAnB+zgmh4Cl8LlTYq2QS8kA1s0NJdr3oA94U6cEVbUw9B vVtkxIUU5oXMjcy3NUoTOmpCpw+wcvckzFBooY6rnt3XQtU2WtL4XXtz5uKodrGmaIu2Rk6fpndY qyiNLKy/PKv/8GDPj1BSAJgC0H6ZCQVyUwNjqebwMzJkQwUoXKUNab3hEuIl1qXbGmMVN+a8wUO0 mmrHX4SVkMn8GYoN+F17wujMn9a0y6X/fKS48y9k9SHhAbVotEsA/w3uvD8S6o/57AvwjELkNt8L NLvW+rYtBv/SFh0z/sMHrMgzXYDIUxITT+egxZZIT7KGbNCVhb0GCddC2xPiKBKBgYbB7ASUlB5T o0L6eZCqtktq2FYcZ9wIkUJe2KZLitxr9QXj0zAO7JQaLnO0eXo/x+8DofIMTcTwkhsjFP6ZHw87 oQSsKwO4efrA4IQHSUPUcWJo81JCxNFVWRYas9EmXpaCK6TGR8qpCgJ23IB1UdGDSOKThwS/Gh6M mnOhYVmj0n2Zib1VjVEHaXagS5FITPsTs+piY7DbBGhjByp5rvPtsANpvVZgdkh4yZqJlWAFEvcT 9eALzypxBU+xTUTLn4UW6gWrraXRtm8xXUViOVaDTaVwl+paE9T8mEqm0hwh2Qkis4+KlRvfzm5u blY9dkIKWb/fkf2IpmVku5WtLYN9aVD/Y0WUS0eO563xQWOnoXGYo+cCUDHN014aXD2XvXTzit42 2J625TqHohm8Gb1+06PvGb4EPomtbXQjeTtxd7HzS4ABAJZb8e4KZW5kc3RyZWFtDWVuZG9iag03 IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAxMiAwIFIgDS9SZXNvdXJjZXMgOCAwIFIg DS9Db250ZW50cyA5IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQg WyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDIgMTkgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9H UzEgMjMgMCBSID4+IA0+PiANZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAzMTggL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImEkMluwyAQQO98xRxtqUyAeAnHtImq5lTV9BT1QG3i uk1sC5wuf19wnKrLoYOEhhFv3sClIjOlBHBQO8I5SimB+TWlIpMo8zyDXCTIs0SCOhAGNZldFxxq RyhDxpinS19Wb2QbNcVVcRNT7oNFXNKVKc3h0VjKePygNoRyiSnQNAe1CkxJIojVM2EoUhC4SEL9 W9uQilPrzXHf6BYKPVjdxr49eI/fv6IYdFtpWzlQVpcvFwDr976xxoFHP0Aw32mMieOLcD6NNfpT jpmcBgvGJfoLhWmH0Xa7uofedqVxrmnrEeO4ACoCsY16Z45VR/c6XG7ro64NVMaVtumHpmsRcfqA kcF5csKWOAe4878UsObVVP954CwKgP4r+mmZny1JeIm2ASqfYNdZ2Fl98ILfrrUinwIMAFE8ieIK ZW5kc3RyZWFtDWVuZG9iag0xMCAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNMTEgMCBvYmoN PDwgDS9OdW1zIFsgMCAxMCAwIFIgXSANPj4gDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL1Bh Z2VzIA0vS2lkcyBbIDE3IDAgUiAxIDAgUiA0IDAgUiA3IDAgUiBdIA0vQ291bnQgNCANPj4gDWVu ZG9iag0xMyAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDAxMTIxOTIxMTcxMSswMicwMCcp DS9Nb2REYXRlIChEOjIwMDExMjE5MjExNzExKzAyJzAwJykNL1Byb2R1Y2VyIChBY3JvYmF0IERp c3RpbGxlciA1LjAgXChXaW5kb3dzXCkpDS9BdXRob3IgKHNhdHJhbikNL0NyZWF0b3IgKFBzY3Jp cHQuZGxsIFZlcnNpb24gNS4wKQ0vVGl0bGUgKEFwcGVuZGl4LVN5bmNoLWFuZC1TdGVlcmluZ18w NTEyX0FTLUNPV1MuZm0pDT4+IA1lbmRvYmoNMTQgMCBvYmoNPDwgL1R5cGUgL01ldGFkYXRhIC9T dWJ0eXBlIC9YTUwgL0xlbmd0aCAxMTA5ID4+IA1zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0nJyBp ZD0nVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkJyBieXRlcz0nMTEwOCc/PjxyZGY6UkRGIHhtbG5z OnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6 aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+PHJkZjpEZXNjcmlwdGlvbiBhYm91dD0n JyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLycgeG1sbnM6cGRmPSdodHRwOi8v bnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6Q3JlYXRpb25EYXRlPScyMDAxLTEyLTE5VDE5OjE3 OjExWicgcGRmOk1vZERhdGU9JzIwMDEtMTItMTlUMTk6MTc6MTFaJyBwZGY6UHJvZHVjZXI9J0Fj cm9iYXQgRGlzdGlsbGVyIDUuMCAoV2luZG93cyknIHBkZjpBdXRob3I9J3NhdHJhbicgcGRmOkNy ZWF0b3I9J1BzY3JpcHQuZGxsIFZlcnNpb24gNS4wJyBwZGY6VGl0bGU9J0FwcGVuZGl4LVN5bmNo LWFuZC1TdGVlcmluZ18wNTEyX0FTLUNPV1MuZm0nLz4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0n JyB4bWxucz0naHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdodHRwOi8v bnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRlRGF0ZT0nMjAwMS0xMi0xOVQxOToxNzox MVonIHhhcDpNb2RpZnlEYXRlPScyMDAxLTEyLTE5VDE5OjE3OjExWicgeGFwOkF1dGhvcj0nc2F0 cmFuJyB4YXA6TWV0YWRhdGFEYXRlPScyMDAxLTEyLTE5VDE5OjE3OjExWic+PHhhcDpUaXRsZT48 cmRmOkFsdD48cmRmOmxpIHhtbDpsYW5nPSd4LWRlZmF1bHQnPkFwcGVuZGl4LVN5bmNoLWFuZC1T dGVlcmluZ18wNTEyX0FTLUNPV1MuZm08L3JkZjpsaT48L3JkZjpBbHQ+PC94YXA6VGl0bGU+PC9y ZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9w dXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2Vs ZW1lbnRzLzEuMS8nIGRjOmNyZWF0b3I9J3NhdHJhbicgZGM6dGl0bGU9J0FwcGVuZGl4LVN5bmNo LWFuZC1TdGVlcmluZ18wNTEyX0FTLUNPV1MuZm0nLz4KPC9yZGY6UkRGPjw/eHBhY2tldCBlbmQ9 J3InPz4KZW5kc3RyZWFtDWVuZG9iag14cmVmDTAgMTUgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAyODgyNCAwMDAwMCBuDQowMDAwMDI4OTc1IDAwMDAwIG4NCjAwMDAwMjkwNzggMDAwMDAgbg0K MDAwMDAzMDI0NiAwMDAwMCBuDQowMDAwMDMwMzk3IDAwMDAwIG4NCjAwMDAwMzA1MDAgMDAwMDAg bg0KMDAwMDAzMTQwNiAwMDAwMCBuDQowMDAwMDMxNTU3IDAwMDAwIG4NCjAwMDAwMzE2NjAgMDAw MDAgbg0KMDAwMDAzMjA1MSAwMDAwMCBuDQowMDAwMDMyMDgyIDAwMDAwIG4NCjAwMDAwMzIxMjYg MDAwMDAgbg0KMDAwMDAzMjIxMCAwMDAwMCBuDQowMDAwMDMyNDYwIDAwMDAwIG4NCnRyYWlsZXIN PDwNL1NpemUgMTUNL0lEWzw2MTEwNGQzZjBlNzk4YWI1NTBkY2E0ZTk0NDJjNzdlMD48NTU0MjAw ZWEyMjEwZTc1OWIyNmZmYTBmNzIyNGQxNWE+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== --=_mixed 0069BD07C2256B2B_=-- From owner-ips@ece.cmu.edu Mon Dec 24 01:42:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06075 for ; Mon, 24 Dec 2001 01:42:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBO5l1609987 for ips-outgoing; Mon, 24 Dec 2001 00:47:01 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBO5kpZ09978 for ; Mon, 24 Dec 2001 00:47:00 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 9A8B1E00099; Mon, 24 Dec 2001 00:46:45 -0500 (EST) Received: from swathi (pal1nai160096.nsr.hp.com [15.244.160.96]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id VAA08464; Sun, 23 Dec 2001 21:48:17 -0800 (PST) Message-ID: <006301c18c3e$5f42d140$60a0f40f@rose.hp.com> From: "Mallikarjun C." To: Cc: References: <277DD60FB639D511AC0400B0D068B71E029372C4@CORPMX14> Subject: Re: iSCSI: "conservative reuse" requirement Date: Sun, 23 Dec 2001 21:46:45 -0800 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Mon Dec 24 11:59:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23747 for ; Mon, 24 Dec 2001 11:59:37 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBOGDjV18034 for ips-outgoing; Mon, 24 Dec 2001 11:13:45 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic2.us.dg.com (mxic2.us.dg.com [128.221.31.40]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBOGDhZ18028 for ; Mon, 24 Dec 2001 11:13:43 -0500 (EST) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Dec 2001 11:09:17 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372C8@CORPMX14> From: Black_David@emc.com To: cbm@rose.hp.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: "conservative reuse" requirement Date: Mon, 24 Dec 2001 11:01:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Not exactly. "Conservative Reuse" would allow an initiator to present multiple initiator ports, as long as it presented each of them to all target ports (assuming that the connectivity exists). Why would an Initiator want to present different ports to different target portal groups? I don't think there's another example in which SCSI behaves this way in practice. --David > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to > always act > as a single initiator port (wrt one target; assuming only one > session as an > example) per initiator device - which rules out the case of > an initiator > intentionally wanting to present a different port to each > target portal group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should > be completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" > of ISIDs be > > > made a MUST. This is really only required when initiators > need to be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this > approach, the ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being > able to use these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC > and driver > > doesn't know whether shared persistent reservations are > being used and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects > (via SCSI means, > > e.g., something in a mode page) that the Target supports > shared persistent > > reservations, tries to use them, only to discover that they > don't work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues > and possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having > a separate > > initiator side means that the entity has to check only for > iSCSI (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > From owner-ips@ece.cmu.edu Mon Dec 24 11:59:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23759 for ; Mon, 24 Dec 2001 11:59:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBOGevu19300 for ips-outgoing; Mon, 24 Dec 2001 11:40:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBOGesZ19295; Mon, 24 Dec 2001 11:40:54 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id fBOGedH13876; Mon, 24 Dec 2001 08:40:39 -0800 From: "Amir Shalit" To: "Julian Satran" , "shaileshm" Cc: , Subject: RE: Recovery Within Connection - Command Restart Date: Mon, 24 Dec 2001 08:40:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C18C56.A939D420" 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.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C18C56.A939D420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit > 2. Request not acknowledged would be most of the time due to a > header digest errors at the target end. If the header is bad how > would one know at the target, that this was a command PDU v/s a Data > PDU, since the target will have to implement a command scoreboard if > it is a command PDU. > A target that failed to get a command PDU will notice SCSI data PDUs with unrecognized initiator tag . -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, December 21, 2001 8:42 PM To: shaileshm Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: Re: Recovery Within Connection - Command Restart owner-ips@ece.cmu.edu wrote on 20-12-2001 00:06:44: > > > 1. The draft says a) Requests not acknowledged for a long time….. > Does the SCSI timeout’s introduce the notion of time, or does iscsi > has to have timeout’s at the transport layer. Also for detecting > connection failures don’t the NOP’s have to be timed. > Timeouts here are iSCSI timeouts - by the time SCSI timeouts it is too late > 2. Request not acknowledged would be most of the time due to a > header digest errors at the target end. If the header is bad how > would one know at the target, that this was a command PDU v/s a Data > PDU, since the target will have to implement a command scoreboard if > it is a command PDU. > You won't know but initiator sees that ExpCmdSN is not advancing > 3. Usage of Reject PDU talks about Reject on Command PDU : however > the error codes for Reject PDU do not indicate a command PDU error. ??? > > 4. Is the recovery R2T different from the usual R2T. > > No > > These things are not clear from the draft ! > > It is all in the eye of the reader :-) We heard already complaints that the text is too bulky and has things that belong to a tutorial > > Shailesh Manjrekar. Julo ------=_NextPart_000_0016_01C18C56.A939D420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> 2. Request not acknowledged would be most of = the time=20 due to a
> header digest errors at the target end. If the header = is bad=20 how
> would one know at the target, that this was a command PDU = v/s a=20 Data
> PDU, since the target will have to implement a command = scoreboard=20 if
> it is a command PDU.
>
A=20 target that failed to get a command PDU will notice SCSI data PDUs with=20 unrecognized initiator tag .
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Friday, December 21, 2001 8:42 PM
To: = shaileshm
Cc: ips@ece.cmu.edu;=20 owner-ips@ece.cmu.edu
Subject: Re: Recovery Within = Connection -=20 Command Restart



owner-ips@ece.cmu.edu wrote on 20-12-2001 = 00:06:44:

>=20  
>
> 1. = The draft=20 says a) Requests not acknowledged for a long time…..
> = Does the SCSI=20 timeout’s introduce the notion of time, or does iscsi
> = has to have=20 timeout’s at the transport layer. Also for detecting
> = connection=20 failures don’t the NOP’s have to be timed.
> =

Timeouts here are iSCSI timeouts - by = the time SCSI=20 timeouts it is too late

> 2.=20 Request not acknowledged would be most of the time due to a
> = header=20 digest errors at the target end. If the header is bad how
> = would one=20 know at the target, that this was a command PDU v/s a Data
> = PDU, since=20 the target will have to implement a command scoreboard if
> it = is a=20 command PDU.
>

You won't=20 know but initiator sees that ExpCmdSN is not advancing =
 
> 3. Usage of Reject PDU talks about Reject on Command PDU = : however=20
> the error codes for Reject PDU do not indicate a command PDU=20 error.

???
>=20
> 4. Is the recovery = R2T=20 different from the usual R2T.
>
>
No   =
>=20
> These things are = not clear=20 from the draft !
>
>=20
It is all in the eye of = the reader=20 :-)
We heard already = complaints=20 that the text is too bulky and has things that belong to a tutorial =
>=20
> Shailesh = Manjrekar.=20

Julo
------=_NextPart_000_0016_01C18C56.A939D420-- From owner-ips@ece.cmu.edu Mon Dec 24 17:05:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25261 for ; Mon, 24 Dec 2001 17:05:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBOLC9q01718 for ips-outgoing; Mon, 24 Dec 2001 16:12:09 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBOLC8Z01713 for ; Mon, 24 Dec 2001 16:12:08 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id NAA18633; Mon, 24 Dec 2001 13:12:01 -0800 (PST) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id MAA00178; Mon, 24 Dec 2001 12:56:18 -0800 (PST) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Dec 2001 13:12:00 -0800 Message-ID: From: "Mukund, Shridhar" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS Date: Mon, 24 Dec 2001 13:11:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18CBF.A00D6880" Sender: owner-ips@ece.cmu.edu 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_01C18CBF.A00D6880 Content-Type: text/plain; charset="iso-8859-1" Julo, During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft. [-------->] Isn't this "Consistent Overhead Word(Byte) Stuffing" from Stanford? -Shridhar Mukund ------_=_NextPart_001_01C18CBF.A00D6880 Content-Type: text/html; charset="iso-8859-1"
 
Julo, 

During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft.
[-------->] Isn't this "Consistent Overhead Word(Byte) Stuffing" from Stanford? 
 
 -Shridhar Mukund 
------_=_NextPart_001_01C18CBF.A00D6880-- From owner-ips@ece.cmu.edu Wed Dec 26 10:13:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18103 for ; Wed, 26 Dec 2001 10:13:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBQE5Li05624 for ips-outgoing; Wed, 26 Dec 2001 09:05:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1aa.compuserve.com (siaar1aa.compuserve.com [149.174.40.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBQE5JZ05619 for ; Wed, 26 Dec 2001 09:05:19 -0500 (EST) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id JAA27801 for ips@ece.cmu.edu; Wed, 26 Dec 2001 09:05:13 -0500 (EST) Received: from compuserve.com (dal-tgn-tvo-vty19.as.wcom.net [206.175.229.19]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id JAA27725; Wed, 26 Dec 2001 09:05:02 -0500 (EST) Message-ID: <3C29DA26.BC2F966D@compuserve.com> Date: Wed, 26 Dec 2001 08:09:42 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "Rodriguez, Elizabeth" , "Black, David" , IPS Reflector Subject: Re: IPS-ALL: Draft IPS Meeting minutes from IETF-52 References: <005a01c18a50$4257c670$52f1a2ac@D2BVG111> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Regarding the following sentence in the FCIP report. > ... FC-BB-2 - specific solution seems to be preferred to > a generic FC solution. ... I think it would be more correct to say: Since FC does not have the concept of multiple switch-to- switch links between the same pair of switches over a single cable, an FC-BB-2 solution is more appropriate than a generic FC solution. Thanks. Ralph... From owner-ips@ece.cmu.edu Wed Dec 26 11:47:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18724 for ; Wed, 26 Dec 2001 11:47:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBQFx5P11111 for ips-outgoing; Wed, 26 Dec 2001 10:59:05 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar1ab.compuserve.com (siaar1ab.compuserve.com [149.174.40.10]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBQFx3Z11106 for ; Wed, 26 Dec 2001 10:59:03 -0500 (EST) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id KAA06311 for ips@ece.cmu.edu; Wed, 26 Dec 2001 10:58:57 -0500 (EST) Received: from compuserve.com (dal-tgn-tvp-vty16.as.wcom.net [216.192.239.16]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id KAA06209; Wed, 26 Dec 2001 10:58:43 -0500 (EST) Message-ID: <3C29F33F.CEBF4330@compuserve.com> Date: Wed, 26 Dec 2001 09:56:47 -0600 From: Ralph Weber Reply-To: roweber@acm.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector CC: Black_David@emc.com Subject: Re: FCIP: Short Frame Security Solution Proposal References: <277DD60FB639D511AC0400B0D068B71E029372C5@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote [responses embedded]: > I think this is a workable approach. A few comments: > > - There are a dependencies among a number of components > on who supports what, some of which are under T11's > control. If it turns out that the T11 aspects of this > are not mandatory to implement, ... T11 does not have a concept of "mandatory to implement". In IETF terminology, a T11 "mandatory" is "mandatory to implement and mandatory to use". On the other hand, if you ask any storage product vendor about the 'mandatory to implement' aspects of a T11 or T10 standard, you will find that the practical reality is that "anything that is in a standard is 'mandatory to implement' for everybody except hosts." The reason for this is that some customer somewhere wants just about any option listed in the standard, thus making all options listed in a standard, for all intents and purposes, "mandatory to implement". The only "options" that come to mind as exceptions to this are the SCSI CHANGE DEFINITION and COPY commands (SCSI-2 COPY, not SCSI-3 EXTENDED COPY). The problem of mandatory to implement options problem is so fundamental T10 and T11 have seen heated debates over letting an "option" in to a standard because of the burdens it will place on products. > I think multiple TCP > connections in a single FCIP session need to be disallowed > if this authentication cannot be performed by the > implementation (i.e., is not implemented) - putting in a > note to this effect regardless of what T11 does might be > a good idea to decouple FCIP from FC-BB-2 in this area. As currently worded, the FCIP Entity ALWAYS asks the FC Entity for authentication of a second to n-th connection and the FC Entity ALWAYS responds, yes or no. I fail to see how a note such as the one suggested would be viewed as anything more than advisory to FC-BB-2. The FCIP Entity has (in theory) no knowledge of how much or how little work the FC Entity does to generate its response to the request for connection authentication. > - Any nonce must be validated ("yes, that's my connection") > at most once. If the FC Entity on the other end of the > first connection is capable of saying "yes" twice to the > same nonce, there's an obvious replay attack. I had sought to cut this type of attack off at the SF level (long before the FC Entity at the other end gets a nonce to validate) with the following words. }...} To further increase the difficulty of snooping }...} TCP connections, an FCIP Entity that receives }...} a duplicate nonce shall close the connection }...} on which that nonce was received immediately }...} without causing the SW_ILS to be sent. To me, this seems superior for a couple of reasons: o It places the requirement in FCIP, closer to the source of the problem. o It eliminates an unnecessary authentication transaction with the FC Entity at the other end. If this is a recommendation to FC-BB-2, we can carry it forward as such. Otherwise, I need a more detailed description of what is desired in FCIP. > - Some words will need to be added about a nasty race > condition in which the attacker opens up a connection up > to the point of sending the short frame, watches a real > connection get set up to the point that the attacker sees > the short frame on the real connection; the attacker > extracts and uses the nonce, and TCP tricks (e.g., corrupt > the TCP packet containing the nonce to cause a checksum > failure, or send a well-timed RST). The short answer to > dealing with this is "use IKE and also ESP encryption if > warranted" when this sort of attack is a concern. Would it not be better to include a broad caution along the lines of: Warning: The authentication mechanism described here is not designed to thwart sophisticated security threats. The IP security mechanisms described in section 9 should be enabled in environments where security threats are suspected. > - I think it's necessary to authentication the first TCP > connection (up to FCAP or whatever) before sending the ILS > that would authenticate a subsequent one, but details beyond > that (e.g., can one send the SYN for the second TCP connection > before the first connection authenticates) are probably up to > implementations. I had hoped to have covered the case I think is being described above by the following language (note the words "previously authenticated"): }...} In situations where security }...} risks are possible, the FC Entity shall transmit }...} the information provided by the FCIP Entity via a new }...} SW_ILS on a previously authenticated TCP connection }...} (FCIP Data Engine) enabled for Class F frames. "Previously authenticated" may be vague, but it is intended to cover both authentication via FCAP and authentication against another F Class connection using this process. Consider that case where a long lived FCIP Link starts out with one F Class connection. Next, using the authentication process described in this proposal and two or more Class 2/3 connections are added to the FCIP Link. As time goes by the F Class connection becomes unreliable and the Entities at both ends decide to close it and switch one of the Class 2/3 connections to Class F service. The connection switched to F Class service has been duly authenticated, but not by FCAP. It seems perfectly reasonable that the switched F Class connection can serve to authenticate new connect requests. If there is some subtitly that I am missing, try a 4x4 next time as the 2x4 must have missed its mark. Thanks. Ralph... -----Original Proposal Text Follows for Reference----- > > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > > Sent: Thursday, December 20, 2001 8:55 AM > > To: IPS Reflector > > Subject: FCIP: Short Frame Security Solution Proposal > > > > > > This message proposes a solution to the security > > issues surrounding the FCIP Short Frame proposed as > > a solution to the NAPTs problem. The security > > issues and directions toward a solution were > > discussed in Salt Lake and this message is an > > attempt to follow the path charted in those > > discussions. > > > > Solution Assumptions > > > > A) This matters a lot less if IPsec authentication > > is in use and rigorously managed because IPsec solves > > this authenticates TCP connections, substantially > > reducing the opportunity for rogue end-points to > > make TCP connections to FC/FCIP devices. > > > > B) Securing the first TCP connection in an FCIP Link > > is handled outside the scope of this solution. In Fibre > > Channel, securing the first TCP connection may be > > accomplished using FCAP. At this time, it is not clear > > whether FCAP authentication of the TCP connection > > needs to be mandatory or recommended for configurations > > exposed to security risks. > > > > C) Once authenticated, the first TCP connection is > > allowed to carry F Class frames. > > > > D) The objective of this solution is to authenticate > > the second to n-th TCP connections using a protocol > > that has lower overhead than FCAP or IPsec. > > > > Solution Changes in FCIP > > > > The principle change in FCIP is to REQUIRE the FCIP > > Entity to interact with the FC Entity to authenticate > > the second through n-th TCP connections for a given > > Link End Point (LEP). > > > > Upon receipt of an n-th TCP connect request and Short > > Frame (SF), the FCIP Entity MUST request (from the FC > > Entity) confirmation that the TCP connect request is > > from the same FC/FCIP Entity as the first TCP connection. > > The FCIP Entity MUST delay return of the SF until the FC > > Entity provides the confirmation. > > > > In addition, a new 64-bit nonce field is needed in > > the SF. Theoretically, the nonce field could overlay > > the Destination FC Fabric Entity WWN field. However, > > the current leaning is to add a new field, lengthening > > the FCIP Short Frame to the point where it will have > > to be called the FCIP Special Frame. > > > > The FCIP Entity shall communicate the newly defined > > SF nonce plus other SF information to the FC Entity > > in the interaction required to confirm the second > > through n-th TCP connect requests. > > > > Solution Changes in FC-BB-2 > > > > The principle changes in FC-BB-2 are: > > > > a) Discussion of how the FC Entity may respond > > to an FCIP Entity request for authentication > > of a second through n-th TCP connect request; > > b) Definition of a new SW_ILS to be used in > > confirming the second through n-th TCP > > connect requests; and > > c) Description of how the new SW_ILS is exchanged > > between the FC Entity where the TCP connect > > request is received an authenticated FC Entity > > over an existing F Class enabled TCP Connection. > > > > N.B. It is important that this negotiation be placed > > in the FC Entity because the Fibre Channel elements > > at each end of a link have in place protocol mechanisms > > for negotiations and exchanges of this type. > > > > Solution Mechanics > > > > When an FC/FCIP Entity makes a TCP connect request > > for what it knows to be the second to n-th TCP > > connection in an FCIP Link, it places a randomly > > generated 64-bit nonce in the SF. (Note: There needs > > to be requirements on the nonce generation method to > > ensure that predicting nonce values is sufficiently > > difficult. The ULP Framing draft has been recommended > > as a source for these requirements.) > > > > When an FCIP Entity receives a second to n-th > > TCP connect request, it will delay returning the > > SF until the SF nonce and other SF information is > > authenticated by the FC Entity. If the FC Entity > > reports that authentication failed, the FCIP > > Entity SHALL close the TCP connection. > > > > Details of the mechanism by which the FC Entity > > authenticates a second to n-th TCP Connect request > > are to be specified by T11 in FC-BB-2 (along with > > numerous other Fibre Channel protocol issues > > related to FCIP). > > > > A proposal containing at least the following > > will be made. > > > > The FC Entity may authenticate the TCP Connect request > > based on configuration information that is outside the > > scope of the standards. In situations where security > > risks are possible, the FC Entity shall transmit > > the information provided by the FCIP Entity via a new > > SW_ILS on a previously authenticated TCP connection > > (FCIP Data Engine) enabled for Class F frames. > > > > It can be assumed that an authenticated TCP connection > > enabled for F Class frames exists because the absence > > on such a connection prohibits basic Fibre Channel > > link operation (i.e., the problem must be dealt with > > as a general concern for FC-BB-2 operation over FCIP.) > > > > The response to the new SW_ILS will be one of: > > > > SW_ACC - indicating that the new TCP Connect > > request is authenticated > > SW_RJT - indicating that the new TCP Connect > > request is not authenticated > > > > The response shall be communicated to the FCIP Entity > > who shall act accordingly, as described above. > > > > An FC Entity that receives one of the new SW_ILSs shall > > perform the requested authentication by verifying that it > > initiated a TCP connect request and sent the SF nonce. > > The results of the authentication shall be communicated > > in the response to the SW_ILS as described above. > > > > To further increase the difficulty of snooping > > TCP connections, an FCIP Entity that receives > > a duplicate nonce shall close the connection > > on which that nonce was received immediately > > without causing the SW_ILS to be sent. > > > > Solution Pragmatics > > > > This solution binds the authentication of the > > second through n-th TCP connections to the > > authentication of the first TCP connection, > > thus fitting the solution within the bounds > > of the assumptions (but no more). > > > > Once the first TCP connection is properly > > authenticated, it is reasonable to ask the > > FC/FCIP Entity at the other end, "Did you > > make this additional TCP connect request?" > > The nonce (properly guaranteed for randomness) > > represents the "this" aspect of the question > > and renders nearly impossible nonce replay > > attacks wherein the FC/FCIP Entity asked the > > SW_ILS question is fooled into believing > > that SW_ACC should be sent because a correct > > nonce is presented. > > > > This solution slows down the process of > > establishing TCP connections, but that seems > > unavoidable. > > > > It may be desirable to require that there > > be no attempts to establish the second through > > n-th TCP connections until the first is > > authenticated. This is another slow down in > > the process, but one that will be imposed > > anyway at a later step. > > > > It may be desirable to further slow down > > the process by requiring FC/FCIP Entities > > to process only one TCP connect request > > at a time, rejecting all TCP connect > > requests that arrive while another is > > in process. This will further add to the > > difficulty of mounting a replay attack. > > > > From owner-ips@ece.cmu.edu Wed Dec 26 14:02:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19884 for ; Wed, 26 Dec 2001 14:02:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBQIFsq17710 for ips-outgoing; Wed, 26 Dec 2001 13:15:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from emulex.emulex.com (emulex.emulex.com [138.239.112.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBQIFpZ17700 for ; Wed, 26 Dec 2001 13:15:51 -0500 (EST) Received: from xbl.ad.emulex.com (xbl.ma.emulex.com [172.16.12.11]) by emulex.emulex.com (8.9.1a/8.9.1) with ESMTP id KAA00526; Wed, 26 Dec 2001 10:15:41 -0800 (PST) Received: by xbl.ad.emulex.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Dec 2001 13:15:29 -0500 Message-ID: <3356669BBE90C448AD4645C843E2BF280A0575@xbl.ad.emulex.com> From: "Williams, Jim" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS Date: Wed, 26 Dec 2001 13:15:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18E39.4C7D1370" Sender: owner-ips@ece.cmu.edu 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_01C18E39.4C7D1370 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, December 23, 2001 2:19 PM To: ips@ece.cmu.edu Subject: iSCSI - Synch an Steering Appendix - Markers & COWS Dear colleagues, Attached are the two versions of the Synch and Steering appendix that we are considering. During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft. We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it). I believe there is also a third alternative under consideration which is a length/key encoding which is considerably simpler and easier to implement. The primary objection to this mechanism is due to its probabilistic nature, however this objection seems based more on superstition than on any analysis showing that the overall reliability of the system is in any way compromised by the probabilistic nature. In any case, my understanding is that this is also under consideration in TSV working group, so I would hope that IPS will defer to their choice and not try to go it alone regarding the decision. However, I would strongly object to the "SHOULD implement". I believe this should be made a "SHOULD implement" only after the benefit of this technique has been demonstrated. I do concede that there are one or two vendors who have view graphs claiming that "Synch and Steering" layer will allow them to build a more cost effective product. However after doing a considerable amount of study on iSCSI HBA design, I have serious doubts about the viability of this approach. I am more than happy to be proven wrong on this, but the operative word is "proven". I am bothered that a small minority of implementors want everyone else to de-optimize their designs so that they can optimize their own, especially when I suspect the approach is technically flawed to begin with. And, if the "Sync and Steering" approach is successful, it will quickly become a de-facto standard anyway, so I would urge the IETF to remain a bit more neutral on this for now. Any comments/questions are welcome. Happy holidays and a peaceful and prosperous 2002, Julo Thanks for considering my coments, and best to all as well, - Jim ------_=_NextPart_001_01C18E39.4C7D1370 Content-Type: text/html; charset="iso-8859-1"
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, December 23, 2001 2:19 PM
To: ips@ece.cmu.edu
Subject: iSCSI - Synch an Steering Appendix - Markers & COWS


Dear colleagues,

Attached are the two versions of the Synch and Steering appendix that we are considering.

During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft.

We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it).  
 
I believe there is also a third alternative under consideration which is a length/key
encoding which is considerably simpler and easier to implement.  The primary
objection to this mechanism is due to its probabilistic nature, however this
objection seems based more on superstition than on any analysis showing
that the overall reliability of the system is in any way compromised by
the probabilistic nature.
 
In any case, my understanding is that this is also under consideration
in TSV working group, so I would hope that IPS will defer to their
choice and not try to go it alone regarding the decision.
 
However, I would strongly object to the "SHOULD implement".
I believe this should be made a "SHOULD implement" only
after the benefit of this technique has been demonstrated.
I do concede that there are one or two vendors who have
view graphs claiming that "Synch and Steering" layer will allow
them to build a more cost effective product.  However after doing
a considerable amount of study on iSCSI HBA design, I have serious
doubts about the viability of this approach.  I am more than happy to
be proven wrong on this, but the operative word is "proven".
 
I am bothered that a small minority of implementors want everyone
else to de-optimize their designs so that they can optimize their
own, especially when I suspect the approach is technically flawed
to begin with.
 
And, if the "Sync and Steering" approach is successful, it will quickly
become a de-facto standard anyway, so I would urge the IETF
to remain a bit more neutral on this for now.
 
Any comments/questions are welcome.

Happy holidays and a peaceful and prosperous 2002,
Julo  
 
Thanks for considering my coments, and best to all as well,
 - Jim
 
 

------_=_NextPart_001_01C18E39.4C7D1370-- From owner-ips@ece.cmu.edu Wed Dec 26 23:06:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24872 for ; Wed, 26 Dec 2001 23:06:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBR3HD013625 for ips-outgoing; Wed, 26 Dec 2001 22:17:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxic1.isus.emc.com ([168.159.129.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBR3HCZ13621 for ; Wed, 26 Dec 2001 22:17:12 -0500 (EST) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Dec 2001 22:19:44 -0500 Message-ID: <277DD60FB639D511AC0400B0D068B71E029372CD@CORPMX14> From: Black_David@emc.com To: Jim.Williams@emulex.com, ips@ece.cmu.edu Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS Date: Wed, 26 Dec 2001 22:05:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18E83.4F128BC0" Sender: owner-ips@ece.cmu.edu 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_01C18E83.4F128BC0 Content-Type: text/plain; charset="iso-8859-1" > > We also agreed that we will strive to have only one such > > option and we would like to have it required somewhat > > stronger (sender should provide it if receiver wants it). > I believe there is also a third alternative under consideration which is a length/key > encoding which is considerably simpler and easier to implement. The primary > objection to this mechanism is due to its probabilistic nature, however this > objection seems based more on superstition than on any analysis showing > that the overall reliability of the system is in any way compromised by > the probabilistic nature. > > In any case, my understanding is that this is also under consideration > in TSV working group, so I would hope that IPS will defer to their > choice and not try to go it alone regarding the decision. That length/key approach is the TCP ULP framing work in draft-ietf-tsvwg-tcp-ulp-frame-01.txt. That draft is currently planned to become an Experimental RFC, and hence the strongest requirement that iSCSI can express for implementing it is "MAY". > However, I would strongly object to the "SHOULD implement". > I believe this should be made a "SHOULD implement" only > after the benefit of this technique has been demonstrated. > I do concede that there are one or two vendors who have > view graphs claiming that "Synch and Steering" layer will allow > them to build a more cost effective product. However after doing > a considerable amount of study on iSCSI HBA design, I have serious > doubts about the viability of this approach. I am more than happy to > be proven wrong on this, but the operative word is "proven". That's fair. I view the level of requirement (MUST/SHOULD/ MAY) as an open issue - to the extent that Julian expressed a preference for something stronger than MAY, that is not the rough consensus of the IPS WG. Further discussion is encouraged, and I hope to see this issue resolved by/at the February interim meeting. FWIW, I have heard from other hardware implementers that markers are not a make or break product requirement at 1 Gbit/sec, but they will have to speak for themselves in the WG. Thanks, --David --------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 42 South St., Hopkinton, MA 01748 +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 black_david@emc.com Cell: +1 (978) 394-7754 --------------------------------------------------- -----Original Message----- From: Williams, Jim [mailto:Jim.Williams@emulex.com] Sent: Wednesday, December 26, 2001 1:15 PM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, December 23, 2001 2:19 PM To: ips@ece.cmu.edu Subject: iSCSI - Synch an Steering Appendix - Markers & COWS Dear colleagues, Attached are the two versions of the Synch and Steering appendix that we are considering. During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft. We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it). I believe there is also a third alternative under consideration which is a length/key encoding which is considerably simpler and easier to implement. The primary objection to this mechanism is due to its probabilistic nature, however this objection seems based more on superstition than on any analysis showing that the overall reliability of the system is in any way compromised by the probabilistic nature. In any case, my understanding is that this is also under consideration in TSV working group, so I would hope that IPS will defer to their choice and not try to go it alone regarding the decision. However, I would strongly object to the "SHOULD implement". I believe this should be made a "SHOULD implement" only after the benefit of this technique has been demonstrated. I do concede that there are one or two vendors who have view graphs claiming that "Synch and Steering" layer will allow them to build a more cost effective product. However after doing a considerable amount of study on iSCSI HBA design, I have serious doubts about the viability of this approach. I am more than happy to be proven wrong on this, but the operative word is "proven". I am bothered that a small minority of implementors want everyone else to de-optimize their designs so that they can optimize their own, especially when I suspect the approach is technically flawed to begin with. And, if the "Sync and Steering" approach is successful, it will quickly become a de-facto standard anyway, so I would urge the IETF to remain a bit more neutral on this for now. Any comments/questions are welcome. Happy holidays and a peaceful and prosperous 2002, Julo Thanks for considering my coments, and best to all as well, - Jim ------_=_NextPart_001_01C18E83.4F128BC0 Content-Type: text/html; charset="iso-8859-1"
> > We also agreed that we will strive to have only one such
> > option and we would like to have it required somewhat
> > stronger (sender should provide it if receiver wants it).  
 
> I believe there is also a third alternative under consideration which is a length/key
> encoding which is considerably simpler and easier to implement.  The primary
> objection to this mechanism is due to its probabilistic nature, however this
> objection seems based more on superstition than on any analysis showing
> that the overall reliability of the system is in any way compromised by
> the probabilistic nature.
>  
> In any case, my understanding is that this is also under consideration
> in TSV working group, so I would hope that IPS will defer to their
> choice and not try to go it alone regarding the decision.
 
That length/key approach is the TCP ULP framing work in
draft-ietf-tsvwg-tcp-ulp-frame-01.txt.  That draft is currently
planned to become an Experimental RFC, and hence the strongest
requirement that iSCSI can express for implementing it is "MAY".
 
> However, I would strongly object to the "SHOULD implement".
> I believe this should be made a "SHOULD implement" only
> after the benefit of this technique has been demonstrated.
> I do concede that there are one or two vendors who have
> view graphs claiming that "Synch and Steering" layer will allow
> them to build a more cost effective product.  However after doing
> a considerable amount of study on iSCSI HBA design, I have serious
> doubts about the viability of this approach.  I am more than happy to
> be proven wrong on this, but the operative word is "proven".
 
That's fair.  I view the level of requirement (MUST/SHOULD/
MAY) as an open issue - to the extent that Julian expressed
a preference for something stronger than MAY, that is not
the rough consensus of the IPS WG.  Further discussion is
encouraged, and I hope to see this issue resolved by/at
the February interim meeting.  FWIW, I have heard from
other hardware implementers that markers are not a make
or break product requirement at 1 Gbit/sec, but they
will have to speak for themselves in the WG.
 
Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------

 
 -----Original Message-----
From: Williams, Jim [mailto:Jim.Williams@emulex.com]
Sent: Wednesday, December 26, 2001 1:15 PM
To: 'Julian Satran'; ips@ece.cmu.edu
Subject: RE: iSCSI - Synch an Steering Appendix - Markers & COWS

 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, December 23, 2001 2:19 PM
To: ips@ece.cmu.edu
Subject: iSCSI - Synch an Steering Appendix - Markers & COWS


Dear colleagues,

Attached are the two versions of the Synch and Steering appendix that we are considering.

During the SLC meeting we tentatively agreed that we will consider the markers (ugly but workable) and a new alternative Constant Overhead Word stuffing that I had to draft.

We also agreed that we will strive to have only one such option and we would like to have it required somewhat stronger (sender should provide it if receiver wants it).  
 
I believe there is also a third alternative under consideration which is a length/key
encoding which is considerably simpler and easier to implement.  The primary
objection to this mechanism is due to its probabilistic nature, however this
objection seems based more on superstition than on any analysis showing
that the overall reliability of the system is in any way compromised by
the probabilistic nature.
 
In any case, my understanding is that this is also under consideration
in TSV working group, so I would hope that IPS will defer to their
choice and not try to go it alone regarding the decision.
 
However, I would strongly object to the "SHOULD implement".
I believe this should be made a "SHOULD implement" only
after the benefit of this technique has been demonstrated.
I do concede that there are one or two vendors who have
view graphs claiming that "Synch and Steering" layer will allow
them to build a more cost effective product.  However after doing
a considerable amount of study on iSCSI HBA design, I have serious
doubts about the viability of this approach.  I am more than happy to
be proven wrong on this, but the operative word is "proven".
 
I am bothered that a small minority of implementors want everyone
else to de-optimize their designs so that they can optimize their
own, especially when I suspect the approach is technically flawed
to begin with.
 
And, if the "Sync and Steering" approach is successful, it will quickly
become a de-facto standard anyway, so I would urge the IETF
to remain a bit more neutral on this for now.
 
Any comments/questions are welcome.

Happy holidays and a peaceful and prosperous 2002,
Julo  
 
Thanks for considering my coments, and best to all as well,
 - Jim
 
 

------_=_NextPart_001_01C18E83.4F128BC0-- From owner-ips@ece.cmu.edu Thu Dec 27 12:11:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18574 for ; Thu, 27 Dec 2001 12:11:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBRGADB27958 for ips-outgoing; Thu, 27 Dec 2001 11:10:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBRGABZ27953 for ; Thu, 27 Dec 2001 11:10:11 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Dec 2001 11:10:04 -0500 Message-ID: <25369470B6F0D41194820002B328BDD21163BB@ATLOPS> From: Sanjay Goyal To: "'Julian Satran'" , Eddy Quicksall Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: LUN in Data-out and NOP PDU's Date: Thu, 27 Dec 2001 11:09:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18EF0.EBED57A0" Sender: owner-ips@ece.cmu.edu 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_01C18EF0.EBED57A0 Content-Type: text/plain; charset="iso-8859-1" Hi to be very specific on the question, Nop-out and Nop-in PDUs are used by Initiators and Targets also to ping each other. If a target is trying to ping the Initiator, why does it need to use a particular combination of TTT and LUN i.e. the "virtual target". Should we really use TTT and LUN pair for a function which is for target and not for "virtual target" OR am i missing something. Regards Sanjay Goyal -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, December 22, 2001 3:37 AM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: Re: iSCSI: LUN in Data-out and NOP PDU's Eddy, It was felt that TTT management could be kept local to the LU or group of LUs (no requirement to be unique on target). The combination LU and TTT is used instead. That enables groups of entities to form a "virtual target". Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 21-12-01 22:38 To: "ips@ece. cmu. edu \(E-mail\)" cc: Subject: iSCSI: LUN in Data-out and NOP PDU's What is the LUN for in Data-out and NOP-out PDU's? I assume the LUN in Data-out could be used for steering but I don't know what the LUN in NOP-out PDU's is for. Eddy ------_=_NextPart_001_01C18EF0.EBED57A0 Content-Type: text/html; charset="iso-8859-1"
Hi 
to be very specific on the question,
 Nop-out and Nop-in PDUs are used by Initiators and Targets also to ping each other. If a target is trying to ping the Initiator, why does it need to use a particular combination of TTT and LUN i.e. the "virtual target". 
Should we really use TTT and LUN pair for a function which is for target and not for "virtual target"  OR am i missing something.
 
Regards
Sanjay Goyal
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Saturday, December 22, 2001 3:37 AM
To: Eddy Quicksall
Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu
Subject: Re: iSCSI: LUN in Data-out and NOP PDU's


Eddy,

It was felt that TTT management could be kept local to the LU or group of LUs (no requirement to be unique on target).
The combination LU and TTT is used instead. That enables groups of entities to form a "virtual target".

Julo


"Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

21-12-01 22:38

       
        To:        "ips@ece. cmu. edu \(E-mail\)" <ips@ece.cmu.edu>
        cc:        
        Subject:        iSCSI: LUN in Data-out and NOP PDU's



What is the LUN for in Data-out and NOP-out PDU's?

I assume the LUN in Data-out could be used for steering but I don't know what the LUN in NOP-out PDU's is for.

Eddy

------_=_NextPart_001_01C18EF0.EBED57A0-- From owner-ips@ece.cmu.edu Fri Dec 28 12:43:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10197 for ; Fri, 28 Dec 2001 12:43:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSHFE118913 for ips-outgoing; Fri, 28 Dec 2001 12:15:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSHFCZ18908 for ; Fri, 28 Dec 2001 12:15:12 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e32.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA67398; Fri, 28 Dec 2001 12:12:11 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBSHEv2133916; Fri, 28 Dec 2001 10:14:57 -0700 Importance: Normal Subject: Re: FW: iSCSI: "conservative reuse" requirement To: "John Hufferd" , "Eddy Quicksall" , "Mallikarjun C." , Black_David@emc.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Fri, 28 Dec 2001 17:14:51 +0000 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/28/2001 09:15:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Dec 28 12:49:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10237 for ; Fri, 28 Dec 2001 12:49:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSGiHW17242 for ips-outgoing; Fri, 28 Dec 2001 11:44:17 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBS37JZ00533 for ; Thu, 27 Dec 2001 22:07:20 -0500 (EST) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBS37DG03931 for ; Thu, 27 Dec 2001 22:07:13 -0500 (EST) Subject: Change of email address Date: Thu, 27 Dec 2001 22:07:08 -0500 Message-ID: <9410A0F67DFE7F4D998D45382364983604091E@nc8220exchange.ral.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Change of email address content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGPTIGmGpC/Tb1ZSCmTY/DEW+xtMg== From: "Elizabeth Rodriguez" To: "Allison Mankin (E-mail)" , "David Black (E-mail)" , "Scott Bradner (E-mail)" , "Murali Rajagopal (E-mail)" , "Franco Travostino (E-mail)" , "John Hufferd (E-mail)" , "Yaron Lederman (E-mail)" Cc: "IPS Mailing List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id fBS37LZ00537 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, I am leaving Lucent, as of December 31. My email address may go inactive as of Dec 28. So, any new email for me needs to be redirected to my new email address ElizabethRodriguez@ieee.org. Alternate address is Elizabeth.G.Rodriguez@usa.net Thanks, Elizabeth From owner-ips@ece.cmu.edu Fri Dec 28 14:41:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11149 for ; Fri, 28 Dec 2001 14:41:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSIx2l24399 for ips-outgoing; Fri, 28 Dec 2001 13:59:02 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSIx0Z24395 for ; Fri, 28 Dec 2001 13:59:00 -0500 (EST) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id fBSIwpn19376; Fri, 28 Dec 2001 13:58:51 -0500 (EST) From: "Eddy Quicksall" To: "ips@ece. cmu. edu \(E-mail\)" Cc: "'Sanjay Goyal'" Subject: RE: iSCSI: LUN in Data-out and NOP PDU's Date: Fri, 28 Dec 2001 13:58:32 -0500 Message-ID: <000301c18fd1$a8c51670$0202a8c0@eddylaptop> 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 In-Reply-To: <25369470B6F0D41194820002B328BDD21163C1@ATLOPS> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1) Can someone please give an example of how the LUN would be used in a NOP PDU. 2) If the NOP-In is used as a ping, the TTT is set to a valid value and the LUN must be set to a correct value when the TTT is valid. But, if the ping comes from the target (not an LU), then what should the LUN contain? Eddy -----Original Message----- From: Sanjay Goyal [mailto:sanjay_goyal@ivivity.com] Sent: Friday, December 28, 2001 1:38 PM To: Eddy Quicksall Subject: FW: iSCSI: LUN in Data-out and NOP PDU's -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, December 28, 2001 11:17 AM To: Sanjay Goyal Subject: RE: iSCSI: LUN in Data-out and NOP PDU's Sanjay, I am not sure I understand you question. The NOPs follow the pattern of all other target to initiator PDUs that expect a follow-up action (like R2T) when they do. For this they use TTT+LUN. If they are originated or not at the LU or a front-end device is an "implementation detail". Julo Sanjay Goyal cc: "'ips@ece.cmu.edu'" 27-12-01 18:09 Subject: RE: iSCSI: LUN in Data-out and NOP PDU's Hi to be very specific on the question, Nop-out and Nop-in PDUs are used by Initiators and Targets also to ping each other. If a target is trying to ping the Initiator, why does it need to use a particular combination of TTT and LUN i.e. the "virtual target". Should we really use TTT and LUN pair for a function which is for target and not for "virtual target" OR am i missing something. Regards Sanjay Goyal -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Saturday, December 22, 2001 3:37 AM To: Eddy Quicksall Cc: ips@ece. cmu. edu (E-mail); owner-ips@ece.cmu.edu Subject: Re: iSCSI: LUN in Data-out and NOP PDU's Eddy, It was felt that TTT management could be kept local to the LU or group of LUs (no requirement to be unique on target). The combination LU and TTT is used instead. That enables groups of entities to form a "virtual target". Julo "Eddy Quicksall" To: "ips@ece. cmu. Sent by: owner-ips@ece.cmu.edu edu \(E-mail\)" cc: Subject: iSCSI: LUN 21-12-01 22:38 in Data-out and NOP PDU's What is the LUN for in Data-out and NOP-out PDU's? I assume the LUN in Data-out could be used for steering but I don't know what the LUN in NOP-out PDU's is for. Eddy From owner-ips@ece.cmu.edu Fri Dec 28 14:43:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11162 for ; Fri, 28 Dec 2001 14:43:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSJKMZ25502 for ips-outgoing; Fri, 28 Dec 2001 14:20:22 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSJKLZ25497 for ; Fri, 28 Dec 2001 14:20:21 -0500 (EST) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id fBSJK8n20978; Fri, 28 Dec 2001 14:20:09 -0500 (EST) From: "Eddy Quicksall" To: "'Jim Hafner'" Cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Fri, 28 Dec 2001 14:19:33 -0500 Message-ID: <000501c18fd4$a1b113e0$0202a8c0@eddylaptop> 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target port, there can be only one I_T nexus (session)", aren't we always "assuming no more than one session"? Or are you talking about more than one session between different SCSI initiator ports and a single SCSI target port? Is the ISID equivalent to SAM-2's Initiator Port Identifier? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, December 28, 2001 12:15 PM To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: FW: iSCSI: "conservative reuse" requirement Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Dec 28 16:52:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12245 for ; Fri, 28 Dec 2001 16:52:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSL5Dt00857 for ips-outgoing; Fri, 28 Dec 2001 16:05:13 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls16.mediaone.net (chmls16.mediaone.net [24.147.1.151]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSL5Bg00852 for ; Fri, 28 Dec 2001 16:05:11 -0500 (EST) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls16.mediaone.net (8.11.1/8.11.1) with SMTP id fBSL1Jn01208; Fri, 28 Dec 2001 16:01:19 -0500 (EST) From: "Eddy Quicksall" To: "julian_satran@il. ibm. com \(E-mail\)" Cc: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: the I bit in response PDU's Date: Fri, 28 Dec 2001 16:00:51 -0500 Message-ID: <000d01c18fe2$c4f9ca50$0202a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C18FB8.DC23C250" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C18FB8.DC23C250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit A while back, I wondered why the I bit needs to be set in all response PDU’s. That generated some discussion but none had the answer. What is the reason? If there is not one, can we make it a 0? Eddy ------=_NextPart_000_000E_01C18FB8.DC23C250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A while back, I wondered why the I bit needs to be set in all = response PDU’s. That generated some discussion but none had the = answer.

 

What is the reason? If there is not one, can we make it a = 0?

 

Eddy

------=_NextPart_000_000E_01C18FB8.DC23C250-- From owner-ips@ece.cmu.edu Fri Dec 28 18:44:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12798 for ; Fri, 28 Dec 2001 18:44:36 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSN3Cf06923 for ips-outgoing; Fri, 28 Dec 2001 18:03:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSN3Ag06912 for ; Fri, 28 Dec 2001 18:03:10 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA32304; Fri, 28 Dec 2001 17:59:36 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBSN2QN143130; Fri, 28 Dec 2001 16:02:26 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: "Eddy Quicksall" Cc: "ips@ece. cmu. edu \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Dec 2001 15:01:29 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/28/2001 04:02:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, There can be parallel Sessions from the same Initiator NODE but not from the same Initiator SCSI Port (which I call the Initiator iSCSI/SCSI Port). It is invalid to have more then one Session between an Initiator SCSI Port and a specific Target SCSI Port (which I call the Target iSCSI/SCSI Port). The Identifier of the Initiator iSCSI/SCSI Port is the Concatenation of Initiator Node Name and the ISID. The Identifier of the Target iSCSI/SCSI Port is the Concatenation of the Target Node Name and a Target Portal Group Tag. SAM-2 Initiator Port Identifier, in the context of iSCSI, is the Identifier of what I called the Initiator iSCSI/SCSI Port. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" @ece.cmu.edu on 12/28/2001 11:19:33 AM Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target port, there can be only one I_T nexus (session)", aren't we always "assuming no more than one session"? Or are you talking about more than one session between different SCSI initiator ports and a single SCSI target port? Is the ISID equivalent to SAM-2's Initiator Port Identifier? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, December 28, 2001 12:15 PM To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: FW: iSCSI: "conservative reuse" requirement Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Fri Dec 28 19:49:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13076 for ; Fri, 28 Dec 2001 19:49:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBSNwTD09579 for ips-outgoing; Fri, 28 Dec 2001 18:58:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBSNwNg09572 for ; Fri, 28 Dec 2001 18:58:23 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA15846 for ; Fri, 28 Dec 2001 17:55:26 -0600 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBSNwJJ276878 for ; Fri, 28 Dec 2001 16:58:19 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: FW: iSCSI: "conservative reuse" requirement To: "Jim Hafner" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 28 Dec 2001 15:57:22 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/28/2001 04:58:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk It is true that this does not need to be MUST, but it seems silly not to make it MUST or SHOULD. To think that a vendor would want to have a price feature that has the HBA or the Device Driver using the same ISID with Conservative reuse, seems very unlikely. Likewise, I can not think of a customer advantage not to have Conservative reuse. When a customer installs the HBA and Device Driver and then finds that he must change the SW or HW if he wishes to Share LUs among a number of Systems, that customer will be very disappointed, and will be upset if the vendor then tries to sell him this upgrade especially when the vendors do not charge extra. Since Conservative Reuse (just reusing the same ISID over and over) requires no more and probably less code, and has potential customer impacts if not done, we should strongly come down on the side of the customer. I think the Spec should work to prevent this silliness, and specify either MUST or SHOULD. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Jim Hafner 12/28/2001 09:14 AM To: John Hufferd/San Jose/IBM@IBMUS, "Eddy Quicksall" , "Mallikarjun C." , Black_David@emc.com cc: ips@ece.cmu.edu From: Jim Hafner/Almaden/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: John Hufferd) Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Sat Dec 29 12:10:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28636 for ; Sat, 29 Dec 2001 12:10:57 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBTGHQW03083 for ips-outgoing; Sat, 29 Dec 2001 11:17:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBTGHNg03076 for ; Sat, 29 Dec 2001 11:17:24 -0500 (EST) Received: from eddylaptop (equicksall.ne.mediaone.net [24.61.64.49]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id fBTGIcx10015; Sat, 29 Dec 2001 11:18:38 -0500 (EST) From: "Eddy Quicksall" To: "julian_satran@il. ibm. com \(E-mail\)" Cc: "ips@ece. cmu. edu \(E-mail\)" Subject: iSCSI: definitions Date: Sat, 29 Dec 2001 11:16:28 -0500 Message-ID: <001101c19084$38e6d7e0$0202a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C1905A.5010CFE0" 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C1905A.5010CFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 1) SAM-2 defines “initiator” as “a SCSI initiator port”. iSCSI uses “initiator” to mean the “SCSI Initiator Device” as in ‘iSCSI Initiator Node: The "initiator"’ (because we say “there can be at most one SCSI Device within a given iSCSI Node” so the node is the device). Should we be consistent with SAM-2? 2) We don’t specifically define the “iSCSI Initiator” (I agree ... it is implied to be the same as iSCSI Initiator Node). My I suggest we define it based on the answer to question 1? 3) Is the iSCSI Target Name equivalent to the SCSI Target Device Name? If so, can we specify that? Eddy ------=_NextPart_000_0012_01C1905A.5010CFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

1) SAM-2 defines = “initiator” as “a SCSI initiator port”. iSCSI uses “initiator” to mean the = “SCSI Initiator Device” as in ‘iSCSI Initiator Node: The "initiator"’ (because we say = “there can be at most one SCSI Device within a given iSCSI Node” so the node is the = device).

 

Should we be consistent with SAM-2?

 

2) We don’t specifically define the “iSCSI Initiator” (I = agree ... it is implied to be the same as iSCSI Initiator Node).

 

My I suggest we define it based on the answer to question = 1?

 

3) Is the iSCSI Target Name equivalent to the SCSI Target Device Name? If so, = can we specify that?

 

Eddy

 

 <= /p>

------=_NextPart_000_0012_01C1905A.5010CFE0-- From owner-ips@ece.cmu.edu Sat Dec 29 18:19:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01338 for ; Sat, 29 Dec 2001 18:19:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBTMaGt20647 for ips-outgoing; Sat, 29 Dec 2001 17:36:16 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBTMaEg20642 for ; Sat, 29 Dec 2001 17:36:14 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA205552 for ; Sat, 29 Dec 2001 15:38:52 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBTKfW8114498 for ; Sat, 29 Dec 2001 13:41:32 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Text Request & Text Response Brackets and Colons To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 29 Dec 2001 12:40:48 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/29/2001 01:41:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Our current document talks about the characters that are permitted in Text Request and Text Response PDUs. However, it does not permit the characters -- Brackets ([ and ]) and Colon (:). Therefore, we must update that text or it will not be possible to support some of the values shown in Appendix D. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Dec 29 18:37:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01420 for ; Sat, 29 Dec 2001 18:37:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBTNGBt22360 for ips-outgoing; Sat, 29 Dec 2001 18:16:11 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBTNG9g22356 for ; Sat, 29 Dec 2001 18:16:09 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA41774; Sat, 29 Dec 2001 18:11:30 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBTNENE116146; Sat, 29 Dec 2001 16:14:24 -0700 Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: "Eddy Quicksall" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Sat, 29 Dec 2001 23:14:16 +0000 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/29/2001 03:14:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, The SCSI initiator port is modeled as the endpoint of the iSCSI session; the SCSI target port is modeled as the iSCSI target portal group. The reason we did it this way was to allow more than one session between portal groups by allowing multi-plexing of sessions with different ISIDs from the same iSCSI initiator portal group to the same target portal group. So, the answer to your questions are: 1) no, we're assuming no more than on session *with the same ISID* to the same target portal group (that'd be more than one nexus), but by allowing different ISIDs we get different SCSI initiator ports. 2) no, we're allowing more than one session between an iSCSI initiator portal group and an iSCSI target portal group (each session has a different SCSI initiator port (id'ed by its ISID) but the same SCSI target port (id'ed by its portal group tag). 3) sort of, the ISID together with the iSCSI Initiator Name fully identifies the SCSI initiator port (and so defines the SCSI initiator port name and the identifier). Does that clear this up? Jim Hafner "Eddy Quicksall" on 12/28/2001 07:19:33 PM To: Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target port, there can be only one I_T nexus (session)", aren't we always "assuming no more than one session"? Or are you talking about more than one session between different SCSI initiator ports and a single SCSI target port? Is the ISID equivalent to SAM-2's Initiator Port Identifier? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, December 28, 2001 12:15 PM To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: FW: iSCSI: "conservative reuse" requirement Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Sat Dec 29 18:38:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01437 for ; Sat, 29 Dec 2001 18:38:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBTNLuj22609 for ips-outgoing; Sat, 29 Dec 2001 18:21:56 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBTNLtg22605 for ; Sat, 29 Dec 2001 18:21:55 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA27580 for ; Sat, 29 Dec 2001 18:18:16 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBTNL9E143632 for ; Sat, 29 Dec 2001 16:21:09 -0700 Importance: Normal Subject: Re: FW: iSCSI: "conservative reuse" requirement To: "John Hufferd" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Sat, 29 Dec 2001 23:21:03 +0000 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/29/2001 03:21:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, You make sense here. I have no problem with SHOULD, I just don't think there is a fundamental structural or architectural need for MUST. Jim Hafner John Hufferd 12/28/2001 11:57 PM To: Jim Hafner/Almaden/IBM cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) It is true that this does not need to be MUST, but it seems silly not to make it MUST or SHOULD. To think that a vendor would want to have a price feature that has the HBA or the Device Driver using the same ISID with Conservative reuse, seems very unlikely. Likewise, I can not think of a customer advantage not to have Conservative reuse. When a customer installs the HBA and Device Driver and then finds that he must change the SW or HW if he wishes to Share LUs among a number of Systems, that customer will be very disappointed, and will be upset if the vendor then tries to sell him this upgrade especially when the vendors do not charge extra. Since Conservative Reuse (just reusing the same ISID over and over) requires no more and probably less code, and has potential customer impacts if not done, we should strongly come down on the side of the customer. I think the Spec should work to prevent this silliness, and specify either MUST or SHOULD. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Jim Hafner 12/28/2001 09:14 AM To: John Hufferd/San Jose/IBM@IBMUS, "Eddy Quicksall" , "Mallikarjun C." , Black_David@emc.com cc: ips@ece.cmu.edu From: Jim Hafner/Almaden/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: John Hufferd) Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Sat Dec 29 23:37:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05053 for ; Sat, 29 Dec 2001 23:37:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBU3uLv04967 for ips-outgoing; Sat, 29 Dec 2001 22:56:21 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBU3uKg04962 for ; Sat, 29 Dec 2001 22:56:20 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id WAA09226 for ; Sat, 29 Dec 2001 22:52:38 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBU3t3F107208 for ; Sat, 29 Dec 2001 20:55:04 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Time2Retain To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 29 Dec 2001 19:54:20 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/29/2001 08:55:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I am wondering if we have a minor discrepancy between the Asynchronous Message PDU and the Logout Response PDU. The Asynchronous Message Parameter3 is the "Time2Retain" variable, and it is the maximum time to reconnect after the initial wait (Parameter2) which is the "Time2Wait". The Logout Response PDU has both the "Time2Wait" and the "Time2Retain" but the "Time2Retain" is defined as the "maximum time that the target waits for a connection reinstatement Login after which the connection state is discarded", and that definition makes no reference to the "Time2Wait". Since Both "Time2Wait" and "Time2Retain" are specified in both PDUs, the question is: did we intend in the Logout Response PDU to have no relation between the two values, and did we intend the two Commands to have different interpretations of the "Time2Retain" variable? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sat Dec 29 23:38:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05064 for ; Sat, 29 Dec 2001 23:38:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBU4UvW06432 for ips-outgoing; Sat, 29 Dec 2001 23:30:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBU4Usg06425 for ; Sat, 29 Dec 2001 23:30:54 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id FAA24150; Sun, 30 Dec 2001 05:30:45 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBU4VQf16684; Sun, 30 Dec 2001 05:31:26 +0100 To: "Eddy Quicksall" Cc: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iSCSI: the I bit in response PDU's X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Sun, 30 Dec 2001 06:31:24 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/12/2001 06:31:30, Serialize complete at 30/12/2001 06:31:30 Content-Type: multipart/alternative; boundary="=_alternative 0057FA5FC2256B31_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0057FA5FC2256B31_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable People have become sensitive even to minor changes so we may want to call=20 for a consensus. Julo "Eddy Quicksall" 29-12-01 15:51 =20 To: Julian Satran/Haifa/IBM@IBMIL cc:=20 Subject: RE: iSCSI: the I bit in response PDU's =20 Well, the problem I see, if it is left in just due to history, you will=20 get people thinking like we have seen IOL think ? "it must be checked" or=20 like me ? "what is it for" or like someone else ? "attaching an assumed=20 significance to it". =20 Also, if it is left a 1 for no reason, it is more difficult to give it a=20 meaning later if it is needed. =20 My vote would be to make it a 0 and call it "reserved". =20 I wonder if others have simply forgotten about it and the question needs=20 to be asked for a consensus? =20 Eddy =20 -----Original Message----- From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] Sent: Saturday, December 29, 2001 4:20 AM To: Eddy Quicksall Subject: Re: iSCSI: the I bit in response PDU's =20 Eddy,=20 It is only history and nobody (including myself) bothered to change it.=20 We could make it 0 - but what exactly would that buy us?=20 I am waiting for others to share your concern about regularity.=20 Regards,=20 Julo=20 =20 "Eddy Quicksall" =20 Sent by: owner-ips@ece.cmu.edu=20 28-12-01 23:00=20 =20 To: Julian Satran/Haifa/IBM@IBMIL=20 cc: "ips@ece. cmu. edu \(E-mail\)" =20 Subject: iSCSI: the I bit in response PDU's=20 =20 A while back, I wondered why the I bit needs to be set in all response=20 PDU's. That generated some discussion but none had the answer.=20 =20 What is the reason? If there is not one, can we make it a 0?=20 =20 Eddy=20 --=_alternative 0057FA5FC2256B31_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
People have become sensitive even to= minor changes so we may want to call for a consensus.

Julo


"Eddy Quicksall" <Ed= dy=5FQuicksall@iVivity.com>

29-12-01 15:51

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      
        Subject:=        RE: iSCSI: the I bit in response PDU's

       


Well, the problem I see, = if it is left in just due to history, you will get people thinking like we = have seen IOL think … "it must be checked" or like me … "what i= s it for" or like someone else … "attaching an assumed significance t= o it".

 

Also, if it is left a 1 fo= r no reason, it is more difficult to give it a meaning later if it is neede= d.

 

My vote would be to make i= t a 0 and call it "reserved".

 

I wonder if others have si= mply forgotten about it and the question needs to be asked for a consensus?=

 

Eddy

 

-----Original Message-----
From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
Sent: Saturday, December 29, 2001 4:20 AM
To: Eddy Quicksall
Subject: Re: iSCSI: the I bit in response PDU's

 


Eddy,

It is only history and nobody (including myself) bothered to change it.
We could make it 0 - but what exactly would that buy us?
I am waiting for others to share your concern about regularity.

Regards,
Julo

  "Eddy Quicksall&= quot; <Eddy=5FQuicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu28-12-01 23:00 		        <= /font>
       To:        Julian Satran/Ha= ifa/IBM@IBMIL
       cc:        "ips@ece. c= mu. edu \(E-mail\)" <ips@ece.cmu.edu>
       Subject:        iSCSI: the = I bit in response PDU's

     



A while back, I wondered why the I bit needs to be set in all response PDU'= s. That generated some discussion but none had the answer.

 

What is the reason? If there is not one, c= an we make it a 0?

 

Eddy

--=_alternative 0057FA5FC2256B31_=-- From owner-ips@ece.cmu.edu Sun Dec 30 04:31:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14657 for ; Sun, 30 Dec 2001 04:31:22 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBU8dEb17086 for ips-outgoing; Sun, 30 Dec 2001 03:39:14 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBU8dCg17081 for ; Sun, 30 Dec 2001 03:39:12 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.99.140.24]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id DAA130048 for ; Sun, 30 Dec 2001 03:36:14 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay03.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBU8d9F61822 for ; Sun, 30 Dec 2001 01:39:09 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Terminology problem with the term Command Recovery within Session To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Dec 2001 00:38:25 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/30/2001 01:39:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I have found a problem with the Term "Command Recovery within Session". We use this Term in the SNACK Request PDU, and in Section 2.2.8 but it is not explained, defined, or described in the Error Recovery Section (8). The following Recovery Classes are defined: 1. Recovery Within-command 2. Recovery Within-connection 3. Connection Recovery 4. Session Recovery Which Recovery Class was SNACK Request PDU and Section 2.2.8 referring to when they used the Term "Command Recovery within Session"? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun Dec 30 05:04:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14862 for ; Sun, 30 Dec 2001 05:04:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBU9NU718947 for ips-outgoing; Sun, 30 Dec 2001 04:23:30 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBU9NSg18941 for ; Sun, 30 Dec 2001 04:23:28 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA145084 for ; Sun, 30 Dec 2001 04:20:31 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBU9NP8190004 for ; Sun, 30 Dec 2001 02:23:25 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Inconsistent RUN Length 0 Meaning To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Dec 2001 01:22:38 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/30/2001 02:23:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, There may be an inconsistency in the Description of a Run Length of 0. The following Statement was made in the 2nd Paragraph of section 3.16 (SNACK Request): "... The SNACK request indicates to the Target the missed numbered-response or data run, where the run is composed of an initial missed StatSN, DataSN or R2TSN and the number of additional missed Status, Data or R2T PDUs (0 means only the initial)." Then later on in paragraph 4 is the following statement: "... Data-In PDUs requested with RunLength 0 (meaning all after this number) ..." So this seems to mean that either RunLength of 0 can mean lots of Data_ PDUs in the RUN (i.e. all after this number), or it can mean only one (i.e. only the initial). So my question is what does a Run Length of 0 really mean, and independent of your answer, I think we should do something to enhance/correct the above wording in section 3.16. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun Dec 30 08:37:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15982 for ; Sun, 30 Dec 2001 08:37:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBUD0sN08608 for ips-outgoing; Sun, 30 Dec 2001 08:00:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBUD0pg08597 for ; Sun, 30 Dec 2001 08:00:52 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id OAA11988 for ; Sun, 30 Dec 2001 14:00:45 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBUD1PN103300 for ; Sun, 30 Dec 2001 14:01:25 +0100 Subject: Re: iSCSI:Time2Retain To: "John Hufferd" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 30 Dec 2001 12:25:48 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/12/2001 15:01:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, The intent of the parametrs is the same and we will fix the wording to say it. Thanks, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu 30-12-01 05:54 From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI:Time2Retain Julian, I am wondering if we have a minor discrepancy between the Asynchronous Message PDU and the Logout Response PDU. The Asynchronous Message Parameter3 is the "Time2Retain" variable, and it is the maximum time to reconnect after the initial wait (Parameter2) which is the "Time2Wait". The Logout Response PDU has both the "Time2Wait" and the "Time2Retain" but the "Time2Retain" is defined as the "maximum time that the target waits for a connection reinstatement Login after which the connection state is discarded", and that definition makes no reference to the "Time2Wait". Since Both "Time2Wait" and "Time2Retain" are specified in both PDUs, the question is: did we intend in the Logout Response PDU to have no relation between the two values, and did we intend the two Commands to have different interpretations of the "Time2Retain" variable? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun Dec 30 08:40:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16008 for ; Sun, 30 Dec 2001 08:40:12 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBUD0s308609 for ips-outgoing; Sun, 30 Dec 2001 08:00:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBUD0qg08603 for ; Sun, 30 Dec 2001 08:00:53 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id OAA11990 for ; Sun, 30 Dec 2001 14:00:46 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBUD1QN103302 for ; Sun, 30 Dec 2001 14:01:26 +0100 Subject: Re: iSCSI:Terminology problem with the term Command Recovery within Session To: "John Hufferd" Cc: ips@ece.cmu.edu, "Julian Satran" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: From: "Julian Satran" Date: Sun, 30 Dec 2001 12:32:22 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/12/2001 15:01:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, We refer to connection recovery. Will fix wording. Thanks, Julo John Hufferd@IBMUS To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu 30-12-01 10:38 From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI:Terminology problem with the term Command Recovery within Session Julian, I have found a problem with the Term "Command Recovery within Session". We use this Term in the SNACK Request PDU, and in Section 2.2.8 but it is not explained, defined, or described in the Error Recovery Section (8). The following Recovery Classes are defined: 1. Recovery Within-command 2. Recovery Within-connection 3. Connection Recovery 4. Session Recovery Which Recovery Class was SNACK Request PDU and Section 2.2.8 referring to when they used the Term "Command Recovery within Session"? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun Dec 30 18:35:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18518 for ; Sun, 30 Dec 2001 18:35:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBUMeTW04510 for ips-outgoing; Sun, 30 Dec 2001 17:40:29 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBUMeRg04504 for ; Sun, 30 Dec 2001 17:40:27 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.99.140.22]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA169336 for ; Sun, 30 Dec 2001 17:37:07 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBUMdXV155952 for ; Sun, 30 Dec 2001 15:39:33 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Dec 2001 14:38:47 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/30/2001 03:39:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, in the SNACK Request PDU (section 3.16), there is the statements that current values of ExpStatSN and ExpDataSN should be used on the resent PDUs, but no mention of sending the current values of ExpCmdSN or MaxCmdSN. I have thought that those also should be included in the fields that must be current when resent. Is there any reason to exempt those fields? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Sun Dec 30 19:47:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18900 for ; Sun, 30 Dec 2001 19:47:03 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBUNskZ07455 for ips-outgoing; Sun, 30 Dec 2001 18:54:46 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBUNsig07448 for ; Sun, 30 Dec 2001 18:54:44 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA23724 for ; Sun, 30 Dec 2001 18:51:34 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBUNsKD60186 for ; Sun, 30 Dec 2001 16:54:20 -0700 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: SNACK and ExpDataSN To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Dec 2001 15:53:34 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/30/2001 04:54:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The Section 3.16.1(dealing with SNACK) states: "For a Status SNACK the ExpDataSN field is reserved." I can not think of a reason that it should be used for Data/R2T SNACK either. Especially since the Begin Run field identifies the begging of the missing Data. Perhaps it should be revised to state "The ExpDataSN field is reserved except for use with the Positive Acknowledgement SNACK." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Dec 31 01:48:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23539 for ; Mon, 31 Dec 2001 01:48:25 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBV5rlo20577 for ips-outgoing; Mon, 31 Dec 2001 00:53:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBV5rjg20573 for ; Mon, 31 Dec 2001 00:53:45 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id GAA69984 for ; Mon, 31 Dec 2001 06:53:38 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBV5sLb34754 for ; Mon, 31 Dec 2001 06:54:21 +0100 To: "John Hufferd" Cc: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: SNACK and ExpDataSN X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 31 Dec 2001 07:54:20 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/12/2001 07:54:22, Serialize complete at 31/12/2001 07:54:22 Content-Type: multipart/alternative; boundary="=_alternative 0020085CC2256B33_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0020085CC2256B33_= Content-Type: text/plain; charset="us-ascii" John, If look at the field numbering you will see that my intent was to take out ExpDataSN. I don't know how it ended up staying in. Thanks anyhow, Julo John Hufferd@IBMUS 31-12-01 01:53 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI: SNACK and ExpDataSN Julian, The Section 3.16.1(dealing with SNACK) states: "For a Status SNACK the ExpDataSN field is reserved." I can not think of a reason that it should be used for Data/R2T SNACK either. Especially since the Begin Run field identifies the begging of the missing Data. Perhaps it should be revised to state "The ExpDataSN field is reserved except for use with the Positive Acknowledgement SNACK." . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 0020085CC2256B33_= Content-Type: text/html; charset="us-ascii"
John,

If look at the field numbering you will see that my intent was to take out ExpDataSN.
I don't know how it ended up staying in.

Thanks anyhow,
Julo


John Hufferd@IBMUS

31-12-01 01:53

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI: SNACK and ExpDataSN

       


Julian,
The Section 3.16.1(dealing with SNACK) states:

"For a Status SNACK the ExpDataSN field is reserved."

I can not think of a reason that it should be used for Data/R2T SNACK either.  Especially since the Begin Run field identifies the begging of the missing Data.

Perhaps it should be revised to state "The ExpDataSN field is reserved except for use with the Positive Acknowledgement SNACK."

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 0020085CC2256B33_=-- From owner-ips@ece.cmu.edu Mon Dec 31 01:48:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23550 for ; Mon, 31 Dec 2001 01:48:38 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBV6Gv421361 for ips-outgoing; Mon, 31 Dec 2001 01:16:57 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBV6Grg21353; Mon, 31 Dec 2001 01:16:53 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id HAA22156; Mon, 31 Dec 2001 07:16:40 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBV6HNb110756; Mon, 31 Dec 2001 07:17:23 +0100 To: "John Hufferd" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 31 Dec 2001 08:17:21 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/12/2001 08:17:24, Serialize complete at 31/12/2001 08:17:24 Content-Type: multipart/alternative; boundary="=_alternative 00218E3CC2256B33_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00218E3CC2256B33_= Content-Type: text/plain; charset="us-ascii" John, The current text reads: The numbered-response, or R2T, requested by a SNACK have to be deliv-ered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN, MaxCmdSN and ExpDataSN fields that MUST carry the current values. The numbered Data-In PDUs, individually requested by a SNACK, have to be delivered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN and MaxCmdSN fields that MUST carry they current values. Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent in order to reflect changes in MaxRecvPDULength. Regards, Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-12-01 00:38 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN Julian, in the SNACK Request PDU (section 3.16), there is the statements that current values of ExpStatSN and ExpDataSN should be used on the resent PDUs, but no mention of sending the current values of ExpCmdSN or MaxCmdSN. I have thought that those also should be included in the fields that must be current when resent. Is there any reason to exempt those fields? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com --=_alternative 00218E3CC2256B33_= Content-Type: text/html; charset="us-ascii"
John,

The current text reads:

The numbered-response, or R2T, requested by a SNACK have to be deliv-ered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN, MaxCmdSN and ExpDataSN fields that MUST carry the current values.

The numbered Data-In PDUs, individually requested by a SNACK, have to be delivered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN and MaxCmdSN fields that MUST carry they current values.  Data-In PDUs requested with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent in order to reflect changes in MaxRecvPDULength.

Regards,
Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

31-12-01 00:38

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN

       


Julian,
in the SNACK Request PDU (section 3.16), there is the statements that
current values of ExpStatSN and ExpDataSN should be used on the resent
PDUs, but no mention of sending the current values of ExpCmdSN or MaxCmdSN.
I have thought that those also should be included in the fields that must
be current when resent.

Is there any reason to exempt those fields?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com

--=_alternative 00218E3CC2256B33_=-- From owner-ips@ece.cmu.edu Mon Dec 31 03:44:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02360 for ; Mon, 31 Dec 2001 03:44:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBV7mlJ24480 for ips-outgoing; Mon, 31 Dec 2001 02:48:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBV7mkg24474 for ; Mon, 31 Dec 2001 02:48:46 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA57382 for ; Mon, 31 Dec 2001 02:45:48 -0500 Received: from d03nm014.boulder.ibm.com (d03nm014.boulder.ibm.com [9.99.140.13]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBV7mhD232806 for ; Mon, 31 Dec 2001 00:48:43 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN To: "Julian Satran" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 30 Dec 2001 23:47:52 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/31/2001 12:48:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Good change, I have included minor edits in-line below. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com Julian Satran@IBMIL 12/30/2001 10:06 PM To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu From: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN (Document link: John Hufferd) John, The current text reads: The numbered-response, or R2T, requested by a SNACK have to be deliv-ered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN, MaxCmdSN and ExpDataSN fields that MUST carry the current values. The numbered Data-In PDUs, individually requested by ^^^^^^^^^^^^ Delete this a SNACK, have to be delivered as exact replicas of the ones the initiator missed including all its flags except for the ExpCmdSN and MaxCmdSN fields that MUST carry they current values. Data-In PDUs requested ^ Should delete the y with RunLength 0 (meaning all PDUs after this number) may be different from the ones originally sent in add comma ^ order to reflect changes in MaxRecvPDULength. Regards, Julo John Hufferd/San Jose/IBM@IBMUS To: Julian Satran/Haifa/IBM@IBMIL Sent by: cc: ips@ece.cmu.edu owner-ips@ece.cmu Subject: iSCSI: SNACK and resend with .edu current values of ExpCmdSn and MaxCmdSN 31-12-01 00:38 Julian, in the SNACK Request PDU (section 3.16), there is the statements that current values of ExpStatSN and ExpDataSN should be used on the resent PDUs, but no mention of sending the current values of ExpCmdSN or MaxCmdSN. I have thought that those also should be included in the fields that must be current when resent. Is there any reason to exempt those fields? . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com From owner-ips@ece.cmu.edu Mon Dec 31 11:32:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04875 for ; Mon, 31 Dec 2001 11:32:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVFT8e21419 for ips-outgoing; Mon, 31 Dec 2001 10:29:08 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVFT6g21415 for ; Mon, 31 Dec 2001 10:29:06 -0500 (EST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id QAA87278 for ; Mon, 31 Dec 2001 16:28:59 +0100 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBVFTeS181764 for ; Mon, 31 Dec 2001 16:29:40 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - last change for 2001! X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 From: "Julian Satran" Message-ID: Date: Mon, 31 Dec 2001 17:29:41 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/12/2001 17:29:44, Serialize complete at 31/12/2001 17:29:44 Content-Type: multipart/alternative; boundary="=_alternative 0054E21CC2256B33_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0054E21CC2256B33_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, According to the agreement reached in SLC here is the new text for the Task Management Request/Response (with all synchronization functions delegated to the target). The impementer's notes - subsection 4 is out. Task Management Function Request Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|0|I| x02 |0| Function | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | +---------------+---------------+---------------+---------------+ 8| Logical Unit Number (LUN) or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32| RefCmdSN or ExpDataSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48 Function The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management functions are listed below. For a more detailed description of SCSI task management, see [SAM2]. 1 ABORT TASK - aborts the task identified by the Referenced Task Tag field. 2 ABORT TASK SET - aborts all Tasks issued via this session on the logical unit. 3 CLEAR ACA - clears the Auto Contingent Allegiance condi-tion. 4 CLEAR TASK SET - aborts all Tasks for the Logical Unit. 5 LOGICAL UNIT RESET 6 TARGET WARM RESET 7 TARGET COLD RESET 8 TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field on this con-nection, thus resuming the iSCSI exchanges for the task. For all these functions, if executed, the Task Management Function Response MUST be returned using the Initiator Task Tag to identify the operation for which it is responding. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations. Task management commands must be executed as if all the commands having a CmdSN lower or equal to the task manage-ment CmdSN have been received by the target (i.e., have to be executed as if received for ordered delivery even when marked for immediate delivery). For all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the task management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the task management response (i.e., it is a matter of implementation if the SCSI responses received before the task mangement response but after the task management request are delivered to the SCSI layer by the iSCSI layer in the ini-tiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI ini-tiator after the task management response. If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Manage-ment Request is issued. If the connection is being implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the fail-ing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reas-signed, and its status, if issued, but not acknowledged will be reis-sued). For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]. The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented, should act as described below. Target Reset MAY also be subject to SCSI access controls for the requesting initiator. When not implemented or when authorization fails at target, Target Reset functions should end as if the function was executed success-fully and the response qualifier will detail what was executed. For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators. In addition, for the TARGET COLD RESET, the target MUST then terminate all of its TCP connections to all initiators (all sessions are termi-nated). For the TASK REASSIGN function, the target should reassign the connec-tion allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST be received by the target ONLY after the connection on which the command was previously execut-ing has been successfully logged-out. For additional usage semantics see Section 7.1 Retry and Reassign in Recovery. TASK REASSIGN MUST be issued as an immediate command. LUN This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. Referenced Task Tag The Initiator Task Tag of the task to be aborted or reassigned. RefCmdSN or ExpDataSN For ABORT TASK, the task CmdSN to enable task removal. If RefCmdSN does not match the CmdSN of the command to be aborted at the target, the abort action MUST NOT be performed and the response MUST be func-tion rejected. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirectional command, this field will contain the next consecutive input DataSN number expected by the initiator (no gaps) for the referenced command in a previous execution. Otherwise, this field is reserved. Task Management Function Response Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|0|1| 0x22 |1| Reserved | Response | Qualifier | +---------------+---------------+---------------+---------------+ 4/ Reserved / / / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digest (if any) | +---------------------------------------------------------------+ For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. Response and Qualifier The target provides a Response, which may take on the following val-ues: 0 - Function Complete 1 - Task specified in the Referenced Task Tag field was not in task set. 2 - LUN does not exist. 3 - Task still allegiant. 4 - Task failover not supported. 5 - Task management function not supported. 255 Function Rejected All other values are reserved. The Qualifier field provides additional information about the Response. For a Response of "Function Complete" the valid Qualifiers are: 0 - Function Executed 1 - Not Authorized For a discussion on usage of response codes 3 and 4, see Section 7.1.2 Allegiance Reassignment. For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations. For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initia-tors (terminates all sessions). The mapping of the response code into a SCSI service response code, if needed, is outside the scope of this document. The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the target only after all the commands affected have been received by the target the corresponding task management functions functions have been executed by the SCSI target and the delivery of all previous responses has been confirmed (acknowledged through ExpStatSN) by the initiator on all connections of this session. Referenced Task Tag If the Request was ABORT TASK and the Response is "task not found", THE Referenced Task Tag contains the Initiator Task Tag of the task that had to be aborted. In other cases, it MUST be set to 0xffffffff. Your comments please. Julo --=_alternative 0054E21CC2256B33_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

According to the agreement reached in SLC here is the new text for the Task Management Request/Response (with all synchronization functions delegated to the target). The impementer's notes - subsection 4 is out.

Task Management Function Request

Byte /    0       |       1       |       2       |       3       |
   /              |               |               |               |
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  +---------------+---------------+---------------+---------------+
 0|0|I| x02       |0| Function    | Reserved                      |
  +---------------+---------------+---------------+---------------+
 4| Reserved                                                      |
  +---------------+---------------+---------------+---------------+
 8| Logical Unit Number (LUN) or Reserved                         |
  +                                                               +
12|                                                               |
  +---------------+---------------+---------------+---------------+
16| Initiator Task Tag                                            |
  +---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff                             |
  +---------------+---------------+---------------+---------------+
24| CmdSN                                                         |
  +---------------+---------------+---------------+---------------+
28| ExpStatSN                                                     |
  +---------------+---------------+---------------+---------------+
32| RefCmdSN or ExpDataSN                                         |
  +---------------+---------------+---------------+---------------+
36/ Reserved                                                      /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
48

Function

The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management functions are listed below. For a more detailed description of SCSI task management, see [SAM2].

1    ABORT TASK - aborts the task identified by the Referenced       Task Tag field.

2    ABORT TASK SET - aborts all Tasks issued via this session on the logical unit.
3    CLEAR ACA - clears the Auto Contingent Allegiance condi-tion.

4    CLEAR TASK SET - aborts all Tasks for the Logical Unit.

5    LOGICAL UNIT RESET

6    TARGET WARM RESET

7                    TARGET COLD RESET

8    TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field on this con-nection, thus resuming the iSCSI exchanges for the task.

For all these functions, if executed, the Task Management Function Response MUST be returned using the Initiator Task Tag to identify the operation for which it is responding. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations.  Task management commands must be executed as if all the commands having a CmdSN lower or equal to the task manage-ment CmdSN have been received by the target (i.e., have to be executed as if received for ordered delivery even when marked for immediate delivery).  For all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the task management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the task management response (i.e., it is a matter of implementation i! f ! the SCSI responses received before the task mangement response but after the task management request are delivered to the SCSI layer by the iSCSI layer in the ini-tiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI ini-tiator after the task management response.

If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Manage-ment Request is issued. If the connection is being implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the fail-ing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reas-signed, and its status, if issued, but not acknowledged will be reis-sued). For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2].

The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented, should act as described below. Target Reset MAY also be subject to SCSI access controls for the requesting initiator. When not implemented or when authorization fails at target, Target Reset functions should end as if the function was executed success-fully and the response qualifier will detail what was executed.

For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators.
 
In addition, for the TARGET COLD RESET, the target MUST then terminate all of its TCP connections to all initiators (all sessions are termi-nated).
 
For the TASK REASSIGN function, the target should reassign the connec-tion allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST be received by the target ONLY after the connection on which the command was previously execut-ing has been successfully logged-out. For additional usage semantics see Section 7.1 Retry and Reassign in Recovery.


TASK REASSIGN MUST be issued as an immediate command.


LUN

This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others.

Referenced Task Tag

The Initiator Task Tag of the task to be aborted or reassigned.

RefCmdSN or ExpDataSN

For ABORT TASK, the task CmdSN to enable task removal. If RefCmdSN does not match the CmdSN of the command to be aborted at the target,
the abort action MUST NOT be performed and the response MUST be func-tion rejected.

If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirectional command, this field will contain the next consecutive input DataSN number expected by the initiator (no gaps) for the referenced command in a previous execution.

Otherwise, this field is reserved.


Task Management Function Response


Byte /    0       |       1       |       2       |       3       |
   /              |               |               |               |
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  +---------------+---------------+---------------+---------------+
 0|0|1| 0x22      |1| Reserved    | Response      | Qualifier     |
  +---------------+---------------+---------------+---------------+
 4/ Reserved                                                      /
  /                                                               /
  +---------------+---------------+---------------+---------------+
16| Initiator Task Tag                                            |
  +---------------+---------------+---------------+---------------+
20| Referenced Task Tag or 0xffffffff                             |
  +---------------+---------------+---------------+---------------+
24| StatSN                                                        |
  +---------------+---------------+---------------+---------------+
28| ExpCmdSN                                                      |
  +---------------+---------------+---------------+---------------+
32| MaxCmdSN                                                      |
  +---------------+---------------+---------------+---------------+
36/ Reserved                                                      /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
48| Digest (if any)                                               |
  +---------------------------------------------------------------+

For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator.

Response and Qualifier

The target provides a Response, which may take on the following val-ues:

0 - Function Complete
1 - Task specified in the Referenced Task Tag field was not in task set.
2 - LUN does not exist.
3 - Task still allegiant.
4 - Task failover not supported.
5 - Task management function not supported.
255   Function Rejected

All other values are reserved.

The Qualifier field provides additional information about the Response.

For a Response of "Function Complete" the valid Qualifiers are:

0 - Function Executed
1 - Not Authorized

For a discussion on usage of response codes 3 and 4, see Section 7.1.2 Allegiance Reassignment.

For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations.  For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initia-tors (terminates all sessions).

The mapping of the response code into a SCSI service response code, if needed, is outside the scope of this document.

The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the target only after all the commands affected have been received by the target the corresponding task management functions functions have been executed by the SCSI target and the delivery of all previous responses has been confirmed (acknowledged through ExpStatSN) by the initiator on all connections of this session.

Referenced Task Tag

If the Request was ABORT TASK and the Response is "task not found", THE Referenced Task Tag contains the Initiator Task Tag of the task that had to be aborted. In other cases, it MUST be set to 0xffffffff.

Your comments please.

Julo --=_alternative 0054E21CC2256B33_=-- From owner-ips@ece.cmu.edu Mon Dec 31 15:06:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06468 for ; Mon, 31 Dec 2001 15:06:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVIdQt29394 for ips-outgoing; Mon, 31 Dec 2001 13:39:26 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVIdKg29389 for ; Mon, 31 Dec 2001 13:39:21 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 13:39:11 -0500 Message-ID: <25369470B6F0D41194820002B328BDD220228F@ATLOPS> From: Eddy Quicksall To: Jim Hafner Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 13:39:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Regarding answer 2 below: There is no given definition for an iSCSI Initiator Portal Group (however, it is implied to be the same as the endpoint in 9.1.1, which would be the same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is the same as a SCSI Target Port, then each session in answer number 2 would not have a "different SCSI initiator port"; hence you would have a parallel nexus. One thing that is not clear in section 9.1.1 (however, it is loosely implied) is that the reuse of ISID's applies to a given initiator endpoint (SCSI Initiator Port or what should be called an iSCSI Initiator Portal Group)). I think that should be made clear. What am I missing? Could it be that an iSCSI Initiator Portal Group is not equivalent to a SCSI Target Port? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Saturday, December 29, 2001 6:14 PM To: Eddy Quicksall Cc: ips Subject: RE: FW: iSCSI: "conservative reuse" requirement Eddy, The SCSI initiator port is modeled as the endpoint of the iSCSI session; the SCSI target port is modeled as the iSCSI target portal group. The reason we did it this way was to allow more than one session between portal groups by allowing multi-plexing of sessions with different ISIDs from the same iSCSI initiator portal group to the same target portal group. So, the answer to your questions are: 1) no, we're assuming no more than on session *with the same ISID* to the same target portal group (that'd be more than one nexus), but by allowing different ISIDs we get different SCSI initiator ports. 2) no, we're allowing more than one session between an iSCSI initiator portal group and an iSCSI target portal group (each session has a different SCSI initiator port (id'ed by its ISID) but the same SCSI target port (id'ed by its portal group tag). 3) sort of, the ISID together with the iSCSI Initiator Name fully identifies the SCSI initiator port (and so defines the SCSI initiator port name and the identifier). Does that clear this up? Jim Hafner "Eddy Quicksall" on 12/28/2001 07:19:33 PM To: Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target port, there can be only one I_T nexus (session)", aren't we always "assuming no more than one session"? Or are you talking about more than one session between different SCSI initiator ports and a single SCSI target port? Is the ISID equivalent to SAM-2's Initiator Port Identifier? Eddy -----Original Message----- From: Jim Hafner [mailto:hafner@almaden.ibm.com] Sent: Friday, December 28, 2001 12:15 PM To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: FW: iSCSI: "conservative reuse" requirement Folks, Sorry for taking so long to jump into this discussion. There are a number of issues raised in this thread: 1) should "conservative reuse" of ISIDs be made a MUST 2) does "conservative reuse" imply that all hosts look "single SCSI ported" Here's my two cents (using "CR" as a shorthand for "conservative reuse") I don't believe that CR needs to be a MUST. The only time this has any real value is in configurations that use SCSI persistent reservations (and where new SCSI target reservation features are enabled -- NB. these features are yet to be approved but are working their way through the process). I don't think these are going to be (even in the future) the majority of installations. There are many ways then that CR could be something that is not generally available in most drivers but is added by configuration and perhaps even "value add" (:-{)). In short, I don't see a strong case for this to be a MUST. So, to David Black, my answer is that having a mechanism to enable this feature or have it as a "purchase requirement" is an acceptable mechanism to make sure the feature is there when needed, but it is need not be a requirement of the protocol. To Mallikarjun, I think I'm agreeing with you that so long as there is a mechanism defined, iSCSI has done it's job. As for the second issue (raised by Mallikarjun), let's look at the definition of CR. What is means is that when an iSCSI initiator (node) creates ISIDs for use in session identifiers, it attempts to reuse them as much as possible with different SCSI target ports (iSCSI target portal groups). This is the only way that a SCSI target or LU can see the same SCSI initiator port through two or more of its SCSI target ports -- that is, that the target can determine multiple paths *from* the same SCSI initiator port. But, the model for generating ISIDs is not really at the node level but at the initiator portal group level. So, IMO, the conclusion that all hosts must then look "single SCSI ported" is too dramatic. As I mentioned, ISIDs are conceptually generated within initiator portal groups (that's why we defined the mechanism for generating ISIDs). The conclusion I draw is that (assuming no more than one session to any given target portal group), an iSCSI initiator implementing CR will have as many SCSI initiator ports as iSCSI initiator portal groups (independent HBAs?). Each initiator portal group would generate one ISID (that is different from that generated by/for the other initiator portal groups) and use CR for repeatability. [This is consistent with a model that mapped SCSI initiator ports to initiator portal groups, which we had to abandon because the "assuming no more than one session..." was no acceptable as a requirement!!!] This independence of ISIDs for each initiator portal group allows each initiator portal group to open sessions with *every* target portal group it knows about without having to worry about interfering with other sessions. [This has shades of the "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] (I have a feeling that this note is not well composed -- it is the holidays, you know). I hope I've addressed everyone's concerns and we can lay this one to rest. Jim Hafner John Hufferd 12/25/2001 08:49 AM To: "Eddy Quicksall" cc: Jim Hafner/Almaden/IBM@IBMUS From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document link: Jim Hafner) You are correct. The section was created by Jim Hafner, and via this note I will ask him if he could answer Mallikarjun Directly since I did not understand his issue. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Eddy Quicksall" on 12/24/2001 06:06:44 PM To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: FW: iSCSI: "conservative reuse" requirement John, Were you the author of "conservative reuse"? I am wondering about some issues. Maybe you could educate me somewhat ... I started this subject in a different thread by saying that it may be good to make "conservative reuse" a MUST. I got one objection from Santosh below. Then David Black picked it up by basically agreeing with me. Then Mallikarjun objected to that. It seems like the objective would be to give targets a way to figure out that two or more sessions are coming from the same Initiator Port. That is needed support persistent reservations. If an initiator does not use "conservative reuse", I don't think targets will be able to make that determination. Comments? Eddy -----Original Message----- From: Mallikarjun C. [mailto:cbm@rose.hp.com] Sent: Monday, December 24, 2001 12:47 AM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: "conservative reuse" requirement > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. Mandating "conservative reuse" appears to force initiators to always act as a single initiator port (wrt one target; assuming only one session as an example) per initiator device - which rules out the case of an initiator intentionally wanting to present a different port to each target portal group. IMHO, if iSCSI provides an architected mechanism to support shared persistent reservations ("conservative reuse"), that should be completely adequate to meet the expectations to be a legal SCSI protocol. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: To: Cc: Sent: Friday, December 21, 2001 4:50 PM Subject: iSCSI: "conservative reuse" requirement > Santosh Rao writes: > > > I am opposed to the suggestion that "conservative re-use" of ISIDs be > > made a MUST. This is really only required when initiators need to be > > using the new T10 Reservation scheme that can be shared > > across initiator ports. > > Those reservations are a Target feature. With this approach, the ability > to use the target feature depends on details of the initiator > implementation. > More below ... > > > For those initiators that don't care about this type of reservation, > > conservative re-use is of no use and initiators may like to assign > > ISID's in a per-initiator node fashion, thereby, being able to use these > > ISIDs as a lookup index for the sessions on that initiator node. > > > > Hence, I suggest that "conservative re-use" be worded as > > "encouraged to use" or something to that effect, but not MUST USE. > > > > Comments ? > > The "initiator" is more than one entity. The iSCSI HBA/NIC and driver > doesn't know whether shared persistent reservations are being used and > shouldn't have to care - they're just more SCSI commands to transport. > Some other entity (e.g., clustering software) will be generating the > shared persistent reservations. This raise the possible scenario > involving a target that supports the new shared persistent reservations > and an entity that wants to use them. The entity detects (via SCSI means, > e.g., something in a mode page) that the Target supports shared persistent > reservations, tries to use them, only to discover that they don't work > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > I'm worried about this causing both interoperability issues and possible > T10 issues -- from a T10 viewpoint, if shared persistent reservations > don't work, the initiating entity should have some SCSI-level means > of determining this ... if that means exists only on the Target, the > above scenario is iSCSI's problem (Target can't query Initiator to > determine whether it does "conservative reuse"), and having a separate > initiator side means that the entity has to check only for iSCSI (and > not for any other SCSI transport) does not seem like the right > approach. > > I think this is headed towards "conservative reuse" being a MUST if > we're serious about support for shared persistent reservations. > > Comments? > --David > --------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 42 South St., Hopkinton, MA 01748 > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > black_david@emc.com Cell: +1 (978) 394-7754 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Mon Dec 31 16:35:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07270 for ; Mon, 31 Dec 2001 16:35:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVKPC203554 for ips-outgoing; Mon, 31 Dec 2001 15:25:12 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVKOsg03540 for ; Mon, 31 Dec 2001 15:24:55 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 15:24:39 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202291@ATLOPS> From: Eddy Quicksall To: Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iSCSI - last change for 2001! Date: Mon, 31 Dec 2001 15:24:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19239.28054630" Sender: owner-ips@ece.cmu.edu 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_01C19239.28054630 Content-Type: text/plain; charset="iso-8859-1" For ABORT TASK, the task CmdSN to enable task removal. I assume "the CmdSN to enable task removal" is the CmdSN of the command corresponding to the "Referenced Task Tag" and not some other concept that I missed. Is that correct? Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, December 31, 2001 10:30 AM To: ips@ece.cmu.edu Subject: iSCSI - last change for 2001! Dear colleagues, According to the agreement reached in SLC here is the new text for the Task Management Request/Response (with all synchronization functions delegated to the target). The impementer's notes - subsection 4 is out. Task Management Function Request Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|0|I| x02 |0| Function | Reserved | +---------------+---------------+---------------+---------------+ 4| Reserved | +---------------+---------------+---------------+---------------+ 8| Logical Unit Number (LUN) or Reserved | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| CmdSN | +---------------+---------------+---------------+---------------+ 28| ExpStatSN | +---------------+---------------+---------------+---------------+ 32| RefCmdSN or ExpDataSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48 Function The Task Management functions provide an initiator with a way to explicitly control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task Management functions are listed below. For a more detailed description of SCSI task management, see [SAM2]. 1 ABORT TASK - aborts the task identified by the Referenced Task Tag field. 2 ABORT TASK SET - aborts all Tasks issued via this session on the logical unit. 3 CLEAR ACA - clears the Auto Contingent Allegiance condi-tion. 4 CLEAR TASK SET - aborts all Tasks for the Logical Unit. 5 LOGICAL UNIT RESET 6 TARGET WARM RESET 7 TARGET COLD RESET 8 TASK REASSIGN - reassigns connection allegiance for the task identified by the Initiator Task Tag field on this con-nection, thus resuming the iSCSI exchanges for the task. For all these functions, if executed, the Task Management Function Response MUST be returned using the Initiator Task Tag to identify the operation for which it is responding. All these functions apply to the referenced tasks regardless of whether they are proper SCSI tasks or tagged iSCSI operations. Task management commands must be executed as if all the commands having a CmdSN lower or equal to the task manage-ment CmdSN have been received by the target (i.e., have to be executed as if received for ordered delivery even when marked for immediate delivery). For all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN), additional responses MUST NOT be delivered to the SCSI layer after the task management response. The iSCSI initiator MAY deliver to the SCSI layer all responses received before the task management response (i.e., it is a matter of implementation i! f ! the SCSI responses received before the task mangement response but after the task management request are delivered to the SCSI layer by the iSCSI layer in the ini-tiator). The iSCSI target MUST ensure that no responses for the tasks covered by a task management function are delivered to the iSCSI ini-tiator after the task management response. If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued on the same connection to which the task to be aborted is allegiant at the time the Task Manage-ment Request is issued. If the connection is being implicitly or explicitly logged out (i.e., no other request will be issued on the failing connection and no other response will be received on the fail-ing connection), then an ABORT TASK function request may be issued on another connection. This Task Management request will then establish a new allegiance for the command to be aborted as well as abort it (i.e., the task to be aborted will not have to be retried or reas-signed, and its status, if issued, but not acknowledged will be reis-sued). For the LOGICAL UNIT RESET function, the target MUST behave as dictated by the Logical Unit Reset function in [SAM2]. The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented, should act as described below. Target Reset MAY also be subject to SCSI access controls for the requesting initiator. When not implemented or when authorization fails at target, Target Reset functions should end as if the function was executed success-fully and the response qualifier will detail what was executed. For the TARGET WARM RESET and TARGET COLD RESET functions, the target cancels all pending operations. Both functions are equivalent to the Target Reset function specified by [SAM2]. They can affect many other initiators. In addition, for the TARGET COLD RESET, the target MUST then terminate all of its TCP connections to all initiators (all sessions are termi-nated). For the TASK REASSIGN function, the target should reassign the connec-tion allegiance to this new connection (and thus resume iSCSI exchanges for the task). TASK REASSIGN MUST be received by the target ONLY after the connection on which the command was previously execut-ing has been successfully logged-out. For additional usage semantics see Section 7.1 Retry and Reassign in Recovery. TASK REASSIGN MUST be issued as an immediate command. LUN This field is required for functions that address a specific LU (ABORT TASK, CLEAR TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all others. Referenced Task Tag The Initiator Task Tag of the task to be aborted or reassigned. RefCmdSN or ExpDataSN For ABORT TASK, the task CmdSN to enable task removal. If RefCmdSN does not match the CmdSN of the command to be aborted at the target, the abort action MUST NOT be performed and the response MUST be func-tion rejected. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirectional command, this field will contain the next consecutive input DataSN number expected by the initiator (no gaps) for the referenced command in a previous execution. Otherwise, this field is reserved. Task Management Function Response Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|0|1| 0x22 |1| Reserved | Response | Qualifier | +---------------+---------------+---------------+---------------+ 4/ Reserved / / / +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Referenced Task Tag or 0xffffffff | +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 48| Digest (if any) | +---------------------------------------------------------------+ For the functions ABORT TASK, ABORT TASK SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, and TARGET WARM RESET, the target performs the requested Task Management function and sends a Task Management Response back to the initiator. Response and Qualifier The target provides a Response, which may take on the following val-ues: 0 - Function Complete 1 - Task specified in the Referenced Task Tag field was not in task set. 2 - LUN does not exist. 3 - Task still allegiant. 4 - Task failover not supported. 5 - Task management function not supported. 255 Function Rejected All other values are reserved. The Qualifier field provides additional information about the Response. For a Response of "Function Complete" the valid Qualifiers are: 0 - Function Executed 1 - Not Authorized For a discussion on usage of response codes 3 and 4, see Section 7.1.2 Allegiance Reassignment. For the TARGET COLD RESET and TARGET WARM RESET functions, the target cancels all pending operations. For the TARGET COLD RESET function, the target MUST then close all of its TCP connections to all initia-tors (terminates all sessions). The mapping of the response code into a SCSI service response code, if needed, is outside the scope of this document. The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the target only after all the commands affected have been received by the target the corresponding task management functions functions have been executed by the SCSI target and the delivery of all previous responses has been confirmed (acknowledged through ExpStatSN) by the initiator on all connections of this session. Referenced Task Tag If the Request was ABORT TASK and the Response is "task not found", THE Referenced Task Tag contains the Initiator Task Tag of the task that had to be aborted. In other cases, it MUST be set to 0xffffffff. Your comments please. Julo ------_=_NextPart_001_01C19239.28054630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

For = ABORT TASK, the task CmdSN to enable task removal.

 

I = assume “the CmdSN to enable task removal” is the CmdSN of the command = corresponding to the “Referenced Task Tag” and not some other concept that I = missed.

 

Is that = correct?

 

Eddy

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, December = 31, 2001 10:30 AM
To: ips@ece.cmu.edu
Subject: iSCSI - last = change for 2001!

 


Dear = colleagues,

According to the agreement = reached in SLC here is the new text for the Task Management Request/Response = (with all synchronization functions delegated to the target). The impementer's = notes - subsection 4 is out.

Task Management Function = Request =

Byte / =    0       |       1     =   |       2       |       3 =       |
   /         =      |               | =               |           =     | =
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 = 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  = +---------------+---------------+---------------+---------------+=
 0|0|I| x02       |0| = Function    | Reserved             =          |
  +---------------+---------------+---------------+---------------+=
 4| Reserved       =                         =                       =  |
  +---------------+---------------+---------------+---------------+=
 8| Logical Unit Number (LUN) or = Reserved                     =     | =
  +           =                       =                       =         +
12|           =                         =                       =       |
  +---------------+---------------+---------------+---------------+=
16| Initiator Task Tag       =                       =                |
  +---------------+---------------+---------------+---------------+=
20| Referenced Task Tag or 0xffffffff   =                       =     | =
  +---------------+---------------+---------------+---------------+=
24| CmdSN           =                       =                       =   |
  +---------------+---------------+---------------+---------------+=
28| ExpStatSN         =                       =                       = |
  +---------------+---------------+---------------+---------------+=
32| RefCmdSN or ExpDataSN     =                       =               |
  = +---------------+---------------+---------------+---------------+=
36/ Reserved         =                       =                       =  /
 +/           =                       =                       =         /
  +---------------+---------------+---------------+---------------+=
48

Function

The = Task Management functions provide an initiator with a way to explicitly = control the execution of one or more Tasks (SCSI and iSCSI tasks). The Task = Management functions are listed below. For a more detailed description of SCSI = task management, see [SAM2].

1    ABORT TASK - aborts the task identified by the Referenced       Task Tag = field.

2    ABORT TASK SET - aborts all = Tasks issued via this session on the logical unit.
3    CLEAR ACA - clears the Auto Contingent Allegiance condi-tion.

4    CLEAR TASK SET - aborts all = Tasks for the Logical Unit.

5    LOGICAL UNIT = RESET

6    TARGET WARM = RESET

7             =        TARGET COLD RESET

8    TASK REASSIGN - reassigns = connection allegiance for the task identified by the Initiator Task Tag field on = this con-nection, thus resuming the iSCSI exchanges for the = task.

For all these functions, if executed, the = Task Management Function Response MUST be returned using the Initiator Task = Tag to identify the operation for which it is responding. All these functions = apply to the referenced tasks regardless of whether they are proper SCSI tasks = or tagged iSCSI operations.  Task management commands must be executed as if = all the commands having a CmdSN lower or equal to the task manage-ment CmdSN = have been received by the target (i.e., have to be executed as if received for = ordered delivery even when marked for immediate delivery).  For all the = tasks covered by the task management response (i.e., with CmdSN not higher = than the task management command CmdSN), additional responses MUST NOT be = delivered to the SCSI layer after the task management response. The iSCSI initiator = MAY deliver to the SCSI layer all responses received before the task = management response (i.e., it is a matter of implementation i! f ! the SCSI = responses received before the task mangement response but after the task = management request are delivered to the SCSI layer by the iSCSI layer in the = ini-tiator). The iSCSI target MUST ensure that no responses for the tasks covered by = a task management function are delivered to the iSCSI ini-tiator after the = task management response.

If the connection is still active (it is not undergoing an implicit or explicit logout), ABORT TASK MUST be issued = on the same connection to which the task to be aborted is allegiant at the = time the Task Manage-ment Request is issued. If the connection is being = implicitly or explicitly logged out (i.e., no other request will be issued on the = failing connection and no other response will be received on the fail-ing = connection), then an ABORT TASK function request may be issued on another connection. = This Task Management request will then establish a new allegiance for the command = to be aborted as well as abort it (i.e., the task to be aborted will not have = to be retried or reas-signed, and its status, if issued, but not acknowledged = will be reis-sued). For the LOGICAL UNIT RESET function, the target MUST behave = as dictated by the Logical Unit Reset function in [SAM2]. =

The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and when implemented, should act as = described below. Target Reset MAY also be subject to SCSI access controls for the = requesting initiator. When not implemented or when authorization fails at target, = Target Reset functions should end as if the function was executed = success-fully and the response qualifier will detail what was = executed.

For the TARGET WARM RESET and TARGET COLD = RESET functions, the target cancels all pending operations. Both functions = are equivalent to the Target Reset function specified by [SAM2]. They can = affect many other initiators.
 
In addition, for the TARGET COLD RESET, the = target MUST then terminate all of its TCP connections to all initiators (all = sessions are termi-nated).
 
For the TASK REASSIGN function, the target = should reassign the connec-tion allegiance to this new connection (and thus = resume iSCSI exchanges for the task). TASK REASSIGN MUST be received by the = target ONLY after the connection on which the command was previously = execut-ing has been successfully logged-out. For additional usage semantics see = Section 7.1 Retry and Reassign in Recovery.


TASK REASSIGN MUST be issued as an immediate command. =


LUN

This = field is required for functions that address a specific LU (ABORT TASK, CLEAR = TASK SET, ABORT TASK SET, CLEAR ACA, LOGICAL UNIT RESET) and is reserved in all = others.

Referenced Task Tag =

The = Initiator Task Tag of the task to be aborted or reassigned.

RefCmdSN or ExpDataSN =

For = ABORT TASK, the task CmdSN to enable task removal. If RefCmdSN does not match the = CmdSN of the command to be aborted at the target,
the abort action MUST NOT be performed and = the response MUST be func-tion rejected.

If the function is TASK REASSIGN, which = establishes a new connection allegiance for a previously issued Read or = Bidirectional command, this field will contain the next consecutive input DataSN = number expected by the initiator (no gaps) for the referenced command in a = previous execution.

Otherwise, this field is = reserved.


Task Management Function = Response =


Byte /    0       | =       1       |       2   =     |       3       = |
   /         =      |               | =               |           =     | =
  |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 = 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
  +---------------+---------------+---------------+---------------+=
 0|0|1| 0x22      |1| = Reserved    | Response      | Qualifier     = |
  +---------------+---------------+---------------+---------------+=
 4/ Reserved       =                         =                       =  /
  /           =                       =                       =         /
  +---------------+---------------+---------------+---------------+=
16| Initiator Task Tag       =                       =                |
  +---------------+---------------+---------------+---------------+=
20| Referenced Task Tag or 0xffffffff   =                       =     | =
  +---------------+---------------+---------------+---------------+=
24| StatSN         =                         =                       =  |
  +---------------+---------------+---------------+---------------+=
28| ExpCmdSN         =                       =                       =  |
  +---------------+---------------+---------------+---------------+=
32| MaxCmdSN         =                       =                       =  |
  +---------------+---------------+---------------+---------------+=
36/ Reserved         =                       =                       =  /
 +/           =                       =                       =         /
  +---------------+---------------+---------------+---------------+=
48| Digest (if any)       =                       =                   = |
  +---------------------------------------------------------------+=

For the functions ABORT TASK, ABORT TASK = SET, CLEAR ACA, CLEAR TASK SET, LOGICAL UNIT RESET, and TARGET WARM RESET, the = target performs the requested Task Management function and sends a Task = Management Response back to the initiator.

Response and Qualifier =

The = target provides a Response, which may take on the following = val-ues:

0 - Function Complete
1 - Task specified in the Referenced Task = Tag field was not in task set.
2 - LUN does not exist.
3 - Task still allegiant.
4 - Task failover not = supported.
5 - Task management function not = supported.
255   Function = Rejected

All other values are = reserved.

The Qualifier field provides additional = information about the Response.

For a Response of "Function = Complete" the valid Qualifiers are:

0 - Function Executed
1 - Not Authorized

For a discussion on usage of response codes = 3 and 4, see Section 7.1.2 Allegiance Reassignment.

For the TARGET COLD RESET and TARGET WARM = RESET functions, the target cancels all pending operations.  For the = TARGET COLD RESET function, the target MUST then close all of its TCP connections = to all initia-tors (terminates all sessions).

The mapping of the response code into a SCSI = service response code, if needed, is outside the scope of this document. =

The response to ABORT TASK SET and CLEAR = TASK SET MUST be issued by the target only after all the commands affected have = been received by the target the corresponding task management functions = functions have been executed by the SCSI target and the delivery of all previous responses has been confirmed (acknowledged through ExpStatSN) by the = initiator on all connections of this session.

Referenced Task Tag =

If the = Request was ABORT TASK and the Response is "task not found", THE = Referenced Task Tag contains the Initiator Task Tag of the task that had to be = aborted. In other cases, it MUST be set to 0xffffffff.

Your comments = please.

Julo=

------_=_NextPart_001_01C19239.28054630-- From owner-ips@ece.cmu.edu Mon Dec 31 17:46:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07789 for ; Mon, 31 Dec 2001 17:46:44 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVMFeQ08300 for ips-outgoing; Mon, 31 Dec 2001 17:15:41 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVMFag08286 for ; Mon, 31 Dec 2001 17:15:36 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 17:15:31 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202293@ATLOPS> From: Eddy Quicksall To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" , Jim Hafner Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 17:15:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 31 17:50:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07831 for ; Mon, 31 Dec 2001 17:50:19 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVLmV306982 for ips-outgoing; Mon, 31 Dec 2001 16:48:31 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVLmSg06973 for ; Mon, 31 Dec 2001 16:48:28 -0500 (EST) Received: from xparelay2.corp.hp.com (xparelay2.corp.hp.com [15.58.137.112]) by palrel10.hp.com (Postfix) with ESMTP id 5D715400684; Mon, 31 Dec 2001 13:48:19 -0800 (PST) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 90864400094; Mon, 31 Dec 2001 13:47:55 -0800 (PST) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 13:48:18 -0800 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF2DA@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Eddy Quicksall'" , Jim Hafner Cc: "ips@ece. cmu. edu (E-mail)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 13:48:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 31 19:34:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08428 for ; Mon, 31 Dec 2001 19:34:09 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fBVNagP11543 for ips-outgoing; Mon, 31 Dec 2001 18:36:42 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id fBVNadg11536 for ; Mon, 31 Dec 2001 18:36:39 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id fBVNZxH14098; Mon, 31 Dec 2001 15:35:59 -0800 From: "Amir Shalit" To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "Jim Hafner" Cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 15:35:56 -0800 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.50.4807.1700 In-Reply-To: <25369470B6F0D41194820002B328BDD2202293@ATLOPS> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 31 20:57:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09056 for ; Mon, 31 Dec 2001 20:57:50 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g011MPK15522 for ips-outgoing; Mon, 31 Dec 2001 20:22:25 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from astutenetworks.com (2.astutenetworks.com [216.142.74.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g011MNg15517 for ; Mon, 31 Dec 2001 20:22:23 -0500 (EST) Received: from amirdesktop (dhcp62 [172.21.2.62]) by astutenetworks.com (8.11.6/8.11.2) with SMTP id g011MFH19030; Mon, 31 Dec 2001 17:22:15 -0800 From: "Amir Shalit" To: "John Hufferd" Cc: Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 17:22:13 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit It could have been defined as {IP address, port, channel_id} or {IP address, port, stream_number}. This would let you span multiple HBAs etc. and still be consistent with other IP/ATM protocols like SCTP and AAL2. Amir -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 5:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 31 20:57:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09069 for ; Mon, 31 Dec 2001 20:57:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g0112i414839 for ips-outgoing; Mon, 31 Dec 2001 20:02:44 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g0112gg14834 for ; Mon, 31 Dec 2001 20:02:42 -0500 (EST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA15117144 for ; Mon, 31 Dec 2001 19:59:17 -0500 Received: from d03nm014.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.188.135]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g01123S145444 for ; Mon, 31 Dec 2001 18:02:03 -0700 X-Priority: 1 (High) Importance: Normal Subject: RE: FW: iSCSI: "conservative reuse" requirement To: "Amir Shalit" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 31 Dec 2001 17:01:14 -0800 X-MIMETrack: Serialize by Router on D03NM014/03/M/IBM(Release 5.0.9 |November 16, 2001) at 12/31/2001 06:02:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > > From owner-ips@ece.cmu.edu Mon Dec 31 23:05:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11530 for ; Mon, 31 Dec 2001 23:05:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id g013PZw20137 for ips-outgoing; Mon, 31 Dec 2001 22:25:35 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.ivivity.com (user-vc8ftn3.biz.mindspring.com [216.135.246.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id g013PWg20132 for ; Mon, 31 Dec 2001 22:25:32 -0500 (EST) Received: by ATLOPS with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 22:25:26 -0500 Message-ID: <25369470B6F0D41194820002B328BDD2202294@ATLOPS> From: Eddy Quicksall To: John Hufferd Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement Date: Mon, 31 Dec 2001 22:25:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk My problem is that we have not done a good job of defining the iSCSI Initiator Portal Group in the spec. If defined correctly, there should be no need for the "conservative reuse" clause. Here is how I think it should be defined ... SCSI Initiator Port: this maps to an iSCSI Initiator Portal Group. You could go on to say something like Marjorie said below ... that it is a collection of IP addresses that can be used to support one or more iSCSI sessions. Given that it is equivalent to a SCSI Initiator Port and that it is identified by the InitiatorName+ISID, it follows that every session from that "port" would have to use the same ISID; and that is what will make persistent reservations work. It is not that "conservative reuse" won't work ... it is more that it is hard to explain because we don't have a clear definition of a SCSI Initiator Port and Initiator Port Identifier. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, December 31, 2001 8:01 PM To: Amir Shalit Cc: ips@ece.cmu.edu Subject: RE: FW: iSCSI: "conservative reuse" requirement We overtly chose NOT to identify an ISID with a TCP/IP address, since the ISID may span several HBAs and/or TCP/IP addresses. It was more general and consistent NOT to be tied to a TCP/IP address. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Home Office (408) 997-6136, Cell: (408) 499-9702 Internet address: hufferd@us.ibm.com "Amir Shalit" @ece.cmu.edu on 12/31/2001 03:35:56 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , Jim Hafner/Almaden/IBM@IBMUS cc: "ips@ece. cmu. edu \(E-mail\)" Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If an "initiator/target portal group" concept is "the collection of IP addresses which can be combined to create a single iSCSI session." why isn't it defined as such in the draft? IMO, it would have been better to define ISID/TSID in simple networking terms like {TCP/IP address + Name} instead of coming up with network entity, network portal and portal group terminology. Amir -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, December 31, 2001 2:15 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1); Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Marjorie, If "an initiator portal group is the same concept as the target portal group", then it must be equivalent to the SCSI Initiator Port (because we have said that the SCSI Target Port maps to an iSCSI Target Portal Group). Comments? Eddy -----Original Message----- From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:marjorie_krueger@hp.com] Sent: Monday, December 31, 2001 4:48 PM To: 'Eddy Quicksall'; Jim Hafner Cc: ips@ece. cmu. edu (E-mail) Subject: RE: FW: iSCSI: "conservative reuse" requirement Your assumption of what is meant by an initiator portal group is incorrect (I don't think it's implied that IPG = IP???) An initiator portal group is the same concept as a target portal group - it's the collection of IP addresses which can be combined to create a single iSCSI session. Frequently this is thought of as an iSCSI HBA, but that is not necessarily so, it could be a number of iSCSI HBAs, etc. Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard tel: +1 916 785 2656 fax: +1 916 785 0391 email: marjorie_krueger@hp.com > -----Original Message----- > From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com] > Sent: Monday, December 31, 2001 10:39 AM > To: Jim Hafner > Cc: ips@ece. cmu. edu (E-mail) > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Regarding answer 2 below: > There is no given definition for an iSCSI Initiator Portal Group (however, > it is implied to be the same as the endpoint in 9.1.1, which would be the > same as the SCSI Initiator Port). Since an iSCSI Initiator Portal Group is > the same as a SCSI Initiator Port and since an iSCSI Target Portal Group is > the same as a SCSI Target Port, then each session in answer number 2 would > not have a "different SCSI initiator port"; hence you would have a parallel > nexus. > One thing that is not clear in section 9.1.1 (however, it is loosely > implied) is that the reuse of ISID's applies to a given initiator endpoint > (SCSI Initiator Port or what should be called an iSCSI Initiator Portal > Group)). I think that should be made clear. > What am I missing? Could it be that an iSCSI Initiator Portal Group is not > equivalent to a SCSI Target Port? > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Saturday, December 29, 2001 6:14 PM > To: Eddy Quicksall > Cc: ips > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > Eddy, > > The SCSI initiator port is modeled as the endpoint of the > iSCSI session; > the SCSI target port is modeled as the iSCSI target portal group. The > reason we did it this way was to allow more than one session > between portal > groups by allowing multi-plexing of sessions with different > ISIDs from the > same iSCSI initiator portal group to the same target portal group. > > So, the answer to your questions are: > 1) no, we're assuming no more than on session *with the same > ISID* to the > same target portal group (that'd be more than one nexus), but > by allowing > different ISIDs we get different SCSI initiator ports. > 2) no, we're allowing more than one session between an iSCSI initiator > portal group and an iSCSI target portal group (each session > has a different > SCSI initiator port (id'ed by its ISID) but the same SCSI target port > (id'ed by its portal group tag). > 3) sort of, the ISID together with the iSCSI Initiator Name fully > identifies the SCSI initiator port (and so defines the SCSI > initiator port > name and the identifier). > > Does that clear this up? > > Jim Hafner > > > "Eddy Quicksall" on 12/28/2001 > 07:19:33 PM > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: "ips@ece. cmu. edu \(E-mail\)" > Subject: RE: FW: iSCSI: "conservative reuse" requirement > > > > Due to 2.5.3 (b) "Between a given SCSI initiator port and SCSI target > port, there can be only one I_T nexus (session)", aren't we always > "assuming no more than one session"? > > Or are you talking about more than one session between different SCSI > initiator ports and a single SCSI target port? > > Is the ISID equivalent to SAM-2's Initiator Port Identifier? > > > Eddy > > -----Original Message----- > From: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Friday, December 28, 2001 12:15 PM > To: John Hufferd; Eddy Quicksall; Mallikarjun C.; Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: FW: iSCSI: "conservative reuse" requirement > > > Folks, > > Sorry for taking so long to jump into this discussion. > > There are a number of issues raised in this thread: > 1) should "conservative reuse" of ISIDs be made a MUST > 2) does "conservative reuse" imply that all hosts look "single SCSI > ported" > > Here's my two cents (using "CR" as a shorthand for "conservative > reuse") > > I don't believe that CR needs to be a MUST. The only time this has > any > real value is in configurations that use SCSI persistent reservations > (and > where new SCSI target reservation features are enabled -- NB. these > features are yet to be approved but are working their way through the > process). I don't think these are going to be (even in the future) the > majority of installations. There are many ways then that CR could be > something that is not generally available in most drivers but is added > by > configuration and perhaps even "value add" (:-{)). > > In short, I don't see a strong case for this to be a MUST. So, to > David > Black, my answer is that having a mechanism to enable this feature or > have > it as a "purchase requirement" is an acceptable mechanism to make sure > the > feature is there when needed, but it is need not be a requirement of > the > protocol. To Mallikarjun, I think I'm agreeing with you that so long > as > there is a mechanism defined, iSCSI has done it's job. > > As for the second issue (raised by Mallikarjun), let's look at the > definition of CR. What is means is that when an iSCSI initiator > (node) > creates ISIDs for use in session identifiers, it attempts to reuse > them > as > much as possible with different SCSI target ports (iSCSI target portal > groups). This is the only way that a SCSI target or LU can see the > same > SCSI initiator port through two or more of its SCSI target ports -- > that > is, that the target can determine multiple paths *from* the same SCSI > initiator port. But, the model for generating ISIDs is not really at > the > node level but at the initiator portal group level. > So, IMO, the conclusion that all hosts must then look "single SCSI > ported" > is too dramatic. As I mentioned, ISIDs are conceptually generated > within > initiator portal groups (that's why we defined the mechanism for > generating > ISIDs). The conclusion I draw is that (assuming no more than one > session > to any given target portal group), an iSCSI initiator implementing CR > will > have as many SCSI initiator ports as iSCSI initiator portal groups > (independent HBAs?). Each initiator portal group would generate one > ISID > (that is different from that generated by/for the other initiator > portal > groups) and use CR for repeatability. [This is consistent with a > model > that mapped SCSI initiator ports to initiator portal groups, which we > had > to abandon because the "assuming no more than one session..." was no > acceptable as a requirement!!!] This independence of ISIDs for each > initiator portal group allows each initiator portal group to open > sessions > with *every* target portal group it knows about without having to > worry > about interfering with other sessions. [This has shades of the > "partitioning" rule for ISIDs that has been discussed ad nauseum!!!] > > (I have a feeling that this note is not well composed -- it is the > holidays, you know). I hope I've addressed everyone's concerns and we > can > lay this one to rest. > > Jim Hafner > > > John Hufferd > 12/25/2001 08:49 AM > > To: "Eddy Quicksall" > cc: Jim Hafner/Almaden/IBM@IBMUS > From: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: FW: iSCSI: "conservative reuse" requirement (Document > link: > Jim Hafner) > > You are correct. The section was created by Jim Hafner, and via this > note > I will ask him if he could answer Mallikarjun Directly since I did not > understand his issue. > > . > . > . > John L. Hufferd > Senior Technical Staff Member (STSM) > IBM/SSG San Jose Ca > Main Office (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136, Cell: (408) 499-9702 > Internet address: hufferd@us.ibm.com > > > "Eddy Quicksall" on 12/24/2001 06:06:44 > PM > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: FW: iSCSI: "conservative reuse" requirement > > > > John, > > Were you the author of "conservative reuse"? I am wondering about some > issues. Maybe you could educate me somewhat ... > > I started this subject in a different thread by saying that it may be > good to make "conservative reuse" a MUST. > > I got one objection from Santosh below. Then David Black picked it up > by basically agreeing with me. Then Mallikarjun objected to that. > > It seems like the objective would be to give targets a way to figure > out that two or more sessions are coming from the same Initiator Port. > That is needed support persistent reservations. > > If an initiator does not use "conservative reuse", I don't think > targets will be able to make that determination. > > Comments? > > Eddy > > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, December 24, 2001 12:47 AM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: "conservative reuse" requirement > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > Mandating "conservative reuse" appears to force initiators to always > act > as a single initiator port (wrt one target; assuming only one session > as > an > example) per initiator device - which rules out the case of an > initiator > > intentionally wanting to present a different port to each target > portal > group. > > IMHO, if iSCSI provides an architected mechanism to support shared > persistent reservations ("conservative reuse"), that should be > completely > adequate to meet the expectations to be a legal SCSI protocol. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, December 21, 2001 4:50 PM > Subject: iSCSI: "conservative reuse" requirement > > > > Santosh Rao writes: > > > > > I am opposed to the suggestion that "conservative re-use" of ISIDs > be > > > made a MUST. This is really only required when initiators need to > be > > > using the new T10 Reservation scheme that can be shared > > > across initiator ports. > > > > Those reservations are a Target feature. With this approach, the > ability > > to use the target feature depends on details of the initiator > > implementation. > > More below ... > > > > > For those initiators that don't care about this type of > reservation, > > > conservative re-use is of no use and initiators may like to assign > > > ISID's in a per-initiator node fashion, thereby, being able to use > these > > > ISIDs as a lookup index for the sessions on that initiator node. > > > > > > Hence, I suggest that "conservative re-use" be worded as > > > "encouraged to use" or something to that effect, but not MUST USE. > > > > > > Comments ? > > > > The "initiator" is more than one entity. The iSCSI HBA/NIC and > driver > > doesn't know whether shared persistent reservations are being used > and > > shouldn't have to care - they're just more SCSI commands to > transport. > > Some other entity (e.g., clustering software) will be generating the > > shared persistent reservations. This raise the possible scenario > > involving a target that supports the new shared persistent > reservations > > and an entity that wants to use them. The entity detects (via SCSI > means, > > e.g., something in a mode page) that the Target supports shared > persistent > > reservations, tries to use them, only to discover that they don't > work > > because the iSCSI HBA/NIC doesn't implement "conservative reuse". > > > > I'm worried about this causing both interoperability issues and > possible > > T10 issues -- from a T10 viewpoint, if shared persistent > reservations > > don't work, the initiating entity should have some SCSI-level means > > of determining this ... if that means exists only on the Target, the > > above scenario is iSCSI's problem (Target can't query Initiator to > > determine whether it does "conservative reuse"), and having a > separate > > initiator side means that the entity has to check only for iSCSI > (and > > not for any other SCSI transport) does not seem like the right > > approach. > > > > I think this is headed towards "conservative reuse" being a MUST if > > we're serious about support for shared persistent reservations. > > > > Comments? > > --David > > --------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 42 South St., Hopkinton, MA 01748 > > +1 (508) 249-6449 *NEW* FAX: +1 (508) 497-8500 > > black_david@emc.com Cell: +1 (978) 394-7754 > > --------------------------------------------------- > > > > > > >

Section 3.9.1 = says:<= /p>

 <= /p>

 Initiator MUST send a Logout = with a reason code of "Close the

 connection" to cleanly = shutdown the connection. The initiator

 MAY also issue a Logout with = the reason code of "Close the

 session"[ESQ1] , to completely close the session, but ONLY if it does

 not support or use multiple = connections in the specific

 session.

 

I think this should say:

 

 Initiator MUST send a Logout = with a reason code of “Close the

 connection" (if not the = only connection) or “Close the session”

 (if using multiple = connections).

 

Because once you comply with the 1st sentence, you would not be = able

To comply with the 2nd sentence.

 

Eddy<= /p>