From owner-ips@ece.cmu.edu Mon Jul 2 04:50:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05135 for ; Mon, 2 Jul 2001 04:50:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f626XYL28856 for ips-outgoing; Mon, 2 Jul 2001 02:33:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ws1-2.us4.outblaze.com (205-158-62-54.outblaze.com [205.158.62.54]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f626XWg28851 for ; Mon, 2 Jul 2001 02:33:32 -0400 (EDT) Received: (qmail 2932 invoked by uid 1001); 2 Jul 2001 06:33:26 -0000 Message-ID: <20010702063326.2929.qmail@mail.com> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Received: from ws1-2.us4.outblaze.com for [65.12.81.24] via web-mailer on Mon, 02 Jul 2001 14:33:26 +0800 From: "Tow Wang" To: mbakke@cisco.com, IPS Date: Mon, 02 Jul 2001 14:33:26 +0800 Subject: Re: iSCSI: Iterating long text responses Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark (and others): I'd like to suggest one extra piece of functionality to option 5: let the initiator specify not only the amount, but also the OFFSET of the data it would like to receive, as some implementations of initiators may find it difficult to reallocate/resize the buffer(s) to receive "SendTargets" data. Thus, if the initiator finishes processing data for the first n targets being listed, it would be more flexible to let the initiator say "I am ready to know about any further targets you'd like to report". From the way you described this functionality, I understand that every time the initiator issues the "SendTargets" key/request, the target will rebuild all information about all adjacent targets (so that this target issuing the response will not need to keep state, as you said). If that is the case, would it be too difficult for the responding target to offset into the data it has re-built, and pack the remaining bytes into PDU's? Please let me know your thoughts about this. Thanks. Tow -----Original Message----- From: Mark Bakke Date: Fri, 29 Jun 2001 15:18:20 -0500 To: IPS Subject: iSCSI: Iterating long text responses > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as SendTargets > can easily exceed the response size. [snip] > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if it > can't handle them. This solution is a lot like #1, but with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the problem > of the target keeping state; it sends ALL of the response PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) -- _______________________________________________ FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup FREE PC-to-Phone calls with Net2Phone http://www.net2phone.com/cgi-bin/link.cgi?121 From owner-ips@ece.cmu.edu Mon Jul 2 11:27:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03389 for ; Mon, 2 Jul 2001 11:27:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62DQ4u00650 for ips-outgoing; Mon, 2 Jul 2001 09:26:04 -0400 (EDT) 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 f62DQ2g00645 for ; Mon, 2 Jul 2001 09:26:02 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA20258; Mon, 2 Jul 2001 09:25:55 -0400 (EDT) Message-ID: <3B40754B.97844186@cisco.com> Date: Mon, 02 Jul 2001 08:21:15 -0500 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: Tow Wang CC: IPS Subject: Re: iSCSI: Iterating long text responses References: <20010702063326.2929.qmail@mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Tow- As you said, adding that functionality would either: - Require the target to keep state; it would have to build the whole response, and keep it until the initiator was finished with it. -OR- - Require the target to rebuild the same data, and send a different piece of it. Since the SendTargets response could change in between (targets could be added or deleted, acquire new addresses, or have authorization changes), using an offset would not work; we would have to iterate on something else. Option #3 (from my earlier response) would give you what you had requested with some added complexity to the target. That said, I think that it is in general best to keep the implementation simpler on targets, especially since most of these are equally complex for the initiator. Are you working on a particular initiator that will have trouble with options 4 or 5? Thanks, Mark Tow Wang wrote: > > Mark (and others): > > I'd like to suggest one extra piece of functionality to option 5: let the initiator specify not only the amount, but also the OFFSET of the data it would like to receive, as some implementations of initiators may find it difficult to reallocate/resize the buffer(s) to receive "SendTargets" data. Thus, if the initiator finishes processing data for the first n targets being listed, it would be more flexible to let the initiator say "I am ready to know about any further targets you'd like to report". > >From the way you described this functionality, I understand that every time the initiator issues the "SendTargets" key/request, the target will rebuild all information about all adjacent targets (so that this target issuing the response will not need to keep state, as you said). If that is the case, would it be too difficult for the responding target to offset into the data it has re-built, and pack the remaining bytes into PDU's? > > Please let me know your thoughts about this. Thanks. > > Tow > > -----Original Message----- > From: Mark Bakke > Date: Fri, 29 Jun 2001 15:18:20 -0500 > To: IPS > Subject: iSCSI: Iterating long text responses > > > Initiator developers- > > > > Please respond to the questions at the end. > > > > Thanks, > > > > Mark > > > > > > > > The current iSCSI draft allows text command and response > > PDUs of up to 4096 bytes. While we don't see any real > > problems for the command PDU size, commands such as SendTargets > > can easily exceed the response size. > > [snip] > > > 4. Allow multiple response PDUs to a single text command: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > T->I Text Response (last PDU, F bit set) > > > > Basically, we are doing (3) without the R2T. The initiator, > > upon sending the text command, must be prepared either to > > accept as many PDUs as come back, or throw them away if it > > can't handle them. This solution is a lot like #1, but with > > the response spread across 4k PDUs. > > > > Also note that this (and the following scheme) avoid the problem > > of the target keeping state; it sends ALL of the response PDUs > > without the initiator asking for them. > > > > 5. Do #4, but allow the initiator to specify the amount of data > > it is willing to accept: > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > > > In the above example, we have created a new text command field: > > > > AcceptResponseLength > > > > And in the text response PDU: > > > > TotalResponseLength > > > > The initiator indicated it was willing to accept a 4k response. > > The target returned the first 4k in the text response, but set > > the F bit since it was at its limit. It also returned a > > TotalResponseLength field. Since this was greater than the > > AcceptResponseLength, the initiator knows the amount of buffer > > space it will need to get the full response. It can then choose > > whether it will re-send the command, and if so, can give it a > > large enough response length: > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > T->I Text Response (first PDU, F bit clear) > > T->I Text Response (next PDU, F bit clear) > > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > -- > > _______________________________________________ > FREE Personalized E-mail at Mail.com > http://www.mail.com/?sr=signup > > FREE PC-to-Phone calls with Net2Phone > http://www.net2phone.com/cgi-bin/link.cgi?121 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 2 12:31:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15963 for ; Mon, 2 Jul 2001 12:31:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62FNoQ09050 for ips-outgoing; Mon, 2 Jul 2001 11:23:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62FNmg09046 for ; Mon, 2 Jul 2001 11:23:49 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id IAA23169; Mon, 2 Jul 2001 08:23:01 -0700 (PDT) From: "Rod Harrison" To: "Mark Bakke" , "IPS" Subject: RE: iSCSI: Iterating long text responses Date: Mon, 2 Jul 2001 16:24:32 +0100 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.2314.1300 In-Reply-To: <3B3CE28C.F9748D5C@cisco.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We have a concern over option #5, the outline below assumes that it is safe to issue the same text command more than once with no side effects. This does seem safe for the current use of SendTargets, however it might not be if this mechanism is extended for other long response text commands. Our preference would be for option #3 with #4 a close second. Number 4 has the disadvantage that the initiator has to deal with a stream of unsolicited text responses with no idea of when they might stop. Perhaps #3 with the following modifications might suffice. Add an offset to the initiator R2T (iR2T?) allowing the target to choose to either buffer the whole response or regenerate it on the fly. The target should know whether the data can be regenerated safely and so can make this decision. Add a final bit to the iR2T allowing the initiator to stop the response transfer at any time. Mandate that the initiator must either receive all the data or send an iR2T with final bit set to indicate no more data is required. This prevents a target getting stuck with the response data in a buffer forever. A typical transfer might be. I->T Text command (F bit set) T->I Text response (F bit clear) I->T iR2T incl. valid offset and length (F bit clear) T->I Text response (F bit clear) .... Sequence either ends with T->I Text response (F bit set) or I->T iR2T Offset 0, length 0, (F bit set) Since the first text response is unsolicited all current text command implementations can remain unchanged. Only if the target responds with the F bit clear does the initiator need to change. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mark Bakke Sent: Friday, June 29, 2001 9:18 PM To: IPS Subject: iSCSI: Iterating long text responses Initiator developers- Please respond to the questions at the end. Thanks, Mark The current iSCSI draft allows text command and response PDUs of up to 4096 bytes. While we don't see any real problems for the command PDU size, commands such as SendTargets can easily exceed the response size. There are several ways we can fix this. The first two solutions require no differences in the current iSCSI text command and response; the latter three involve the use of the F bit. 1. Assume that such commands are done on a "special" connection or are handled completely in software, and allow its response PDU to be as large as it needs to be. This one appears too restrictive to be a solid solution. It will also weaken any data digests done on the longer PDU. 2. Create an iterative SendTargets key (and do the same for any other text commands that need this), that would allow the initiator to request the "next target" or "next address". This would work, but would require any new command that needed a large response to implement an iterator. It also means that each part of the response from the iterator would have to fit in the 4k PDU. The remainder of these require that only one text command sequence be outstanding on a connection at a given time. They use the F bit to indicate the last PDU of the sequence. Note that connection allegiance is assumed for the entire sequence, and text commands are never retried on another connection; a new command is issued instead. 3. Do a text-response R2T, where the initiator controls when the next partial response is sent. This would be more generic: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) I->T Text Command (with some indicator that we want more) T->I Text Response (next PDU, F bit cleared) ... I->T Text Command (with indicator that we want more) T->I Text Response (last PDU, F bit set) The main problem with this is that the target must keep track of the state of its responses; if the initiator just stops asking, it may have to keep a buffered response around until it times out, the connection is dropped, or another text command comes along. 4. Allow multiple response PDUs to a single text command: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) T->I Text Response (next PDU, F bit cleared) ... T->I Text Response (last PDU, F bit set) Basically, we are doing (3) without the R2T. The initiator, upon sending the text command, must be prepared either to accept as many PDUs as come back, or throw them away if it can't handle them. This solution is a lot like #1, but with the response spread across 4k PDUs. Also note that this (and the following scheme) avoid the problem of the target keeping state; it sends ALL of the response PDUs without the initiator asking for them. 5. Do #4, but allow the initiator to specify the amount of data it is willing to accept: I->T Text Command (F bit set, AcceptResponseLength=4096) T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) In the above example, we have created a new text command field: AcceptResponseLength And in the text response PDU: TotalResponseLength The initiator indicated it was willing to accept a 4k response. The target returned the first 4k in the text response, but set the F bit since it was at its limit. It also returned a TotalResponseLength field. Since this was greater than the AcceptResponseLength, the initiator knows the amount of buffer space it will need to get the full response. It can then choose whether it will re-send the command, and if so, can give it a large enough response length: I->T Text Command (F bit set, AcceptResponseLength=12288) T->I Text Response (first PDU, F bit clear) T->I Text Response (next PDU, F bit clear) T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) Note that most initiators will probably send an AcceptResponseLength of the largest response they would normally accept, and that most target responses will fit in one or a few PDUs anyway. #5 is really a compromise between #3 and #4; the target has the benefit of being less statefull, and the initiator has the benefit of controlling the amount of data it receives. I would like to recommend either #4 or #5. I think that #5 is probably the safest solution, but #4 may not be a problem for anyone. Assuming that none of the implementors of initiators have a problem with #4, I would pick that. If they do have a problem with it, we should go with #5. Targets probably don't care much whether we do #4 or #5. Initiator developers- Please indicate which solution (#4 or #5) appeals to you. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 2 12:33:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16762 for ; Mon, 2 Jul 2001 12:33:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62EuU107159 for ips-outgoing; Mon, 2 Jul 2001 10:56:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62Eu4g07077 for ; Mon, 2 Jul 2001 10:56:05 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id HAA08588; Mon, 2 Jul 2001 07:55:53 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 07:55:53 -0700 Message-ID: From: Robert Snively To: "'Mark Bakke'" , IPS Subject: RE: iSCSI: Iterating long text responses Date: Mon, 2 Jul 2001 07:55:41 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I have looked over the options for iterating long text responses. In the context of SCSI driver stacks, #5 is a familiar behavior that could be applied very easily to the text commands. If anyone was interested, it could even be extended to a future SCSI command within the SCSI command set. I favor #5. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, > TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, > TotalResponseLength=12288) > > Note that most initiators will probably send an > AcceptResponseLength > of the largest response they would normally accept, and that most > target responses will fit in one or a few PDUs anyway. From owner-ips@ece.cmu.edu Mon Jul 2 12:36:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18598 for ; Mon, 2 Jul 2001 12:36:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62EuO807143 for ips-outgoing; Mon, 2 Jul 2001 10:56:24 -0400 (EDT) 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 f62Eu1g07068 for ; Mon, 2 Jul 2001 10:56:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09513; Mon, 2 Jul 2001 10:55:16 -0400 (EDT) Message-Id: <200107021455.KAA09513@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-fcovertcpip-03.txt Date: Mon, 02 Jul 2001 10:55:16 -0400 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 : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, R. Bhagwat et al. Filename : draft-ietf-ips-fcovertcpip-03.txt Pages : 44 Date : 29-Jun-01 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcovertcpip-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcovertcpip-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010629141336.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010629141336.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 2 14:33:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04065 for ; Mon, 2 Jul 2001 14:33:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62Gmre15043 for ips-outgoing; Mon, 2 Jul 2001 12:48:53 -0400 (EDT) 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 f62Gmpg15037 for ; Mon, 2 Jul 2001 12:48:51 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id QAA11392; Mon, 2 Jul 2001 16:48:48 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Jul 2001 16:48:48 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 09:48:46 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA3A@FMSMSX94> From: "Herbert, Howard C" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 09:48:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C10316.DBCA0BE0" 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_01C10316.DBCA0BE0 Content-Type: text/plain; charset="ISO-8859-1" David: CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17). These standards used DES as the algorithm. We just need to substitute AES for DES. Another excellent reference can be found in section 9.5.1 in "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone. Use of any other algorithms (e.g., one of the new SHAs) raises concerns about being able to scale to 1Gbit/sec. On the second issue, even if you specify a re-keying algorithm that does not solve your problem. You must also extend the size of the sequence number field itself so that you are not having to re-key as often. At the December 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering AES CBC MAC and sequence number rollover (see attached presentation). If the sequence number space were increased to per Steve's proposal, that may also make "manual" re-key viable for the short term (i.e., 2002 products). I would expect that we could achieve quick alignment with the IPsec WG on these issues, have the IPsec WG generate any missing RFCs (if they are not already doing so), and reference them in our specification. Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, June 29, 2001 5:25 PM To: howard.c.herbert@intel.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? 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 --------------------------------------------------- ------_=_NextPart_000_01C10316.DBCA0BE0 Content-Type: application/octet-stream; name="IPsec_WG_1200.ZIP" Content-Disposition: attachment; filename="IPsec_WG_1200.ZIP" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAE1J4ir+z1NbOxcAAABuAAASAAAASVBzZWNfV0dfMTIwMDEucHB07DxtcBzlec/u nj6t851l2TiA7RdMHBtkI1sODYTBlj+IXSxbgxSTMrTR6m5PWnx3e9nbsywmU0SIEwOZFocMjakn CHAzhhLGJZ1pTNMgGiZDwDhqBiaEKdRt+dFQB84EWiBg9Xme9927vS8j7ECTmXtvdt/v5/t93o/d vamfzTl+39+d++9QFq4CA05Nt0BjoEzDa42fiQLWT09T0o+78Zquhz+oEIH/MsQ80u2vjGWov/H5 AMej8qJ0A5a14nVOwAYoisAbxruYuRSeirRhQRf8PBJSbSLwfFMXN/yHyEa8D4ANKbAgi+n1kAQT YrAT01svPwJbX26HwcuOwIEX2+GreJ2YaOpqVnCo7DonjKBCaG4SVg+4CM1EKGcGCxCWULB6wYE0 Xh6MQQbpE9CPORfzROkHw9IRVlcFXaKErpnCIroADkZI1uMwCHIkAfwNSxdD80q86Zx8kFs1cb4l 1BJaBw9E0kC6mn5/LcYXCoC4gu/HAOu4s86QX+cSaQELKKlxdxCakApuoPayB6UHjUHDT4+HxlnR EZgVukinGPLnc8vG/F7srU+SNQAswcvnsknFhoo/qWKyOE21ozrfgkKqPKTKLwiUB/uHPmTcpeLu Gbb/oNjnqzlwUWgNlFfLl8edKiZdh9TVqGJdxQ1Qip9wtwfyoPqA6mNos/KDGI+zRm/RsE3zrSzs x7UojqdJDTPNT2gk6Se5zTPagVUAz3L6GN+n+P4vfP+FxrajNSPVmo7p5rU6YYrCuScJP00B62DR ySgoy5J0NP8vzhWLIR85nyn7jdEBRZ4oaGTwQHY01TSmUfyuMcw1pwxDNYD3jTV43wDSoP04OJDu fNEXBsDDiL0VL+qZgd8afptMczFPdetmASyGptCVXCtxrFaw/fiRm8Nd5FgobP2jI1ARtHaEMe2z FWoLVBGbi6EjJFmfF6I2jy3MnYCn7/ns6m3P/pRi1IK2GOaW0BAvu36IvE3dEu46hHEHVAlIQwT2 zr0CSHy3z13NhY9FZuP9i/zrw98AXI75O+YShGpuey38UjmbF1XZJxFaPvIOgVGK8wewNDCVgXsj vsECHIpcjPctfVkrJjalR8x0zEpZaS8rEo47a7M9PCL6M5YVF9ssb9Rxd6J3vC+C8wxcIkE1k2Yu UTjIPTzENF2i4LeEaOUh8TUofFTf71mZESstrkFUfp9woI9P/4USizTAMvpBwZuL9w0510VQYoOT znquaSMDPtgOqCRFU12H8N5vfSlnIdcinUsNWa7IZkzMWLtHzFzWs510eFM65o5lKCkylotiSZGQ wlvSnjXs2t6YWGam48LMeciQZ8dMark82NSnJAaVDC5VbBCDTTUYPDdI5TZJ5aYCfT7086A2nykE 3+OJXZY7JkZIp1nSaVYsW9UlPjd0aXZ5p0DqRfdqMWR7IuvjkqKImWkxVJAImsLQmMimzGRSYPVO C03FTgtTJKxRkbLTOc/Khq+zvRGGmMtawkmInk39goSUpjZO3MoSPtMTrmXG7eSY8Jyk5ZqeJZKm O2wJ1GAiYcfELieZS1HjIXt4mFRTQlhWmK4lzEzGdTKujb3DfZhysmbyChHuSSadUbHlmk0IG9EO Ox61QDLXfGZFCY9S64gi5xHedDaFtU6aiEL6CYjjxhG3lE0Wq4RlxkYU72gFsWQubkmpyparLpMt USp2wUZiI1Zsp0CWubOVjneyQFJkqnghopiZFDEnhz3cLBGNxGAPJCJbAp1Ah6+1Ypa9yxKjdjqO FKKVmcM8bIWdFWgVqBtTgUyZHkIMb3OQBDNNwnUEG6ZHivFZGrVdqxPJ4vEfF9Id2KlMkqGySUtx DyFRo6YbR1JTGSwfSmI/tPUV/T0ikbR220N2EvklL0Gm/VrBjMc13xxfC5T4s+dD3HpBwIR5QLAJ U25Arxw6SxQcatlQY+iQpwqM377KQXkO1B42yzFBpotCTZho+i5ZbVp0b9zUH16f8zrFhvUb2J7J 8O2UfRPapJPJOK6XS9uebbETRUtxcbBYSVZ4xs5YSTuNMi6TbniD1L0cH2JZwnaznohbu6ykk8Hm BKlnoBd15HOzHBWYsIrw7WwqiMJOD5cSE74aQbBm0fZ8U1Pk48AWZgx1ilkehw4W+MObgDo5thdp g6br2rvMJBoMDVMbeUiOhX2BXqxVquoiKK6Nmmuoilx9j5BDGPn1xRHQXi+S6mNZchq1nYdo/O4k tlWXrRgaQ6aGcETsZF+UHXFyyTh5tVWrP8ODoFOM2RYWxW2SKY0kZDBncf/AeC8M//6e8NYK38Ay ZQSMKovDyhth5yh7FxwZm1EaXbCFfgBVnGY8W/p2XSZuRH/kDLtmKrzN2u2hu5Kg2dX5RCjddaJ7 JS2To7J2Z1BNKLdN/X3lzk0sI+fGPq3SnxHgGCmUTLLEty2XFPjuLOZIT2Ui+Jhr+QLCJuioaFpI uE5K9F+z6U+2bOyUho9o0C2g+RE5VlZa0k7LyhDVvgFKaOEBJ1NCk8ndFcNbdohluXTGteJ2zDPR 5yCpGXLYDjNfkAfxOWImE1yaxfFINsst1Ppgy47lYd83xQrGd6Tgm2KBklLfdCRgcC0Q9E3XVzF4 f8NDBt9Yw+BxFw/FRUQV1zQfatn4RORhzFyHO1gPRkBAAvevWUwL3BWnkQmXd8ge1tOOuRPLqR3t mG3Me5ga5v0v7aQFrkEE9s+pNmnuF8MSv7/AnAMphEhtguW0Gx/FeAj7yTZ0akDQqIx26h7urQmm xfvrTqZgJeZWcnoz7ul7cHsgcOnYCxvh05iiHT3t7DdjzQpYBcu5D0HNIizCF+aTgLjCRVSbzLuk YIh5tGrIQnJbTQophDKmeBFY4zAOgjqCKZII4evkFiSHMOYkx8Svy7E8nZCUpLHeZq1ImQqk3NfX JuSvD+MM9nMU5CxTNczQ0ow5i/SkWeK7WULVdUR4E5hzGVdR18RrnOXuS2B5Cc02a9TBkiLlkksT OUxyaYbh0CkJ1Ul5J5SGsiyxJJ+gZNT5iQV0fhJWFEiZlMrVl3ySMcQwnVOnMFIWGe4nNSJLJC0p ZVdZlqPsL+2AsDiwi/t1qlrBpV9C2LaiwoTiKOlk6j0l5xWM31E2U80yqH6YMUn9pQJSkJqUeH2p 26xtabM5lm9cQRYIieSYA7LzBN570M7DePdHjaTLVVQmWaKfELI2zvLxuBfhXREYPUXbMhX3ccQS U7gvh8tYA5Iyh+1IjublBalSP7KXBNsZaTyMOKSVEB2dAQlazLscecSVP46lZEmvOaaB8iv5R053 K94nCw7wiYI3O1woW1oo89s9oWJugz5PC/GOSR3eSD95Xcni8FXe80bgbePbzeSAXzcWKKia3tTi Hy34YRDyTQL4BITz4+PjsuLofujuPgpHj07Do48+WmhH5yZ+W4qm98sEldx9990BeEe5TSLRDQSy ez/GVIAwp48mKvB2d8szrpdeeolp6O3thVdffbUmfQSDaEEKYXJysmY7qoOEpA/21+a3e/807J8+ yvCIX4AHIlcByW3mZ5QateZAGBKnaNZ6IPIV8E86m9BWdO69/xRBoYnyhdNA8U869zaQPnPwnCY0 jdt1wDcb6MCgAxFNqXPPcSyZK/Lq5JNy/wjRhvEQQW5HOzzdmesilSqlBMA/c21TlHzYM9f/n5Pe PsR6rSwCrYXGhqYwaZyfjbGEpnO+DfMSolHIS6ihQl5CHkTIbQAFeBQyylIaCiU66kcrpNtBD6SN QDpUSEdxbFRCaQ9AiQagRANQogEos9FK2kKJEFmLnv8zXjU155sV1KYOyi846a+iImDk8wbFobw8 127JRzGevrn0p0MrwyBzbQDZngC0q3KdzLi1eH57M1vwOEw4R+AWGDU1+Arc/z2AWzn9VU5/nSl4 HOlZXHbSq8EcddIrT3enMd1Scn6LXDDece2wNtUxoUdgDtMN8ONZvnfTcLkagXD+C5wrXXYKvG9I 2nS24AhcUHuiV+1tbQ8X1llvLIkr0Psj5FEvUL0e4qNJyskT9JaQlMPGgBwMJYffwKz89VCUw7fd 2nI4Owl0GSSBzOxyCRAgXUngfi4v3R9eW1MCtN9hAWTD/RZueOIiSRvw8MCI7frpq52c6434GTvh p0lmiwoyCzO+NqaE0kbhWYGUZT+Uy5J0tV6TsgwpWd6KsuzC5B7mWlmNBvw04D1tGTyjXfVv1c74 fQlN6Ye1ox1TOsEPBXTVVKarcfjG6Om01F6hJSg8kfC1BGU07DWkvCUlJyL3RG+d/0qUdHITl0ud SMs8FIkS9+u3iQErNpJ2ks6wbWVpzUBH8XO4DQg65JfpJpQnpWiOkWsAyhXXAN/lg5+TqI7l+rna udoafY2+3dhu2CE7RLJYD0VZaCQLBJFFWdBR+C3M4V3aX9x7B3xLe/mfRlDii+iRAXMYMmjzt9Yg 247OcO0g4DGmcRtqvQdzO3CfE4G80dpINnLSf7yBncNd5MGebpAe7J/JpysPRrbStFt6resbKr3W N6WwWQZ3aSR/5bV2F73WCwGudSwnC3gAuaZHGf5oXfeTPdqZjkcKfU1Cq+aRWvU9Gul+gHNB3U9E CAJJ/r4IqcL3835K55HzTsCHyRFEtaUj6EUIeKMa/MHTZ8PfnS3Ho5X8aUyJ5G8Hl9fibz4U+Gum VJDDt2fAYRyKHIYUhzHk8CIgDkP4kz7iZo2oelybg7yRd2iBtbrGNZIT9Jt6dLZoLeeEMDYwJ6H8 0oC/aKghzR8cO3NpHm5dp0/Mnuoop4Hm9kZlLUHvLWX1++q9X4aitBqVtL6P0iJP40sr/7M92teZ jzOV2eA8GmHj88tlRpS1nOUIe3cG9nccAnNIDS7//vmz55LGWSWX5Mea9bMdZy/MgM/NEJgfiM+2 4lws54dbtQaeJWh++BbPFY9r7djnzGeJCLxmPMZykDtWCjwtgj87+I9s3zFUMQdcw4P+Ujuvfa/V 5czxxzo9KpYzB40nAkgzx39olTNHeSjMHAuKM8dPIDBzYLlA+N243nWBCDt4ovbaYQ/D/BrfpW/a y+nb+H473+/gu1wL0spiDhTXFOS5mEeD1tl71cJf2skLWh7y8w41VptvImr9xzs3+E7gXadQ/l8h ME9UcHPiwEy5oXCm3BgV3GSan9J+0DEerja7RBU3F3L5dwKr2e+yBb8NtJN+Dr163og2VFgwmVNN C/7w65x9+/ZxbP7l+wCPANBK9NixY2zBL2hFCyY0YX4ZoWjBNM7IUvdq0lLHMV4XtNQD0lIXnMZS n8XrHghY6oGipaIjL1rqAanbDcg30TMOV8b3aKQTjbnUlFXNZEcVVvN7NXsK4jQqcL5SgdMI4Dzd HmZ2FZwaVPFQiHNm+j17D3Um+u0L6vfQGej3UA39HiqX9cHUR67fCpyD6Y9cv4jz91m/g0H9TpyB fidq6HeiXNYT2Y9cvxU4b/A+cv0izo9Lv481zEy/N6o96BDGGaVfuuYcRvnAgpM+jzpIfb8a+hD6 PlzU9/MQWDdjOa0of4xyIPmMw9tf3qMFzz4+6Ayi/BxkryFXflJXk8Zk5PDcqQbSyZ9yeekZBL0K It8RUA+Uw8vUE+nl/qJygeSomZiUaZ2PseUhBJX4hxDlC43mCuaO3vK7ZW6wZTIimYtzeSlztLmh dwPKXiQLi2XqFYMCj4u5h+RRpoM8UkmQx2egyGPLYSjjMar/bnmc0O9slDz2V+GRtmpbdiBL5Wqb HWBpdgVLs8tYCvqD1sPl/qBt70ftg2ZV4rztdD5osHFcm+g4XnXleDof9GQAZxRxBndz4/Dc7Wen uqLS7mwcbJFKu5apKFUaUfYF1Jl6z6SgszDXS53JdFBnwZdFiZcboXh6OqeMlyAXG4mLwvlIORfH 1DvTC3AoV+dlahb+KlfYhPFj8uBnMkOL4Ax9sPYMPY7CQQXwi9e9EPDYB2vM0AfLLXXrU0fgTEdH 7R1byQxdgbP5p+U4Zz5DV+L0R0eJfhHnx6FfAPecLqahi6uXzQN4cQm9pBiFpxbS69B9cGApwA0X A1zZCXAKbfbLpEB4i0/K6cj917Pl47GXuyUvn2J4i6UfrYc/8HBqmkZipTJJ08f33PvGO9tHon+7 rxku+dT3f9mFZQON8isVqh8B6csyIL3vwyC9xSTItd0JkK+2ySdFOH40+SVMlyZhXKlJv7uZPQfC 1uRzlxs0CfcVBErLjNXUxhnFpUYs51pig5kW11mi19xJb/VtsFzPTqjX5EVPzhtx6P23teDY1HcW 8McBuyz5acAGKrsQr14zZqc9JzsiNm+8os+1soUXZ6/Y1t8jdnwaPO4fkbjpDeXNlosLHA8sKqch sWY1mJSeR/DsmOtknYQn+pxRy+1zEDqCcNZhXZ/4+ehnMab0+Ou3f8/70Y80Suff7hifYzyhEazb kefPYfxaSD6tN1iGt0WH29ibIkJHpxmKBydLaWljBGeVaXYBUfDDpEFP6aTcqUUztyBpnqNKlnBJ CM6DgW19fR0Q146whKent/N82As29P15q2rdyq1IH28apTCJwogq6eBWIX6yL22DAnn4WbqfatOn 9EmDUiGNtE6W8p7u+zCynxWatJt39YYCDFmuFeqJhoWNF0AeCFqxRXV4Osf5AlwohNJepdiMAlaq PS+0UHvQ2I6SD8KkvuQhf1vND77RDvvct0bXYfK/m1rvDn/+rdH5eEksXap/iKXSQv11SnUwJAnz GenW4YcSOgLqcW0zCRLm11prwWxQ/BZhJwKwKbWSD+8opdM6he1pdeuDuLahNVL1z3bIZhbBQvxF MXUBCMzRtQgu5VQ71kSA3omZp3BoBRy6Ss2ElouYll/BL2Aupqp9K7QU8Qj8SToWMvYIzkgLEfsl jJ+orEWDTFXXcY+eM0a0rRU6rka71NHx0+oI9f7XtfQuddRQVf/V5PIJILl8Q7tJI68Z/NRpHvq3 dpTWXL634BineNaMJKAVJCH5iapnFpIfXK1e2D+W9awU5VrBX18TlFo2V+kNgqHUexAMeVztQj3U Qz3UQz3UQz3UQz18fOF0+3/9+WefP7DyvOhdf4X7/853HunCsr263G1S/V6Qa7g7Qe4ED4FcJT4J 8iz1KMj91XMg91/0+IJWga+AXFHS+QDtSt8EuU9/DyRsOi+gHUCbJr9Z69DkOcH5mjw3WKaXng8Q 7u3pFdmYa+G6uH/EGZXlc6DaO6AJpvmKNZJ2er/HUPSq1yeqxr+e3cI0UqgVL4rKNMEasFOIjFJy V0A09jppxxvLWKLfcb0ss8KVYn3SjO1kUamzB/q7g+p7MVFtW9QB1f+xgD7hP82H/iT7Gh8zL4EZ fTzLe8aqnxy2RaUc/DOYqx1i4PMIjMUZUlXYCjZaWXs4jVpKZZKmZ3G9pupJ7f1JO26JAXqbPFvQ VT3UQz3UQz3UQz3UQz3UQz3UQz182PA//Hc0tIX84uS+/5y/ht5iedMwYI9W+tybdvCb+f9S6P8k /q+9M0hpIAii6FeY/SjERUAQQYjBCC4E9yroymDwAuJWF0IO4MadJ/AG3sBTeA3xDqL9qrrDgBpm 1IVCPRgyTJOpmSab9P/1mxSII8ttOM8JG0EQBEEQBEEQBEEQ/FVM55dmoiz+TvRVxGj+8aPXo9Wj 4ZY+KRqE0LNruca+LNfrWUPoyTV7tGVcrHhX+/I9gvCZrsqFXdr+1uT5KOt5HP/vhjy1kS4TvMl0 Dw3z+Fb6HKVjW2xg4Lt57Mj7Axh/TcduPg/acWq5tKR4HlpSKdmuXVhRtVDuxW+ovru5uD95Wrp9 0YMeN58/+07ZLwr2LdnzWiXT9szyPtt7gvtanNV/a9x3Hra9RO3nlSbpCS4tVZZ3P07P4VmsXCkp v18zyB7tLvWxZZT6Y1tR443Hlgrss3BgKb5TS9a9mru2Nmh4utvWB/wvUH2o1W0+9r4x/5hLGi0r P6Zr/d/mP9d/B1BLAQIUCxQAAAAIAE1J4ir+z1NbOxcAAABuAAASAAAAAAAAAAAAIAAAAAAAAABJ UHNlY19XR18xMjAwMS5wcHRQSwUGAAAAAAEAAQBAAAAAaxcAAAAA ------_=_NextPart_000_01C10316.DBCA0BE0-- From owner-ips@ece.cmu.edu Mon Jul 2 14:36:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05912 for ; Mon, 2 Jul 2001 14:36:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62GWft13942 for ips-outgoing; Mon, 2 Jul 2001 12:32:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from exchange.store-age.com ([199.203.178.211]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62GWdg13938 for ; Mon, 2 Jul 2001 12:32:39 -0400 (EDT) Received: by exchange.store-age.com with Internet Mail Service (5.5.2653.19) id <3BY2PWKK>; Mon, 2 Jul 2001 19:32:05 +0200 Message-ID: From: Nelson Nahum To: IPS Subject: iSCSI: iSCSI test tool Date: Mon, 2 Jul 2001 19:32:05 +0200 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 very nice iSCSI test tool can be downloaded free from http://www.swattest.com Enjoy, Nelson From owner-ips@ece.cmu.edu Mon Jul 2 15:42:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19610 for ; Mon, 2 Jul 2001 15:42:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62IMiO21813 for ips-outgoing; Mon, 2 Jul 2001 14:22:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62IMgg21808 for ; Mon, 2 Jul 2001 14:22:42 -0400 (EDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id SAA22187; Mon, 2 Jul 2001 18:22:29 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Jul 2001 18:22:28 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 11:22:26 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA40@FMSMSX94> From: "Herbert, Howard C" To: "'Black_David@emc.com'" , ips@ece.cmu.edu, "Walker, Jesse" Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 11:22:23 -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 David: I will find out if anyone is writing a AES CBC MAC draft over in the IPsec WG. If no one has started, then I will sign up to producing one. Also, Steve Kent's sequence number proposal DID NOT change the format on the wire (at least that is what he says on slide #3). I think we are going to have to come to terms with folks who want to use IKE in this application. The functionality already exists in the major host OSs and HBA vendors are going to want to take advantage of that fact (one less thing to add). Maybe the trick here is to define a subset of the IKE functionality that limits the impact to target vendors. If we can do so, would you consider making IKE mandatory to implement? Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 02, 2001 10:56 AM To: howard.c.herbert@intel.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal > CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17). > These standards used DES as the algorithm. We just need to substitute AES > for DES. Another excellent reference can be found in section 9.5.1 in > "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone. > Use of any other algorithms (e.g., one of the new SHAs) raises concerns > about being able to scale to 1Gbit/sec. I'd suggest writing a draft on the use of the AES CBC MAC with ESP and starting it through the IPsec WG, as I think that would have to come out as an RFC at the same time as iSCSI in order for iSCSI to use it. Such a draft will also be necessary to get an ISAKMP value allocated for the MAC, which will be needed independent of whether iSCSI uses IKE. Absent such a draft, we may be left with no choice but to use one of the SHAs (or MD5). FWIW, there are chip vendors who are claiming the ability to do SHA-1 at multi-gigabit speeds, so I don't think scaling to 1Gbit/sec is a showstopper. OTOH I would agree that whether any of the SHA algorithms can be effectively scaled to 10 Gbit/sec in the near future is an open issue. > On the second issue, even if you specify a re-keying algorithm that does not > solve your problem. You must also extend the size of the sequence number > field itself so that you are not having to re-key as often. At the December > 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering > AES CBC MAC and sequence number rollover (see attached presentation). I'm familiar with Steve's presentation, as I was in the room in San Diego when he gave it. What he described is a worthy goal, but is not compatible on the wire with current ESP. If iSCSI were to depend on this, iSCSI would be likely to get caught in a security document hairball/tarball behind a whole pile of potentially pending revisions to IPsec (e.g., iSCSI will depend on an ESP rev that depends on "son of IKE"). I don't recommend this if the goal is to get a stable iSCSI document completed in a timely fashion. > I would expect that we could achieve quick alignment with the IPsec WG on > these issues, have the IPsec WG generate any missing RFCs (if they are not > already doing so), and reference them in our specification. Writing drafts that will become the "missing RFCs" is a better approach, and (as indicated above) I would stay away from any basic revisions to ESP. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 2 15:43:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19621 for ; Mon, 2 Jul 2001 15:42:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62IlQV23508 for ips-outgoing; Mon, 2 Jul 2001 14:47:26 -0400 (EDT) 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 f62IlPg23501 for ; Mon, 2 Jul 2001 14:47:25 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 14:49:10 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070988@corpmx14.us.dg.com> From: Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 14:43:49 -0400 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 Howard, > I will find out if anyone is writing a AES CBC MAC draft over in the IPsec > WG. If no one has started, then I will sign up to producing one. Thank you. > Also, Steve Kent's sequence number proposal DID NOT change the format on the > wire (at least that is what he says on slide #3). True, BUT ... it does change the data over which the authentication (MAC) algorithm is run (two bullets above on the same slide) - the 16 bits that aren't on the wire are included in the authentication/integrity check. Before anyone draws the wrong conclusion, Steve also proposed that this behavior be negotiable on a per-SA basis for backwards compatibility. This change really needs to be made via a modification to RFC 2406 (the basic ESP RFC), hence the concern about the security document hairball/tarball. OTOH, I was just involved in the new ECN RFC (coming soon from the RFC Editor) which managed to "update" RFC 2401 (IPsec architecture) without getting hung up, so this sort of modification isn't completely out of the question. > I think we are going to have to come to terms with folks who want to use IKE > in this application. The functionality already exists in the major host OSs > and HBA vendors are going to want to take advantage of that fact (one less > thing to add). Maybe the trick here is to define a subset of the IKE > functionality that limits the impact to target vendors. If we can do so, > would you consider making IKE mandatory to implement? It's up to the WG, but I have no fundamental problem with an IKE subset ... and I've been independently pursuing a set of volunteers to work on such a subset - want to join the party? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 2 15:44:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20376 for ; Mon, 2 Jul 2001 15:44:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62J0EP24439 for ips-outgoing; Mon, 2 Jul 2001 15:00:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62J07g24421 for ; Mon, 2 Jul 2001 15:00:07 -0400 (EDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id TAA01486; Mon, 2 Jul 2001 19:00:05 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Jul 2001 19:00:04 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 12:00:02 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA44@FMSMSX94> From: "Herbert, Howard C" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 11:58:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Points on the hairball/tarball noted - things are sticky enough already. For the IKE subteam - Sure, sign me up. -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Monday, July 02, 2001 11:44 AM To: howard.c.herbert@intel.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Howard, > I will find out if anyone is writing a AES CBC MAC draft over in the IPsec > WG. If no one has started, then I will sign up to producing one. Thank you. > Also, Steve Kent's sequence number proposal DID NOT change the format on the > wire (at least that is what he says on slide #3). True, BUT ... it does change the data over which the authentication (MAC) algorithm is run (two bullets above on the same slide) - the 16 bits that aren't on the wire are included in the authentication/integrity check. Before anyone draws the wrong conclusion, Steve also proposed that this behavior be negotiable on a per-SA basis for backwards compatibility. This change really needs to be made via a modification to RFC 2406 (the basic ESP RFC), hence the concern about the security document hairball/tarball. OTOH, I was just involved in the new ECN RFC (coming soon from the RFC Editor) which managed to "update" RFC 2401 (IPsec architecture) without getting hung up, so this sort of modification isn't completely out of the question. > I think we are going to have to come to terms with folks who want to use IKE > in this application. The functionality already exists in the major host OSs > and HBA vendors are going to want to take advantage of that fact (one less > thing to add). Maybe the trick here is to define a subset of the IKE > functionality that limits the impact to target vendors. If we can do so, > would you consider making IKE mandatory to implement? It's up to the WG, but I have no fundamental problem with an IKE subset ... and I've been independently pursuing a set of volunteers to work on such a subset - want to join the party? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 2 15:44:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20692 for ; Mon, 2 Jul 2001 15:44:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62Hxet20219 for ips-outgoing; Mon, 2 Jul 2001 13:59:40 -0400 (EDT) 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 f62Hxdg20215 for ; Mon, 2 Jul 2001 13:59:39 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 14:01:26 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070985@corpmx14.us.dg.com> From: Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 13:56:02 -0400 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 > CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17). > These standards used DES as the algorithm. We just need to substitute AES > for DES. Another excellent reference can be found in section 9.5.1 in > "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone. > Use of any other algorithms (e.g., one of the new SHAs) raises concerns > about being able to scale to 1Gbit/sec. I'd suggest writing a draft on the use of the AES CBC MAC with ESP and starting it through the IPsec WG, as I think that would have to come out as an RFC at the same time as iSCSI in order for iSCSI to use it. Such a draft will also be necessary to get an ISAKMP value allocated for the MAC, which will be needed independent of whether iSCSI uses IKE. Absent such a draft, we may be left with no choice but to use one of the SHAs (or MD5). FWIW, there are chip vendors who are claiming the ability to do SHA-1 at multi-gigabit speeds, so I don't think scaling to 1Gbit/sec is a showstopper. OTOH I would agree that whether any of the SHA algorithms can be effectively scaled to 10 Gbit/sec in the near future is an open issue. > On the second issue, even if you specify a re-keying algorithm that does not > solve your problem. You must also extend the size of the sequence number > field itself so that you are not having to re-key as often. At the December > 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering > AES CBC MAC and sequence number rollover (see attached presentation). I'm familiar with Steve's presentation, as I was in the room in San Diego when he gave it. What he described is a worthy goal, but is not compatible on the wire with current ESP. If iSCSI were to depend on this, iSCSI would be likely to get caught in a security document hairball/tarball behind a whole pile of potentially pending revisions to IPsec (e.g., iSCSI will depend on an ESP rev that depends on "son of IKE"). I don't recommend this if the goal is to get a stable iSCSI document completed in a timely fashion. > I would expect that we could achieve quick alignment with the IPsec WG on > these issues, have the IPsec WG generate any missing RFCs (if they are not > already doing so), and reference them in our specification. Writing drafts that will become the "missing RFCs" is a better approach, and (as indicated above) I would stay away from any basic revisions to ESP. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 2 16:34:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22659 for ; Mon, 2 Jul 2001 16:34:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62IpT323867 for ips-outgoing; Mon, 2 Jul 2001 14:51:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms3.broadcom.com (mms3.broadcom.com [63.70.210.38]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f62IpRg23859 for ; Mon, 2 Jul 2001 14:51:27 -0400 (EDT) Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom MMS-3 SMTP Relay (MMS v4.7)); Mon, 02 Jul 2001 11:51:23 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA04762; Mon, 2 Jul 2001 11:51:24 -0700 (PDT) Received: from ltjtardo (dhcpe1-sj1-390 [10.16.66.136]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id LAA16218; Mon, 2 Jul 2001 11:51:25 -0700 (PDT) From: "Joseph Tardo" To: "Herbert, Howard C" , Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 11:51:24 -0700 Message-ID: MIME-Version: 1.0 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.6600 In-Reply-To: <3677E033A5F3D211AC4000A0C96B53EB05C2EA3A@FMSMSX94> X-WSS-ID: 175E1D21403784-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Howard: These proposals have been discussed in the IPsec WG but not much progress has actually been made. It remains to be seen what happens in London, but "quick alignment" is perhaps optimistic. To adopt AES and longer sequence numbers for iSCSI means potentially holding up the RFC until IPsec completes its part. Interlocking standards even within the security WG itself created undesirably long delays in the past. It also severely limits implementation options until interoperable products supporting these features become available. On another note, I would also take issue with your assertion that SHA-1 would be impractical at Gigabit and beyond but AES in 128-bit block CBC feedback mode MAC would work. This has not been the case as far as I have seen. Do you have anything to substantiate this? Gigabit 3DES+HMAC products are available today. By the way, sequence space exhaustion is only one motivation for re-keying. --Joe -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Herbert, Howard C Sent: Monday, July 02, 2001 9:49 AM To: 'Black_David@emc.com'; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal David: CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17). These standards used DES as the algorithm. We just need to substitute AES for DES. Another excellent reference can be found in section 9.5.1 in "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone. Use of any other algorithms (e.g., one of the new SHAs) raises concerns about being able to scale to 1Gbit/sec. On the second issue, even if you specify a re-keying algorithm that does not solve your problem. You must also extend the size of the sequence number field itself so that you are not having to re-key as often. At the December 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering AES CBC MAC and sequence number rollover (see attached presentation). If the sequence number space were increased to per Steve's proposal, that may also make "manual" re-key viable for the short term (i.e., 2002 products). I would expect that we could achieve quick alignment with the IPsec WG on these issues, have the IPsec WG generate any missing RFCs (if they are not already doing so), and reference them in our specification. Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, June 29, 2001 5:25 PM To: howard.c.herbert@intel.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 2 20:07:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04246 for ; Mon, 2 Jul 2001 20:07:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f62Ljht05825 for ips-outgoing; Mon, 2 Jul 2001 17:45:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f62Ljfg05821 for ; Mon, 2 Jul 2001 17:45:41 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id VAA06514; Mon, 2 Jul 2001 21:45:26 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 02 Jul 2001 21:45:26 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 2 Jul 2001 14:45:24 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA47@FMSMSX94> From: "Herbert, Howard C" To: "'Joseph Tardo'" , Black_David@emc.com, ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Date: Mon, 2 Jul 2001 14:45: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 No issue that SHA-1/3DES can be scaled to 1 Gbit. I am just trying to avoid creating legacy implementations that will not scale to 10 Gbit that I then have to keep around for backward compatibility with the original 1 Gbit implementations (i.e., I only want to have to put "one" algorithm into hardware not "three"). Howard -----Original Message----- From: Joseph Tardo [mailto:jtardo@broadcom.com] Sent: Monday, July 02, 2001 11:51 AM To: Herbert, Howard C; Black_David@emc.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal Howard: These proposals have been discussed in the IPsec WG but not much progress has actually been made. It remains to be seen what happens in London, but "quick alignment" is perhaps optimistic. To adopt AES and longer sequence numbers for iSCSI means potentially holding up the RFC until IPsec completes its part. Interlocking standards even within the security WG itself created undesirably long delays in the past. It also severely limits implementation options until interoperable products supporting these features become available. On another note, I would also take issue with your assertion that SHA-1 would be impractical at Gigabit and beyond but AES in 128-bit block CBC feedback mode MAC would work. This has not been the case as far as I have seen. Do you have anything to substantiate this? Gigabit 3DES+HMAC products are available today. By the way, sequence space exhaustion is only one motivation for re-keying. --Joe -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Herbert, Howard C Sent: Monday, July 02, 2001 9:49 AM To: 'Black_David@emc.com'; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal David: CBC MAC has been standardized for years (see FIPS PUB 113 or ANSI X9.17). These standards used DES as the algorithm. We just need to substitute AES for DES. Another excellent reference can be found in section 9.5.1 in "Handbook of Applied Cryptography" by Menezes, van Oorschot, and Vanstone. Use of any other algorithms (e.g., one of the new SHAs) raises concerns about being able to scale to 1Gbit/sec. On the second issue, even if you specify a re-keying algorithm that does not solve your problem. You must also extend the size of the sequence number field itself so that you are not having to re-key as often. At the December 2000 IETF meeting, Steve Kent of the IPsec WG presented proposals covering AES CBC MAC and sequence number rollover (see attached presentation). If the sequence number space were increased to per Steve's proposal, that may also make "manual" re-key viable for the short term (i.e., 2002 products). I would expect that we could achieve quick alignment with the IPsec WG on these issues, have the IPsec WG generate any missing RFCs (if they are not already doing so), and reference them in our specification. Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Friday, June 29, 2001 5:25 PM To: howard.c.herbert@intel.com; ips@ece.cmu.edu Subject: RE: iSCSI IPsec-Related Algorithm Proposal > Specifically, phase one products would use AES CBC MAC mode as the integrity > algorithm and AES CBC mode as the confidentiality algorithm. This proposal > means vendors only have to implement a single base-algorithm with slight > mode variations in order to have a complete 1 Gbit solution (integrity and > confidentiality). Adopting AES in phase one also establishes a foundation > upon which to build phase two solutions (different modes of operation on the > same base algorithm). What would you recommend as reference specifications for these algorithms, and specifically their use with ESP? There are no RFCs specifying this, and I haven't seen an Internet-Draft on the MAC (there is one on use of AES for confidentiality). My personal preference would be for something AES-based (perhaps using one of the new SHA hashes in an HMAC instead of the AES CBC MAC) rather than falling back to things like SHA-1 and 3DES. Meanwhile, we have another issue. As of the outcome of the Nashua meeting, the minimum (MUST implement) requirement for keying ESP was manual keying. That's not going to be sufficient because there will be situations in which iSCSI causes ESP's 32-bit sequence number to roll over, creating a vulnerability to replay attacks. This is going to require specification of a MUST implement rekeying algorithm. IKE or a subset is one possibility, and working out the details of SRP-based keying (and rekeying) of ESP is another. A somewhat drafty draft on the latter may appear prior to London assuming that I can find the "copious spare time" to get it written. Comments? 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 3 10:56:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23435 for ; Tue, 3 Jul 2001 10:56:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f63CwHJ05234 for ips-outgoing; Tue, 3 Jul 2001 08:58:17 -0400 (EDT) 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 f63CwDg05227 for ; Tue, 3 Jul 2001 08:58:13 -0400 (EDT) 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 OAA336144 for ; Tue, 3 Jul 2001 14:58:01 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f63CvwK63292 for ; Tue, 3 Jul 2001 14:58:02 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7E.0047005A ; Tue, 3 Jul 2001 14:55:31 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Tue, 3 Jul 2001 16:03:49 +0300 Subject: RE: mailing list Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk To clarify the point the text in 1.2.2 reads now: MaxCmdSN and ExpCmdSN fields are processed as follows: -if the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), they are both ignored -if the PDU MaxCmdSN is less than the local MaxCmdSN (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), it is ignored; else it updates the local MaxCmdSN -if the PDU ExpCmdSN is less than the local ExpCmdSN (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), it is ignored; else it updates the local ExpCmdSN And 2.4.9 & 2.4.10 read: 1.1.1 ExpCmdSN - Next Expected CmdSN from this Initiator ExpCmdSN is a Sequence Number that the target iSCSI returns to the initiator to acknowledge command reception. It is used to update a local register with the same name. An ExpCmdSN equal to MaxCmdSN+1 indicates that the target cannot accept new commands. 1.1.2 MaxCmdSN - Maximum CmdSN Acceptable from this Initiator MaxCmdSN is a Sequence Number that the target iSCSI returns to the initiator to indicate the maximum CmdSN the initiator can send. It is used to update a local register with the same name. If MaxCmdSN is equal to ExpCmdSN-1 that indicates to the initiator that the target can't receive any additional commands. When MaxCmdSN changes at the target while the target has no pending PDUs to convey this information to the initiator it MUST generate a NOP-IN to carry the new MaxCmdSN. Julo "Ayman Ghanem" on 03-07-2001 05:36:26 Please respond to "Ayman Ghanem" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: mailing list Thanks Julian. Looks like the URL I put for point (1) below was not the right one. Here it is again about having MaxCmdSn = (ExpCmdSn - 1) as allowed value. Any comments?. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05088.html Thanks. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > julian_satran@il.ibm.com > Sent: Saturday, June 30, 2001 6:41 PM > To: ips@ece.cmu.edu > Subject: RE: mailing list > > > > > No - I did not see it earlier - probably wwhen I was taken of the list... > > comments in text. > > Thanks, > Julo > > "Ayman Ghanem" on 30-06-2001 23:45:13 > > Please respond to "Ayman Ghanem" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: RE: mailing list > > > > > Julian, > > I sent this to you last week. Not sure if you got it. Also, in the Task > Management Response, I believe the MSB of the reserved field (bit 24) > should > be set to 1 like other PDUs going from the target side. > > > +++ fixed +++ > > -Ayman > > > > ------------------------------------------------------------------ > ---------- > > ------ > Julian, > > I have the following comments on draft-6.90: > > 1- I am not sure if you saw this posting, but it is not clarified in 6.90 > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05089.html > > 2- I would prefer, for this draft and any future drafts, that any new > response codes added to be assigned new values and not values assigned > earlier to still-existing return codes. This will help backward > compatibility with earlier drafts. For example, Task Mgt Rsp, Reject, and > logout have responses which existed in earlier drafts but are now > given new > codes. > > ++OK (for the future and if regularity does not require otherwise) +++ > > 3- Section 7.1, there is no reject response code for "Unsupported Replay". > > +++ yes there is - code 7 - i'll make wording clearer +++ > > 4- In sec. 4.1, version number 0x'01' should be 0x'02' > > +++ fixed ++++ > > 5- Sec. 2.16.5, no Additional Runs field in the SNACK PDU > > +++ fixed +++ > > 6- Bit-7 of byte 1 of the logout command should be set to 0, or > as an F-bit > to be consistent with text of section 2.2.2.4 > > +++ Logout is always single and last. That is why I set the F bit to 1 +++ > > 7- In section 2.16.1, "targets MUST support Status SNACK". However, in > section 1.2.2.2, "To enable command recovery the target MAY > maintain enough > state information to enable data and status recovery after a connection > failure". These seem to be inconsistent. Also, I could not see > the scenario > if the target can not support a Status SNACK request. If dropping the > connection is the option, then I think it should be clarified. > > +++ the current text reads: > > > An iSCSI target that does not support recovery within connection MAY > discard status SNACK. If the target supports command recovery within > session it MAY discard the SNACK after which it MUST issue an > Asynchronous Message PDU with an iSCSI event indicating "Request > Logout". > > > ++++ > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > julian_satran@il.ibm.com > > Sent: Wednesday, June 27, 2001 8:29 AM > > To: ips@ece.cmu.edu > > Cc: bassoon@YOGI.PDL.CMU.EDU > > Subject: mailing list > > > > > > > > > > Dear colleagues, > > > > I do not receive mail from the list (since mid last week). > > Please address mail that you think should reach me adding me explicitly > > until the issue is fixed. > > > > Regards, > > Julo > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jul 3 12:02:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10413 for ; Tue, 3 Jul 2001 12:02:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f63E8bK09906 for ips-outgoing; Tue, 3 Jul 2001 10:08:37 -0400 (EDT) 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 f63E8ag09901 for ; Tue, 3 Jul 2001 10:08:36 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 10:10:23 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070993@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: draft-ietf-ips-iscsi-reqmts-04.txt - Informal Last Call CLOSED Date: Tue, 3 Jul 2001 10:05:00 -0400 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 There have been no comments on this draft on the list since this Informal Last Call was announced, therefore I declare the Informal Last Call to be closed. Some minor editorial problems have been found - after these are corrected the resulting -05 draft will be forwarded to the Area Directors for consideration by the IESG for publication as an Informational RFC. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 3 16:47:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19283 for ; Tue, 3 Jul 2001 16:47:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f63J6Gq00542 for ips-outgoing; Tue, 3 Jul 2001 15:06:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f63J6Dg00532 for ; Tue, 3 Jul 2001 15:06:13 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA08736; Tue, 3 Jul 2001 15:06:00 -0400 (EDT) Date: Tue, 3 Jul 2001 15:06:00 -0400 From: "Robert D. Russell" To: julian_satran@il.ibm.com cc: ips@ece.cmu.edu Subject: iSCSI version number In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: The 06-91 draft section 2.10.4 on page 57 lists the version number of the current draft as 0x2, whereas previously it was always 0x1. Shouldn't it still be 0x1?? After all, there has been no approved version 0x1, and the 06-91 draft is only a small incremental improvement over the 06 draft, not a major revision. Changing to version 0x2 implies a consensus on what 0x1 was, and there is none (was it the 06 draft, the 06 draft updated by some (all) of the mailing list e-mails that followed, or what?) What exactly would it mean to support version 0x1 when the current (still under revision draft) is 0x2 and there is no consensus on what version 0x1 was? And what criteria will you use to decide when a version number changes and when it doesn't? I believe these drafts should remain version 0x1 until the "final" draft in this sequence is approved by IETF. Otherwise, you will end up will a bunch of meaningless version numbers that will be impossible to track. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Tue Jul 3 18:25:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12473 for ; Tue, 3 Jul 2001 18:25:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f63KtAe07598 for ips-outgoing; Tue, 3 Jul 2001 16:55:10 -0400 (EDT) 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 f63Kt9g07593 for ; Tue, 3 Jul 2001 16:55:09 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 16:53:49 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070998@corpmx14.us.dg.com> From: Black_David@emc.com To: tsvwg@ietf.org, ips@ece.cmu.edu Subject: RE: [Tsvwg] Another view of the SCTP error check problem (as rela ted to FCIP) Date: Tue, 3 Jul 2001 16:51:33 -0400 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 To the extent that this thread is about review of the new version of the FCIP spec, it belongs on the IPS list. Thanks, --David > -----Original Message----- > From: Robert Snively [SMTP:rsnively@brocade.com] > Sent: Tuesday, July 03, 2001 4:23 PM > To: 'Douglas Otis'; Robert Snively; Black_David@emc.com; tsvwg@ietf.org > Subject: RE: [Tsvwg] Another view of the SCTP error check problem (as > rela ted to FCIP) > > Folks, > > At that meeting, I was requested to demonstrate a > data stream resynchronization algorithm > that met the requirements. I believe that we have done so in 6.6.2.4 > and Annex A of FCIP revision 3. There are hundreds of variations that > can be applied to that algorithm with many different properties. > I believe, however, that the principles of this algorithm are > valid and welcome your review. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > > > > -----Original Message----- > > From: Douglas Otis [mailto:dotis@sanlight.net] > > Sent: Tuesday, July 03, 2001 1:04 PM > > To: Robert Snively; Black_David@emc.com; tsvwg@ietf.org > > Subject: RE: [Tsvwg] Another view of the SCTP error check problem (as > > related to FCIP) > > > > > > Bob, > > > > David has already responded to this framing recovery issue > > back in March on > > the IPS reflector and I see little that has changed in Annex > > A to ensure > > there is not this problem. > > > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03736.html > > > > Doug > > > > > > From owner-ips@ece.cmu.edu Tue Jul 3 18:27:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13642 for ; Tue, 3 Jul 2001 18:27:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f63LGfm09062 for ips-outgoing; Tue, 3 Jul 2001 17:16:41 -0400 (EDT) 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 f63LGeg09058 for ; Tue, 3 Jul 2001 17:16:40 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 17:15:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E07099A@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Security: Environment and Requirements Date: Tue, 3 Jul 2001 17:13:05 -0400 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 part of some work to get some more concrete proposals for some of the open portions of iSCSI security (results will hopefully be visible soon), I generated the following working note. It'll probably go into an Internet Draft next week, but I can't be sure I'll get that done far enough ahead of the deadline for review and comment. Hence, I'm putting this up now for discussion with the intent of putting an improved version into the draft. Comment away. Thanks, --David iSCSI and Security: Environment and Requirements Drafty draft - working note -- David L. Black, July 2001 -- Conventions and Caveat Capitalized words are to be read according to RFC 2119. All descriptions of current status or the like are to the best of my (WG co-chair) understanding, and are accordingly subject to change. -- iSCSI overview iSCSI is an TCP/IP encapsulation of the SCSI protocols used to access disk, tape and other devices. iSCSI is a client-server protocol in which clients (Initiators) open connections to servers (Targets). We use the SCSI terms Initiators and Targets for clarity and to avoid the common intuition that clients have considerably less computational and memory resources than servers; the reverse is often the case for SCSI, as Targets are usually dedicated devices of some form. iSCSI Initiators and Targets are layer 5 entities that are independent of TCP ports and IP addresses. An Initiator or Target may use multiple communication endpoints ( pair), and such endpoints may be shared by multiple Initiators or Targets, although the common case for sharing will be that the sharing entities are all of the same type (i.e., all Initiators or all Targets). The iSCSI protocol has a text based negotiation mechanism as part of its initial (Login) procedure. The mechanism is extensible both in what can be negotiated (new text keys and values can be defined) and in the number of negotiation rounds to accommodate functionality such as authentication based on responding to a challenge. -- Security functionality requirements o Authentication Bi-directional authentication (Initiator to Target) and vice-versa is REQUIRED. This authentication is logically of the iSCSI Initiator to the iSCSI Target (as opposed to authenticating the communication endpoints). The intention of the iSCSI design is that Initiator and Target should represent the systems (e.g., host and disk array) participating in the communication, as opposed to communication interfaces or endpoints. The current status is that the Secure Remote Password protocol (SRP) as specified in RFC 2945 will be REQUIRED of all implementations based on the text-based multi-round negotiation mechanism defined above. A number of additional authentication protocols have also been specified. Negotiation between Initiator and Target is used to determine which authentication algorithm will be used; the connection closes if either side requires authentication and no mutually acceptable algorithm can be agreed upon. o Data origin authentication (cryptographic communication integrity) Cryptographic integrity of all iSCSI communications after the login phase is REQUIRED, and this integrity mechanism must be keyed to an authentication to provide data origin authentication for all received data (e.g., this prevents a TCP hijack attack from succeeding because the hijacker does not know the key required to generate the correct cryptographic integrity checks). The current status is that ESP with NULL encryption has been chosen as the implementation approach to meet this requirement, but the Authentication Algorithm (MAC, e.g., HMAC-SHA1) has not been selected. o Confidentiality A confidentiality mechanism will be part of the iSCSI specification, but the current status is that any such mechanism will be OPTIONAL to implement and use. The current status is also that ESP has been chosen as the implementation approach, but no preferred ESP transform (i.e., encryption algorithm) has been chosen. My personal expectation is that a single algorithm will be RECOMMENDED or REQUIRED of those implementations that choose to implement encryption. o Negotiation of Security Functionality The current status is that the iSCSI negotiation mechanism described above is expected to be usable to negotiate away security functionality in environments where it is not needed (as determined by local policy). The inband negotiation mechanism has no intrinsic security, as it's done in the clear as far as iSCSI is concerned. If such a negotiation is conducted over an otherwise unsecured connection, man-in-the-middle attacks on this negotiation have to be considered when it is used to negotiate use of security functionality. o Approach to Specification Selecting appropriate subsets of existing security specifications is believed to be acceptable provided that good engineering judgement is used and the result is sound from a security standpoint. An example below is that iSCSI currently intends to use ESP without AH even though both are REQUIRED by the basic IPsec RFCs. Such an approach may also be applicable in areas such as IKE/ISAKMP and algorithm selection (e.g., believe it or not, DES is still REQUIRED). -- Implementation Classes and Resource iSCSI will be implemented on a variety of systems ranging from large servers running general purpose operating systems to embedded host bus adapters (HBAs). Host Bus Adapter is a general term for a SCSI interface to other device(s); it's roughly analogous to the term Network Interface Card (NIC) for a TCP/IP, except that HBAs are expected to have on-board SCSI implementations, whereas most NICs do not implement TCP, UDP, or IP. In general, a host bus adapter is the most constrained implementation environment, although an HBA may draw upon the resources of the system to which it is attached in some cases (e.g., authentication computations required for system setup). More resources tend to be available to implementations for embedded and general purpose operating systems. The following general guidelines indicate the level of resources that authentication, keying, and rekeying functionality can reasonably expect to draw upon: - Low power processors with small word size are generally not used, as power is usually not a constraining factor for these systems (with the possible exception of HBAs, which can draw upon the computational resources of the system into which they are inserted). Computational horsepower should be available to perform a reasonable amount of exponentiation as part of authentication and key derivation for connection setup. The same is true of rekeying, although the ability to avoid exponentiation for rekeying may be desirable (but NOT REQUIRED). - RAM and/or flash resources tend to be constrained in embedded implementations. 8-10 MB of code and data is clearly excessive, 800-1000 KB is larger than desirable, but tolerable if necessary and 80-100 KB should be fine. These numbers are intended as rough order of magnitude guidance, and should not be taken as hard targets or limits (e.g., smaller code sizes are always better). Software implementations in general purpose operating systems may have more leeway, but even in that environment these guidelines are a reasonable approximation. In summary, the primary concern in looking for a "lightweight" authentication and keying mechanism is code size, as the computational horsepower to do exponentiations (e.g., those required by SRP) is generally expected to be available. -- Implementation Scaling There is no dominant iSCSI usage scenario - such scenarios range from a single connection constrained only by media bandwidth to connection fan-out well beyond the current practical limits of Fibre Channel - hundreds of Initiator connections to a single Target or single communication endpoint are quite likely in some cases. SCSI sessions and hence the connections they use tend to be relatively long lived; for disk storage, a host typically opens a SCSI connection on boot and closes it on shutdown. Tape session length tends to be measured in significant fractions of an hour or multiple hours (i.e., rapid fire sharing of the same tape device among different users is unusual), although tape robot control sessions can be short when the robot is being shared. On the other hand, tape will not see a large fan-out as each drive is dedicated to a single user at a single time, and a dozen tape drives is a large tape device; add a few robot sessions to this number to get a total. Given current networking technology, security solutions must work well at 1 Gbit/sec; solutions that scale up to 10 Gbits/sec would be nice to use but are not an absolute requirement as there are issues with a number of technologies at 10 Gbits/sec. -- Implementation Environment Q&A Gathering up a bunch of questions about the Q: Will IPsec generally be present on systems supporting iSCSI due to other traffic requiring IPsec security? A: No, especially on Targets which may have no other important functionality. Q: What are the persistence requirements for security state across power off or loss of TCP connections? A: Essentially none; most SCSI state does not survive power loss or system crash events with a few exceptions like persistent reservations. Security state for open TCP connections need not survive the loss of those connections. Any new connection will have to re-authenticate. Q: What about load-balancing or fail-over middleboxes? A: Discussions of iSCSI-aware middleboxes have usually assumed that such a box serves as an endpoint for the iSCSI sessions on both sides of it. There have not been any major objections voiced in the WG to the fashion in which IPsec can interact with such boxes (e.g., TCP header is encrypted). Q: What about NATs? A: The IP Storage WG charter indicates that the ability to operate across NATs is important, but not an absolute requirement. Work is underway in the ipsec WG to specify transparent operation across NATs via UDP encapsulation. --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 4 03:00:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00906 for ; Wed, 4 Jul 2001 03:00:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6458vb04836 for ips-outgoing; Wed, 4 Jul 2001 01:08:57 -0400 (EDT) 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 f6458ug04832 for ; Wed, 4 Jul 2001 01:08:56 -0400 (EDT) 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 HAA17878 for ; Wed, 4 Jul 2001 07:08:49 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6458jf128418 for ; Wed, 4 Jul 2001 07:08:49 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7F.001C0A30 ; Wed, 4 Jul 2001 07:06:16 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 4 Jul 2001 08:13:15 +0300 Subject: Re: iSCSI version number Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, You have a good point - and for this reason I intended to keep the version number to 01 up to the RFC date. But several folks on the list tought that we are too far from 01 (one even suggested that we number according to the draft number). I would like to hear some more voices. Julo "Robert D. Russell" on 03-07-2001 22:06:00 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI version number Julian: The 06-91 draft section 2.10.4 on page 57 lists the version number of the current draft as 0x2, whereas previously it was always 0x1. Shouldn't it still be 0x1?? After all, there has been no approved version 0x1, and the 06-91 draft is only a small incremental improvement over the 06 draft, not a major revision. Changing to version 0x2 implies a consensus on what 0x1 was, and there is none (was it the 06 draft, the 06 draft updated by some (all) of the mailing list e-mails that followed, or what?) What exactly would it mean to support version 0x1 when the current (still under revision draft) is 0x2 and there is no consensus on what version 0x1 was? And what criteria will you use to decide when a version number changes and when it doesn't? I believe these drafts should remain version 0x1 until the "final" draft in this sequence is approved by IETF. Otherwise, you will end up will a bunch of meaningless version numbers that will be impossible to track. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Wed Jul 4 10:58:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07766 for ; Wed, 4 Jul 2001 10:58:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f64Crrk09344 for ips-outgoing; Wed, 4 Jul 2001 08:53:53 -0400 (EDT) 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 f649f7g29929 for ; Wed, 4 Jul 2001 05:41:07 -0400 (EDT) Received: from eddylaptop (h00045a099bc5.ne.mediaone.net [66.31.72.75]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f649f2603036; Wed, 4 Jul 2001 05:41:02 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iqn added to names Date: Wed, 4 Jul 2001 05:41:09 -0400 Message-ID: <005d01c1046d$76660b70$4b481f42@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01C1044B.EF546B70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_005E_01C1044B.EF546B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I noticed in 06-92 that iqn was added to each iSCSI name in the examples but I can't find an explanation for what iqn means. Can someone explain that? Eddy@Quicksall.com ------=_NextPart_000_005E_01C1044B.EF546B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I = noticed in 06-92=20 that iqn was added to each iSCSI name in the examples but I can't find = an=20 explanation for what iqn means. Can someone explain = that?
 
Eddy@Quicksall.com
 
------=_NextPart_000_005E_01C1044B.EF546B70-- From owner-ips@ece.cmu.edu Wed Jul 4 12:12:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08704 for ; Wed, 4 Jul 2001 12:12:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f64EU0t14320 for ips-outgoing; Wed, 4 Jul 2001 10:30:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from [192.168.90.11] (mail.ams.de [195.30.77.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f64EPhg14134 for ; Wed, 4 Jul 2001 10:25:44 -0400 (EDT) Received: from excadva.advaoptical.de (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 4 Jul 2001 16:24:41 +0200 Received: by excadva.advaoptical.de with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 16:25:10 +0200 Message-ID: <79CB6B56B942D411A9AB001083FCE91E10B5B7@san-exchange.dino> From: John Vrabel To: ips@ece.cmu.edu Subject: iSCSI: Data in Response PDUs Date: Wed, 4 Jul 2001 16:25:35 +0200 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 thread last August http://www.pdl.cmu.edu/mailinglists/ips/mail/msg00590.html suggested that Read Data should not be sent attached to a Status PDU, and indeed the current draft does not explicitly say you can do this. However several implementations to version-03 do just that. The current draft is unclear to me - must all Read Data be sent as a/several Data-In PDU(s), or can it also be sent as part of a Status PDU. ( This question is entirely separate from Immediate Write Data, or S bit in Data-In ) John Vrabel From owner-ips@ece.cmu.edu Wed Jul 4 12:58:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09391 for ; Wed, 4 Jul 2001 12:58:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f64FxZp19175 for ips-outgoing; Wed, 4 Jul 2001 11:59:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14401.mail.yahoo.com (web14401.mail.yahoo.com [216.136.174.58]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f64FxXg19171 for ; Wed, 4 Jul 2001 11:59:33 -0400 (EDT) Message-ID: <20010704155932.62266.qmail@web14401.mail.yahoo.com> Received: from [202.56.250.52] by web14401.mail.yahoo.com; Wed, 04 Jul 2001 08:59:32 PDT Date: Wed, 4 Jul 2001 08:59:32 -0700 (PDT) From: Rishabh Srivastav Subject: iSCSI: Indication of final data-out sequence To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk A doubt regarding the final sequence of data-out PDUs : My apologies if this had already been discussed long time ago. Couldn't locate it in the huge mail repository. In FC, the last sequence of an exchange is indicated by a 'Last_Sequence' bit in F_CTL of FC-FS header. What is the equivalent of it in iSCSI, specifically in the case of Data-Out ? If there is none, will not the presence of a similar bit be useful for iSCSI-FCP gateways ? Thanks, Rishabh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Wed Jul 4 13:02:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09473 for ; Wed, 4 Jul 2001 13:02:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f64FOeD17344 for ips-outgoing; Wed, 4 Jul 2001 11:24:40 -0400 (EDT) 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 f64FOdg17340 for ; Wed, 4 Jul 2001 11:24:39 -0400 (EDT) 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 RAA79246 for ; Wed, 4 Jul 2001 17:24:31 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f64FOWf59346 for ; Wed, 4 Jul 2001 17:24:32 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A7F.005468D4 ; Wed, 4 Jul 2001 17:21:58 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Wed, 4 Jul 2001 18:30:21 +0300 Subject: Re: iSCSI: Data in Response PDUs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Status can accompany the last Data-in PDU. Presence of (good) status is signaled through the S flag. Julo John Vrabel on 04-07-2001 17:25:35 Please respond to John Vrabel To: ips@ece.cmu.edu cc: Subject: iSCSI: Data in Response PDUs A thread last August http://www.pdl.cmu.edu/mailinglists/ips/mail/msg00590.html suggested that Read Data should not be sent attached to a Status PDU, and indeed the current draft does not explicitly say you can do this. However several implementations to version-03 do just that. The current draft is unclear to me - must all Read Data be sent as a/several Data-In PDU(s), or can it also be sent as part of a Status PDU. ( This question is entirely separate from Immediate Write Data, or S bit in Data-In ) John Vrabel From owner-ips@ece.cmu.edu Wed Jul 4 17:40:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11863 for ; Wed, 4 Jul 2001 17:40:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f64JqJj01713 for ips-outgoing; Wed, 4 Jul 2001 15:52:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe42.law11.hotmail.com [64.4.16.100]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f64JqHg01708 for ; Wed, 4 Jul 2001 15:52:17 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jul 2001 12:52:11 -0700 X-Originating-IP: [66.31.72.75] From: "Eddy Quicksall" To: , Cc: References: Subject: Re: iSCSI version number Date: Wed, 4 Jul 2001 15:52:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 04 Jul 2001 19:52:11.0385 (UTC) FILETIME=[D0A6E690:01C104C2] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have mixed emotions ... I agree with Bob in principal. But, I figured the reason you changed it was actually to distinguish from rev 0 ... as I understand it, Intel has already released code that conforms to rev 0 (but Intel should respond to this). If we don't increase the version, how do we protect ourselves from running into one of the Intel controllers? Eddy ----- Original Message ----- From: To: Sent: Wednesday, July 04, 2001 1:13 AM Subject: Re: iSCSI version number > > > Robert, > > You have a good point - and for this reason I intended to keep the version > number to 01 up to the RFC date. > But several folks on the list tought that we are too far from 01 (one even > suggested that we number according to the draft number). > > I would like to hear some more voices. > > Julo > > "Robert D. Russell" on 03-07-2001 22:06:00 > > Please respond to "Robert D. Russell" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI version number > > > > > Julian: > > The 06-91 draft section 2.10.4 on page 57 lists the version number > of the current draft as 0x2, whereas previously it was always 0x1. > Shouldn't it still be 0x1?? After all, there has been no > approved version 0x1, and the 06-91 draft is only a small > incremental improvement over the 06 draft, not a major revision. > Changing to version 0x2 implies a consensus on what 0x1 was, > and there is none (was it the 06 draft, the 06 draft updated > by some (all) of the mailing list e-mails that followed, or what?) > What exactly would it mean to support version 0x1 when the current > (still under revision draft) is 0x2 and there is no consensus on > what version 0x1 was? And what criteria will you use to decide > when a version number changes and when it doesn't? > > I believe these drafts should remain version 0x1 until the "final" > draft in this sequence is approved by IETF. Otherwise, you will > end up will a bunch of meaningless version numbers that will > be impossible to track. > > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > > > > From owner-ips@ece.cmu.edu Thu Jul 5 03:43:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04637 for ; Thu, 5 Jul 2001 03:43:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f655euX00778 for ips-outgoing; Thu, 5 Jul 2001 01:40:56 -0400 (EDT) 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 f655etg00774 for ; Thu, 5 Jul 2001 01:40:55 -0400 (EDT) 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 HAA148736 for ; Thu, 5 Jul 2001 07:40:48 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f655eih131800 for ; Thu, 5 Jul 2001 07:40:48 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A80.001EF66A ; Thu, 5 Jul 2001 07:38:11 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 5 Jul 2001 08:46:41 +0300 Subject: Re: iSCSI: Indication of final data-out sequence Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk the F bit. Julo Rishabh Srivastav on 04-07-2001 18:59:32 Please respond to Rishabh Srivastav To: ips@ece.cmu.edu cc: Subject: iSCSI: Indication of final data-out sequence A doubt regarding the final sequence of data-out PDUs : My apologies if this had already been discussed long time ago. Couldn't locate it in the huge mail repository. In FC, the last sequence of an exchange is indicated by a 'Last_Sequence' bit in F_CTL of FC-FS header. What is the equivalent of it in iSCSI, specifically in the case of Data-Out ? If there is none, will not the presence of a similar bit be useful for iSCSI-FCP gateways ? Thanks, Rishabh __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Thu Jul 5 04:42:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05091 for ; Thu, 5 Jul 2001 04:42:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f656ejk03796 for ips-outgoing; Thu, 5 Jul 2001 02:40:45 -0400 (EDT) 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 f656eig03792 for ; Thu, 5 Jul 2001 02:40:44 -0400 (EDT) Received: from ahganemw2k (sjc-vpn-tmp29.cisco.com [10.21.64.29]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id CAA03421 for ; Thu, 5 Jul 2001 02:40:35 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI version number Date: Thu, 5 Jul 2001 01:39:33 -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.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: 7bit I am not sure that increasing the version number in draft-07 will provide this protection. I believe drafts 3 through 6 had the same version number (0x01) but they don't interoperate. On the other hand, drafts 6 and 7 will have different version numbers and they very much interoperate. I prefer keeping the version number at 0x01 until the final draft. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Eddy Quicksall > Sent: Wednesday, July 04, 2001 2:52 PM > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > Cc: Tri.G[tri.g.nguyen@intel.com] > Subject: Re: iSCSI version number > > > I have mixed emotions ... I agree with Bob in principal. > > But, I figured the reason you changed it was actually to distinguish from > rev 0 ... as I understand it, Intel has already released code > that conforms > to rev 0 (but Intel should respond to this). > > If we don't increase the version, how do we protect ourselves from running > into one of the Intel controllers? > > Eddy > > ----- Original Message ----- > From: > To: > Sent: Wednesday, July 04, 2001 1:13 AM > Subject: Re: iSCSI version number > > > > > > > > Robert, > > > > You have a good point - and for this reason I intended to keep the > version > > number to 01 up to the RFC date. > > But several folks on the list tought that we are too far from > 01 (one even > > suggested that we number according to the draft number). > > > > I would like to hear some more voices. > > > > Julo > > > > "Robert D. Russell" on 03-07-2001 22:06:00 > > > > Please respond to "Robert D. Russell" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI version number > > > > > > > > > > Julian: > > > > The 06-91 draft section 2.10.4 on page 57 lists the version number > > of the current draft as 0x2, whereas previously it was always 0x1. > > Shouldn't it still be 0x1?? After all, there has been no > > approved version 0x1, and the 06-91 draft is only a small > > incremental improvement over the 06 draft, not a major revision. > > Changing to version 0x2 implies a consensus on what 0x1 was, > > and there is none (was it the 06 draft, the 06 draft updated > > by some (all) of the mailing list e-mails that followed, or what?) > > What exactly would it mean to support version 0x1 when the current > > (still under revision draft) is 0x2 and there is no consensus on > > what version 0x1 was? And what criteria will you use to decide > > when a version number changes and when it doesn't? > > > > I believe these drafts should remain version 0x1 until the "final" > > draft in this sequence is approved by IETF. Otherwise, you will > > end up will a bunch of meaningless version numbers that will > > be impossible to track. > > > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 5 06:57:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06814 for ; Thu, 5 Jul 2001 06:57:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f659InN11115 for ips-outgoing; Thu, 5 Jul 2001 05:18:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14408.mail.yahoo.com (web14408.mail.yahoo.com [216.136.174.78]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f659Img11111 for ; Thu, 5 Jul 2001 05:18:48 -0400 (EDT) Message-ID: <20010705091847.35050.qmail@web14408.mail.yahoo.com> Received: from [202.56.250.52] by web14408.mail.yahoo.com; Thu, 05 Jul 2001 02:18:47 PDT Date: Thu, 5 Jul 2001 02:18:47 -0700 (PDT) From: Rishabh Srivastav Subject: Re: iSCSI: Indication of final data-out sequence To: julian_satran@il.ibm.com, 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 Julo, I'm still not convinced. There can be multiple data-out PDU's in response to one R2T. In this case the F bit indicates the end of sequence corresponding to that particular R2T and not for the whole write operation. However, the last_sequence bit in FC-FS is something which indicates the final data IU for that whole exchange. So, how can 'F' bit be equated to the last_sequence bit ?? The semantics of 'F' bit is same as last_sequence bit in the case of Data-In PDUs and not in the case of data-out PDU. Where am i going wrong in my assumptions ? Please clarify. Thanks, Rishabh --- julian_satran@il.ibm.com wrote: > > > the F bit. Julo > > A doubt regarding the final sequence of data-out > PDUs > : My apologies if this had already been discussed > long > time ago. Couldn't locate it in the huge mail > repository. > In FC, the last sequence of an exchange is indicated > by a 'Last_Sequence' bit in F_CTL of FC-FS header. > What is the equivalent of it in iSCSI, specifically > in > the case of Data-Out ? If there is none, will not > the > presence of a similar bit be useful for iSCSI-FCP > gateways ? > > Thanks, > Rishabh > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Thu Jul 5 08:59:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10708 for ; Thu, 5 Jul 2001 08:59:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65B2l526611 for ips-outgoing; Thu, 5 Jul 2001 07:02:47 -0400 (EDT) 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 f65B2jg26607 for ; Thu, 5 Jul 2001 07:02:45 -0400 (EDT) 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 NAA180822 for ; Thu, 5 Jul 2001 13:02:38 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f65B2ch123152 for ; Thu, 5 Jul 2001 13:02:39 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A80.003C6E04 ; Thu, 5 Jul 2001 13:00:03 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: ips@ece.cmu.edu Message-ID: Date: Thu, 5 Jul 2001 14:08:27 +0300 Subject: Re: iSCSI: Indication of final data-out sequence Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk There is no need for an additional bit. Every outstanding R2T has a target task tag (and a number...) The target has to keep track of what he got and send the status after the last R2T sequence. Thee is also an ordering delivery requirement but that is weaker. Julo Rishabh Srivastav on 05-07-2001 12:18:47 Please respond to Rishabh Srivastav To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: Re: iSCSI: Indication of final data-out sequence Julo, I'm still not convinced. There can be multiple data-out PDU's in response to one R2T. In this case the F bit indicates the end of sequence corresponding to that particular R2T and not for the whole write operation. However, the last_sequence bit in FC-FS is something which indicates the final data IU for that whole exchange. So, how can 'F' bit be equated to the last_sequence bit ?? The semantics of 'F' bit is same as last_sequence bit in the case of Data-In PDUs and not in the case of data-out PDU. Where am i going wrong in my assumptions ? Please clarify. Thanks, Rishabh --- julian_satran@il.ibm.com wrote: > > > the F bit. Julo > > A doubt regarding the final sequence of data-out > PDUs > : My apologies if this had already been discussed > long > time ago. Couldn't locate it in the huge mail > repository. > In FC, the last sequence of an exchange is indicated > by a 'Last_Sequence' bit in F_CTL of FC-FS header. > What is the equivalent of it in iSCSI, specifically > in > the case of Data-Out ? If there is none, will not > the > presence of a similar bit be useful for iSCSI-FCP > gateways ? > > Thanks, > Rishabh > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Thu Jul 5 08:59:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10737 for ; Thu, 5 Jul 2001 08:59:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65Ax8S26395 for ips-outgoing; Thu, 5 Jul 2001 06:59:08 -0400 (EDT) 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 f65Ax7g26391 for ; Thu, 5 Jul 2001 06:59:07 -0400 (EDT) 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 MAA09426; Thu, 5 Jul 2001 12:58:59 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f65Awuh215434; Thu, 5 Jul 2001 12:58:56 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A80.003C16DB ; Thu, 5 Jul 2001 12:56:20 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: John Vrabel cc: ips@ece.cmu.edu Message-ID: Date: Thu, 5 Jul 2001 14:00:08 +0300 Subject: Re: iSCSI: Data in Response PDUs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk That is absolutely correct. No data besides response/sense are supposed to arrive in the response PDU. Julo John Vrabel on 05-07-2001 10:43:22 Please respond to John Vrabel To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI: Data in Response PDUs I'm sorry I asked the question very badly - I mistakenly said Status PDU instead of Response PDU. Both the Intel version-03 code and the Swat version-03 send Read Data as part of Response PDUs, which I believe is wrong. My understanding is that all Read Data MUST be sent in Data-In PDUs. Only Sense Data can be included in a Response PDU. Is this correct.? John Vrabel From owner-ips@ece.cmu.edu Thu Jul 5 11:18:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16249 for ; Thu, 5 Jul 2001 11:18:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65D9S103040 for ips-outgoing; Thu, 5 Jul 2001 09:09:28 -0400 (EDT) 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 f65D9Rg03035 for ; Thu, 5 Jul 2001 09:09:27 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 09:08:05 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709A5@corpmx14.us.dg.com> From: Black_David@emc.com To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Security: Environment and Requirements Date: Thu, 5 Jul 2001 09:05:48 -0400 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 CC'ing the list with an answer to an off-line question as I believe the answer is of general interest. > Is built-in IPsec support a requirement for iSCSI initiators and > targets or can initiators/targets rely on external IPsec gateways. > Also, what type of IPsec support (tunnel or transport mode, > AH/ESP) is envisioned? As of right now, external gateways can be used, BUT the result would be that only the interface on the secure side of the gateway would be considered compliant to the iSCSI spec (i.e., the interface between the iSCSI device and the gateway would NOT be compliant). I would offer the caution that some of the possible solutions to the rekeying situation may result in tighter binding between iSCSI and IPsec that would favor built-in IPsec support and/or require modifications to external gateways. I believe the anticipated IPsec requirement is ESP in tunnel mode, but this is also subject to change (e.g., will almost certainly be discussed further in London). 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 5 12:35:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18861 for ; Thu, 5 Jul 2001 12:35:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65EXUY08596 for ips-outgoing; Thu, 5 Jul 2001 10:33:30 -0400 (EDT) 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 f65EXSg08592 for ; Thu, 5 Jul 2001 10:33:29 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA29732; Thu, 5 Jul 2001 10:33:22 -0400 (EDT) Message-ID: <3B44758F.185C06B3@cisco.com> Date: Thu, 05 Jul 2001 09:11:27 -0500 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: Rod Harrison CC: IPS Subject: Re: iSCSI: Iterating long text responses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod- You are correct that this assumes that the initiator can do the same text command multiple times. I think that the real question is whether attempting to allow non-idempotent text commands, and providing easier mechanisms for doing them is a requirement. If so, your addition to #3 would work. If not, it would place unnecessary burden on the target. At the moment, I can't think of much that would need to be added to iSCSI from a (non-negotiation) text command point of view. In fact, we are supposed to be careful to limit what can be done in this way, since most other functionality we can envision should be left to other standard protocols. Any thoughts on specific uses for non-idempotent text commands? -- Mark Some more comments: Rod Harrison wrote: > > We have a concern over option #5, the outline below assumes > that it is safe to issue the same text command more than > once with no side effects. This does seem safe for the > current use of SendTargets, however it might not be if this > mechanism is extended for other long response text commands. True; SendTargets doesn't care. However, we seem to have a general consensus that the use of text commands should be carefully limited; what are the real chances that some functionality comes along that we really need, and that does not fit in? I don't see that really happening. > Our preference would be for option #3 with #4 a close > second. Number 4 has the disadvantage that the initiator has > to deal with a stream of unsolicited text responses with no > idea of when they might stop. Actually, an initiator can do the same thing with #4 as with #5; it could issue the text command, and just keep track of the number of bytes of response that it was unable to keep. It could then allocate enough space, and re-do the request. #5 is just a cleaner mechanism to do this. At any rate, the burden is on the initiator as to whether it wants to make use of these mechanisms. > Perhaps #3 with the following modifications might suffice. > > Add an offset to the initiator R2T (iR2T?) allowing the > target to choose to either buffer the whole response or > regenerate it on the fly. The target should know whether the > data can be regenerated safely and so can make this > decision. > > Add a final bit to the iR2T allowing the initiator to stop > the response transfer at any time. Mandate that the > initiator must either receive all the data or send an iR2T > with final bit set to indicate no more data is required. > This prevents a target getting stuck with the response data > in a buffer forever. > > A typical transfer might be. > > I->T Text command (F bit set) > T->I Text response (F bit clear) > I->T iR2T incl. valid offset and length (F bit clear) > T->I Text response (F bit clear) > > .... > > Sequence either ends with > > T->I Text response (F bit set) > > or > > I->T iR2T Offset 0, length 0, (F bit set) > > Since the first text response is unsolicited all current > text command implementations can remain unchanged. Only if > the target responds with the F bit clear does the initiator > need to change. > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Mark Bakke > Sent: Friday, June 29, 2001 9:18 PM > To: IPS > Subject: iSCSI: Iterating long text responses > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as > SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two > solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" > connection > or are handled completely in software, and allow its > response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. > It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for > any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that > needed > a large response to implement an iterator. It also means > that > each part of the response from the iterator would have to > fit > in the 4k PDU. > > The remainder of these require that only one text command > sequence > be outstanding on a connection at a given time. They use > the F > bit to indicate the last PDU of the sequence. Note that > connection > allegiance is assumed for the entire sequence, and text > commands > are never retried on another connection; a new command is > issued > instead. > > 3. Do a text-response R2T, where the initiator controls when > the > next partial response is sent. This would be more > generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want > more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep > track > of the state of its responses; if the initiator just > stops asking, > it may have to keep a buffered response around until it > times out, > the connection is dropped, or another text command comes > along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The > initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if > it > can't handle them. This solution is a lot like #1, but > with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the > problem > of the target keeping state; it sends ALL of the response > PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of > data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, > TotalResponseLength=12288) > > In the above example, we have created a new text command > field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k > response. > The target returned the first 4k in the text response, > but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than > the > AcceptResponseLength, the initiator knows the amount of > buffer > space it will need to get the full response. It can then > choose > whether it will re-send the command, and if so, can give > it a > large enough response length: > > I->T Text Command (F bit set, > AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, > TotalResponseLength=12288) > > Note that most initiators will probably send an > AcceptResponseLength > of the largest response they would normally accept, and > that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target > has the > benefit of being less statefull, and the initiator has > the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 > is > probably the safest solution, but #4 may not be a problem > for anyone. > > Assuming that none of the implementors of initiators have a > problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 5 13:36:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21063 for ; Thu, 5 Jul 2001 13:36:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65FYD412956 for ips-outgoing; Thu, 5 Jul 2001 11:34:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f65FYBg12952 for ; Thu, 5 Jul 2001 11:34:11 -0400 (EDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 096552C7; Thu, 5 Jul 2001 08:33:53 -0700 (PDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id BE1E01EC for ; Thu, 5 Jul 2001 08:33:52 -0700 (PDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Thu, 5 Jul 2001 10:34:04 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C659C25F@cceexc17.americas.cpqcorp.net> From: "Elliott, Robert" To: ips@ece.cmu.edu Subject: RE: iSCSI version number Date: Thu, 5 Jul 2001 10:34:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The UNH plugfest is testing implementations based version 0 or version 6. These are conveniently differentiated by using version code 0x00 for version 0 and 0x01 for version 6. Implementations based on versions 1-5 are discouraged by the plugfest choice. Since there will exist numerous version 6 implementations, I think it's advantageous for the iSCSI version number to increment from this point forward to differentiate them from newer implementations. Unfortunately, UNH created a bit of a mess by asking that version 7 opcode encoding be used with the version 6 implementations without incrementing the version number. I expect that to create some confusion (easily solved by a recompile, I hope). --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Thursday, July 05, 2001 1:40 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI version number > > > I am not sure that increasing the version number in draft-07 > will provide > this protection. I believe drafts 3 through 6 had the same > version number > (0x01) but they don't interoperate. On the other hand, drafts > 6 and 7 will > have different version numbers and they very much > interoperate. I prefer > keeping the version number at 0x01 until the final draft. > > -Ayman > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Eddy Quicksall > > Sent: Wednesday, July 04, 2001 2:52 PM > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > > Cc: Tri.G[tri.g.nguyen@intel.com] > > Subject: Re: iSCSI version number > > > > > > I have mixed emotions ... I agree with Bob in principal. > > > > But, I figured the reason you changed it was actually to > distinguish from > > rev 0 ... as I understand it, Intel has already released code > > that conforms > > to rev 0 (but Intel should respond to this). > > > > If we don't increase the version, how do we protect > ourselves from running > > into one of the Intel controllers? > > > > Eddy > > > > ----- Original Message ----- > > From: > > To: > > Sent: Wednesday, July 04, 2001 1:13 AM > > Subject: Re: iSCSI version number > > > > > > > > > > > > > Robert, > > > > > > You have a good point - and for this reason I intended > to keep the > > version > > > number to 01 up to the RFC date. > > > But several folks on the list tought that we are too far from > > 01 (one even > > > suggested that we number according to the draft number). > > > > > > I would like to hear some more voices. > > > > > > Julo > > > > > > "Robert D. Russell" on 03-07-2001 22:06:00 > > > > > > Please respond to "Robert D. Russell" > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: iSCSI version number > > > > > > > > > > > > > > > Julian: > > > > > > The 06-91 draft section 2.10.4 on page 57 lists the version number > > > of the current draft as 0x2, whereas previously it was always 0x1. > > > Shouldn't it still be 0x1?? After all, there has been no > > > approved version 0x1, and the 06-91 draft is only a small > > > incremental improvement over the 06 draft, not a major revision. > > > Changing to version 0x2 implies a consensus on what 0x1 was, > > > and there is none (was it the 06 draft, the 06 draft updated > > > by some (all) of the mailing list e-mails that followed, or what?) > > > What exactly would it mean to support version 0x1 when the current > > > (still under revision draft) is 0x2 and there is no consensus on > > > what version 0x1 was? And what criteria will you use to decide > > > when a version number changes and when it doesn't? > > > > > > I believe these drafts should remain version 0x1 until the "final" > > > draft in this sequence is approved by IETF. Otherwise, you will > > > end up will a bunch of meaningless version numbers that will > > > be impossible to track. > > > > > > > > > Bob Russell > > > InterOperability Lab > > > University of New Hampshire > > > rdr@iol.unh.edu > > > 603-862-3774 > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 5 15:37:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24838 for ; Thu, 5 Jul 2001 15:37:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65Hkt922409 for ips-outgoing; Thu, 5 Jul 2001 13:46:55 -0400 (EDT) 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 f65Hksg22404 for ; Thu, 5 Jul 2001 13:46:54 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA22911; Thu, 5 Jul 2001 13:46:41 -0400 (EDT) Message-ID: <3B44A6E0.B9E2D33C@cisco.com> Date: Thu, 05 Jul 2001 12:41:52 -0500 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: Eddy Quicksall CC: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iqn added to names References: <005d01c1046d$76660b70$4b481f42@eddylaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy- "iqn" stands for "iSCSI qualified name". It is used to prefix names that are generated using the naming authority's assigned domain name. It replaces the old acronym "fqn", which stood for "fully qualified name". For more information, please take a look at the naming & discovery draft, available at http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-name-disc-01.txt This draft will be updated shortly to include the new term "iqn". -- Mark > Eddy Quicksall wrote: > > I noticed in 06-92 that iqn was added to each iSCSI name in the examples but I can't find an > explanation for what iqn means. Can someone explain that? > > Eddy@Quicksall.com > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 5 17:00:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27397 for ; Thu, 5 Jul 2001 17:00:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65JZUw00299 for ips-outgoing; Thu, 5 Jul 2001 15:35:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f65JZSg00294 for ; Thu, 5 Jul 2001 15:35:28 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA18610; Thu, 5 Jul 2001 12:34:39 -0700 (PDT) From: "Rod Harrison" To: Cc: "IPS" Subject: RE: iSCSI: Iterating long text responses Date: Thu, 5 Jul 2001 20:36:10 +0100 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: <3B44758F.185C06B3@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, It was more of a general concern for the iterative process than thoughts of a specific non-idempotent text command. If text commands are ever used in an IOCTL like capacity we might run into problems, but as you say there are probably better ways to do that sort of thing, like Mode Select. I would still prefer to have the initiator able to pace the receipt of, and prematurely end, large text responses but I understand this may be too expensive for some targets. Requiring the initiator to allocate an arbitrarily large buffer for #5 is a little concerning, especially since it seems that could be larger than the negotiated max PDU size. For that reason I would prefer option #4 over #5, but I think we'll need to add a sequence number to the text response to allow the initiator to detect out of order PDUs. - Rod -----Original Message----- From: mbakke@cisco.com [mailto:mbakke@cisco.com] Sent: Thursday, July 05, 2001 3:11 PM To: Rod Harrison Cc: IPS Subject: Re: iSCSI: Iterating long text responses Rod- You are correct that this assumes that the initiator can do the same text command multiple times. I think that the real question is whether attempting to allow non-idempotent text commands, and providing easier mechanisms for doing them is a requirement. If so, your addition to #3 would work. If not, it would place unnecessary burden on the target. At the moment, I can't think of much that would need to be added to iSCSI from a (non-negotiation) text command point of view. In fact, we are supposed to be careful to limit what can be done in this way, since most other functionality we can envision should be left to other standard protocols. Any thoughts on specific uses for non-idempotent text commands? -- Mark Some more comments: Rod Harrison wrote: > > We have a concern over option #5, the outline below assumes > that it is safe to issue the same text command more than > once with no side effects. This does seem safe for the > current use of SendTargets, however it might not be if this > mechanism is extended for other long response text commands. True; SendTargets doesn't care. However, we seem to have a general consensus that the use of text commands should be carefully limited; what are the real chances that some functionality comes along that we really need, and that does not fit in? I don't see that really happening. > Our preference would be for option #3 with #4 a close > second. Number 4 has the disadvantage that the initiator has > to deal with a stream of unsolicited text responses with no > idea of when they might stop. Actually, an initiator can do the same thing with #4 as with #5; it could issue the text command, and just keep track of the number of bytes of response that it was unable to keep. It could then allocate enough space, and re-do the request. #5 is just a cleaner mechanism to do this. At any rate, the burden is on the initiator as to whether it wants to make use of these mechanisms. > Perhaps #3 with the following modifications might suffice. > > Add an offset to the initiator R2T (iR2T?) allowing the > target to choose to either buffer the whole response or > regenerate it on the fly. The target should know whether the > data can be regenerated safely and so can make this > decision. > > Add a final bit to the iR2T allowing the initiator to stop > the response transfer at any time. Mandate that the > initiator must either receive all the data or send an iR2T > with final bit set to indicate no more data is required. > This prevents a target getting stuck with the response data > in a buffer forever. > > A typical transfer might be. > > I->T Text command (F bit set) > T->I Text response (F bit clear) > I->T iR2T incl. valid offset and length (F bit clear) > T->I Text response (F bit clear) > > .... > > Sequence either ends with > > T->I Text response (F bit set) > > or > > I->T iR2T Offset 0, length 0, (F bit set) > > Since the first text response is unsolicited all current > text command implementations can remain unchanged. Only if > the target responds with the F bit clear does the initiator > need to change. > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Mark Bakke > Sent: Friday, June 29, 2001 9:18 PM > To: IPS > Subject: iSCSI: Iterating long text responses > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as > SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two > solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" > connection > or are handled completely in software, and allow its > response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. > It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for > any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that > needed > a large response to implement an iterator. It also means > that > each part of the response from the iterator would have to > fit > in the 4k PDU. > > The remainder of these require that only one text command > sequence > be outstanding on a connection at a given time. They use > the F > bit to indicate the last PDU of the sequence. Note that > connection > allegiance is assumed for the entire sequence, and text > commands > are never retried on another connection; a new command is > issued > instead. > > 3. Do a text-response R2T, where the initiator controls when > the > next partial response is sent. This would be more > generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want > more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep > track > of the state of its responses; if the initiator just > stops asking, > it may have to keep a buffered response around until it > times out, > the connection is dropped, or another text command comes > along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The > initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if > it > can't handle them. This solution is a lot like #1, but > with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the > problem > of the target keeping state; it sends ALL of the response > PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of > data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, > TotalResponseLength=12288) > > In the above example, we have created a new text command > field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k > response. > The target returned the first 4k in the text response, > but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than > the > AcceptResponseLength, the initiator knows the amount of > buffer > space it will need to get the full response. It can then > choose > whether it will re-send the command, and if so, can give > it a > large enough response length: > > I->T Text Command (F bit set, > AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, > TotalResponseLength=12288) > > Note that most initiators will probably send an > AcceptResponseLength > of the largest response they would normally accept, and > that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target > has the > benefit of being less statefull, and the initiator has > the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 > is > probably the safest solution, but #4 may not be a problem > for anyone. > > Assuming that none of the implementors of initiators have a > problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 5 17:00:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27408 for ; Thu, 5 Jul 2001 17:00:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65Je6E00556 for ips-outgoing; Thu, 5 Jul 2001 15:40:06 -0400 (EDT) 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 f65Je5g00552 for ; Thu, 5 Jul 2001 15:40:05 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA21559; Thu, 5 Jul 2001 15:36:13 -0400 (EDT) Message-ID: <3B44C08C.8F4E4858@cisco.com> Date: Thu, 05 Jul 2001 14:31:24 -0500 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: Santosh Rao CC: ips Subject: Re: iSCSI: Iterating long text responses References: <200107051921.MAA04104@hpcuhe.cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh- I was making the assumption that a text command stayed on a single connection, and response PDUs from the target would be in-order, and that if the connection failed, the target would throw away any results it hadn't yet sent, and the initiator would just completely re-do the command. This meant we wouldn't need an offset, since the initiator would have to receive them in order anyway. However, it certainly wouldn't hurt to add the offset. I guess I am just concerned that if we do, then someone will want to make use of the field to be able to send text responses out of order, or to recover them on another connection, and so on, so I would rather leave them out unless we really need them. How badly are they needed? -- Mark Santosh Rao wrote: > > Mark, > > IMO, alternative #4 is sufficient and is semantically aligned with the > FC-GS-2/GS-3 GID_FT model. > > It does require modification of the Text Response PDU to provide a > Relative Offset (RO) field indicating the RO of the text response > PDU from the start of the text response payload, in order to allow initiators > to correctly re-assemble the received response PDUs. > > Regards, > Santosh > > Mark Bakke wrote: > > > > Initiator developers- > > > > Please respond to the questions at the end. > > > > Thanks, > > > > Mark > > > > The current iSCSI draft allows text command and response > > PDUs of up to 4096 bytes. While we don't see any real > > problems for the command PDU size, commands such as SendTargets > > can easily exceed the response size. > > > > There are several ways we can fix this. The first two solutions > > require no differences in the current iSCSI text command and > > response; the latter three involve the use of the F bit. > > > > 1. Assume that such commands are done on a "special" connection > > or are handled completely in software, and allow its response > > PDU to be as large as it needs to be. > > > > This one appears too restrictive to be a solid solution. It > > will also weaken any data digests done on the longer PDU. > > > > 2. Create an iterative SendTargets key (and do the same for any > > other text commands that need this), that would allow the > > initiator to request the "next target" or "next address". > > > > This would work, but would require any new command that needed > > a large response to implement an iterator. It also means that > > each part of the response from the iterator would have to fit > > in the 4k PDU. > > > > The remainder of these require that only one text command sequence > > be outstanding on a connection at a given time. They use the F > > bit to indicate the last PDU of the sequence. Note that connection > > allegiance is assumed for the entire sequence, and text commands > > are never retried on another connection; a new command is issued > > instead. > > > > 3. Do a text-response R2T, where the initiator controls when the > > next partial response is sent. This would be more generic: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > I->T Text Command (with some indicator that we want more) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > I->T Text Command (with indicator that we want more) > > T->I Text Response (last PDU, F bit set) > > > > The main problem with this is that the target must keep track > > of the state of its responses; if the initiator just stops asking, > > it may have to keep a buffered response around until it times out, > > the connection is dropped, or another text command comes along. > > > > 4. Allow multiple response PDUs to a single text command: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > T->I Text Response (last PDU, F bit set) > > > > Basically, we are doing (3) without the R2T. The initiator, > > upon sending the text command, must be prepared either to > > accept as many PDUs as come back, or throw them away if it > > can't handle them. This solution is a lot like #1, but with > > the response spread across 4k PDUs. > > > > Also note that this (and the following scheme) avoid the problem > > of the target keeping state; it sends ALL of the response PDUs > > without the initiator asking for them. > > > > 5. Do #4, but allow the initiator to specify the amount of data > > it is willing to accept: > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > > > In the above example, we have created a new text command field: > > > > AcceptResponseLength > > > > And in the text response PDU: > > > > TotalResponseLength > > > > The initiator indicated it was willing to accept a 4k response. > > The target returned the first 4k in the text response, but set > > the F bit since it was at its limit. It also returned a > > TotalResponseLength field. Since this was greater than the > > AcceptResponseLength, the initiator knows the amount of buffer > > space it will need to get the full response. It can then choose > > whether it will re-send the command, and if so, can give it a > > large enough response length: > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > T->I Text Response (first PDU, F bit clear) > > T->I Text Response (next PDU, F bit clear) > > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > > > Note that most initiators will probably send an AcceptResponseLength > > of the largest response they would normally accept, and that most > > target responses will fit in one or a few PDUs anyway. > > > > #5 is really a compromise between #3 and #4; the target has the > > benefit of being less statefull, and the initiator has the benefit > > of controlling the amount of data it receives. > > > > I would like to recommend either #4 or #5. I think that #5 is > > probably the safest solution, but #4 may not be a problem for anyone. > > > > Assuming that none of the implementors of initiators have a problem > > with #4, I would pick that. > > > > If they do have a problem with it, we should go with #5. > > > > Targets probably don't care much whether we do #4 or #5. > > > > Initiator developers- > > > > Please indicate which solution (#4 or #5) appeals to you. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > -- > ################################# > Santosh Rao > Software Design Engineer, > HP, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################# -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 5 17:01:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27440 for ; Thu, 5 Jul 2001 17:01:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65JLDi29327 for ips-outgoing; Thu, 5 Jul 2001 15:21:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f65JLBg29323 for ; Thu, 5 Jul 2001 15:21:11 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 167931A44 for ; Thu, 5 Jul 2001 12:21:11 -0700 (PDT) Received: (from santoshr@localhost) by hpcuhe.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id MAA04104; Thu, 5 Jul 2001 12:21:06 -0700 (PDT) From: Santosh Rao Message-Id: <200107051921.MAA04104@hpcuhe.cup.hp.com> To: ips@ece.cmu.edu (ips) Date: Thu, 5 Jul 2001 12:21:06 -0700 (PDT) X-Mailer: ELM [version 2.5 PL2] 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 Mark, IMO, alternative #4 is sufficient and is semantically aligned with the FC-GS-2/GS-3 GID_FT model. It does require modification of the Text Response PDU to provide a Relative Offset (RO) field indicating the RO of the text response PDU from the start of the text response payload, in order to allow initiators to correctly re-assemble the received response PDUs. Regards, Santosh Mark Bakke wrote: > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" connection > or are handled completely in software, and allow its response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that needed > a large response to implement an iterator. It also means that > each part of the response from the iterator would have to fit > in the 4k PDU. > > The remainder of these require that only one text command sequence > be outstanding on a connection at a given time. They use the F > bit to indicate the last PDU of the sequence. Note that connection > allegiance is assumed for the entire sequence, and text commands > are never retried on another connection; a new command is issued > instead. > > 3. Do a text-response R2T, where the initiator controls when the > next partial response is sent. This would be more generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep track > of the state of its responses; if the initiator just stops asking, > it may have to keep a buffered response around until it times out, > the connection is dropped, or another text command comes along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if it > can't handle them. This solution is a lot like #1, but with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the problem > of the target keeping state; it sends ALL of the response PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > Note that most initiators will probably send an AcceptResponseLength > of the largest response they would normally accept, and that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target has the > benefit of being less statefull, and the initiator has the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 is > probably the safest solution, but #4 may not be a problem for anyone. > > Assuming that none of the implementors of initiators have a problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- ################################# Santosh Rao Software Design Engineer, HP, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################# From owner-ips@ece.cmu.edu Thu Jul 5 19:02:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29443 for ; Thu, 5 Jul 2001 19:02:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65L4BH06405 for ips-outgoing; Thu, 5 Jul 2001 17:04:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f65L49g06401 for ; Thu, 5 Jul 2001 17:04:09 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id B9CB8199B for ; Thu, 5 Jul 2001 14:04:08 -0700 (PDT) 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 OAA10357 for ; Thu, 5 Jul 2001 14:04:04 -0700 (PDT) Message-ID: <3B44D6E5.F86F90ED@cup.hp.com> Date: Thu, 05 Jul 2001 14:06:45 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iSCSI: Iterating long text responses References: <200107051921.MAA04104@hpcuhe.cup.hp.com> <3B44C08C.8F4E4858@cisco.com> Content-Type: multipart/mixed; boundary="------------270C1923DAD34095EDCEBC10" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------270C1923DAD34095EDCEBC10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Bakke wrote: > > Santosh- > > I was making the assumption that a text command stayed on a single > connection, and response PDUs from the target would be in-order, > and that if the connection failed, the target would throw away any > results it hadn't yet sent, and the initiator would just completely > re-do the command. Mark, The CRC error checking and the Text command processing may be handled in different layers of the iSCSI stack (CRC in hardware, text command in firmware or software), with CRC errors causing a discard of the errant PDU alone. Thus, upon receipt of the final Text Response PDU the layer handling the Text command may not be aware that 1 PDU of the returned set of responses was lost. Some ways to address this would be : a. usage of a RO in each Text Response PDU. b. a count of the number of Text Response PDUs sent in the final Text Response ("f=1"). c. A sequence count applied to all multi-PDU text sequences. In addition, the spec needs to explicitly word the "connection allegiance" description to apply to all iSCSI commands, and not just SCSI commands. > This meant we wouldn't need an offset, since > the initiator would have to receive them in order anyway. The offset is required to ensure integrity of the response received. Regards, Santosh > However, > it certainly wouldn't hurt to add the offset. I guess I am just > concerned that if we do, then someone will want to make use of the > field to be able to send text responses out of order, or to recover > them on another connection, and so on, so I would rather leave them > out unless we really need them. How badly are they needed? > > -- > Mark > > Santosh Rao wrote: > > > > Mark, > > > > IMO, alternative #4 is sufficient and is semantically aligned with the > > FC-GS-2/GS-3 GID_FT model. > > > > It does require modification of the Text Response PDU to provide a > > Relative Offset (RO) field indicating the RO of the text response > > PDU from the start of the text response payload, in order to allow initiators > > to correctly re-assemble the received response PDUs. > > > > Regards, > > Santosh > > > > Mark Bakke wrote: > > > > > > 4. Allow multiple response PDUs to a single text command: > > > > > > I->T Text Command (F bit set) > > > T->I Text Response (first PDU, F bit cleared) > > > T->I Text Response (next PDU, F bit cleared) > > > > > > ... > > > > > > T->I Text Response (last PDU, F bit set) > > > > > > Basically, we are doing (3) without the R2T. The initiator, > > > upon sending the text command, must be prepared either to > > > accept as many PDUs as come back, or throw them away if it > > > can't handle them. This solution is a lot like #1, but with > > > the response spread across 4k PDUs. > > > > > > Also note that this (and the following scheme) avoid the problem > > > of the target keeping state; it sends ALL of the response PDUs > > > without the initiator asking for them. > > > > > > 5. Do #4, but allow the initiator to specify the amount of data > > > it is willing to accept: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > > > > > In the above example, we have created a new text command field: > > > > > > AcceptResponseLength > > > > > > And in the text response PDU: > > > > > > TotalResponseLength > > > > > > The initiator indicated it was willing to accept a 4k response. > > > The target returned the first 4k in the text response, but set > > > the F bit since it was at its limit. It also returned a > > > TotalResponseLength field. Since this was greater than the > > > AcceptResponseLength, the initiator knows the amount of buffer > > > space it will need to get the full response. It can then choose > > > whether it will re-send the command, and if so, can give it a > > > large enough response length: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > > T->I Text Response (first PDU, F bit clear) > > > T->I Text Response (next PDU, F bit clear) > > > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > > > > > Note that most initiators will probably send an AcceptResponseLength > > > of the largest response they would normally accept, and that most > > > target responses will fit in one or a few PDUs anyway. > > > > > > #5 is really a compromise between #3 and #4; the target has the > > > benefit of being less statefull, and the initiator has the benefit > > > of controlling the amount of data it receives. > > > > > > I would like to recommend either #4 or #5. I think that #5 is > > > probably the safest solution, but #4 may not be a problem for anyone. > > > > > > Assuming that none of the implementors of initiators have a problem > > > with #4, I would pick that. > > > > > > If they do have a problem with it, we should go with #5. > > > > > > Targets probably don't care much whether we do #4 or #5. > > > > > > Initiator developers- > > > > > > Please indicate which solution (#4 or #5) appeals to you. > > > --------------270C1923DAD34095EDCEBC10 Content-Type: text/x-vcard; charset=us-ascii; name="santoshr.vcf" Content-Description: Card for Santosh Rao Content-Disposition: attachment; filename="santoshr.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Rao;Santosh tel;work:408-447-3751 x-mozilla-html:FALSE org:Hewlett Packard, Cupertino.;SISL adr:;;19420, Homestead Road, M\S 43LN, ;Cupertino.;CA.;95014.;USA. version:2.1 email;internet:santoshr@cup.hp.com title:Software Design Engineer x-mozilla-cpt:;21088 fn:Santosh Rao end:vcard --------------270C1923DAD34095EDCEBC10-- From owner-ips@ece.cmu.edu Thu Jul 5 20:26:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01368 for ; Thu, 5 Jul 2001 20:26:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f65MPX911582 for ips-outgoing; Thu, 5 Jul 2001 18:25:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f65MPWg11578 for ; Thu, 5 Jul 2001 18:25:32 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3G693YP9>; Thu, 5 Jul 2001 18:25:26 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709B3@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Preliminary London dates/times Date: Thu, 5 Jul 2001 18:21:51 -0400 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 This should appear on the IETF web site tomorrow, but here are the preliminary meeting times for the IP Storage WG during the London IETF meeting week. WARNING: These are SUBJECT TO CHANGE until the final agenda is posted sometime after July 16th. Monday, August 6th, 1930-2200 Friday, August 10th, 0900-1130 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jul 6 12:45:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12224 for ; Fri, 6 Jul 2001 12:45:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66FFaH19534 for ips-outgoing; Fri, 6 Jul 2001 11:15:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66EoNg17540 for ; Fri, 6 Jul 2001 10:50:23 -0400 (EDT) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:41 +0100 X-From_: ietf-123-owner@loki.ietf.org Tue Jun 26 13:29:49 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Tue, 26 Jun 2001 13:29:49 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15EryV-0001GH-00; Tue, 26 Jun 2001 13:29:48 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA18666 for ietf-123-outbound.10@ietf.org; Tue, 26 Jun 2001 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA18511 for ; Tue, 26 Jun 2001 07:01:07 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26990; Tue, 26 Jun 2001 07:01:06 -0400 (EDT) Message-Id: <200106261101.HAA26990@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-iscsi-mib-01.txt Date: Tue, 26 Jun 2001 07:01:05 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:41.0474 (UTC) FILETIME=[961A2220:01C1062B] 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 : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-mib-01.txt Pages : 49 Date : 25-Jun-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-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-iscsi-mib-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: <20010625095401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Cont --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 6 12:46:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12277 for ; Fri, 6 Jul 2001 12:46:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66FFgG19549 for ips-outgoing; Fri, 6 Jul 2001 11:15:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from NEXUS.replicants.org.uk (pc-62-30-167-16-ca.blueyonder.co.uk [62.30.167.16]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66Eoag17563 for ; Fri, 6 Jul 2001 10:50:37 -0400 (EDT) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Fri, 6 Jul 2001 15:54:50 +0100 X-From_: ietf-123-owner@loki.ietf.org Fri Jul 06 13:39:11 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Fri, 06 Jul 2001 13:39:11 +0100 Received: from [132.151.1.177] (helo=loki.ietf.org) by mail8.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 15IUt4-0001EW-00; Fri, 06 Jul 2001 13:39:10 +0100 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA24231 for ietf-123-outbound.10@ietf.org; Fri, 6 Jul 2001 07:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA23663 for ; Fri, 6 Jul 2001 06:50:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25843; Fri, 6 Jul 2001 06:50:15 -0400 (EDT) Message-Id: <200107061050.GAA25843@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-iscsi-reqmts-05.txt Date: Fri, 06 Jul 2001 06:50:15 -0400 X-OriginalArrivalTime: 06 Jul 2001 14:54:50.0467 (UTC) FILETIME=[9B765B30:01C1062B] 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 : iSCSI Requirements and Design Considerations Author(s) : M. Krueger et al. Filename : draft-ietf-ips-iscsi-reqmts-05.txt Pages : 24 Date : 05-Jul-01 The IP Storage Working group is chartered with developing comprehensive technology to transport block storage data over IP protocols. This effort includes a protocol to transport the Small Computer Systems Interface (SCSI) protocol over the Internet (iSCSI). The initial version of the iSCSI protocol will define a mapping of SCSI transport protocol over TCP/IP so that SCSI storage controllers (principally disk and tape arrays and libraries) can be attached to IP networks, notably Gigabit Ethernet (GbE) and 10 Gigabit Ethernet (10 GbE). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-reqmts-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-reqmts-05.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-iscsi-reqmts-05.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: <20010705113829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-reqmts-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-reqmts-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 6 13:58:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14492 for ; Fri, 6 Jul 2001 13:58:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66F6Nt18761 for ips-outgoing; Fri, 6 Jul 2001 11:06:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66F6Lg18757 for ; Fri, 6 Jul 2001 11:06:21 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: Iterating long text responses In-Reply-To: Message from Mark Bakke of "Fri, 29 Jun 2001 15:18:20 CDT." <3B3CE28C.F9748D5C@cisco.com> References: <3B3CE28C.F9748D5C@cisco.com> Date: Fri, 06 Jul 2001 11:05:54 -0400 From: Stephen Bailey Message-Id: <20010706150620.283C14E8C@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Please indicate which solution (#4 or #5) appeals to you. Well, this makes a hearty assumption.... I believe 4 completely misses the point. The initiator will still have no control over the resource requirements to swallow the target's responses. This is bad both for the initiator and the target since it can flow-control the connection. For iSCSI to work well, you must make sure that the connection is kept `lively' (connection-level flow control is not engaged). Solution #5 is better, but you still have an irritating problem dealing with what happens when the response length is larger than your reserved resources. I believe in #2. If we specify that each text PDU results in at most one response PDU, that gives you effective control over the resources required for text messages. Then, on a case-by-case basis, you build a protocol for addressing this limitation within its confines. In the case if SendTargets, we use an iterator. In the case of each X-* operation, the protocol is chosen to meet the needs of the operation. The reason why you don't want to solve this problem `in general' (which we haven't actually done with any of these solutions anyway) for everybody is because `everybody' has different needs. Some actions of X-* are NOT going to be idempotent, and the vendor (or whomever) may want to build an exactly-once protocol which works across connections, and on recovered sessions. Other cases, might want at-most-once semantics, and yet other cases, unreliable, best-effort. It's too painful (and pointless) for us to build an exactly-once protocol for text messages when the only specified application is SendTargets, which doesn't need exactly-once semantics. What you're trying to provide is the equivalent of general IP fragmentation. For application purposes (as opposed to network purposes), IP fragmentation just gets in the way. Provide a basic datagram capability the upper layer can build everything else as necessary. If the application heavy data transfer services, it should use SCSI directly. This is already a tradition within SCSI architecture. Steph From owner-ips@ece.cmu.edu Fri Jul 6 13:59:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14542 for ; Fri, 6 Jul 2001 13:59:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66EeXS16854 for ips-outgoing; Fri, 6 Jul 2001 10:40:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66EeWg16849 for ; Fri, 6 Jul 2001 10:40:32 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: SendTargets In-Reply-To: Message from Mark Bakke of "Tue, 26 Jun 2001 15:30:06 CDT." <3B38F0CE.B767C0C1@cisco.com> References: <3B38F0CE.B767C0C1@cisco.com> Date: Fri, 06 Jul 2001 10:40:04 -0400 From: Stephen Bailey Message-Id: <20010706144030.7E2114E8C@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, > Valid only on the canonical session, not on an operational > session. I would recommend that we discontinue the use of the term canonical in this context. I prefer `discovery session'. Steph From owner-ips@ece.cmu.edu Fri Jul 6 16:20:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18603 for ; Fri, 6 Jul 2001 16:20:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66IXbY03349 for ips-outgoing; Fri, 6 Jul 2001 14:33:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pop.mainstreet.net (smtp.mainstreet.net [207.5.0.46]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66IBVg01876 for ; Fri, 6 Jul 2001 14:11:31 -0400 (EDT) Received: from vip (saqibj.mainstreet.net [207.5.1.168]) by pop.mainstreet.net (8.11.3/8.11.3) with SMTP id f66IArr43539; Fri, 6 Jul 2001 11:10:58 -0700 (PDT) Reply-To: From: "Saqib Jang" To: Cc: Subject: RE: iSCSI Security: Environment and Requirements Date: Fri, 6 Jul 2001 11:13:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Thanks for your reponse to the earlier question. Have another quick question. > I would offer the caution that some of the possible solutions to the > rekeying situation may result in tighter binding between iSCSI and > IPsec that would favor built-in IPsec support and/or require modifications > to external gateways. I believe the anticipated IPsec requirement > is ESP in tunnel mode, but this is also subject to change (e.g., > will almost certainly be discussed further in London). Are iSCSI HBAs considered "gateways" in IPsec terminilogy? Per RFC 2401, only "gateways" can support only tunnel-mode IPsec, whereas "hosts' are required to support both tunnel and transport mode IPsec. Saqib Saqib Jang Margalla Communications, Inc. 3301 El Camino Real, Suite 220 Atherton, CA 94027 Ph: 650 298 8462 Fax: 650 851 1613 www.margallacomm.com From owner-ips@ece.cmu.edu Fri Jul 6 16:26:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18809 for ; Fri, 6 Jul 2001 16:26:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66IeGW03824 for ips-outgoing; Fri, 6 Jul 2001 14:40:16 -0400 (EDT) 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 f66IYXg03408 for ; Fri, 6 Jul 2001 14:34:33 -0400 (EDT) Received: from eddylaptop (h00045a099bc5.ne.mediaone.net [66.31.72.75]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f66IYP609997; Fri, 6 Jul 2001 14:34:25 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: security conflict Date: Fri, 6 Jul 2001 14:34:29 -0400 Message-ID: <00e001c1064a$4e3383b0$4b481f42@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit draft 06-92: In section "4.2 iSCSI Security and Integrity Negotiation" it says: The security exchange sets the security mechanism and authenticates the user and the target to each other. The exchange proceeds according to the algorithms that were chosen in the negotiation phase and is conducted by the text commands key=value parameters. The negotiation proceeds as follows: -The initiator sends a text command with an ordered list of the options it supports for each subject (authentication algorithm, But a few lines down it says: If security is to be established, the initiator MUST NOT send parameters other than security parameters in the login command. These two statements conflict because the 1st says he must send security parameters in text commands but the 2nd says "login command". The examples clearly point out that security commands can be in the Login command. Maybe the above text should be changed to "by the login/text commands" and "sends a login/text command". Comments anyone? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 6 16:27:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18829 for ; Fri, 6 Jul 2001 16:27:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66IXiW03360 for ips-outgoing; Fri, 6 Jul 2001 14:33:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f66IK3g02399 for ; Fri, 6 Jul 2001 14:20:03 -0400 (EDT) Received: from 157.54.9.101 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 06 Jul 2001 11:19:57 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:19:55 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:19:41 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 6 Jul 2001 11:19:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10648.240E4461" Subject: Sense data and Response Data Date: Fri, 6 Jul 2001 11:19:05 -0700 Message-ID: <8CC03F47967BF14D9710887723FADDB6A5827A@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Sense data and Response Data thread-index: AcEFrcivUWicbtBfRK68HkkK9hG6FgAmlRBA From: "Lakshmi Ramasubramanian" To: X-OriginalArrivalTime: 06 Jul 2001 18:19:05.0654 (UTC) FILETIME=[241F7D60:01C10648] Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C10648.240E4461 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In SCSI Response PDU, the target can send either Sense Data or Response Data, but not both. In certain cases, such as when a filemark is detected on the tape during read, the target needs to return both the data read before reaching the filemark and the sense data.=20 =20 Is there anyway targets can do this? thanks! -lakshmi ------_=_NextPart_001_01C10648.240E4461 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
In SCSI Response PDU, the target can send either Sense = Data or=20 Response Data, but not both. = In certain cases, such = as when a=20 filemark is detected on the tape during read, = the target needs = to  return both the=20 data read before reaching the filemark = and the sense data. 
 
Is there anyway targets can do=20 this?
thanks!
 -lakshmi
=00 ------_=_NextPart_001_01C10648.240E4461-- From owner-ips@ece.cmu.edu Fri Jul 6 18:00:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21263 for ; Fri, 6 Jul 2001 18:00:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66K7IJ09794 for ips-outgoing; Fri, 6 Jul 2001 16:07:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66K7Hg09788 for ; Fri, 6 Jul 2001 16:07:17 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: security conflict In-Reply-To: Message from "Eddy Quicksall" of "Fri, 06 Jul 2001 14:34:29 EDT." <00e001c1064a$4e3383b0$4b481f42@eddylaptop> References: <00e001c1064a$4e3383b0$4b481f42@eddylaptop> Date: Fri, 06 Jul 2001 16:06:48 -0400 From: Stephen Bailey Message-Id: <20010706200715.948E44E95@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Comments anyone? The `initiator MUST NOT send parameters other than security in the login command' prohibition means that the intiator must not send operation parameters in the login command when security is being turned on. In this case, identity parameters (initiator name & target name), and the set of supported mechanisms are considered to be security parameters. This is to ensure that operational parameter negotiation is secured. It does not say that ALL security `parameters' (including those used for the actual security mechanism establishment) must ONLY be sent in the login command. Once a security mode has been chosen, negotiation happens with text commands. Steph From owner-ips@ece.cmu.edu Fri Jul 6 18:35:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22344 for ; Fri, 6 Jul 2001 18:35:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66LHN214250 for ips-outgoing; Fri, 6 Jul 2001 17:17:23 -0400 (EDT) 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 f66LHLg14246 for ; Fri, 6 Jul 2001 17:17:21 -0400 (EDT) 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 XAA308018; Fri, 6 Jul 2001 23:17:14 +0200 From: julian_satran@il.ibm.com Received: from d12mta02.de.ibm.com (d12mta01_cs0 [9.165.222.237]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f66LHEf32718; Fri, 6 Jul 2001 23:17:14 +0200 Received: by d12mta02.de.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256A81.0074AED2 ; Fri, 6 Jul 2001 23:14:29 +0200 X-Lotus-FromDomain: IBMIL@IBMDE To: "Lakshmi Ramasubramanian" cc: ips@ece.cmu.edu Message-ID: Date: Sat, 7 Jul 2001 00:21:13 +0300 Subject: Re: FW: Sense data and Response Data Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk The target can return the data in data-in PDUs followed by the response. Response data is meant in contrast to user data (response data are some form of device exception message). Julo "Lakshmi Ramasubramanian" on 06-07-2001 21:30:57 Please respond to "Lakshmi Ramasubramanian" To: mbakke@cisco.com, Julian Satran/Haifa/IBM@IBMIL, dap@cisco.com cc: Subject: FW: Sense data and Response Data Pardon me for sending this mail to you folks directly. I didn't receive any email on the reflector since yesterday afternoon. Has this issue related to sense data and response data been discussed earlier? thanks! -lakshmi -----Original Message----- From: Lakshmi Ramasubramanian Sent: Friday, July 06, 2001 11:19 AM To: 'ips@ece.cmu.edu' Subject: Sense data and Response Data In SCSI Response PDU, the target can send either Sense Data or Response Data, but not both. In certain cases, such as when a filemark is detected on the tape during read, the target needs to return both the data read before reaching the filemark and the sense data. Is there anyway targets can do this? thanks! -lakshmi - att1.htm From owner-ips@ece.cmu.edu Fri Jul 6 18:38:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22392 for ; Fri, 6 Jul 2001 18:38:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f66KtlF12993 for ips-outgoing; Fri, 6 Jul 2001 16:55:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f66Ktkg12989 for ; Fri, 6 Jul 2001 16:55:46 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3G69PFVQ>; Fri, 6 Jul 2001 16:55:41 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709BF@corpmx14.us.dg.com> From: Black_David@emc.com To: saqibj@margallacomm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Security: Environment and Requirements Date: Fri, 6 Jul 2001 16:52:04 -0400 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 > Are iSCSI HBAs considered "gateways" in IPsec terminilogy? Per > RFC 2401, only "gateways" can support only tunnel-mode IPsec, whereas > "hosts' are required to support both tunnel and transport mode IPsec. Not exactly. The current path is to pick out an appropriate subset of IPsec -- if we were to require IPsec starting with RFC 2401, we'd wind up requiring a lot of stuff (AH, ESP, IKE, ISAKMP, DES, etc.). Not only is this far more than is necessary, but it also requires things that have little current justification (e.g., AH and DES). In any case, the whole point of this paragraph is that one should not to make inferences about iSCSI based on requirements in IPsec RFCs as the current plan is to require an IPsec subset. The specific answer to your question is that an iSCSI HBA is a "host" as far as IPsec is concerned, however, here are rationales I've heard for only requiring tunnel mode: (1) Only one IPsec mode (transport or tunnel) is needed for a protocol like iSCSI. (2) Tunnel mode has better NAT transparency because the encapsulated IP and TCP checksums work in tunnel mode (they fail in transport mode). See draft-ietf-ipsec-nat-reqts-00.txt for more details. (3) Tunnel mode would allow the use of external gateways, transport mode would not. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jul 6 23:38:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28985 for ; Fri, 6 Jul 2001 23:38:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f671wGY29438 for ips-outgoing; Fri, 6 Jul 2001 21:58:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f671wFg29433 for ; Fri, 6 Jul 2001 21:58:15 -0400 (EDT) Received: from ljlamers-lap.ieee.org (user-vcaump1.dsl.mindspring.com [216.175.91.33]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA01278; Fri, 6 Jul 2001 21:56:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706080424.00b17c10@pop.mindspring.com> X-Sender: ljlamers@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jul 2001 08:05:13 -0700 To: Santosh Rao , ips@ece.cmu.edu (ips) From: "Lawrence J. Lamers" Subject: Re: In-Reply-To: <200107051921.MAA04104@hpcuhe.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Santosh, The behavior in #5 is what most SCSI device guys are used to. It is similar to the way MODE SENSE and other commands work that return parameter lists. I would vote for #5. At 07/05/2001, Santosh Rao wrote: >Mark, > >IMO, alternative #4 is sufficient and is semantically aligned with the >FC-GS-2/GS-3 GID_FT model. > >It does require modification of the Text Response PDU to provide a >Relative Offset (RO) field indicating the RO of the text response >PDU from the start of the text response payload, in order to allow initiators >to correctly re-assemble the received response PDUs. > >Regards, >Santosh > > >Mark Bakke wrote: > > > > Initiator developers- > > > > Please respond to the questions at the end. > > > > Thanks, > > > > Mark > > > > The current iSCSI draft allows text command and response > > PDUs of up to 4096 bytes. While we don't see any real > > problems for the command PDU size, commands such as SendTargets > > can easily exceed the response size. > > > > There are several ways we can fix this. The first two solutions > > require no differences in the current iSCSI text command and > > response; the latter three involve the use of the F bit. > > > > 1. Assume that such commands are done on a "special" connection > > or are handled completely in software, and allow its response > > PDU to be as large as it needs to be. > > > > This one appears too restrictive to be a solid solution. It > > will also weaken any data digests done on the longer PDU. > > > > 2. Create an iterative SendTargets key (and do the same for any > > other text commands that need this), that would allow the > > initiator to request the "next target" or "next address". > > > > This would work, but would require any new command that needed > > a large response to implement an iterator. It also means that > > each part of the response from the iterator would have to fit > > in the 4k PDU. > > > > The remainder of these require that only one text command sequence > > be outstanding on a connection at a given time. They use the F > > bit to indicate the last PDU of the sequence. Note that connection > > allegiance is assumed for the entire sequence, and text commands > > are never retried on another connection; a new command is issued > > instead. > > > > 3. Do a text-response R2T, where the initiator controls when the > > next partial response is sent. This would be more generic: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > I->T Text Command (with some indicator that we want more) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > I->T Text Command (with indicator that we want more) > > T->I Text Response (last PDU, F bit set) > > > > The main problem with this is that the target must keep track > > of the state of its responses; if the initiator just stops asking, > > it may have to keep a buffered response around until it times out, > > the connection is dropped, or another text command comes along. > > > > 4. Allow multiple response PDUs to a single text command: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > T->I Text Response (last PDU, F bit set) > > > > Basically, we are doing (3) without the R2T. The initiator, > > upon sending the text command, must be prepared either to > > accept as many PDUs as come back, or throw them away if it > > can't handle them. This solution is a lot like #1, but with > > the response spread across 4k PDUs. > > > > Also note that this (and the following scheme) avoid the problem > > of the target keeping state; it sends ALL of the response PDUs > > without the initiator asking for them. > > > > 5. Do #4, but allow the initiator to specify the amount of data > > it is willing to accept: > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > > > In the above example, we have created a new text command field: > > > > AcceptResponseLength > > > > And in the text response PDU: > > > > TotalResponseLength > > > > The initiator indicated it was willing to accept a 4k response. > > The target returned the first 4k in the text response, but set > > the F bit since it was at its limit. It also returned a > > TotalResponseLength field. Since this was greater than the > > AcceptResponseLength, the initiator knows the amount of buffer > > space it will need to get the full response. It can then choose > > whether it will re-send the command, and if so, can give it a > > large enough response length: > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > T->I Text Response (first PDU, F bit clear) > > T->I Text Response (next PDU, F bit clear) > > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > > > Note that most initiators will probably send an AcceptResponseLength > > of the largest response they would normally accept, and that most > > target responses will fit in one or a few PDUs anyway. > > > > #5 is really a compromise between #3 and #4; the target has the > > benefit of being less statefull, and the initiator has the benefit > > of controlling the amount of data it receives. > > > > I would like to recommend either #4 or #5. I think that #5 is > > probably the safest solution, but #4 may not be a problem for anyone. > > > > Assuming that none of the implementors of initiators have a problem > > with #4, I would pick that. > > > > If they do have a problem with it, we should go with #5. > > > > Targets probably don't care much whether we do #4 or #5. > > > > Initiator developers- > > > > Please indicate which solution (#4 or #5) appeals to you. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 >-- >################################# >Santosh Rao >Software Design Engineer, >HP, Cupertino. >email : santoshr@cup.hp.com >Phone : 408-447-3751 >################################# Regards, ========================================== Lawrence J. Lamers email: ljlamers@ieee.org Cell Phone: (408) 234-0071 Home Phone: (408) 578-1709 From owner-ips@ece.cmu.edu Fri Jul 6 23:42:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29045 for ; Fri, 6 Jul 2001 23:42:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f671v8M29393 for ips-outgoing; Fri, 6 Jul 2001 21:57:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f671v7g29389 for ; Fri, 6 Jul 2001 21:57:07 -0400 (EDT) Received: from ljlamers-lap.ieee.org (user-vcaump1.dsl.mindspring.com [216.175.91.33]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id VAA30090; Fri, 6 Jul 2001 21:57:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706080743.00abe740@pop.mindspring.com> X-Sender: ljlamers@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jul 2001 08:09:06 -0700 To: "Elliott, Robert" , ips@ece.cmu.edu From: "Lawrence J. Lamers" Subject: RE: iSCSI version number In-Reply-To: <78AF3C342AEAEF4BA33B35A8A15668C659C25F@cceexc17.americas.c pqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk If we need intermediate versions we should clone an approach similar to what Gene Milligan put in the SCSI Block Devices command set. This intermediate versions will continue to be an issue, Gene recognized that many folks implement before there is an 'official' standard and that we need to deal with it. At 07/05/2001, Elliott, Robert wrote: >The UNH plugfest is testing implementations based version 0 or version 6. >These are conveniently differentiated by using version code 0x00 for version >0 and 0x01 for version 6. Implementations based on versions 1-5 are >discouraged by the plugfest choice. Since there will exist numerous version >6 implementations, I think it's advantageous for the iSCSI version number to >increment from this point forward to differentiate them from newer >implementations. > >Unfortunately, UNH created a bit of a mess by asking that version 7 opcode >encoding be used with the version 6 implementations without incrementing the >version number. I expect that to create some confusion (easily solved by a >recompile, I hope). >--- >Rob Elliott, Compaq Server Storage >Robert.Elliott@compaq.com > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Thursday, July 05, 2001 1:40 AM > > To: ips@ece.cmu.edu > > Subject: RE: iSCSI version number > > > > > > I am not sure that increasing the version number in draft-07 > > will provide > > this protection. I believe drafts 3 through 6 had the same > > version number > > (0x01) but they don't interoperate. On the other hand, drafts > > 6 and 7 will > > have different version numbers and they very much > > interoperate. I prefer > > keeping the version number at 0x01 until the final draft. > > > > -Ayman > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Eddy Quicksall > > > Sent: Wednesday, July 04, 2001 2:52 PM > > > To: julian_satran@il.ibm.com; ips@ece.cmu.edu > > > Cc: Tri.G[tri.g.nguyen@intel.com] > > > Subject: Re: iSCSI version number > > > > > > > > > I have mixed emotions ... I agree with Bob in principal. > > > > > > But, I figured the reason you changed it was actually to > > distinguish from > > > rev 0 ... as I understand it, Intel has already released code > > > that conforms > > > to rev 0 (but Intel should respond to this). > > > > > > If we don't increase the version, how do we protect > > ourselves from running > > > into one of the Intel controllers? > > > > > > Eddy > > > > > > ----- Original Message ----- > > > From: > > > To: > > > Sent: Wednesday, July 04, 2001 1:13 AM > > > Subject: Re: iSCSI version number > > > > > > > > > > > > > > > > > > Robert, > > > > > > > > You have a good point - and for this reason I intended > > to keep the > > > version > > > > number to 01 up to the RFC date. > > > > But several folks on the list tought that we are too far from > > > 01 (one even > > > > suggested that we number according to the draft number). > > > > > > > > I would like to hear some more voices. > > > > > > > > Julo > > > > > > > > "Robert D. Russell" on 03-07-2001 22:06:00 > > > > > > > > Please respond to "Robert D. Russell" > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > > cc: ips@ece.cmu.edu > > > > Subject: iSCSI version number > > > > > > > > > > > > > > > > > > > > Julian: > > > > > > > > The 06-91 draft section 2.10.4 on page 57 lists the version number > > > > of the current draft as 0x2, whereas previously it was always 0x1. > > > > Shouldn't it still be 0x1?? After all, there has been no > > > > approved version 0x1, and the 06-91 draft is only a small > > > > incremental improvement over the 06 draft, not a major revision. > > > > Changing to version 0x2 implies a consensus on what 0x1 was, > > > > and there is none (was it the 06 draft, the 06 draft updated > > > > by some (all) of the mailing list e-mails that followed, or what?) > > > > What exactly would it mean to support version 0x1 when the current > > > > (still under revision draft) is 0x2 and there is no consensus on > > > > what version 0x1 was? And what criteria will you use to decide > > > > when a version number changes and when it doesn't? > > > > > > > > I believe these drafts should remain version 0x1 until the "final" > > > > draft in this sequence is approved by IETF. Otherwise, you will > > > > end up will a bunch of meaningless version numbers that will > > > > be impossible to track. > > > > > > > > > > > > Bob Russell > > > > InterOperability Lab > > > > University of New Hampshire > > > > rdr@iol.unh.edu > > > > 603-862-3774 > > > > > > > > > > > > > > > > > > > > > > > > > Regards, ========================================== Lawrence J. Lamers email: ljlamers@ieee.org Cell Phone: (408) 234-0071 Home Phone: (408) 578-1709 From owner-ips@ece.cmu.edu Mon Jul 9 14:23:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24791 for ; Mon, 9 Jul 2001 14:23:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69GOW013453 for ips-outgoing; Mon, 9 Jul 2001 12:24:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ext1.pirus.com ([4.36.58.197]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69GOUg13448 for ; Mon, 9 Jul 2001 12:24:30 -0400 (EDT) Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21) id <3H22849B>; Mon, 9 Jul 2001 12:24:55 -0400 Message-ID: From: "Binford, Charles" To: ips@ece.cmu.edu Subject: FCIP Multiple Connection Management Date: Mon, 9 Jul 2001 12:24:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk From pages 41-42 of FCIP rev 03 ******************************************* 5.5 Multiple Connection Management A pair of FCIP device endpoints MAY establish a certain number of TCP connections between them. Since a Virtual ISL potentially maps a fairly large number of FC flows (where a flow is a pair of Fibre Channel S_ID, D_ID addresses), it may not be practical to establish a separate TCP connection for each Fibre Channel flow. In order to address this, an implementation MAY choose to manage a pool of TCP connections for a single Virtual ISL and map Fibre Channel flows to TCP connections of that ISL. However, while assigning Fibre Channel flows to TCP connections, an implementation SHALL follow the following rules: 1) Once a Fibre Channel flow is assigned to a TCP connection within the virtual ISL, it SHALL send all Fibre Channel frames of that flow on that connection. 2) When an FCIP endpoint processes any response traffic from a particular target, the Endpoint SHALL send the response on the same connection on which the request was sent. 3) Any class 2 ACK frames SHALL be sent on the same connection in which the original frame was sent. These rules are in place to honor any in-order delivery guarantees that may have been made between the two end points of the Fibre Channel flow. ************************************* Given the above rules, consider the following: |-----| |-----| -------- |FCIP |--TCP_Con_1--|FCIP | ------- FC_Node_A -------|FC-SW |--|Dev1 |--TCP_Con_2--|Dev2 |---|FC-SW| ---- FC_NODE_B -------- |-----| |-----| ------- FCIP devices 1 and 2 have a single Virtual ISL composed of two separate TCP connections. Assume FC_NODE_A and FC_NODE_B both send PLOGI to each other at approximately the same time. FCIP_Dev1 happens to choose TCP_Con_1 for the FC Flow of S_ID_A-to-D_ID_B. FCIP_Dev2 happens to choose TCP_Con_2 for the FC Flow of S_ID_B-to-D_ID_A. So far so good, both FCIP devices are following the above rules. Now, FC_Node_A sends the PLOGI ACC. What is FCIP_Dev1 supposed to do? Rule 1 says choose TCP_Con_1 (this is the S_ID_A-to-D_ID_B flow and that flow has already been established to be TCP_Con_1). Rule 2 says choose TCP_Con_2 (this is a response to a frame that was received on TCP_Con_2). I believe rules 2 and 3 are not needed. What the combination of all three rules really say is there must be a defined negotiation or hash algorithm that both FCIP_dev 1 and 2 have to follow to keep all of the traffic between FC_Node_A and B on the same TCP connection. I believe this is totally unnecessary. If both sides obey only rule 1 then "any in-order delivery guarantees that may have been made between the two end points of the Fibre Channel flow" will still be met. Charles Binford Pirus Networks From owner-ips@ece.cmu.edu Mon Jul 9 15:48:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27084 for ; Mon, 9 Jul 2001 15:48:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69I0rh20742 for ips-outgoing; Mon, 9 Jul 2001 14:00:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69I0og20736 for ; Mon, 9 Jul 2001 14:00:51 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 1BC6DADF; Mon, 9 Jul 2001 11:00:50 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id DE51B1F512; Mon, 9 Jul 2001 03:59:52 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id <3PHKYYFQ>; Mon, 9 Jul 2001 11:00:48 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6503F00D16@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Lawrence J. Lamers'" , Santosh Rao Cc: ips@ece.cmu.edu Subject: RE: Date: Mon, 9 Jul 2001 11:00:47 -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 would vote for #5 as it is a familiar way of doing things for SCSI folks. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: Lawrence J. Lamers [mailto:ljlamers@ieee.org] > Sent: Friday, July 06, 2001 8:05 AM > To: Santosh Rao; ips@ece.cmu.edu > Subject: Re: > > > Mark, Santosh, > > The behavior in #5 is what most SCSI device guys are used to. It is > similar to the way MODE SENSE and other commands work that > return parameter > lists. I would vote for #5. > > > > > At 07/05/2001, Santosh Rao wrote: > >Mark, > > > >IMO, alternative #4 is sufficient and is semantically > aligned with the > >FC-GS-2/GS-3 GID_FT model. > > > >It does require modification of the Text Response PDU to provide a > >Relative Offset (RO) field indicating the RO of the text response > >PDU from the start of the text response payload, in order to > allow initiators > >to correctly re-assemble the received response PDUs. > > > >Regards, > >Santosh > > > > > >Mark Bakke wrote: > > > > > > Initiator developers- > > > > > > Please respond to the questions at the end. > > > > > > Thanks, > > > > > > Mark > > > > > > The current iSCSI draft allows text command and response > > > PDUs of up to 4096 bytes. While we don't see any real > > > problems for the command PDU size, commands such as SendTargets > > > can easily exceed the response size. > > > > > > There are several ways we can fix this. The first two solutions > > > require no differences in the current iSCSI text command and > > > response; the latter three involve the use of the F bit. > > > > > > 1. Assume that such commands are done on a "special" connection > > > or are handled completely in software, and allow its response > > > PDU to be as large as it needs to be. > > > > > > This one appears too restrictive to be a solid solution. It > > > will also weaken any data digests done on the longer PDU. > > > > > > 2. Create an iterative SendTargets key (and do the same for any > > > other text commands that need this), that would allow the > > > initiator to request the "next target" or "next address". > > > > > > This would work, but would require any new command that needed > > > a large response to implement an iterator. It also means that > > > each part of the response from the iterator would have to fit > > > in the 4k PDU. > > > > > > The remainder of these require that only one text command sequence > > > be outstanding on a connection at a given time. They use the F > > > bit to indicate the last PDU of the sequence. Note that > connection > > > allegiance is assumed for the entire sequence, and text commands > > > are never retried on another connection; a new command is issued > > > instead. > > > > > > 3. Do a text-response R2T, where the initiator controls when the > > > next partial response is sent. This would be more generic: > > > > > > I->T Text Command (F bit set) > > > T->I Text Response (first PDU, F bit cleared) > > > I->T Text Command (with some indicator that we want more) > > > T->I Text Response (next PDU, F bit cleared) > > > > > > ... > > > > > > I->T Text Command (with indicator that we want more) > > > T->I Text Response (last PDU, F bit set) > > > > > > The main problem with this is that the target must keep track > > > of the state of its responses; if the initiator just > stops asking, > > > it may have to keep a buffered response around until > it times out, > > > the connection is dropped, or another text command comes along. > > > > > > 4. Allow multiple response PDUs to a single text command: > > > > > > I->T Text Command (F bit set) > > > T->I Text Response (first PDU, F bit cleared) > > > T->I Text Response (next PDU, F bit cleared) > > > > > > ... > > > > > > T->I Text Response (last PDU, F bit set) > > > > > > Basically, we are doing (3) without the R2T. The initiator, > > > upon sending the text command, must be prepared either to > > > accept as many PDUs as come back, or throw them away if it > > > can't handle them. This solution is a lot like #1, but with > > > the response spread across 4k PDUs. > > > > > > Also note that this (and the following scheme) avoid > the problem > > > of the target keeping state; it sends ALL of the response PDUs > > > without the initiator asking for them. > > > > > > 5. Do #4, but allow the initiator to specify the amount of data > > > it is willing to accept: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > > T->I Text Response (first PDU, F bit set, > TotalResponseLength=12288) > > > > > > In the above example, we have created a new text command field: > > > > > > AcceptResponseLength > > > > > > And in the text response PDU: > > > > > > TotalResponseLength > > > > > > The initiator indicated it was willing to accept a 4k response. > > > The target returned the first 4k in the text response, but set > > > the F bit since it was at its limit. It also returned a > > > TotalResponseLength field. Since this was greater than the > > > AcceptResponseLength, the initiator knows the amount of buffer > > > space it will need to get the full response. It can > then choose > > > whether it will re-send the command, and if so, can give it a > > > large enough response length: > > > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > > T->I Text Response (first PDU, F bit clear) > > > T->I Text Response (next PDU, F bit clear) > > > T->I Text Response (last PDU, F bit set, > TotalResponseLength=12288) > > > > > > Note that most initiators will probably send an > AcceptResponseLength > > > of the largest response they would normally accept, > and that most > > > target responses will fit in one or a few PDUs anyway. > > > > > > #5 is really a compromise between #3 and #4; the target has the > > > benefit of being less statefull, and the initiator has > the benefit > > > of controlling the amount of data it receives. > > > > > > I would like to recommend either #4 or #5. I think that #5 is > > > probably the safest solution, but #4 may not be a problem > for anyone. > > > > > > Assuming that none of the implementors of initiators have > a problem > > > with #4, I would pick that. > > > > > > If they do have a problem with it, we should go with #5. > > > > > > Targets probably don't care much whether we do #4 or #5. > > > > > > Initiator developers- > > > > > > Please indicate which solution (#4 or #5) appeals to you. > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > >-- > >################################# > >Santosh Rao > >Software Design Engineer, > >HP, Cupertino. > >email : santoshr@cup.hp.com > >Phone : 408-447-3751 > >################################# > > Regards, > > ========================================== > Lawrence J. Lamers > email: ljlamers@ieee.org > Cell Phone: (408) 234-0071 > Home Phone: (408) 578-1709 > From owner-ips@ece.cmu.edu Mon Jul 9 15:48:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27110 for ; Mon, 9 Jul 2001 15:48:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69I9XT21288 for ips-outgoing; Mon, 9 Jul 2001 14:09:33 -0400 (EDT) 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 f69I9Wg21284 for ; Mon, 9 Jul 2001 14:09:32 -0400 (EDT) Received: by LUCY with Internet Mail Service (5.5.2653.19) id <3H2SLLFN>; Mon, 9 Jul 2001 14:13:35 -0400 Message-ID: <63616B261CEFD411834D00D0B7A86CF7113F43@LUCY> From: Sudhir Srinivasan To: "'Binford, Charles'" , ips@ece.cmu.edu Subject: RE: FCIP Multiple Connection Management Date: Mon, 9 Jul 2001 14:13:29 -0400 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 Charles, Agree 100% - this was discussed in the following thread, although, to my recollection, we did not explicitly state a consensus and the text is still found in Annex E of rev 0.3. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04662.html > -----Original Message----- > From: Binford, Charles [mailto:CBinford@pirus.com] > Sent: Monday, July 09, 2001 12:25 PM > To: ips@ece.cmu.edu > Subject: FCIP Multiple Connection Management > > > From pages 41-42 of FCIP rev 03 > ******************************************* > 5.5 Multiple Connection Management > > A pair of FCIP device endpoints MAY establish a certain number of > TCP connections between them. Since a Virtual ISL > potentially maps a > fairly large number of FC flows (where a flow is a pair of Fibre > Channel S_ID, D_ID addresses), it may not be practical to > establish > a separate TCP connection for each Fibre Channel flow. In order to > address this, an implementation MAY choose to manage a pool of TCP > connections for a single Virtual ISL and map Fibre Channel > flows to > TCP connections of that ISL. However, while assigning > Fibre Channel > flows to TCP connections, an implementation SHALL follow the > following rules: > > 1) Once a Fibre Channel flow is assigned to a TCP > connection within > the virtual ISL, it SHALL send all Fibre Channel > frames of that > flow on that connection. > > 2) When an FCIP endpoint processes any response traffic from a > particular target, the Endpoint SHALL send the response on the > same connection on which the request was sent. > > 3) Any class 2 ACK frames SHALL be sent on the same connection in > which the original frame was sent. > > These rules are in place to honor any in-order delivery guarantees > that may have been made between the two end points of the Fibre > Channel flow. > ************************************* > > Given the above rules, consider the following: > |-----| |-----| > -------- |FCIP |--TCP_Con_1--|FCIP | ------- > FC_Node_A -------|FC-SW |--|Dev1 |--TCP_Con_2--|Dev2 |---|FC-SW| ---- > FC_NODE_B > -------- |-----| |-----| ------- > > FCIP devices 1 and 2 have a single Virtual ISL composed of > two separate TCP > connections. Assume FC_NODE_A and FC_NODE_B both send PLOGI > to each other > at approximately the same time. FCIP_Dev1 happens to choose > TCP_Con_1 for > the FC Flow of S_ID_A-to-D_ID_B. FCIP_Dev2 happens to choose > TCP_Con_2 for > the FC Flow of S_ID_B-to-D_ID_A. So far so good, both FCIP > devices are > following the above rules. > > Now, FC_Node_A sends the PLOGI ACC. What is FCIP_Dev1 > supposed to do? Rule > 1 says choose TCP_Con_1 (this is the S_ID_A-to-D_ID_B flow > and that flow has > already been established to be TCP_Con_1). Rule 2 says > choose TCP_Con_2 > (this is a response to a frame that was received on TCP_Con_2). > > I believe rules 2 and 3 are not needed. What the combination > of all three > rules really say is there must be a defined negotiation or > hash algorithm > that both FCIP_dev 1 and 2 have to follow to keep all of the > traffic between > FC_Node_A and B on the same TCP connection. I believe this is totally > unnecessary. > > If both sides obey only rule 1 then "any in-order delivery > guarantees that > may have been made between the two end points of the Fibre > Channel flow" > will still be met. > > Charles Binford > Pirus Networks > From owner-ips@ece.cmu.edu Mon Jul 9 17:51:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29486 for ; Mon, 9 Jul 2001 17:51:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69KAtW00962 for ips-outgoing; Mon, 9 Jul 2001 16:10:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraab.compuserve.com (ds-img-rel-2.compuserve.com [149.174.206.155]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69KAmg00951 for ; Mon, 9 Jul 2001 16:10:48 -0400 (EDT) Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id QAA09470 for ips@ece.cmu.edu; Mon, 9 Jul 2001 16:10:42 -0400 (EDT) Received: from compuserve.com (dal-tgn-tvn-vty65.as.wcom.net [206.175.228.65]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id QAA09433; Mon, 9 Jul 2001 16:10:30 -0400 (EDT) Message-ID: <3B4A10B5.5AADC255@compuserve.com> Date: Mon, 09 Jul 2001 15:14:45 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: "'Binford, Charles'" CC: Sudhir Srinivasan , ips@ece.cmu.edu Subject: Re: FCIP Multiple Connection Management References: <63616B261CEFD411834D00D0B7A86CF7113F43@LUCY> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Charles, Sudhir, Please examine the title and first paragraph of Annex C (which encompasses pages 39 to 44). "ANNEX E - FC-BB-2 Inputs "This annex contains text from previous FCIP drafts that, because of the new model structure, probably belongs in FC-BB-2 [4]. As soon as the correctness of this annex is agreed, its contents will be transferred to a T11 document do be used in the development of FC-BB-2." The correctness of the annex (such as it is) has been agreed among the FCIP authors and the content of the annex can now be found at: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-342v0.pdf The annex will not appear in FCIP revision 04. I cannot guarantee that discussions on this reflector will be considered by T11 in its deliberations over FC-BB-2, although they probably will. Thanks. Ralph... Sudhir Srinivasan wrote: > > > Charles, > > Agree 100% - this was discussed in the following thread, > although, to my recollection, we did not explicitly > state a consensus and the text is still found in > Annex E of rev 0.3. > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04662.html > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Monday, July 09, 2001 12:25 PM > > To: ips@ece.cmu.edu > > Subject: FCIP Multiple Connection Management > > > > > > From pages 41-42 of FCIP rev 03 > > ******************************************* > > 5.5 Multiple Connection Management > > > > A pair of FCIP device endpoints MAY establish a certain number of > > TCP connections between them. Since a Virtual ISL > > potentially maps a > > fairly large number of FC flows (where a flow is a pair of Fibre > > Channel S_ID, D_ID addresses), it may not be practical to > > establish > > a separate TCP connection for each Fibre Channel flow. In order to > > address this, an implementation MAY choose to manage a pool of TCP > > connections for a single Virtual ISL and map Fibre Channel > > flows to > > TCP connections of that ISL. However, while assigning > > Fibre Channel > > flows to TCP connections, an implementation SHALL follow the > > following rules: > > > > 1) Once a Fibre Channel flow is assigned to a TCP > > connection within > > the virtual ISL, it SHALL send all Fibre Channel > > frames of that > > flow on that connection. > > > > 2) When an FCIP endpoint processes any response traffic from a > > particular target, the Endpoint SHALL send the response on the > > same connection on which the request was sent. > > > > 3) Any class 2 ACK frames SHALL be sent on the same connection in > > which the original frame was sent. > > > > These rules are in place to honor any in-order delivery guarantees > > that may have been made between the two end points of the Fibre > > Channel flow. > > ************************************* > > > > Given the above rules, consider the following: > > |-----| |-----| > > -------- |FCIP |--TCP_Con_1--|FCIP | ------- > > FC_Node_A -------|FC-SW |--|Dev1 |--TCP_Con_2--|Dev2 |---|FC-SW| ---- > > FC_NODE_B > > -------- |-----| |-----| ------- > > > > FCIP devices 1 and 2 have a single Virtual ISL composed of > > two separate TCP > > connections. Assume FC_NODE_A and FC_NODE_B both send PLOGI > > to each other > > at approximately the same time. FCIP_Dev1 happens to choose > > TCP_Con_1 for > > the FC Flow of S_ID_A-to-D_ID_B. FCIP_Dev2 happens to choose > > TCP_Con_2 for > > the FC Flow of S_ID_B-to-D_ID_A. So far so good, both FCIP > > devices are > > following the above rules. > > > > Now, FC_Node_A sends the PLOGI ACC. What is FCIP_Dev1 > > supposed to do? Rule > > 1 says choose TCP_Con_1 (this is the S_ID_A-to-D_ID_B flow > > and that flow has > > already been established to be TCP_Con_1). Rule 2 says > > choose TCP_Con_2 > > (this is a response to a frame that was received on TCP_Con_2). > > > > I believe rules 2 and 3 are not needed. What the combination > > of all three > > rules really say is there must be a defined negotiation or > > hash algorithm > > that both FCIP_dev 1 and 2 have to follow to keep all of the > > traffic between > > FC_Node_A and B on the same TCP connection. I believe this is totally > > unnecessary. > > > > If both sides obey only rule 1 then "any in-order delivery > > guarantees that > > may have been made between the two end points of the Fibre > > Channel flow" > > will still be met. > > > > Charles Binford > > Pirus Networks > > From owner-ips@ece.cmu.edu Mon Jul 9 18:49:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00379 for ; Mon, 9 Jul 2001 18:49:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69L3Ft05263 for ips-outgoing; Mon, 9 Jul 2001 17:03:15 -0400 (EDT) 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 f69L3Eg05258 for ; Mon, 9 Jul 2001 17:03:14 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA01007; Mon, 9 Jul 2001 17:03:02 -0400 (EDT) Message-ID: <3B4A1ADB.8FD58F44@cisco.com> Date: Mon, 09 Jul 2001 15:58:03 -0500 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: Stephen Bailey CC: ips@ece.cmu.edu Subject: Re: iSCSI: Iterating long text responses References: <3B3CE28C.F9748D5C@cisco.com> <20010706150620.283C14E8C@sandmail.sandburst.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steph- Comments are below. -- Mark Stephen Bailey wrote: > > > Please indicate which solution (#4 or #5) appeals to you. > > Well, this makes a hearty assumption.... > > I believe 4 completely misses the point. The initiator will still > have no control over the resource requirements to swallow the target's > responses. This is bad both for the initiator and the target since it > can flow-control the connection. For iSCSI to work well, you must > make sure that the connection is kept `lively' (connection-level flow > control is not engaged). Absolutely true. > Solution #5 is better, but you still have an irritating problem > dealing with what happens when the response length is larger than your > reserved resources. Also true, but at least the initiator is in control of the amount of data it receives; the target must not send more than was requested, and simply indicates the amount of data the would have been available had the initiator been able to receive it. > I believe in #2. If we specify that each text PDU results in at most > one response PDU, that gives you effective control over the resources > required for text messages. Then, on a case-by-case basis, you build > a protocol for addressing this limitation within its confines. In the > case if SendTargets, we use an iterator. > > In the case of each X-* operation, the protocol is chosen to meet the > needs of the operation. The reason why you don't want to solve this > problem `in general' (which we haven't actually done with any of these > solutions anyway) for everybody is because `everybody' has different > needs. Some actions of X-* are NOT going to be idempotent, and the > vendor (or whomever) may want to build an exactly-once protocol which > works across connections, and on recovered sessions. Other cases, > might want at-most-once semantics, and yet other cases, unreliable, > best-effort. > > It's too painful (and pointless) for us to build an exactly-once > protocol for text messages when the only specified application is > SendTargets, which doesn't need exactly-once semantics. > > What you're trying to provide is the equivalent of general IP > fragmentation. For application purposes (as opposed to network > purposes), IP fragmentation just gets in the way. Provide a basic > datagram capability the upper layer can build everything else as > necessary. Your arguments for #2 do make sense. However, The reason I had favored #5 over #2 is that I felt 5 would be simpler; subject to occasional flow control for a large response (which I hope will be rare), the target does not have to keep track of where it was during the response. Sending messages fragmented in this way is very simple, although it might make receiving and piecing them together more difficult. This didn't really bother me, though; I'd rather put more of the burden on the initiator than on the target for anything discovery- related, since the target is not in control of when and how often this happens. Anyway, #2 would work fine as well, but again, I'd really like to avoid keeping state on the target. -- Mark > If the application heavy data transfer services, it should use SCSI > directly. This is already a tradition within SCSI architecture. Agreed. > Steph -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 9 18:50:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00418 for ; Mon, 9 Jul 2001 18:50:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69Kpoo04310 for ips-outgoing; Mon, 9 Jul 2001 16:51:50 -0400 (EDT) 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 f69Kpng04306 for ; Mon, 9 Jul 2001 16:51:49 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA03821; Mon, 9 Jul 2001 16:49:06 -0400 (EDT) Message-ID: <3B4A1797.EBE52849@cisco.com> Date: Mon, 09 Jul 2001 15:44:07 -0500 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: Santosh Rao CC: ips Subject: Re: iSCSI: Iterating long text responses References: <200107051921.MAA04104@hpcuhe.cup.hp.com> <3B44C08C.8F4E4858@cisco.com> <3B44D6E5.F86F90ED@cup.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh- Good point; I guess a relative offset would be useful for an implementation that does this. It would be used only for error checking, and not for recovery. I like this better than the other two alternatives you had mentioned. So I have to take back my response to Rod as well. The new wording of the second paragraph of 1.2.5 should take care of text commands: If an iSCSI request is issued over one TCP connection, the corresponding response or requested PDU MUST be sent over the same connection. We call this "connection allegiance". Anyway, if we end up with #5, I will suggest the addition of a relative offset in the text response as well. -- Mark Santosh Rao wrote: > > Mark Bakke wrote: > > > > Santosh- > > > > I was making the assumption that a text command stayed on a single > > connection, and response PDUs from the target would be in-order, > > and that if the connection failed, the target would throw away any > > results it hadn't yet sent, and the initiator would just completely > > re-do the command. > > Mark, > > The CRC error checking and the Text command processing may be handled in > different layers > of the iSCSI stack (CRC in hardware, text command in firmware or > software), with CRC errors causing a discard of the errant PDU alone. > Thus, upon receipt of the final Text Response PDU the layer handling the > Text command may not be aware that 1 PDU of the returned set of > responses was lost. > > Some ways to address this would be : > a. usage of a RO in each Text Response PDU. > b. a count of the number of Text Response PDUs sent in the final Text > Response ("f=1"). > c. A sequence count applied to all multi-PDU text sequences. > > In addition, the spec needs to explicitly word the "connection > allegiance" description to apply to all iSCSI commands, and not just > SCSI commands. > > > This meant we wouldn't need an offset, since > > the initiator would have to receive them in order anyway. > > The offset is required to ensure integrity of the response received. > > Regards, > Santosh > > > However, > > it certainly wouldn't hurt to add the offset. I guess I am just > > concerned that if we do, then someone will want to make use of the > > field to be able to send text responses out of order, or to recover > > them on another connection, and so on, so I would rather leave them > > out unless we really need them. How badly are they needed? > > > > -- > > Mark > > > > Santosh Rao wrote: > > > > > > Mark, > > > > > > IMO, alternative #4 is sufficient and is semantically aligned with the > > > FC-GS-2/GS-3 GID_FT model. > > > > > > It does require modification of the Text Response PDU to provide a > > > Relative Offset (RO) field indicating the RO of the text response > > > PDU from the start of the text response payload, in order to allow initiators > > > to correctly re-assemble the received response PDUs. > > > > > > Regards, > > > Santosh > > > > > > Mark Bakke wrote: > > > > > > > > > 4. Allow multiple response PDUs to a single text command: > > > > > > > > I->T Text Command (F bit set) > > > > T->I Text Response (first PDU, F bit cleared) > > > > T->I Text Response (next PDU, F bit cleared) > > > > > > > > ... > > > > > > > > T->I Text Response (last PDU, F bit set) > > > > > > > > Basically, we are doing (3) without the R2T. The initiator, > > > > upon sending the text command, must be prepared either to > > > > accept as many PDUs as come back, or throw them away if it > > > > can't handle them. This solution is a lot like #1, but with > > > > the response spread across 4k PDUs. > > > > > > > > Also note that this (and the following scheme) avoid the problem > > > > of the target keeping state; it sends ALL of the response PDUs > > > > without the initiator asking for them. > > > > > > > > 5. Do #4, but allow the initiator to specify the amount of data > > > > it is willing to accept: > > > > > > > > I->T Text Command (F bit set, AcceptResponseLength=4096) > > > > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > > > > > > > In the above example, we have created a new text command field: > > > > > > > > AcceptResponseLength > > > > > > > > And in the text response PDU: > > > > > > > > TotalResponseLength > > > > > > > > The initiator indicated it was willing to accept a 4k response. > > > > The target returned the first 4k in the text response, but set > > > > the F bit since it was at its limit. It also returned a > > > > TotalResponseLength field. Since this was greater than the > > > > AcceptResponseLength, the initiator knows the amount of buffer > > > > space it will need to get the full response. It can then choose > > > > whether it will re-send the command, and if so, can give it a > > > > large enough response length: > > > > > > > > I->T Text Command (F bit set, AcceptResponseLength=12288) > > > > T->I Text Response (first PDU, F bit clear) > > > > T->I Text Response (next PDU, F bit clear) > > > > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > > > > > > > Note that most initiators will probably send an AcceptResponseLength > > > > of the largest response they would normally accept, and that most > > > > target responses will fit in one or a few PDUs anyway. > > > > > > > > #5 is really a compromise between #3 and #4; the target has the > > > > benefit of being less statefull, and the initiator has the benefit > > > > of controlling the amount of data it receives. > > > > > > > > I would like to recommend either #4 or #5. I think that #5 is > > > > probably the safest solution, but #4 may not be a problem for anyone. > > > > > > > > Assuming that none of the implementors of initiators have a problem > > > > with #4, I would pick that. > > > > > > > > If they do have a problem with it, we should go with #5. > > > > > > > > Targets probably don't care much whether we do #4 or #5. > > > > > > > > Initiator developers- > > > > > > > > Please indicate which solution (#4 or #5) appeals to you. > > > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 9 19:48:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01380 for ; Mon, 9 Jul 2001 19:48:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69M2RZ09596 for ips-outgoing; Mon, 9 Jul 2001 18:02:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pdc.dinocom.com (dns1.dinocom.com [66.59.159.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69LfQg07993 for ; Mon, 9 Jul 2001 17:41:27 -0400 (EDT) Received: from perfisan4 ([207.139.124.38] unverified) by pdc.dinocom.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 9 Jul 2001 17:41:11 -0400 Reply-To: From: "Trang Nguyen" To: , , Cc: "Trang Nguyen" Subject: iSCSI Framing Formats Date: Mon, 9 Jul 2001 17:43:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 09 Jul 2001 21:41:12.0192 (UTC) FILETIME=[DF579800:01C108BF] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello everyone, I've read your discussion about how to find iSCSI PDU header from the TCP stream at the receiving end. There are 2 different approaches with various ways: 1. TCP unaware approach suggests: periodic marker, fixed length messages, byte stuffing, chunks. 2. TCP aware approach suggests: Urgent pointer, and PSH bit. I found that there are some objections about using Urgent point and PSH bit because the TCP has to be modified. The iSCSI internet draft suggests the use of periodic marker. The problem with the periodic marker in the iSCSI I-D is that both initiator and target have to agree on the marker. "In certain environments a sender not willing to supply markers to a receiver willing to accept marker MAY suffer from a considerable performance degradation." (draft-ietf-ips-iscsi-06.txt). I am just wondering if any method of iSCSI framing has been finalized yet? What is the status of this issue? Will the next version of iSCSI I-D have more information about it? Thank you in advance for your reply, Trang Nguyen From owner-ips@ece.cmu.edu Mon Jul 9 20:36:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02341 for ; Mon, 9 Jul 2001 20:36:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69JgIm28580 for ips-outgoing; Mon, 9 Jul 2001 15:42:18 -0400 (EDT) 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 f69JgGg28575 for ; Mon, 9 Jul 2001 15:42:16 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA21615; Mon, 9 Jul 2001 15:42:09 -0400 (EDT) Message-ID: <3B4A07E6.888117E7@cisco.com> Date: Mon, 09 Jul 2001 14:37:10 -0500 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: Rod Harrison CC: IPS Subject: Re: iSCSI: Iterating long text responses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod- I don't see where option #4 is any better than option #5, since 5 is the same as 4, but with the initiator able to restrict the amount of data returned. The response is still sent back in multiple text response PDUs, just as in #4. I don't think that out-of-order PDUs are a problem, since the text command would have connection allegiance. I think that we should explicitly state that text commands are not to be recovered if something goes wrong. That would eliminate the need for a text response sequence number. -- Mark Rod Harrison wrote: > > Mark, > > It was more of a general concern for the iterative process > than thoughts of a specific non-idempotent text command. If > text commands are ever used in an IOCTL like capacity we > might run into problems, but as you say there are probably > better ways to do that sort of thing, like Mode Select. > > I would still prefer to have the initiator able to pace the > receipt of, and prematurely end, large text responses but I > understand this may be too expensive for some targets. > > Requiring the initiator to allocate an arbitrarily large > buffer for #5 is a little concerning, especially since it > seems that could be larger than the negotiated max PDU size. > For that reason I would prefer option #4 over #5, but I > think we'll need to add a sequence number to the text > response to allow the initiator to detect out of order PDUs. > > - Rod > > -----Original Message----- > From: mbakke@cisco.com [mailto:mbakke@cisco.com] > Sent: Thursday, July 05, 2001 3:11 PM > To: Rod Harrison > Cc: IPS > Subject: Re: iSCSI: Iterating long text responses > > Rod- > > You are correct that this assumes that the initiator can do > the same text command multiple times. I think that the real > question is whether attempting to allow non-idempotent text > commands, and providing easier mechanisms for doing them is > a requirement. > > If so, your addition to #3 would work. > > If not, it would place unnecessary burden on the target. > > At the moment, I can't think of much that would need to be > added to iSCSI from a (non-negotiation) text command point > of view. In fact, we are supposed to be careful to limit > what can be done in this way, since most other functionality > we can envision should be left to other standard protocols. > > Any thoughts on specific uses for non-idempotent text > commands? > > -- > Mark > > Some more comments: > > Rod Harrison wrote: > > > > We have a concern over option #5, the outline > below assumes > > that it is safe to issue the same text command more than > > once with no side effects. This does seem safe for the > > current use of SendTargets, however it might not be if > this > > mechanism is extended for other long response text > commands. > > True; SendTargets doesn't care. However, we seem to have a > general consensus that the use of text commands should be > carefully limited; what are the real chances that some > functionality comes along that we really need, and that does > not fit in? I don't see that really happening. > > > Our preference would be for option #3 with #4 a > close > > second. Number 4 has the disadvantage that the initiator > has > > to deal with a stream of unsolicited text responses with > no > > idea of when they might stop. > > Actually, an initiator can do the same thing with #4 as with > #5; > it could issue the text command, and just keep track of the > number > of bytes of response that it was unable to keep. It could > then > allocate enough space, and re-do the request. #5 is just a > cleaner > mechanism to do this. > > At any rate, the burden is on the initiator as to whether it > wants to make use of these mechanisms. > > > Perhaps #3 with the following modifications might > suffice. > > > > Add an offset to the initiator R2T (iR2T?) > allowing the > > target to choose to either buffer the whole response or > > regenerate it on the fly. The target should know whether > the > > data can be regenerated safely and so can make this > > decision. > > > > Add a final bit to the iR2T allowing the initiator > to stop > > the response transfer at any time. Mandate that the > > initiator must either receive all the data or send an iR2T > > with final bit set to indicate no more data is required. > > This prevents a target getting stuck with the response > data > > in a buffer forever. > > > > A typical transfer might be. > > > > I->T Text command (F bit set) > > T->I Text response (F bit clear) > > I->T iR2T incl. valid offset and length (F bit > clear) > > T->I Text response (F bit clear) > > > > .... > > > > Sequence either ends with > > > > T->I Text response (F bit set) > > > > or > > > > I->T iR2T Offset 0, length 0, (F bit set) > > > > Since the first text response is unsolicited all > current > > text command implementations can remain unchanged. Only if > > the target responds with the F bit clear does the > initiator > > need to change. > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On > > Behalf Of > > Mark Bakke > > Sent: Friday, June 29, 2001 9:18 PM > > To: IPS > > Subject: iSCSI: Iterating long text responses > > > > Initiator developers- > > > > Please respond to the questions at the end. > > > > Thanks, > > > > Mark > > > > The current iSCSI draft allows text command and response > > PDUs of up to 4096 bytes. While we don't see any real > > problems for the command PDU size, commands such as > > SendTargets > > can easily exceed the response size. > > > > There are several ways we can fix this. The first two > > solutions > > require no differences in the current iSCSI text command > and > > response; the latter three involve the use of the F bit. > > > > 1. Assume that such commands are done on a "special" > > connection > > or are handled completely in software, and allow its > > response > > PDU to be as large as it needs to be. > > > > This one appears too restrictive to be a solid > solution. > > It > > will also weaken any data digests done on the longer > PDU. > > > > 2. Create an iterative SendTargets key (and do the same > for > > any > > other text commands that need this), that would allow > the > > initiator to request the "next target" or "next > address". > > > > This would work, but would require any new command that > > needed > > a large response to implement an iterator. It also > means > > that > > each part of the response from the iterator would have > to > > fit > > in the 4k PDU. > > > > The remainder of these require that only one text command > > sequence > > be outstanding on a connection at a given time. They use > > the F > > bit to indicate the last PDU of the sequence. Note that > > connection > > allegiance is assumed for the entire sequence, and text > > commands > > are never retried on another connection; a new command is > > issued > > instead. > > > > 3. Do a text-response R2T, where the initiator controls > when > > the > > next partial response is sent. This would be more > > generic: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > I->T Text Command (with some indicator that we want > > more) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > I->T Text Command (with indicator that we want more) > > T->I Text Response (last PDU, F bit set) > > > > The main problem with this is that the target must keep > > track > > of the state of its responses; if the initiator just > > stops asking, > > it may have to keep a buffered response around until it > > times out, > > the connection is dropped, or another text command > comes > > along. > > > > 4. Allow multiple response PDUs to a single text command: > > > > I->T Text Command (F bit set) > > T->I Text Response (first PDU, F bit cleared) > > T->I Text Response (next PDU, F bit cleared) > > > > ... > > > > T->I Text Response (last PDU, F bit set) > > > > Basically, we are doing (3) without the R2T. The > > initiator, > > upon sending the text command, must be prepared either > to > > accept as many PDUs as come back, or throw them away if > > it > > can't handle them. This solution is a lot like #1, but > > with > > the response spread across 4k PDUs. > > > > Also note that this (and the following scheme) avoid > the > > problem > > of the target keeping state; it sends ALL of the > response > > PDUs > > without the initiator asking for them. > > > > 5. Do #4, but allow the initiator to specify the amount of > > data > > it is willing to accept: > > > > I->T Text Command (F bit set, > AcceptResponseLength=4096) > > T->I Text Response (first PDU, F bit set, > > TotalResponseLength=12288) > > > > In the above example, we have created a new text > command > > field: > > > > AcceptResponseLength > > > > And in the text response PDU: > > > > TotalResponseLength > > > > The initiator indicated it was willing to accept a 4k > > response. > > The target returned the first 4k in the text response, > > but set > > the F bit since it was at its limit. It also returned > a > > TotalResponseLength field. Since this was greater than > > the > > AcceptResponseLength, the initiator knows the amount of > > buffer > > space it will need to get the full response. It can > then > > choose > > whether it will re-send the command, and if so, can > give > > it a > > large enough response length: > > > > I->T Text Command (F bit set, > > AcceptResponseLength=12288) > > T->I Text Response (first PDU, F bit clear) > > T->I Text Response (next PDU, F bit clear) > > T->I Text Response (last PDU, F bit set, > > TotalResponseLength=12288) > > > > Note that most initiators will probably send an > > AcceptResponseLength > > of the largest response they would normally accept, and > > that most > > target responses will fit in one or a few PDUs anyway. > > > > #5 is really a compromise between #3 and #4; the target > > has the > > benefit of being less statefull, and the initiator has > > the benefit > > of controlling the amount of data it receives. > > > > I would like to recommend either #4 or #5. I think that > #5 > > is > > probably the safest solution, but #4 may not be a problem > > for anyone. > > > > Assuming that none of the implementors of initiators have > a > > problem > > with #4, I would pick that. > > > > If they do have a problem with it, we should go with #5. > > > > Targets probably don't care much whether we do #4 or #5. > > > > Initiator developers- > > > > Please indicate which solution (#4 or #5) appeals to > you. > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 9 20:56:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02683 for ; Mon, 9 Jul 2001 20:56:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69NJ0o14479 for ips-outgoing; Mon, 9 Jul 2001 19:19:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dominoe.integrix.com ([207.171.9.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69NIwg14474 for ; Mon, 9 Jul 2001 19:18:58 -0400 (EDT) Received: from MIKES (mparkhurst [192.9.200.139]) by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA26000; Mon, 9 Jul 2001 16:17:57 -0700 (PDT) Reply-To: From: "Mike Parkhurst" To: , , , Subject: RE: iSCSI Framing Formats Date: Mon, 9 Jul 2001 16:23:54 -0700 Organization: Integrix Corporation Message-ID: <000c01c108ce$3968cfe0$8bc809c0@MIKES> 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, Build 10.0.2627 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: 7bit Hello All, I've had the same thoughts after reading the spec. Pardon my lack of knowledge as to the previous discussions, but why not use a framing bit pattern as a marker? Pick some 32 bit number, anything but all zeros or ones would work, and prefix each header with it. If there is a packet loss then the receiver can scan for the next "possible" marker. Once a marker pattern is found the receiver then does a sanity check on the header. If it passes then the receiver is re-synced. If not then the search continues until a valid marker & header is found. Mike Parkhurst -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Trang Nguyen Sent: Monday, July 09, 2001 1:44 PM To: ips@ece.cmu.edu; julian_satran@il.ibm.com; steph@cs.uchicago.edu Cc: Trang Nguyen Subject: iSCSI Framing Formats Hello everyone, I've read your discussion about how to find iSCSI PDU header from the TCP stream at the receiving end. There are 2 different approaches with various ways: 1. TCP unaware approach suggests: periodic marker, fixed length messages, byte stuffing, chunks. 2. TCP aware approach suggests: Urgent pointer, and PSH bit. I found that there are some objections about using Urgent point and PSH bit because the TCP has to be modified. The iSCSI internet draft suggests the use of periodic marker. The problem with the periodic marker in the iSCSI I-D is that both initiator and target have to agree on the marker. "In certain environments a sender not willing to supply markers to a receiver willing to accept marker MAY suffer from a considerable performance degradation." (draft-ietf-ips-iscsi-06.txt). I am just wondering if any method of iSCSI framing has been finalized yet? What is the status of this issue? Will the next version of iSCSI I-D have more information about it? Thank you in advance for your reply, Trang Nguyen From owner-ips@ece.cmu.edu Mon Jul 9 21:02:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02775 for ; Mon, 9 Jul 2001 21:02:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f69NRSt15057 for ips-outgoing; Mon, 9 Jul 2001 19:27:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f69NRQg15052 for ; Mon, 9 Jul 2001 19:27:26 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id 2DC4AC67; Mon, 9 Jul 2001 16:27:25 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay2.corp.hp.com (Postfix) with ESMTP id DEF6D1F525; Mon, 9 Jul 2001 16:26:25 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id <3PHKZPGJ>; Mon, 9 Jul 2001 16:27:23 -0700 Message-ID: <499DC368E25AD411B3F100902740AD65BC5B73@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: "'tnguyen@perfisans.com'" , ips@ece.cmu.edu, julian_satran@il.ibm.com, steph@cs.uchicago.edu Cc: "WENDT,JIM (HP-Roseville,ex1)" Subject: RE: iSCSI Framing Formats Date: Mon, 9 Jul 2001 16:27:20 -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 > From: Trang Nguyen [mailto:tnguyen@perfisans.com] > .... > I am just wondering if any method of iSCSI framing has been > finalized yet? > What is the status of this issue? Will the next version of > iSCSI I-D have > more information about it? > Trang, The Framing and Error Recovery design teams met recently to discuss the framing issue and possible solutions. We should be posting a summary of the outcomes from this meeting within the next few days for IPS discussion. > Thank you in advance for your reply, > > > Trang Nguyen > Regards, Jim Wendt Networked Storage Architecture / NSSO Hewlett-Packard Company jim_wendt@hp.com 916-785-5198 From owner-ips@ece.cmu.edu Mon Jul 9 22:21:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04587 for ; Mon, 9 Jul 2001 22:21:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6A0dZb19244 for ips-outgoing; Mon, 9 Jul 2001 20:39:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6A0dXg19239 for ; Mon, 9 Jul 2001 20:39:33 -0400 (EDT) Received: from lose (64-171-32-198.netliant.com [64.171.32.198] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with SMTP id RAA22049 for ; Mon, 9 Jul 2001 17:39:39 -0700 From: "Nate Lawson" To: Subject: RE: iSCSI Framing Formats Date: Mon, 9 Jul 2001 17:38:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit FYI, I don't know which approach has been decided either. > -----Original Message----- > From: owner-ips@ece.cmu.edu On Behalf Of Trang Nguyen > I've read your discussion about how to find iSCSI PDU header from the TCP > stream at the receiving end. There are 2 different approaches > with various ways: > > 1. TCP unaware approach suggests: periodic marker, fixed length messages, > byte stuffing, chunks. I recommend these, and in particular, TLV headers (Type, Length, Value). TLV headers are used for IP options, for instance. Fixed length usually implies overhead for short messages, periodic marker implies the need to escape inband data, etc. Finally, these other approaches aren't expandable for future standards. > 2. TCP aware approach suggests: Urgent pointer, and PSH bit. > I found that there are some objections about using Urgent point > and PSH bit because the TCP has to be modified. Terrible. There is no agreement on the meaning of the UP and all stacks that I know of ignore PSH as well as there being no user-level way of setting it on any OS I've used. I'm curious too. What approach(es) are supported? -Nate From owner-ips@ece.cmu.edu Mon Jul 9 22:23:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04623 for ; Mon, 9 Jul 2001 22:23:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6A1gUi23004 for ips-outgoing; Mon, 9 Jul 2001 21:42:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web10406.mail.yahoo.com (web10406.mail.yahoo.com [216.136.130.98]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6A08qg17482 for ; Mon, 9 Jul 2001 20:08:53 -0400 (EDT) Message-ID: <20010710000851.23236.qmail@web10406.mail.yahoo.com> Received: from [198.95.226.224] by web10406.mail.yahoo.com via HTTP; Mon, 09 Jul 2001 17:08:51 PDT Date: Mon, 9 Jul 2001 17:08:51 -0700 (PDT) From: Mohan Srinivasan Subject: Draft version 6 iSCSI initiators... To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk A question for iSCSI initiator developers planning on attending the UNH interoperability testing event - Does anyone have a draft version 6 compliant iSCSI initiator (preferably Linux) that folks working on version 6 targets can test against ? The publicly available initiators (UNH, Intel etc) are all version 3 based. We're working on a version 6 target implementation and plan to attend the interoperability event. But we would like to do some debugging/testing against a version 6 initiator before the event. thanks mohan __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Mon Jul 9 22:28:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04662 for ; Mon, 9 Jul 2001 22:28:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6A1C5l21219 for ips-outgoing; Mon, 9 Jul 2001 21:12:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6A1C3g21215 for ; Mon, 9 Jul 2001 21:12:04 -0400 (EDT) Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.148]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6A1C1804380 for ; Mon, 9 Jul 2001 21:12:02 -0400 (EDT) Message-Id: <200107100112.f6A1C1804380@chmls06.mediaone.net> To: ips@ece.cmu.edu Subject: Re: iSCSI: Iterating long text responses In-Reply-To: Message from Mark Bakke of "Mon, 09 Jul 2001 15:58:03 CDT." <3B4A1ADB.8FD58F44@cisco.com> References: <3B3CE28C.F9748D5C@cisco.com> <20010706150620.283C14E8C@sandmail.sandburst.com> <3B4A1ADB.8FD58F44@cisco.com> Date: Mon, 09 Jul 2001 21:11:33 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, > Anyway, #2 would work fine as well, but again, I'd really like > to avoid keeping state on the target. You have to keep state on lots of state at this granularity (per session/connection) on the target anyway. All this would require is an integer index into your target list table (which you obviously have in some form to respond to SendTargets at all...) One might suggest a variant of #5 with an initial offset argument to the request, so you could get `what's left', but that really does create a state problem. With the simple iterator at least you know that every return is (or was) a complete target description. But then again, what do I know? [this list is like driving, cf. Repo Man] Certainly doing #5 would not leave a criminal hole in the spec. Neither would it probably be used in general by X-* operations. Steph From owner-ips@ece.cmu.edu Tue Jul 10 03:37:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24788 for ; Tue, 10 Jul 2001 03:37:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6A5waG08095 for ips-outgoing; Tue, 10 Jul 2001 01:58:36 -0400 (EDT) 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 f6A5wYg08090 for ; Tue, 10 Jul 2001 01:58:34 -0400 (EDT) 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 HAA131824; Tue, 10 Jul 2001 07:58:19 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6A5wGb83116; Tue, 10 Jul 2001 07:58:16 +0200 Importance: Normal Subject: RE: iSCSI Framing Formats To: mike@integrix.com Cc: "tnguyen" , "ips" , "steph" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 10 Jul 2001 09:04:12 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 10/07/2001 07:58:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mike & All, We don't want this thread to be started again in this forum. For anything related to framing go to the TSWG or to the RDMA mailing list. Julo "Mike Parkhurst" on 10-07-2001 02:23:54 Please respond to mike@integrix.com To: tnguyen@perfisans.com, ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL, steph@cs.uchicago.edu cc: Subject: RE: iSCSI Framing Formats Hello All, I've had the same thoughts after reading the spec. Pardon my lack of knowledge as to the previous discussions, but why not use a framing bit pattern as a marker? Pick some 32 bit number, anything but all zeros or ones would work, and prefix each header with it. If there is a packet loss then the receiver can scan for the next "possible" marker. Once a marker pattern is found the receiver then does a sanity check on the header. If it passes then the receiver is re-synced. If not then the search continues until a valid marker & header is found. Mike Parkhurst -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Trang Nguyen Sent: Monday, July 09, 2001 1:44 PM To: ips@ece.cmu.edu; julian_satran@il.ibm.com; steph@cs.uchicago.edu Cc: Trang Nguyen Subject: iSCSI Framing Formats Hello everyone, I've read your discussion about how to find iSCSI PDU header from the TCP stream at the receiving end. There are 2 different approaches with various ways: 1. TCP unaware approach suggests: periodic marker, fixed length messages, byte stuffing, chunks. 2. TCP aware approach suggests: Urgent pointer, and PSH bit. I found that there are some objections about using Urgent point and PSH bit because the TCP has to be modified. The iSCSI internet draft suggests the use of periodic marker. The problem with the periodic marker in the iSCSI I-D is that both initiator and target have to agree on the marker. "In certain environments a sender not willing to supply markers to a receiver willing to accept marker MAY suffer from a considerable performance degradation." (draft-ietf-ips-iscsi-06.txt). I am just wondering if any method of iSCSI framing has been finalized yet? What is the status of this issue? Will the next version of iSCSI I-D have more information about it? Thank you in advance for your reply, Trang Nguyen From owner-ips@ece.cmu.edu Tue Jul 10 11:28:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03670 for ; Tue, 10 Jul 2001 11:28:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ADqLD15718 for ips-outgoing; Tue, 10 Jul 2001 09:52:21 -0400 (EDT) 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 f6ADqJg15698 for ; Tue, 10 Jul 2001 09:52:20 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 09:50:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709E3@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Interim meeting plans Date: Tue, 10 Jul 2001 09:48:26 -0400 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 This is not definite yet, as there are still details to work out, so it might change. We are tentatively planning an IPS WG interim meeting for August 27-28 in Orange County, CA. The idea is to spend one day on Fibre Channel-related work and one day on Security (iSCSI/FCIP/iFCP). Details will be posted when they're available. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 11:31:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03889 for ; Tue, 10 Jul 2001 11:31:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ADhJh15023 for ips-outgoing; Tue, 10 Jul 2001 09:43:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6ADhIg15017 for ; Tue, 10 Jul 2001 09:43:18 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3G69QDT7>; Tue, 10 Jul 2001 09:43:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709DF@corpmx14.us.dg.com> From: Black_David@emc.com To: uri@broadcom.com Cc: ips@ece.cmu.edu Subject: RE: Cleaned up iSCSI security requirements text Date: Tue, 10 Jul 2001 09:39:17 -0400 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 cc:'ing the list on a question of general interest ... > I need to satisfy my curiosity, so I'd like to ask you why is it that "Data > origin authentication' is not optional or negotiable? I'm not aware of any > other IETF protocol that mandates use of security in this way. Pls don't > take to be a position for/against it. It's pure curiosity at this point The current status is that it's mandatory to implement due to threats such as TCP hijacking. It's optional to use, and I need to make sure the revised draft makes this clear. Good catch. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 12:28:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07171 for ; Tue, 10 Jul 2001 12:28:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AEcw819529 for ips-outgoing; Tue, 10 Jul 2001 10:38:58 -0400 (EDT) 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 f6AEcug19520 for ; Tue, 10 Jul 2001 10:38:56 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 10:37:29 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709E5@corpmx14.us.dg.com> From: Black_David@emc.com To: ENDL_TX@computer.org Cc: ips@ece.cmu.edu Subject: FCIP Annex E Date: Tue, 10 Jul 2001 10:35:01 -0400 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 > Please examine the title and first paragraph of Annex C > (which encompasses pages 39 to 44). > > "ANNEX E - FC-BB-2 Inputs > > "This annex contains text from previous FCIP drafts that, > because of the new model structure, probably belongs in > FC-BB-2 [4]. As soon as the correctness of this annex is > agreed, its contents will be transferred to a T11 document > do be used in the development of FC-BB-2." > > The correctness of the annex (such as it is) has been agreed > among the FCIP authors and the content of the annex can now > be found at: > > ftp://ftp.t11.org/t11/pub/fc/bb-2/01-342v0.pdf > > The annex will not appear in FCIP revision 04. > > In at attempt to make sure that we don't lose anything important in removing this text from the FCIP draft, here are some suggestions: E-4.3 FCIP's Interaction with FC and TCP {partial} This is about what happens when FCIP drops an FC frame for some reason (one of the checks in 6.6.2.2 failed). Annex D needs to place responsibility for recovery from this event on the FC entity, which may defer to something else (e.g., the FC entity may ignore this in favor of FCP or SCSI retry). A sentence in 6.6.2.2. pointing out where the responsibility for recovery lies and giving possible examples would be a useful addition to the last paragraph. E-5.3 TCP Connection Management E-5.5 Multiple Connection Management Some of the information in these sections probably needs to be in both FCIP and FC-BB-2. FCIP should contain information describing how TCP connections may be mapped to FC port connections (Section 7 in -03 is silent on this topic). The first paragraph of E-5.3 and most of E-5.5 fall into this category, although they should be generalized to avoid references to ISLs, E ports and B ports. The connection setup material in E-5.3 seems to be adequately covered in 7.1 and its subsections. E-5.4.1 Determining loss of connectivity {partial} Somewhere, possibly in Annex D, making the FC entity responsible for checking for loss of TCP connectivity ought to be enhanced by giving the HLO SW_ILS as an example of how this could be done without requiring it to be used. E-5.6 Multi Virtual ISL Management This looks like an FC fabric topology issue, and hence moving it to FC-BB-2 makes sense (IMHO). E-8.3 Corruption {partial} Most of this seems to be covered in 6.6.2.2, but noting that FC has the option to begin transmitting a frame and terminate that with an EOF invalidating the partially transmitted frame should be added. Annex D does not appear to capture the possible interactions between the FC and FCIP entities in this area - some more explanation of possibilities and responsibilities is needed. E-8.4 Timeouts {partial} The mechanism to deal with this is covered in 6.6.2.3, but that section would be considerably more readable if it included an explanation of what R_A_TOV and E_D_TOV govern and why only R_A_TOV needs to be enforced in FCIP. E-10.1 Flow control on FC network Section 7.4 covers this topic, but calling out FC Buffer-to-Buffer flow control as an example of how arrival of frames from the fabric can be controlled at the bottom of p.21 would improve readability. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 12:38:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07683 for ; Tue, 10 Jul 2001 12:38:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AFAiv22032 for ips-outgoing; Tue, 10 Jul 2001 11:10:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mxbh4.isus.emc.com (mxbh4.isus.emc.com [128.221.10.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AFAgg22028 for ; Tue, 10 Jul 2001 11:10:42 -0400 (EDT) Received: by mxbh4.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3G69QF00>; Tue, 10 Jul 2001 11:10:37 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709E7@corpmx14.us.dg.com> From: Black_David@emc.com To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Framing Formats Date: Tue, 10 Jul 2001 11:06:39 -0400 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 NOTE: iSCSI tag removed because there's FCIP-related material in this message. > We don't want this thread to be started again in this forum. > For anything related to framing go to the TSWG or to the RDMA mailing list. I think Julian may have jumped for that conclusion a little too quickly. Certainly, there are topics that belong on those mailing lists: - TCP-aware framing mechanisms are in the domain of TSVWG. Use of URG and PSH for framing is not going to happen. - RDMA mechanism discussions belong on the RDMA list - this is not an official IETF list. Beyond these, there are a couple of topics that are fair game for the IPS list: - TCP-unaware framing mechanisms intended for specification as part of an IPS protocol; this includes markers, as well as the synchronization recovery mechanism proposed for FCIP. - Discussion of appropriate requirements (e.g., should markers be specified as "MUST implement" with some additional rules about which end of a connection controls their usage on what traffic?). The requirements issue is definitely an open issue at this point in time. As for alternatives to markers, a fairly high level of rigor will be expected of approaches that scan data looking for some distinctive pattern - it basically needs to be the case that this sort of scan and detect algorithm cannot get confused by any pattern appearing in a data payload (read or write data for iSCSI). A motivating example to think about is where trace data that includes the distinctive pattern (e.g., from a sniffer) is being written to or read from a file. Byte and word stuffing mechanisms to ensure that the pattern the algorithm is looking for can't appear in data are one way to accomplish this, but there are others. While I'm on this topic, let me note that the algorithm in Annex A of the -03 FCIP draft does not meet this "cannot get confused" criterion. For FCIP, it is possible to meet this criterion without resorting to stuffing techniques - the basic idea is to scan enough incoming data so that there have to be valid headers in there, note every possible header found, and their relationships based on length fields. If the resulting situation is ambiguous/confusing, restart and/or abandon the attempt to re-establish synchronization. A considerably improved algorithm should appear in the -04 version of the FCIP draft based on some offline discussion with some of the draft authors. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 13:30:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10205 for ; Tue, 10 Jul 2001 13:30:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AFdgu24456 for ips-outgoing; Tue, 10 Jul 2001 11:39:42 -0400 (EDT) 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 f6AFdeg24451 for ; Tue, 10 Jul 2001 11:39:40 -0400 (EDT) Received: by LUCY with Internet Mail Service (5.5.2653.19) id <3H2SLLV6>; Tue, 10 Jul 2001 11:43:49 -0400 Message-ID: <63616B261CEFD411834D00D0B7A86CF7113F48@LUCY> From: Sudhir Srinivasan To: "'ENDL_TX@computer.org'" , "'Binford, Charles'" Cc: Sudhir Srinivasan , ips@ece.cmu.edu Subject: RE: FCIP Multiple Connection Management Date: Tue, 10 Jul 2001 11:43:46 -0400 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 > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Monday, July 09, 2001 4:15 PM > > ftp://ftp.t11.org/t11/pub/fc/bb-2/01-342v0.pdf > > The annex will not appear in FCIP revision 04. > > I cannot guarantee that discussions on this reflector will be > considered by T11 in its deliberations over FC-BB-2, although > they probably will. Ralph, Given the overlap in attendees at T11, I would hope some of the discussions on this reflector do carry over there. Assuming so, it would be good if we could have consensus on the allegiance rules - whether to drop rules 2 & 3 - before we delete the annex and forward the text to BB-2. The embedded author comments in the document listed above still leave this issue open - in other words, what exactly have the authors "agreed upon"? Regards, - Sudhir From owner-ips@ece.cmu.edu Tue Jul 10 15:13:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15799 for ; Tue, 10 Jul 2001 15:13:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AHL6s02047 for ips-outgoing; Tue, 10 Jul 2001 13:21:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dominoe.integrix.com ([207.171.9.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AHL4g02043 for ; Tue, 10 Jul 2001 13:21:04 -0400 (EDT) Received: from MIKES (mparkhurst [192.9.200.139]) by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA02858; Tue, 10 Jul 2001 10:18:00 -0700 (PDT) Reply-To: From: "Mike Parkhurst" To: Cc: Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 10:23:52 -0700 Organization: Integrix Corporation Message-ID: <001a01c10965$16f95370$8bc809c0@MIKES> 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, Build 10.0.2627 Importance: Normal In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0709E7@corpmx14.us.dg.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In my previous posting I was referring to the TCP-unaware variety. At the heart of the matter is whether we trust the underlying transport mechanism or not. If we don't, then there has to be some sort of error-recovery procedure for when information/data is lost in transit. If we do trust it, then the iSCSI specification is simplified and we assume that the protocol is riding on an error free link. But to go back to the point of this thread.... Byte and word stuffing mechanisms have been proven to work for many years. Picking a 32 bit number reduces the chances of it showing up in the data stream. Even if it does the stuffing mechanism would mask it. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Black_David@emc.com Sent: Tuesday, July 10, 2001 7:07 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Framing Formats NOTE: iSCSI tag removed because there's FCIP-related material in this message. > We don't want this thread to be started again in this forum. > For anything related to framing go to the TSWG or to the RDMA mailing list. I think Julian may have jumped for that conclusion a little too quickly. Certainly, there are topics that belong on those mailing lists: - TCP-aware framing mechanisms are in the domain of TSVWG. Use of URG and PSH for framing is not going to happen. - RDMA mechanism discussions belong on the RDMA list - this is not an official IETF list. Beyond these, there are a couple of topics that are fair game for the IPS list: - TCP-unaware framing mechanisms intended for specification as part of an IPS protocol; this includes markers, as well as the synchronization recovery mechanism proposed for FCIP. - Discussion of appropriate requirements (e.g., should markers be specified as "MUST implement" with some additional rules about which end of a connection controls their usage on what traffic?). The requirements issue is definitely an open issue at this point in time. As for alternatives to markers, a fairly high level of rigor will be expected of approaches that scan data looking for some distinctive pattern - it basically needs to be the case that this sort of scan and detect algorithm cannot get confused by any pattern appearing in a data payload (read or write data for iSCSI). A motivating example to think about is where trace data that includes the distinctive pattern (e.g., from a sniffer) is being written to or read from a file. Byte and word stuffing mechanisms to ensure that the pattern the algorithm is looking for can't appear in data are one way to accomplish this, but there are others. While I'm on this topic, let me note that the algorithm in Annex A of the -03 FCIP draft does not meet this "cannot get confused" criterion. For FCIP, it is possible to meet this criterion without resorting to stuffing techniques - the basic idea is to scan enough incoming data so that there have to be valid headers in there, note every possible header found, and their relationships based on length fields. If the resulting situation is ambiguous/confusing, restart and/or abandon the attempt to re-establish synchronization. A considerably improved algorithm should appear in the -04 version of the FCIP draft based on some offline discussion with some of the draft authors. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 17:29:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25467 for ; Tue, 10 Jul 2001 17:29:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AJfIL12569 for ips-outgoing; Tue, 10 Jul 2001 15:41:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AJfFg12536 for ; Tue, 10 Jul 2001 15:41:15 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA09614 for ; Tue, 10 Jul 2001 12:40:29 -0700 (PDT) From: "Rod Harrison" To: Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 20:42:11 +0100 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: <001a01c10965$16f95370$8bc809c0@MIKES> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Byte stuffing will kill the performance of software implementations. Do we really believe re-synching in this way is necessary? Remember that the host SCSI layer will retry failed commands. I believe we will see error rates low enough to make pushing recovery back onto the host a viable solution. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mike Parkhurst Sent: Tuesday, July 10, 2001 6:24 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Framing Formats In my previous posting I was referring to the TCP-unaware variety. At the heart of the matter is whether we trust the underlying transport mechanism or not. If we don't, then there has to be some sort of error-recovery procedure for when information/data is lost in transit. If we do trust it, then the iSCSI specification is simplified and we assume that the protocol is riding on an error free link. But to go back to the point of this thread.... Byte and word stuffing mechanisms have been proven to work for many years. Picking a 32 bit number reduces the chances of it showing up in the data stream. Even if it does the stuffing mechanism would mask it. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Black_David@emc.com Sent: Tuesday, July 10, 2001 7:07 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Framing Formats NOTE: iSCSI tag removed because there's FCIP-related material in this message. > We don't want this thread to be started again in this forum. > For anything related to framing go to the TSWG or to the RDMA mailing list. I think Julian may have jumped for that conclusion a little too quickly. Certainly, there are topics that belong on those mailing lists: - TCP-aware framing mechanisms are in the domain of TSVWG. Use of URG and PSH for framing is not going to happen. - RDMA mechanism discussions belong on the RDMA list - this is not an official IETF list. Beyond these, there are a couple of topics that are fair game for the IPS list: - TCP-unaware framing mechanisms intended for specification as part of an IPS protocol; this includes markers, as well as the synchronization recovery mechanism proposed for FCIP. - Discussion of appropriate requirements (e.g., should markers be specified as "MUST implement" with some additional rules about which end of a connection controls their usage on what traffic?). The requirements issue is definitely an open issue at this point in time. As for alternatives to markers, a fairly high level of rigor will be expected of approaches that scan data looking for some distinctive pattern - it basically needs to be the case that this sort of scan and detect algorithm cannot get confused by any pattern appearing in a data payload (read or write data for iSCSI). A motivating example to think about is where trace data that includes the distinctive pattern (e.g., from a sniffer) is being written to or read from a file. Byte and word stuffing mechanisms to ensure that the pattern the algorithm is looking for can't appear in data are one way to accomplish this, but there are others. While I'm on this topic, let me note that the algorithm in Annex A of the -03 FCIP draft does not meet this "cannot get confused" criterion. For FCIP, it is possible to meet this criterion without resorting to stuffing techniques - the basic idea is to scan enough incoming data so that there have to be valid headers in there, note every possible header found, and their relationships based on length fields. If the resulting situation is ambiguous/confusing, restart and/or abandon the attempt to re-establish synchronization. A considerably improved algorithm should appear in the -04 version of the FCIP draft based on some offline discussion with some of the draft authors. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 18:25:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27423 for ; Tue, 10 Jul 2001 18:25:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AKufE18361 for ips-outgoing; Tue, 10 Jul 2001 16:56:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AKudg18352 for ; Tue, 10 Jul 2001 16:56:39 -0400 (EDT) Received: from lose (64-171-32-198.netliant.com [64.171.32.198] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with SMTP id NAA10294 for ; Tue, 10 Jul 2001 13:56:44 -0700 From: "Nate Lawson" To: Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 13:56:03 -0700 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 In-Reply-To: <001a01c10965$16f95370$8bc809c0@MIKES> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: owner-ips@ece.cmu.edu On Behalf Of Mike Parkhurst > In my previous posting I was referring to the TCP-unaware variety. At > the heart of the matter is whether we trust the underlying transport > mechanism or not. If we don't, then there has to be some sort of > error-recovery procedure for when information/data is lost in transit. > If we do trust it, then the iSCSI specification is simplified and we > assume that the protocol is riding on an error free link. With TCP you get reliable delivery and sending rate adaptability for free. Some posts on this thread have expressed sentiments doubting the reliability of the transport which is surprising. > Byte and word stuffing mechanisms have been proven to work for many > years. Picking a 32 bit number reduces the chances of it showing up in > the data stream. Even if it does the stuffing mechanism would mask it. At least in the most naive case, this hurts performance since you have to analyze more data looking for the marker than you would otherwise (type/length/value or fixed size headers). I certainly hope that I wouldn't have to parse the data of a read looking for autosense data separated by a marker. If you have N bytes of data, here is a summary of the amount you'd have to examine to retrieve a header: Naive case (say SLIP over a serial link): N bytes Fixed length packet size: 0 bytes Fixed length header, variable data: ~4 bytes (length field) Type/Length: 1 byte type, 4 byte length The problem with fixed headers is that they're not expandable for future protocols. To be fair, TLV has a problem where if the length field gets corrupted, you have to read up to the maximum number of bytes before throwing away the PDU. But I thought iSCSI will be depending on a reliable transport. In any case, TLV should be familiar since this is how SCSI cdbs work. -Nate From owner-ips@ece.cmu.edu Tue Jul 10 18:27:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27529 for ; Tue, 10 Jul 2001 18:27:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ALe8Z21580 for ips-outgoing; Tue, 10 Jul 2001 17:40:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6ALe6g21571 for ; Tue, 10 Jul 2001 17:40:06 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id VAA08257; Tue, 10 Jul 2001 21:39:44 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 10 Jul 2001 21:39:28 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id <3MWJBY5L>; Tue, 10 Jul 2001 14:39:27 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA7F@FMSMSX94> From: "Herbert, Howard C" To: "'Black_David@emc.com'" , ips@ece.cmu.edu Subject: RE: Interim meeting plans Date: Tue, 10 Jul 2001 14:39:15 -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 David: Do you have a more precise "place" where the meeting will be held (e.g., in Anaheim at the YYY Hotel). Howard -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Tuesday, July 10, 2001 6:48 AM To: ips@ece.cmu.edu Subject: Interim meeting plans This is not definite yet, as there are still details to work out, so it might change. We are tentatively planning an IPS WG interim meeting for August 27-28 in Orange County, CA. The idea is to spend one day on Fibre Channel-related work and one day on Security (iSCSI/FCIP/iFCP). Details will be posted when they're available. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 18:29:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27600 for ; Tue, 10 Jul 2001 18:29:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AKtRj18252 for ips-outgoing; Tue, 10 Jul 2001 16:55:27 -0400 (EDT) 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 f6AKtQg18247 for ; Tue, 10 Jul 2001 16:55:26 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 2963F5A9 for ; Tue, 10 Jul 2001 16:55:21 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id EE2E21953 for ; Tue, 10 Jul 2001 14:55:24 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id NAA14062 for ; Tue, 10 Jul 2001 13:55:23 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA3A2F for ; Tue, 10 Jul 2001 13:55:21 -0700 Message-ID: <3B4B6CD2.D9DC535B@agilent.com> Date: Tue, 10 Jul 2001 14:00:02 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: Preliminary London dates/times References: <277DD60FB639D511AC0400B0D068B71E0709B3@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit cool! 2 days of meetings, and 3 days of company paid london vacation! [I love how efficient this IETF organization is] -Matt Black_David@emc.com wrote: > > This should appear on the IETF web site tomorrow, but here > are the preliminary meeting times for the IP Storage WG > during the London IETF meeting week. > > WARNING: These are SUBJECT TO CHANGE until > the final agenda is posted sometime after July 16th. > > Monday, August 6th, 1930-2200 > Friday, August 10th, 0900-1130 > > 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 18:30:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27660 for ; Tue, 10 Jul 2001 18:30:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AL9Tp19348 for ips-outgoing; Tue, 10 Jul 2001 17:09:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AL9Rg19342 for ; Tue, 10 Jul 2001 17:09:27 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel1.hp.com (Postfix) with ESMTP id C0657DEC for ; Tue, 10 Jul 2001 14:09:25 -0700 (PDT) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 6C63A1F538 for ; Tue, 10 Jul 2001 07:08:21 -0700 (PDT) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id <3PHK6GFF>; Tue, 10 Jul 2001 14:09:18 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A0917F@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 14:09:17 -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 Framing is not intended for error recovery. See the discussion in the iSCSI requirements draft and on Julian's web site http://www.haifa.il.ibm.com/satran/ips/Randy-Haagens-Framing_r1.pdf 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: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Tuesday, July 10, 2001 12:42 PM > To: ips@ece.cmu.edu > Subject: RE: Framing Formats > > > > Byte stuffing will kill the performance of software > implementations. > > Do we really believe re-synching in this way is necessary? > Remember that the host SCSI layer will retry failed > commands. I believe we will see error rates low enough to > make pushing recovery back onto the host a viable solution. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Mike Parkhurst > Sent: Tuesday, July 10, 2001 6:24 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: RE: Framing Formats > > > In my previous posting I was referring to the TCP-unaware > variety. At > the heart of the matter is whether we trust the underlying > transport > mechanism or not. If we don't, then there has to be some > sort of > error-recovery procedure for when information/data is lost > in transit. > If we do trust it, then the iSCSI specification is > simplified and we > assume that the protocol is riding on an error free link. > > But to go back to the point of this thread.... > > Byte and word stuffing mechanisms have been proven to work > for many > years. Picking a 32 bit number reduces the chances of it > showing up in > the data stream. Even if it does the stuffing mechanism > would mask it. > > Mike > > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] > On Behalf Of > Black_David@emc.com > Sent: Tuesday, July 10, 2001 7:07 AM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Framing Formats > > NOTE: iSCSI tag removed because there's FCIP-related > material in this message. > > > We don't want this thread to be started again in this > forum. > > For anything related to framing go to the TSWG or to the > RDMA mailing > list. > > I think Julian may have jumped for that conclusion a little > too quickly. > Certainly, there are topics that belong on those mailing > lists: > > - TCP-aware framing mechanisms are in the domain of TSVWG. > Use > of URG and PSH for framing is not going to happen. > - RDMA mechanism discussions belong on the RDMA list - this > is not an official IETF list. > > Beyond these, there are a couple of topics that are fair > game > for the IPS list: > > - TCP-unaware framing mechanisms intended for specification > as > part of an IPS protocol; this includes markers, as well as > the synchronization recovery mechanism proposed for FCIP. > - Discussion of appropriate requirements (e.g., should > markers > be specified as "MUST implement" with some additional > rules about which end of a connection controls their > usage on what traffic?). > > The requirements issue is definitely an open issue at this > point > in time. As for alternatives to markers, a fairly high > level of rigor > will be expected of approaches that scan data looking for > some > distinctive pattern - it basically needs to be the case that > this > sort of scan and detect algorithm cannot get confused by any > pattern appearing in a data payload (read or write data for > iSCSI). A motivating example to think about is where trace > data that includes the distinctive pattern (e.g., from a > sniffer) > is being written to or read from a file. > Byte and word stuffing mechanisms to ensure that > the pattern the algorithm is looking for can't appear in > data > are one way to accomplish this, but there are others. > > While I'm on this topic, let me note that the algorithm in > Annex A of the -03 FCIP draft does not meet this "cannot > get confused" criterion. For FCIP, it is possible to meet > this criterion without resorting to stuffing techniques - > the > basic idea is to scan enough incoming data so that there > have to be valid headers in there, note every possible > header found, and their relationships based on length > fields. If the resulting situation is ambiguous/confusing, > restart and/or abandon the attempt to re-establish > synchronization. A considerably improved algorithm > should appear in the -04 version of the FCIP draft based > on some offline discussion with some of the draft authors. > > 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 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Tue Jul 10 18:30:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27684 for ; Tue, 10 Jul 2001 18:30:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AM2AS23173 for ips-outgoing; Tue, 10 Jul 2001 18:02:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dominoe.integrix.com ([207.171.9.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AM28g23168 for ; Tue, 10 Jul 2001 18:02:08 -0400 (EDT) Received: from MIKES (mparkhurst [192.9.200.139]) by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA06660; Tue, 10 Jul 2001 15:01:07 -0700 (PDT) Reply-To: From: "Mike Parkhurst" To: Cc: "'Rod Harrison'" Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 15:06:57 -0700 Organization: Integrix Corporation Message-ID: <001c01c1098c$a2d4a1c0$8bc809c0@MIKES> 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, Build 10.0.2627 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: 7bit If the iSCSI protocol is going to take on the responsibility of insuring a reliable data stream then there are only two alternatives. 1) Fixed length commands with padding. or 2) Pattern markers (and the required byte stuffing) that allow the detection of a command frame boundary. (I agree that this approach is oriented more towards those with hardware solutions) Personally I would rather drop the whole issue of Syncing and Steering (section 1.2.8) from the specification all together. In paragraph two of section 1.2.8.1 there are reasons given for not allowing TCP to do the re-ordering needed when packets are either dropped or show up out of order. Yet in paragraph three of the very same section we are told to use the same TCP techniques to handle dropped or up out of order packets. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Rod Harrison Sent: Tuesday, July 10, 2001 11:42 AM To: ips@ece.cmu.edu Subject: RE: Framing Formats Byte stuffing will kill the performance of software implementations. Do we really believe re-synching in this way is necessary? Remember that the host SCSI layer will retry failed commands. I believe we will see error rates low enough to make pushing recovery back onto the host a viable solution. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mike Parkhurst Sent: Tuesday, July 10, 2001 6:24 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Framing Formats In my previous posting I was referring to the TCP-unaware variety. At the heart of the matter is whether we trust the underlying transport mechanism or not. If we don't, then there has to be some sort of error-recovery procedure for when information/data is lost in transit. If we do trust it, then the iSCSI specification is simplified and we assume that the protocol is riding on an error free link. But to go back to the point of this thread.... Byte and word stuffing mechanisms have been proven to work for many years. Picking a 32 bit number reduces the chances of it showing up in the data stream. Even if it does the stuffing mechanism would mask it. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Black_David@emc.com Sent: Tuesday, July 10, 2001 7:07 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Framing Formats NOTE: iSCSI tag removed because there's FCIP-related material in this message. > We don't want this thread to be started again in this forum. > For anything related to framing go to the TSWG or to the RDMA mailing list. I think Julian may have jumped for that conclusion a little too quickly. Certainly, there are topics that belong on those mailing lists: - TCP-aware framing mechanisms are in the domain of TSVWG. Use of URG and PSH for framing is not going to happen. - RDMA mechanism discussions belong on the RDMA list - this is not an official IETF list. Beyond these, there are a couple of topics that are fair game for the IPS list: - TCP-unaware framing mechanisms intended for specification as part of an IPS protocol; this includes markers, as well as the synchronization recovery mechanism proposed for FCIP. - Discussion of appropriate requirements (e.g., should markers be specified as "MUST implement" with some additional rules about which end of a connection controls their usage on what traffic?). The requirements issue is definitely an open issue at this point in time. As for alternatives to markers, a fairly high level of rigor will be expected of approaches that scan data looking for some distinctive pattern - it basically needs to be the case that this sort of scan and detect algorithm cannot get confused by any pattern appearing in a data payload (read or write data for iSCSI). A motivating example to think about is where trace data that includes the distinctive pattern (e.g., from a sniffer) is being written to or read from a file. Byte and word stuffing mechanisms to ensure that the pattern the algorithm is looking for can't appear in data are one way to accomplish this, but there are others. While I'm on this topic, let me note that the algorithm in Annex A of the -03 FCIP draft does not meet this "cannot get confused" criterion. For FCIP, it is possible to meet this criterion without resorting to stuffing techniques - the basic idea is to scan enough incoming data so that there have to be valid headers in there, note every possible header found, and their relationships based on length fields. If the resulting situation is ambiguous/confusing, restart and/or abandon the attempt to re-establish synchronization. A considerably improved algorithm should appear in the -04 version of the FCIP draft based on some offline discussion with some of the draft authors. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 10 20:08:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00777 for ; Tue, 10 Jul 2001 20:08:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6AMUpA25183 for ips-outgoing; Tue, 10 Jul 2001 18:30:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6AMUng25177 for ; Tue, 10 Jul 2001 18:30:49 -0400 (EDT) Received: from london ([192.168.195.163]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id PAA27544; Tue, 10 Jul 2001 15:30:01 -0700 (PDT) From: "Rod Harrison" To: , Subject: RE: Framing Formats Date: Tue, 10 Jul 2001 23:31:43 +0100 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: <001c01c1098c$a2d4a1c0$8bc809c0@MIKES> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mike, We have (1) now. We have a marker scheme for (2) that doesn't require a search of the data to re-synch. Implementations that want to rely on TCP can do so, and push back onto the host if and when that fails. This should be very rare, I believe there is a discussion about exactly how rare somewhere in the archives. The only reason to not allow TCP to re-order out of order packets is to reduce memory footprint. Using the marker scheme we already have allows an implementation to always find a header without having to resort to scanning the data for sentinel patterns. The option to push back onto the hosts error recovery is always there if this fails. However, where I think we agree is on whether iSCSI needs to provide more integrity than TCP itself. I personally don't believe so, but only some mileage on the clock will really tell us. - Rod -----Original Message----- From: Mike Parkhurst [mailto:mike@integrix.com] Sent: Tuesday, July 10, 2001 11:07 PM To: ips@ece.cmu.edu Cc: 'Rod Harrison' Subject: RE: Framing Formats If the iSCSI protocol is going to take on the responsibility of insuring a reliable data stream then there are only two alternatives. 1) Fixed length commands with padding. or 2) Pattern markers (and the required byte stuffing) that allow the detection of a command frame boundary. (I agree that this approach is oriented more towards those with hardware solutions) Personally I would rather drop the whole issue of Syncing and Steering (section 1.2.8) from the specification all together. In paragraph two of section 1.2.8.1 there are reasons given for not allowing TCP to do the re-ordering needed when packets are either dropped or show up out of order. Yet in paragraph three of the very same section we are told to use the same TCP techniques to handle dropped or up out of order packets. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Rod Harrison Sent: Tuesday, July 10, 2001 11:42 AM To: ips@ece.cmu.edu Subject: RE: Framing Formats Byte stuffing will kill the performance of software implementations. Do we really believe re-synching in this way is necessary? Remember that the host SCSI layer will retry failed commands. I believe we will see error rates low enough to make pushing recovery back onto the host a viable solution. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mike Parkhurst Sent: Tuesday, July 10, 2001 6:24 PM To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: RE: Framing Formats In my previous posting I was referring to the TCP-unaware variety. At the heart of the matter is whether we trust the underlying transport mechanism or not. If we don't, then there has to be some sort of error-recovery procedure for when information/data is lost in transit. If we do trust it, then the iSCSI specification is simplified and we assume that the protocol is riding on an error free link. But to go back to the point of this thread.... Byte and word stuffing mechanisms have been proven to work for many years. Picking a 32 bit number reduces the chances of it showing up in the data stream. Even if it does the stuffing mechanism would mask it. Mike -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu] On Behalf Of Black_David@emc.com Sent: Tuesday, July 10, 2001 7:07 AM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Framing Formats NOTE: iSCSI tag removed because there's FCIP-related material in this message. > We don't want this thread to be started again in this forum. > For anything related to framing go to the TSWG or to the RDMA mailing list. I think Julian may have jumped for that conclusion a little too quickly. Certainly, there are topics that belong on those mailing lists: - TCP-aware framing mechanisms are in the domain of TSVWG. Use of URG and PSH for framing is not going to happen. - RDMA mechanism discussions belong on the RDMA list - this is not an official IETF list. Beyond these, there are a couple of topics that are fair game for the IPS list: - TCP-unaware framing mechanisms intended for specification as part of an IPS protocol; this includes markers, as well as the synchronization recovery mechanism proposed for FCIP. - Discussion of appropriate requirements (e.g., should markers be specified as "MUST implement" with some additional rules about which end of a connection controls their usage on what traffic?). The requirements issue is definitely an open issue at this point in time. As for alternatives to markers, a fairly high level of rigor will be expected of approaches that scan data looking for some distinctive pattern - it basically needs to be the case that this sort of scan and detect algorithm cannot get confused by any pattern appearing in a data payload (read or write data for iSCSI). A motivating example to think about is where trace data that includes the distinctive pattern (e.g., from a sniffer) is being written to or read from a file. Byte and word stuffing mechanisms to ensure that the pattern the algorithm is looking for can't appear in data are one way to accomplish this, but there are others. While I'm on this topic, let me note that the algorithm in Annex A of the -03 FCIP draft does not meet this "cannot get confused" criterion. For FCIP, it is possible to meet this criterion without resorting to stuffing techniques - the basic idea is to scan enough incoming data so that there have to be valid headers in there, note every possible header found, and their relationships based on length fields. If the resulting situation is ambiguous/confusing, restart and/or abandon the attempt to re-establish synchronization. A considerably improved algorithm should appear in the -04 version of the FCIP draft based on some offline discussion with some of the draft authors. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 11 04:19:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28069 for ; Wed, 11 Jul 2001 04:19:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6B6E0423101 for ips-outgoing; Wed, 11 Jul 2001 02:14:00 -0400 (EDT) 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 f6B6Dwg23091 for ; Wed, 11 Jul 2001 02:13:58 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WGBFY98>; Wed, 11 Jul 2001 02:08:51 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709F5@corpmx14.us.dg.com> From: Black_David@emc.com To: nate@decru.com, ips@ece.cmu.edu Subject: TCP "reliability" Date: Tue, 10 Jul 2001 17:33:42 -0400 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 > With TCP you get reliable delivery and sending rate adaptability for free. > Some posts on this thread have expressed sentiments doubting the reliability > of the transport which is surprising. Careful - there are two meanings of the word reliability being confused here. (1) Data is delivered in the face of dropped packets. TCP is definitely reliable in this sense - all the data is delivered, in order, or the connection closes. (2) Data is correctly delivered in the face of corruption. TCP's 16-bit checksum falls short of a 32-bit CRC in its ability to detect corruption, and hence TCP leaves something to be desired here. The word "integrity" is a better term for (2) to avoid confusion. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 11 04:25:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28138 for ; Wed, 11 Jul 2001 04:25:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6B6E0r23103 for ips-outgoing; Wed, 11 Jul 2001 02:14:00 -0400 (EDT) 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 f6B6Dwg23095 for ; Wed, 11 Jul 2001 02:13:58 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WGBFZAM>; Wed, 11 Jul 2001 02:09:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E0709F6@corpmx14.us.dg.com> From: Black_David@emc.com To: howard.c.herbert@intel.com, ips@ece.cmu.edu Subject: RE: Interim meeting plans Date: Tue, 10 Jul 2001 17:43:33 -0400 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 > Do you have a more precise "place" where the meeting will be held (e.g., in > Anaheim at the YYY Hotel). Not at the moment, as it could change. The folks organizing the logistics are on this list - they should take this as a hint to nail down the logistics in an expeditious fashion ;-). Thanks, --David > -----Original Message----- > From: Herbert, Howard C [SMTP:howard.c.herbert@intel.com] > Sent: Tuesday, July 10, 2001 5:39 PM > To: 'Black_David@emc.com'; ips@ece.cmu.edu > Subject: RE: Interim meeting plans > > David: > > Do you have a more precise "place" where the meeting will be held (e.g., > in > Anaheim at the YYY Hotel). > > Howard > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Tuesday, July 10, 2001 6:48 AM > To: ips@ece.cmu.edu > Subject: Interim meeting plans > > > This is not definite yet, as there are still > details to work out, so it might change. We are > tentatively planning an IPS WG interim meeting for > August 27-28 in Orange County, CA. The idea is to > spend one day on Fibre Channel-related work and > one day on Security (iSCSI/FCIP/iFCP). > > Details will be posted when they're available. > > 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 > --------------------------------------------------- > From owner-ips@ece.cmu.edu Wed Jul 11 08:56:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02057 for ; Wed, 11 Jul 2001 08:55:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6B9QvQ14622 for ips-outgoing; Wed, 11 Jul 2001 05:26:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from Gregorio.Stanford.EDU (IDENT:root@Gregorio.Stanford.EDU [171.64.66.243]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6B9Qug14618 for ; Wed, 11 Jul 2001 05:26:56 -0400 (EDT) Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.21]) by Gregorio.Stanford.EDU (8.9.3/8.9.1) with ESMTP id CAA21788; Wed, 11 Jul 2001 02:32:10 -0700 Message-Id: <200107110932.CAA21788@Gregorio.Stanford.EDU> To: Black_David@emc.com cc: ips@ece.cmu.edu Subject: Re: TCP "reliability" In-reply-to: Your message of "Tue, 10 Jul 2001 17:33:42 EDT." <277DD60FB639D511AC0400B0D068B71E0709F5@corpmx14.us.dg.com> Date: Wed, 11 Jul 2001 02:25:20 -0700 From: Jonathan Stone Sender: owner-ips@ece.cmu.edu Precedence: bulk In message <277DD60FB639D511AC0400B0D068B71E0709F5@corpmx14.us.dg.com>, Black_David@emc.com writes: >Careful - there are two meanings of the word reliability being confused >here. > >(1) Data is delivered in the face of dropped packets. TCP is definitely > reliable in this sense - all the data is delivered, in order, or the > connection closes. Yep. >(2) Data is correctly delivered in the face of corruption. TCP's 16-bit > checksum falls short of a 32-bit CRC in its ability to detect > corruption, and hence TCP leaves something to be desired here. David, Can I quote that in my dissertation? stricly, what you say is unquestionably true. But I think you are conflating two quite distinct properties here: 32-bit error-detecting codes (EDCs) and the kinds of errors which a (32-bit) CRC guarantee to catch, versus the errors which to which a transport-level error chehck is, empirically, subjected. It turns out that, on the best data we (I and Craig Partridge) have on empirically-observed transport-level errors, CRCs are just not a whole lot better than a 32-bit mod-M additive sum (where M ~= 2^32). This is work in progress, so i cannot give a proper citation (best is my nearly-complete dissertation). OTOH, Julo Satran saw much of the raw data at the recent framing/error-control meeting; i'd be very happy to let Julo make a more impartial comment and see where that goes. >The word "integrity" is a better term for (2) to avoid confusion. No argument there. The term "reliable transport" shoul,d perhaps, be understood in contrast to the contatenated-x25-virtual-circuit model which telcos were offering in serious competition to IP/TCP, once upon a time. (I think even Bob Braden would buy that.) From owner-ips@ece.cmu.edu Wed Jul 11 14:31:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14921 for ; Wed, 11 Jul 2001 14:31:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BFZm608364 for ips-outgoing; Wed, 11 Jul 2001 11:35:48 -0400 (EDT) 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 f6BFZlg08360 for ; Wed, 11 Jul 2001 11:35:47 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA26140; Wed, 11 Jul 2001 11:35:33 -0400 (EDT) Message-ID: <3B4C7114.2F068C1@cisco.com> Date: Wed, 11 Jul 2001 10:30:28 -0500 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: Stephen Bailey CC: ips@ece.cmu.edu Subject: Re: iSCSI: Iterating long text responses References: <3B3CE28C.F9748D5C@cisco.com> <20010706150620.283C14E8C@sandmail.sandburst.com> <3B4A1ADB.8FD58F44@cisco.com> <200107100112.f6A1C1804380@chmls06.mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stephen Bailey wrote: > > Mark, > > > Anyway, #2 would work fine as well, but again, I'd really like > > to avoid keeping state on the target. > > You have to keep state on lots of state at this granularity (per > session/connection) on the target anyway. All this would require is > an integer index into your target list table (which you obviously have > in some form to respond to SendTargets at all...) True; it just seemed better (well, certainly easier) to avoid the problem of iterating SendTargets at by forcing the long response into the current protocol with multiple PDUs. I would imagine that most responses will fit in a small number of PDUs anyway. > One might suggest a variant of #5 with an initial offset argument to > the request, so you could get `what's left', but that really does > create a state problem. With the simple iterator at least you know > that every return is (or was) a complete target description. If we had to do that, I'd rather do the iterator. > But then again, what do I know? [this list is like driving, cf. Repo > Man] > > Certainly doing #5 would not leave a criminal hole in the spec. > Neither would it probably be used in general by X-* operations. It looks like most folks are comfortable implementing #5 for SendTargets, even if it doesn't solve all of the possible problems of X-* stuff. Are you planning to use X-* commands? BTW, if anyone is planning to make heavy use of X-* text commands, it may be worth speaking up now, to make sure we do this right. > Steph -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 11 16:48:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19709 for ; Wed, 11 Jul 2001 16:48:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BIFUH21221 for ips-outgoing; Wed, 11 Jul 2001 14:15:30 -0400 (EDT) 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 f6BIFSg21213 for ; Wed, 11 Jul 2001 14:15:28 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0SRFGB>; Wed, 11 Jul 2001 14:15:22 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A01@corpmx14.us.dg.com> From: Black_David@emc.com To: jonathan@dsg.stanford.edu Cc: ips@ece.cmu.edu Subject: RE: TCP "reliability" Date: Wed, 11 Jul 2001 14:11:25 -0400 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 Jonathan, > >(2) Data is correctly delivered in the face of corruption. TCP's 16-bit > > checksum falls short of a 32-bit CRC in its ability to detect > > corruption, and hence TCP leaves something to be desired here. > > stricly, what you say is unquestionably true. Right ... I put the numbers of bits in for a reason :-). > But I think you are > conflating two quite distinct properties here: 32-bit error-detecting > codes (EDCs) and the kinds of errors which a (32-bit) CRC guarantee to > catch, versus the errors which to which a transport-level error chehck > is, empirically, subjected. > > It turns out that, on the best data we (I and Craig Partridge) have on > empirically-observed transport-level errors, CRCs are just not a whole > lot better than a 32-bit mod-M additive sum (where M ~= 2^32). I think that's fair, and I certainly don't want to argue with empirical data - my wife claims the first rule of engineering is "never argue with results" ... and she's always right ;-). However, when looking at TCP, we have to deal with the 16-bit checksum that exists and really cannot be changed at this juncture. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 11 16:56:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19995 for ; Wed, 11 Jul 2001 16:56:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BHhmM18097 for ips-outgoing; Wed, 11 Jul 2001 13:43:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.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 f6BHhUg18037 for ; Wed, 11 Jul 2001 13:43:34 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA33478 for ; Wed, 11 Jul 2001 12:37:48 -0500 Received: from f3n42e (d03nm042h.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6BHhAJ130050 for ; Wed, 11 Jul 2001 11:43:10 -0600 Importance: Normal Subject: iSCSI: SAM-iSCSI mapping (alternative) To: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 11 Jul 2001 10:43:07 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/11/2001 10:43:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, This note addresses an alternative (and hopefully) better approach to mapping the SCSI Architecture Model (SAM) constructs onto the iSCSI constructs. This is being recommended by the Naming and Discovery Team. [Note: This is mostly esoteric stuff that shouldn't impact much of the main line use of iSCSI, though part of this alternative proposal is intended to make implementations a bit easier.] Here's a quick summary of relevant iSCSI constructs: a) iSCSI node (either initiator or target) is a WWU named entity b) iSCSI login occurs between an iSCSI initiator node and an iSCSI target node (and names are exchanged during login) c) an iSCSI node can have multiple IPnames/IPaddresses/TCPports d) the IPnames/IPaddresses/TCPports can be organized into "portal groups"; a multi-connection session may ONLY be established within a portal group (not across ip address/ports in two different portal groups). The relevant SAM constructs are "initiator port", "target port", "nexus (a relationship between an initiator port and a target port)" and only as secondary constructs the notion of "initiator device" and "target device". (We need not worry about logical unit wrt iSCSI.) CURRENT PROPOSED MAPPING of SAM to iSCSI: a) a SAM nexus maps to an iSCSI session b) there is at most one SCSI Device (initiator or target) contained within an iSCSI node (in other words, the SCSI device is the SCSI-ness of the iSCSI node); the SCSI device name is the iSCSI name. c) a SCSI Initiator port (which is, by definition, the entity at the initiator side of a nexus) maps to the iSCSI initiator endpoint of the session (and is identified/names by its iSCSI Name + ISID of the session). d) a SCSI Target port (the entity at the target side of the nexus) maps to the iSCSI target endpoint of the session (and is identified/named by its iSCSI Name + TSID). ISID RULE: A consequence of this mapping (to handle some specific SCSI features) is the restriction that between a given iSCSI initiator and iSCSI target, there can be only one session with a given ISID. Note that this does not preclude use of the same ISID with a different iSCSI target, nor does it preclude other sessions with different ISIDs to the same iSCSI target. This model implies some implementation requirements on both the initiator and the target and it "stretches" some notions in SCSI. To minimize these effects (detailed more carefully below), I'd like to propose the following alternative mapping of SAM constructs: ALTERNATIVE PROPOSED MAPPING: a) SAM nexus as above b) SCSI device as above c) SCSI initiator port as above d) SCSI target port is an iSCSI target portal group and is identified by its iSCSI name + portal group tag (as reported in SendTargets); this is very different from above. ISID RULE (modified): Between a given iSCSI initiator and iSCSI target portal group, there can be only one session with a given ISID. Note that this is a much weaker restriction than above. This does not preclude use of the same ISID with different target portal group on the same iSCSI target (or on other iSCSI targets), nor does it preclude other sessions with different ISIDs to the same target portal group. WHY THE CHANGE? 1) The new model better fits with SCSI's sense that target ports are static things, not totally dynamic (like session endpoints). There's less of a static requirement for initiator ports. 2) In spite of the asymmetry of the model, the implementation requirements are actually more symmetric and simpler (more details next). IMPLEMENTATION REQUIREMENTS: OLD NEW -------------------------------------------------------------------------- Initiator ISIDs must be partitioned ISIDs must be partitioned between initiator portal between initiator portal groups groups iSCSI name must be configurable iSCSI name must be configurable to each portal group to each portal group Target TSIDs must be partitioned TSIDs must be partitioned between target portal between target portal groups groups iSCSI name must be configurable iSCSI name must be configurable to each portal group to each portal group Active Initiator name+ISID No requirement: each portal lists must be shared across group can separately manage portal groups (to enforce its own active InitiatorName+ISID ISID RULE) lists; no sharing of active state is required across portal groups within a target NOTES: 1) As noted, implementation on the iSCSI target is analogous to the iSCSI initiator with respect to ISID and TSIDs and names. Portal groups should be configured (by the iSCSI node) with their iSCSI name and with a piece of the [I/T]SID namespace. There need be no other shared state across portal groups. 2) The nexus is still a session, but it connects a dynamic SCSI initiator port (identified by iSCSI name+ISID) with a static target port (identified by iSCSI name+portal group tag). 3) The old model required finessing a reservation requirement that the logical unit device server remember the SCSI target port used for the reservation (so the TSID). Without going into the subtlties here, note only that the new model requires the device server to only remember the portal group. 4) In the old model, changes to port-specific mode pages affected all iSCSI initiators who see the same TSID (odd, but true). In the new model, changes to port-specific mode pages affect all iSCSI initiators logged in to the same portal group (independent of TSID). So, the affect is broader, but makes more sense in that it is scoped to more static constructs (the portal group). 5) This is analogous to how the SCSI over RDMA Protocol (i.e., Infiniband and VI) are modeling SAM. Jim Hafner From owner-ips@ece.cmu.edu Wed Jul 11 16:59:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20348 for ; Wed, 11 Jul 2001 16:59:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BHpPp18772 for ips-outgoing; Wed, 11 Jul 2001 13:51:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe28.law11.hotmail.com [64.4.16.85]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6BHpNg18768 for ; Wed, 11 Jul 2001 13:51:23 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jul 2001 10:50:57 -0700 X-Originating-IP: [66.31.72.75] From: "Eddy Quicksall" To: "Lakshmi Ramasubramanian" , References: <8CC03F47967BF14D9710887723FADDB6A5827A@win-msg-02.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: Sense data and Response Data Date: Wed, 11 Jul 2001 13:50:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 11 Jul 2001 17:50:57.0100 (UTC) FILETIME=[09BB58C0:01C10A32] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit MessageDid anyone get back to you yet? As I see it, you do the following: Send the data as SCSI READ Data (op/code 25) and S bit set to 0. Then send the sense data as SCSI RESPONSE (op/code 21), the S bit set to 1, the status set to CHECK CONDITION, the DataSegmentLength set to the length of the Sense Data and the Sense Data to follow that. Eddy ----- Original Message ----- From: Lakshmi Ramasubramanian To: ips@ece.cmu.edu Sent: Friday, July 06, 2001 2:19 PM Subject: Sense data and Response Data In SCSI Response PDU, the target can send either Sense Data or Response Data, but not both. In certain cases, such as when a filemark is detected on the tape during read, the target needs to return both the data read before reaching the filemark and the sense data. Is there anyway targets can do this? thanks! -lakshmi From owner-ips@ece.cmu.edu Wed Jul 11 17:00:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20404 for ; Wed, 11 Jul 2001 17:00:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BIrur24221 for ips-outgoing; Wed, 11 Jul 2001 14:53:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6BIrsg24214 for ; Wed, 11 Jul 2001 14:53:54 -0400 (EDT) Received: from lava.cs.unh.edu (lava.cs.unh.edu [132.177.4.30]) by cs.unh.edu (8.11.0/8.11.0) with ESMTP id f6BIrrq15844 for ; Wed, 11 Jul 2001 14:53:53 -0400 (EDT) Date: Wed, 11 Jul 2001 14:53:53 -0400 (EDT) From: Anshul Chadda To: ips@ece.cmu.edu Subject: UNH iSCSI draft 6 initiator and target implementations available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi all: We are releasing our draft 6 initiator and target emulator implementations to everybody under GPL. The initiator and target implementations are available as a zipped tar file, iscsi_ver_6.08.tgz and can be downloaded from the UNH iSCSI consortium web-site at http://www.iol.unh.edu/consortiums/iscsi/ under "iSCSI Implementations". Thanks, Anshul ---------------------------------------------------------------------- iSCSI Consortium InterOperability Lab Rm 201, Jere A. Chase Ocean Engg. Bldg 24 Colovis Road Durham, NH 03824-3525 Tel:603-862-1908 ---------------------------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 11 18:44:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23423 for ; Wed, 11 Jul 2001 18:44:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BKb9f01770 for ips-outgoing; Wed, 11 Jul 2001 16:37:09 -0400 (EDT) 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 f6BKb8g01766 for ; Wed, 11 Jul 2001 16:37:08 -0400 (EDT) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6BKb7I00529 for ; Wed, 11 Jul 2001 16:37:07 -0400 (EDT) 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 f6BKb7700522 for ; Wed, 11 Jul 2001 16:37:07 -0400 (EDT) content-class: urn:content-classes:message Subject: Announcement: IPS interim meeting August 27-28 -- FC related drafts and Security (iSCSI/FCIP/iFCP) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 11 Jul 2001 16:37:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D4538236498360BF32B@nc8220exchange.ral.lucent.com> Thread-Topic: Announcement: IPS interim meeting August 27-28 -- FC related drafts and Security (iSCSI/FCIP/iFCP) Thread-Index: AcEKSKwOk/iwrLo4TCWbsrItoh+Xdg== From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f6BKb8g01767 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, An interim meeting of the IPS working group will be held on August 27 and 28 in Irvine, CA. Due to a conflict with T11 the week of August 5th, the FC related drafts will not be addressed in London. Thus, we will be holding an interim meeting to cover those drafts. On Monday, August 27, the FC related drafts will be discussed. This will include FCIP, iFCP, and related MIBs. In addition, more time is needed to discuss the area of Security. This discussion should be of interest to iSCSI, FCIP and iFCP. Security discussions will be held on Tuesday, August 28. The agenda for this meeting will be posted in late July/early August. Plan to meet from 8am-6pm each day. This meeting is being cosponsored by LightSand Communications, Vixel and Gadzoox Networks Hotel information is as follows: Marriott Irvine John Wayne Airport 18000 Von Karman Avenue Irvine, CA 92612 Phone: 949-553-0100 Single or Double Room rate for Aug 26 night and Aug 27 night: $99/night Cut-off Date: July 30 Name of Event: IETF Meeting Parking is $9/day. Shuttle service to/from John Wayne Airport (SNA) is provided. Please let me know if you plan on attending, and which days. Thanks, Elizabeth From owner-ips@ece.cmu.edu Wed Jul 11 18:45:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23452 for ; Wed, 11 Jul 2001 18:45:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BLIlD04805 for ips-outgoing; Wed, 11 Jul 2001 17:18:47 -0400 (EDT) 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 f6BLIjg04801 for ; Wed, 11 Jul 2001 17:18:45 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA07853 for ; Wed, 11 Jul 2001 17:18:40 -0400 (EDT) Message-ID: <3B4CC17F.DCAD14F4@cisco.com> Date: Wed, 11 Jul 2001 16:13:35 -0500 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: iSCSI Naming: iqn format specification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit During the interim meeting, the following problem with the iqn (iSCSI qualified name) format was brought up. From David's draft notes: There is a problem with domain names changing ownership without record of what iSCSI names iqns were created by the old owner. This risks unacceptable duplication. Suggestions for using IANA private enterprise identifier, date, and some sort of existing vendor identifier were made. The simple approach of using WWNs runs into administrative difficulties like a $1500 fee to get initial allocation. Anyway, the basic point of the iqn format is to allow hardware and software vendors, service providers, and possibly end users to manage their own iSCSI name spaces as they see fit. To do so, some sort of naming authority must be used. To avoid having to administer naming authorities, we may consider only existing schemes that are already widely used and understood. It would be beneficial to select a scheme where entities in all of the categories mentioned above (hw, sw, services) will already own a name or number suitable for use as a naming authority. Possible schemes include: 1. OUI-based schemes (including EUI-64) - These schemes are all based on using the IEEE organizationally unique idenfier. These cost $1250 each, and are 24-bit numbers (22 bits, if also used for MAC addresses) assigned for use within MAC addresses and similar binary addresses such as EUI-64 WWNs. + Works fine for hardware vendors + Cannot be re-assigned - Most software vendors do not already have OUIs - Service providers and end users will not (and probably should not) be allocating OUIs. - Wastes part of the available MAC address space - Less transcribable - OUI normally expressed as six-digit hex number; schemes such as MAC address and EUI-64 are expressed as 12 to 16-digit numbers. - Companies are not required to make their OUI public; comparison of an OUI with a list of assigned OUIs is not guaranteed to determine the naming authority's true identity. iSCSI already does provide a way to use EUI-64 addresses as an iSCSI name, so this functionality is already there for those who wish to use it. In the end, OUIs are really meant to be used for lower-level, hardware-based addresses; iSCSI names identify higher-level software entities. While the hardware-based scheme is definitely useful, it is not the most appropriate scheme in all cases. 2. Enterprise number + They don't cost anything. + They are easily obtained from IANA. + Some software vendors and service providers already have them. + Cannot be re-assigned. + Normally expressed as four (soon to be five) digit numbers. + Enterprise numbers are public; it is possible to look one up in an easily available list to determine a naming authority's identity. - Less transcribable than a DNS name (but better than an OUI). - Not everyone has or needs one for other purposes; might cause extra load on IANA-assigned name space, especially if end users, researchers, or university projects start applying for them. In the past year, IANA has assigned about 3,000 enterprise numbers. 3. DNS name + Everyone has one; even researchers and universities can create their own unique names. + More human-friendly; a quick look at an iSCSI name reveals who assigned it. + More transcribable; it's easier to write down a name than a number. - Can expire and be re-assigned. Choice #2 and #3 seem the most useful for naming things that are not tied strictly to hardware. The current method is to use the DNS name, and to reverse it as the Java class hierarchy did to avoid confusion with an address. We had not seriously considered enterprise numbers before the interim meeting. In our last conference call, we considered three possibilities for the iqn format: a. Just keep the DNS name and live with the consequences This is what we currently have; the only issue with it is the fact that it can expire and be re-assigned, and name collisions can result. b. Ditch the DNS name in favor of an enterprise number This might place an unnecessary load on the allocation of enterprise numbers by IANA. c. Use the DNS name format for the best flexibility, but allow the inclusion of the enterprise number to eliminate the uniqueness- over-time issue. This format would look like: Ent Naming Defined by Type # Auth Naming Authority +-+ +--+ +------+ +--------------------+ | | | | | | | | iqn.5886.com.acme.diskarrays-sn-a8675309 The optional enterprise number is expressed in decimal between the iqn and the DNS naming authority. Hardware or software companies shipping products will generally have an enterprise number, and can prefix their reversed DNS name with it; others creating their name- spaces can leave out the enterprise number. Since a component of a DNS name cannot start with a digit, there is no risk of confusing the two. So basically, anyone wanting to use an OUI can already do so, using the EUI-64 format. Anyone needing to define iSCSI names using the DNS name format can do so as well. Anyone wanting to ensure that their names will never conflict with someone else's can add the enterprise number. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 11 20:17:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25772 for ; Wed, 11 Jul 2001 20:17:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BMUFH09613 for ips-outgoing; Wed, 11 Jul 2001 18:30:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6BMUDg09606 for ; Wed, 11 Jul 2001 18:30:13 -0400 (EDT) Received: from lava.cs.unh.edu (lava.cs.unh.edu [132.177.4.30]) by cs.unh.edu (8.11.0/8.11.0) with ESMTP id f6BMUCq16740; Wed, 11 Jul 2001 18:30:13 -0400 (EDT) Date: Wed, 11 Jul 2001 18:30:12 -0400 (EDT) From: Anshul Chadda To: ips@ece.cmu.edu, iscsi@mars.iol.unh.edu Subject: Well known Port Number to be 5003 for iSCSI plug-fest, 16-20July,2001 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi all: There has been debate about the "well known port number" that will be used for the upcoming iSCSI plug-fest. We, UNH, had advertised to the vendors that the "well known port number" will be 4000. Apparently many companies seem to be using port 5003 as "well known port number" for reasons stated by Mark Bakke in the attached email. Well, we(UNH) are willing to move to port 5003 as "well known port number" on the target. I am hoping that this decision doesn't affect many vendors. If there is some problem with anybody, let us know. Anshul ---------------------------------------------------------------------- iSCSI Consortium InterOperability Lab Rm 201, Jere A. Chase Ocean Engg. Bldg 24 Colovis Road Durham, NH 03824-3525 Tel:603-862-1908 ---------------------------------------------------------------------- ---------- Forwarded message ---------- Date: Mon, 09 Jul 2001 15:31:51 -0500 From: Mark Bakke To: Robert D. Russell Cc: Dave Peterson , "Nguyen, Tri G" , 'Barry Reinhold' , Anshul Chadda , Michael Froning , iscsi@mars.iol.unh.edu, 'Rod Harrison' , Eddy Quicksall Subject: Re: iSCSI Plug-fest in mid June We (Cisco) arbitrarily picked 5003 in our initial implementation, since there was no port in the iSCSI document. It is used in our current product as well as in our drivers. This port has been propagated to several other companies' implementations, both through licensing of our drivers and testing with our product. I think that there are enough implementations using 5003 to consider it defacto, at least until IANA assigns us a port number. I wish we would have thought to post the number on this list earlier; it might have avoided some trouble. -- Mark "Robert D. Russell" wrote: > > Dave: > How did 5003 become "defacto" -- as far as I can tell, > it never appeared in any documents or even on this mailing > list prior to this discussion. Who decided it was 5003? > And how was that decision communicated to the rest of the > world? And when was this done? > > Thanks, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Mon, 9 Jul 2001, Dave Peterson wrote: > > > TCP port number 5003 is currently the "defacto" for existing > > implementations. > > There is no well known iSCSI port number yet. > > We need to stick with 5003 for the Plugfest. Even seen some iSCSI > > analyzers using this number for iSCSI. > > > > Dave > > > > -----Original Message----- > > From: owner-iscsi@mars.iol.unh.edu > > [mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Nguyen, Tri G > > Sent: Monday, July 09, 2001 9:49 AM > > To: 'Barry Reinhold'; Dave Peterson; Anshul Chadda; Michael Froning > > Cc: iscsi@mars.iol.unh.edu; 'Rod Harrison'; Eddy Quicksall > > Subject: RE: iSCSI Plug-fest in mid June > > > > > > Barry, > > I thought 5003 is the default port for iSCSI. This was defined in the > > iSCSI specification. Why do we used 4000? Did they change the default port > > to 4000? > > > > -----Original Message----- > > From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] > > Sent: Monday, July 09, 2001 9:43 AM > > To: Dave Peterson; Anshul Chadda; Michael Froning > > Cc: iscsi@mars.iol.unh.edu; 'Rod Harrison'; Eddy Quicksall > > Subject: RE: iSCSI Plug-fest in mid June > > > > > > Dave, > > It's a mixed bag -- UNH has been telling all who asked that port > > 4000 is > > the port to use. Where did 5003 come from? I think people are going to have > > to recompile either way (for me this is not hard, so I don't personally > > care) but I would think it best to keep the message consistent at 4000. > > > > >-----Original Message----- > > >From: Dave Peterson [mailto:dap@cisco.com] > > >Sent: Monday, July 09, 2001 10:30 AM > > >To: Barry Reinhold; Anshul Chadda; Michael Froning > > >Cc: iscsi@mars.iol.unh.edu; 'Rod Harrison'; Eddy Quicksall > > >Subject: RE: iSCSI Plug-fest in mid June > > >Importance: High > > > > > > > > >What are the chances of changing to port 5003. We (and many other vendors) > > >will need to recompile all our stuff and retest to use port 4000. I'd like > > >to avoid this if at all possible at this point in time. > > > > > >Dave > > > > > >-----Original Message----- > > >From: Barry Reinhold [mailto:bbrtrebia@mediaone.net] > > >Sent: Sunday, July 08, 2001 8:30 PM > > >To: Dave Peterson; Anshul Chadda; Michael Froning > > >Cc: iscsi@mars.iol.unh.edu; 'Rod Harrison'; Eddy Quicksall > > >Subject: RE: iSCSI Plug-fest in mid June > > > > > > > > >Dave, > > > The UNH stuff is setup for port 4000. > > > > > >>-----Original Message----- > > >>From: owner-iscsi@mars.iol.unh.edu > > >>[mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Dave Peterson > > >>Sent: Sunday, July 08, 2001 6:45 PM > > >>To: Anshul Chadda; Michael Froning > > >>Cc: iscsi@mars.iol.unh.edu; 'Rod Harrison'; Eddy Quicksall > > >>Subject: RE: iSCSI Plug-fest in mid June > > >>Importance: High > > >> > > >> > > >>Rev 06+ = draft-ietf-ips-iSCSI-06.txt + Rev 07 opcodes > > >> > > >>Rev 06+ IS NOT draft-ietf-ips-iSCSI-06-93.txt posted on Julian's web site. > > >> > > >>We will be using TCP port number 5003. > > >> > > >>Still have not seen the UNH Rev 06 + Rev 07 opcodes reference > > >>implementation > > >>for conformance testing. > > >>This is critical for vendors striving for successful conformance > > >testing at > > >>the Plugfest and needs to made available asap. > > >>Monday or Tuesday at the latest. > > >> > > >>Dave > > >> > > >>-----Original Message----- > > >>From: owner-iscsi@mars.iol.unh.edu > > >>[mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Eddy Quicksall > > >>Sent: Wednesday, July 04, 2001 11:18 AM > > >>To: 'Rod Harrison'; iscsi@mars.iol.unh.edu > > >>Subject: RE: iSCSI Plug-fest in mid June > > >> > > >> > > >>Can you please address questions 1 and 2 below? > > >> > > >>Eddy > > >> > > >>-----Original Message----- > > >>From: owner-iscsi@mars.iol.unh.edu > > >>[mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Rod Harrison > > >>Sent: Wednesday, July 04, 2001 12:14 PM > > >>To: iscsi@mars.iol.unh.edu > > >>Subject: RE: iSCSI Plug-fest in mid June > > >> > > >> > > >> > > >> When we say v06+ are we talking about v06-92 as published > > >>on Julian Satran's web site or something else? > > >> > > >> - Rod > > >> > > >>-----Original Message----- > > >>From: owner-iscsi@mars.iol.unh.edu > > >>[mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Eddy > > >>Quicksall > > >>Sent: Wednesday, July 04, 2001 1:23 PM > > >>To: 'Dave Peterson'; iscsi@mars.iol.unh.edu > > >>Subject: RE: iSCSI Plug-fest in mid June > > >> > > >> > > >>1) What "well known port" are we to use for plug fest? > > >>2) When will you have a version 06+ available for some > > >>testing (before we come to plug fest)? > > >> > > >>Eddy@Quicksall.com > > >> > > >>-----Original Message----- > > >>From: owner-iscsi@mars.iol.unh.edu > > >>[mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Dave > > >>Peterson > > >>Sent: Wednesday, May 16, 2001 11:31 AM > > >>To: Anshul Chadda; iscsi@mars.iol.unh.edu > > >>Subject: RE: iSCSI Plug-fest in mid June > > >> > > >> > > >>As previously indicated to Anshul, we are currently shipping > > >>product to: > > >> > > >>July 2000 (draft-satran-01) version plus support for the > > >>SendTargets > > >>function (can I call this v0?) > > >> > > >>We should have rev 06+ also available for testing. > > >> > > >>I'm not sure what benefit testing for v3 would provide at > > >>this point in > > >>time. > > >> > > >>Dave > > >> > > >>> -----Original Message----- > > >>> From: owner-iscsi@mars.iol.unh.edu > > >>> [mailto:owner-iscsi@mars.iol.unh.edu]On Behalf Of Anshul > > >>Chadda > > >>> Sent: Monday, May 14, 2001 8:20 PM > > >>> To: iscsi@mars.iol.unh.edu > > >>> Subject: iSCSI Plug-fest in mid June > > >>> > > >>> > > >>> Hi all: > > >>> We are trying to organize a plug-fest for iSCSI > > >>InterOperability > > >>> testing during the week of June 18th - June 22th. > > >>> > > >>> We plan to have the following capabilities ready for the > > >>plug-fest: > > >>> > > >>> * Protocol Analyzer to decode iSCSI PDU's: > > >>> Basically, the protocol analyzer will be sitting on a > > >>Gig. Ethernet > > >>> link between initiator and target. The Analyzer will > > >>expect the > > >>> iSCSI traffic to be carried on top of TCP/IP. > > >>> Version supported: 3 and 6 > > >>> > > >>> * Test-tool for iSCSI initiator and target: > > >>> The test tool will enable comprehensive testing of the > > >>basic > > >>> components of the iSCSI protocol for single-session, > > >>single- > > >>> connection initiators and targets. > > >>> Version supported: 3 and 6 > > >>> > > >>> * In house iSCSI Target and Initiator reference > > >>implementations: > > >>> These implementations are implemented in software on > > >>Linux. They > > >>> will be available for testing with other vendor's > > >>> initiators/targets. > > >>> Version supported: 6 > > >>> > > >>> The location is tentatively scheduled to be at UNH for > > >>simplicity of > > >>> logistics, but we are open to a change of location > > >>depending on > > >>> the number > > >>> of companies participating. > > >>> > > >>> We would also like to know what draft version people are > > >>implementing to. > > >>> We can easily support more versions for the Protocol > > >>Analyzer and > > >>> test-tool, > > >>> but doing that for the reference implementation will be > > >>difficult, given > > >>> the time frame. > > >>> > > >>> To make definitive arrangements, we need to get an > > >>approximate number of > > >>> companies interested in this plug-fest. So, please let us > > >>know as soon as > > >>> possible. Other plug-fest details will be mailed on this > > >>mailing list in > > >>> the next couple of days. > > >>> > > >>> Sincerely, > > >>> Anshul > > >>> > > >>> ---------------------------------------------------------- > > >>------------ > > >>> iSCSI Consortium > > >>> InterOperability Lab > > >>> Rm 201, Jere A. Chase Ocean Engg. Bldg > > >>> 24 Colovis Road > > >>> University of New Hampshire > > >>> Durham, NH 03824-3525 > > >>> Tel:603-862-1908 > > >>> ---------------------------------------------------------- > > >>------------ > > >>> > > >>> > > >> > > >> > > > > > > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 11 20:41:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26090 for ; Wed, 11 Jul 2001 20:41:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6BLmuH06870 for ips-outgoing; Wed, 11 Jul 2001 17:48:56 -0400 (EDT) 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 f6BLmtg06866 for ; Wed, 11 Jul 2001 17:48:55 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA18430; Wed, 11 Jul 2001 17:48:49 -0400 (EDT) Message-ID: <3B4CC891.EAB59B99@cisco.com> Date: Wed, 11 Jul 2001 16:43:45 -0500 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: iSCSI: Open source Linux driver Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Cisco's Linux iSCSI driver is now available under the GNU Public License. It currently implements iSCSI version 0 (July 2000); draft-06+ will be available soon. A description of the driver is available on the project home page at: http://linux-iscsi.sourceforge.net/ The project itself is managed on SourceForge at: http://sourceforge.net/projects/linux-iscsi/ SourceForge has made developer and user mailing lists available for those interested, as well as bug reporting and support request mechanisms. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 11 22:05:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27978 for ; Wed, 11 Jul 2001 22:05:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6C18Pr19018 for ips-outgoing; Wed, 11 Jul 2001 21:08:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6C0Y7g16967 for ; Wed, 11 Jul 2001 20:34:07 -0400 (EDT) Received: from aarnet.edu.au (cu901.adelaide.adsl.on.net [150.101.237.139]) by tiny-teddy.aarnet.edu.au (8.11.0/8.11.0) with ESMTP id f6C0Xxv14865; Thu, 12 Jul 2001 10:03:59 +0930 Message-ID: <3B4CF076.F7C725D1@aarnet.edu.au> Date: Thu, 12 Jul 2001 10:03:58 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-ac19 i686) X-Accept-Language: en MIME-Version: 1.0 To: Mark Bakke CC: IPS Subject: Re: iSCSI Naming: iqn format specification References: <3B4CC17F.DCAD14F4@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 Mark Bakke wrote: > > - Not everyone has or needs one for other purposes; might cause > extra load on IANA-assigned name space, especially if end users, > researchers, or university projects start applying for them. > In the past year, IANA has assigned about 3,000 enterprise > numbers. I'd suggest altering the syntax to allow for OIDs, not just IANA-assigned enterprise numbers. Otherwise people with ISO- assigned numbers are going to end up holding multiple OID allocations, which begins to be administratively nightmareish. This also fixes the "load on IANA" problem. As a real example, OIDs are required for LDAP schema and each organisation can be expected to have a unique LDAP scehema (such as Example Corp having an examplePerson schema). To reduce the load on allocation bodies, AARNet already sub-allocates OIDs to Australian universities out of its ISO allocated space for use in universities' private LDAP schema and any private SNMP MIBs. Because of the OID/LDAP linkage, I'd expect DNS registries to be the ultimate allocators of OIDs. > ... Since a component of a > DNS name cannot start with a digit, there is no risk of confusing > the two. Not so, this requirement was removed some time ago. Consider http://www.3com.com/. It would thus be better to list the namespace explicitly rather than make any assumptions about DNS names. Especially as DNS naming is going to go through some major changes to allow for multilingual names. > - Less transcribable - OUI normally expressed as six-digit hex > number; schemes such as MAC address and EUI-64 are expressed > as 12 to 16-digit numbers. OUIs have a OID form, so the OID form should should be either be required or forbidden to prevent confusion. It probably best to treat the OUI as a 12 or 16 hexdigit number. Using just the OUI is problematic for huge organisations, as they then need to track iSCSI namespace use internally. Assigning a "MAC address" (OUI + 3 octets) to the iSCSI team is easy administratively. Finally, we should use the URI name and format for the namespace where a URI format exists. This is simply for consistency. For example: backwardsdns:au.edu.example.faculty oid:1.32.43.5.3.2.43.2.2.34 oui:2e319c65786e Regards, Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Wed Jul 11 22:11:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28066 for ; Wed, 11 Jul 2001 22:11:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6C0IbB16042 for ips-outgoing; Wed, 11 Jul 2001 20:18:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h008.c007.snv.cp.net [209.228.33.214]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6C0Iag16038 for ; Wed, 11 Jul 2001 20:18:36 -0400 (EDT) Received: (cpmta 19480 invoked from network); 11 Jul 2001 17:18:29 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.214) with SMTP; 11 Jul 2001 17:18:29 -0700 X-Sent: 12 Jul 2001 00:18:29 GMT From: "Douglas Otis" To: "Jonathan Stone" , Cc: Subject: RE: TCP "reliability" Date: Wed, 11 Jul 2001 17:16:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <200107110932.CAA21788@Gregorio.Stanford.EDU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, To be more exact about the differences between the various summations and CRC, CRC offers a substantial improvement if due to bus related errors. The same could be true with respect to switch fabric cell re-ordering. Your sample data indicated errors with a prevalence at word bit locations that could relate to either distinct locations or to an internal bus. Assumptions as to a random nature of these errors could lead to conclusions of equivalence but protections in this case are slight if due to an internal bus for summations. These concerns are based on empirical data but I find this compelling to remain cautious about making such assertions. Doug > In message <277DD60FB639D511AC0400B0D068B71E0709F5@corpmx14.us.dg.com>, > Black_David@emc.com writes: > > >Careful - there are two meanings of the word reliability being confused > >here. > > > >(1) Data is delivered in the face of dropped packets. TCP is definitely > > reliable in this sense - all the data is delivered, in order, or the > > connection closes. > > Yep. > > >(2) Data is correctly delivered in the face of corruption. TCP's 16-bit > > checksum falls short of a 32-bit CRC in its ability to detect > > corruption, and hence TCP leaves something to be desired here. > > David, > > Can I quote that in my dissertation? > > stricly, what you say is unquestionably true. But I think you are > conflating two quite distinct properties here: 32-bit error-detecting > codes (EDCs) and the kinds of errors which a (32-bit) CRC guarantee to > catch, versus the errors which to which a transport-level error chehck > is, empirically, subjected. > > It turns out that, on the best data we (I and Craig Partridge) have on > empirically-observed transport-level errors, CRCs are just not a whole > lot better than a 32-bit mod-M additive sum (where M ~= 2^32). > > This is work in progress, so i cannot give a proper citation (best is > my nearly-complete dissertation). OTOH, Julo Satran saw much of the > raw data at the recent framing/error-control meeting; i'd be very > happy to let Julo make a more impartial comment and see where that > goes. > > > > >The word "integrity" is a better term for (2) to avoid confusion. > > No argument there. The term "reliable transport" shoul,d perhaps, be > understood in contrast to the contatenated-x25-virtual-circuit model > which telcos were offering in serious competition to IP/TCP, once upon > a time. (I think even Bob Braden would buy that.) > From owner-ips@ece.cmu.edu Wed Jul 11 23:33:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00603 for ; Wed, 11 Jul 2001 23:33:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6C1kXT21286 for ips-outgoing; Wed, 11 Jul 2001 21:46:33 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6C1kVg21281 for ; Wed, 11 Jul 2001 21:46:31 -0400 (EDT) Received: from lose (64-171-32-198.netliant.com [64.171.32.198] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with SMTP id SAA31919 for ; Wed, 11 Jul 2001 18:46:38 -0700 From: "Nate Lawson" To: Subject: Record-oriented transport Date: Wed, 11 Jul 2001 18:45:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit What has been the word on SCTP (RFC 2960)? It appears to offer a lot of the record boundary functionality needed for iSCSI/TCP. -Nate From owner-ips@ece.cmu.edu Thu Jul 12 07:04:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01125 for ; Thu, 12 Jul 2001 07:04:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6C7PTg09345 for ips-outgoing; Thu, 12 Jul 2001 03:25:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.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 f6C7PSg09341 for ; Thu, 12 Jul 2001 03:25:28 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id CAA54338; Thu, 12 Jul 2001 02:20:05 -0500 Received: from f4n49e (d03nm065h.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6C7PRJ91942; Thu, 12 Jul 2001 01:25:27 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI Naming: iqn format specification To: Glen Turner Cc: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 12 Jul 2001 00:24:46 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/12/2001 01:25:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Glen, I think you missed the simplicities of the name format stuff. The iqn name begins with the com, or org, etc. It never begins with a number. Example "iqn:com.3com.good.stuff" With the proposal from the Naming and Discovery team (that Mark sent to the full list) the item that makes the String Guaranteed to be unique is adding the enterprise number. And Mark is right the rest of the name (he meant the reverse DNS format), never begins with a number so the above example might become "iqn:1234.com.3com.good.stuff" however there was/is never a problem of the reverse DNS ever conflicting with the Enterprise number. 99.999% of the time the iqn name, without the Enterprise number, will never be a problem. However, the Naming and Discovery team was requested, at the last Face-to-Face Meeting, to enhance the approach and come up with a 100% method for those folks that need/want it. None of us wanted to give up on the simplicity of the iqn approach, so a minor extension using Enterprise number was chosen. Mark was speaking for the whole Naming and Discovery team, and stated what we all support. Most of us will never mess around with a iSCSI name that needs number, and IMHO that is the right answer. . . . John L. Hufferd Senior Technical Staff Member (STSM) IBM/SSG San Jose Ca (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 Internet address: hufferd@us.ibm.com Glen Turner @ece.cmu.edu on 07/11/2001 05:33:58 PM Sent by: owner-ips@ece.cmu.edu To: Mark Bakke cc: IPS Subject: Re: iSCSI Naming: iqn format specification Mark Bakke wrote: > > - Not everyone has or needs one for other purposes; might cause > extra load on IANA-assigned name space, especially if end users, > researchers, or university projects start applying for them. > In the past year, IANA has assigned about 3,000 enterprise > numbers. I'd suggest altering the syntax to allow for OIDs, not just IANA-assigned enterprise numbers. Otherwise people with ISO- assigned numbers are going to end up holding multiple OID allocations, which begins to be administratively nightmareish. This also fixes the "load on IANA" problem. As a real example, OIDs are required for LDAP schema and each organisation can be expected to have a unique LDAP scehema (such as Example Corp having an examplePerson schema). To reduce the load on allocation bodies, AARNet already sub-allocates OIDs to Australian universities out of its ISO allocated space for use in universities' private LDAP schema and any private SNMP MIBs. Because of the OID/LDAP linkage, I'd expect DNS registries to be the ultimate allocators of OIDs. > ... Since a component of a > DNS name cannot start with a digit, there is no risk of confusing > the two. Not so, this requirement was removed some time ago. Consider http://www.3com.com/. It would thus be better to list the namespace explicitly rather than make any assumptions about DNS names. Especially as DNS naming is going to go through some major changes to allow for multilingual names. > - Less transcribable - OUI normally expressed as six-digit hex > number; schemes such as MAC address and EUI-64 are expressed > as 12 to 16-digit numbers. OUIs have a OID form, so the OID form should should be either be required or forbidden to prevent confusion. It probably best to treat the OUI as a 12 or 16 hexdigit number. Using just the OUI is problematic for huge organisations, as they then need to track iSCSI namespace use internally. Assigning a "MAC address" (OUI + 3 octets) to the iSCSI team is easy administratively. Finally, we should use the URI name and format for the namespace where a URI format exists. This is simply for consistency. For example: backwardsdns:au.edu.example.faculty oid:1.32.43.5.3.2.43.2.2.34 oui:2e319c65786e Regards, Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Thu Jul 12 11:09:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03665 for ; Thu, 12 Jul 2001 11:09:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6CCx3G06919 for ips-outgoing; Thu, 12 Jul 2001 08:59:03 -0400 (EDT) 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 f6CCx3g06915 for ; Thu, 12 Jul 2001 08:59:03 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7HXV8>; Thu, 12 Jul 2001 08:57:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A0D@corpmx14.us.dg.com> From: Black_David@emc.com To: nate@decru.com, ips@ece.cmu.edu Subject: RE: Record-oriented transport Date: Thu, 12 Jul 2001 08:55:04 -0400 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 > What has been the word on SCTP (RFC 2960)? It appears to offer a lot of the > record boundary functionality needed for iSCSI/TCP. The word is "do the TCP encapsulations first", at least, I believe that is the rough consensus of the WG. SCTP is well-done in a number of ways, but appears to need some time to settle (e.g., its checksum is in the process of being changed for the better), for implementations to become more widely available and for people to get serious about putting SCTP into hardware. --David (WG co-chair) --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 12 12:21:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14536 for ; Thu, 12 Jul 2001 12:21:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6CELsm12724 for ips-outgoing; Thu, 12 Jul 2001 10:21:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ext1.pirus.com ([4.36.58.197]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6CELqg12720 for ; Thu, 12 Jul 2001 10:21:52 -0400 (EDT) Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21) id <3H228519>; Thu, 12 Jul 2001 10:22:24 -0400 Message-ID: From: "Binford, Charles" To: ips@ece.cmu.edu Subject: RE: iSCSI: Indication of final data-out sequence Date: Thu, 12 Jul 2001 10:22:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Rishabh, The 'Last_Sequence' bit in an FC/FCP exchange would be set on the last frame of the FCP_RSP sequence. It does not "indicates the final data IU for that whole exchange". FCP requires an XFER_RDY to be satisfied with a single sequence of FCP_DATA (data out "phase"). The last frame of that single sequence can be recognized by at least two methods: EOFt (vs. EOFn) and End_Sequence bit in F_CTL. Also, with FCP you can only have one XFER_RDY outstanding at a time. With iSCSI, the F bit tells you when you have received the final PDU of data satisfying an R2T. If you as a target choose to send multiple R2T's, then you expect multiple PDUs with the F bit. Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com] Sent: Thursday, July 05, 2001 6:08 AM To: ips@ece.cmu.edu Subject: Re: iSCSI: Indication of final data-out sequence There is no need for an additional bit. Every outstanding R2T has a target task tag (and a number...) The target has to keep track of what he got and send the status after the last R2T sequence. Thee is also an ordering delivery requirement but that is weaker. Julo Rishabh Srivastav on 05-07-2001 12:18:47 Please respond to Rishabh Srivastav To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: Re: iSCSI: Indication of final data-out sequence Julo, I'm still not convinced. There can be multiple data-out PDU's in response to one R2T. In this case the F bit indicates the end of sequence corresponding to that particular R2T and not for the whole write operation. However, the last_sequence bit in FC-FS is something which indicates the final data IU for that whole exchange. So, how can 'F' bit be equated to the last_sequence bit ?? The semantics of 'F' bit is same as last_sequence bit in the case of Data-In PDUs and not in the case of data-out PDU. Where am i going wrong in my assumptions ? Please clarify. Thanks, Rishabh --- julian_satran@il.ibm.com wrote: > > > the F bit. Julo > > A doubt regarding the final sequence of data-out > PDUs > : My apologies if this had already been discussed > long > time ago. Couldn't locate it in the huge mail > repository. > In FC, the last sequence of an exchange is indicated > by a 'Last_Sequence' bit in F_CTL of FC-FS header. > What is the equivalent of it in iSCSI, specifically > in > the case of Data-Out ? If there is none, will not > the > presence of a similar bit be useful for iSCSI-FCP > gateways ? > > Thanks, > Rishabh > __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-ips@ece.cmu.edu Thu Jul 12 15:44:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13295 for ; Thu, 12 Jul 2001 15:44:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6CHjmq28140 for ips-outgoing; Thu, 12 Jul 2001 13:45:48 -0400 (EDT) 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 f6CHjkg28134 for ; Thu, 12 Jul 2001 13:45:46 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA17018 for ; Thu, 12 Jul 2001 13:45:40 -0400 (EDT) Message-ID: <3B4DE111.F2D60838@cisco.com> Date: Thu, 12 Jul 2001 12:40:33 -0500 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: iSCSI: SLP Template Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am planning to submit a new iSCSI SLP template next Wednesday, to meet the deadline for discussion at the London IETF meeting. For those who wish to comment on the last draft, it's at: http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-00.txt Here are the change I plan to make to the draft this week. Most are minor edits. 1. Fix examples (change from fqn. to iqn.) 2. Add a portal-group tag (aggregation tag) to the iSCSI target template. 3. Fix up references to indicate new draft revisions. 4. Add commentary on using Unicast SLP, as discussed in the prior SendTargets thread. 5. Reference and show how to use the SLP notification mechanism from RFC 3082. This will likely require an interation or two of discussion. Anyway, please send any other comments you might have, especially if you see something missing. Thanks, Mark From owner-ips@ece.cmu.edu Thu Jul 12 17:49:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00129 for ; Thu, 12 Jul 2001 17:49:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6CK8VW09728 for ips-outgoing; Thu, 12 Jul 2001 16:08:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6CK8Ug09723 for ; Thu, 12 Jul 2001 16:08:30 -0400 (EDT) Received: from FRED-W2K.cisco.com (shinjuku-equant-dynamic3.cisco.com [64.104.42.3]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6CK7sT24870; Thu, 12 Jul 2001 13:07:55 -0700 (PDT) Message-Id: <5.1.0.14.2.20010712130929.02a95400@mira-sjcm-2.cisco.com> X-Sender: fred@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 12 Jul 2001 13:09:54 +0800 To: "Nate Lawson" From: Fred Baker Subject: Re: Record-oriented transport Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ips@ece.cmu.edu Precedence: bulk At 09:45 AM 7/12/2001, Nate Lawson wrote: >What has been the word on SCTP (RFC 2960)? It appears to offer a lot of the >record boundary functionality needed for iSCSI/TCP. yup. if you have a need for that, I think SCTP brings a lot to the party. From owner-ips@ece.cmu.edu Thu Jul 12 23:20:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10715 for ; Thu, 12 Jul 2001 23:20:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6D1fFd01875 for ips-outgoing; Thu, 12 Jul 2001 21:41:15 -0400 (EDT) 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 f6D1fEg01871 for ; Thu, 12 Jul 2001 21:41:14 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3MRR2>; Thu, 12 Jul 2001 21:43:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A1E@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI security draft Date: Thu, 12 Jul 2001 21:37:13 -0400 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 I've taken my own advice and sent in a draft: draft-black-iscsi-security-00.txt is coming soon to an Internet-Draft server near you. I'll put it on a web site somewhere and send a URL if the secretariat doesn't get it processed by Monday. Please note that the following sentence appears in the draft's Abstract: This draft is an individual submission that the IP Storage WG is free to adopt, modify, reject, fold, spindle, and/or mutilate as it sees fit. and that the draft is not intended to become an RFC, although portions of it could wind up in places such as a future version of the main iSCSI draft. The draft has a couple of purposes, (1) capturing iSCSI security requirements and related considerations in one place, and (2) providing more information on how SRP could be used to provide keying material for ESP. As a -00 version, the draft is somewhat drafty (preliminary), and in particular I haven't had the time to get any expert security review of the keying mechanism (e.g., I'll be pleasantly surprised if there isn't a security oversight somewhere in the rekeying description). It would be wrong to assume that SRP is the most likely keying mechanism for iSCSI's use of ESP just because I wrote this draft. There are a bunch of other folks working on coming up with a subset of IKE that would be reasonable to use with iSCSI, and every so often I hear musings about how it might be better to just drop ESP and go back to inband digests (I don't agree, FWTW). In any case, because I've written this draft, Elizabeth is now the designated referee (WG chair) for this keying area of iSCSI security. I'll be happy to explain what's in the draft and the associated rationale/reasoning, but she'll be in charge of driving, determining and calling consensus. While this will certainly be discussed in London, I don't think a choice of keying mechanism will be made until the interim meeting so that the FCIP and iFCP folks who are interested in following iSCSI's security direction can have their say. Enjoy and 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Fri Jul 13 14:54:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22878 for ; Fri, 13 Jul 2001 14:54:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DGt6p07512 for ips-outgoing; Fri, 13 Jul 2001 12:55:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from xpost.atlp.com (xpost.atlp.com [208.231.80.136]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6DGt3g07506 for ; Fri, 13 Jul 2001 12:55:04 -0400 (EDT) Received: from wally2qfe3 (wally2qfe3.atlp.com [208.231.80.129]) by xpost.atlp.com (Pro-8.9.3/8.9.3) with SMTP id JAA26254 for ; Fri, 13 Jul 2001 09:39:49 -0700 (PDT) Received: from atlp-exch.atlp.com by atlp.com (SMI-8.6/SMI-SVR4) id JAA18656; Fri, 13 Jul 2001 09:54:26 -0700 Received: by atlp-exch.atlp with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Jul 2001 09:54:25 -0700 Message-ID: <7C769A0EFE7BD411B8A300508BAED11B513234@atlp-exch.atlp> From: Mike Donohoe To: "'ips@ece.cmu.edu'" Subject: iSCSI Check Condition Date: Fri, 13 Jul 2001 09:54:23 -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 Based on the iSCSI 06 spec what is the proper way to handle a check condition when the Initiator is not expecting Input (R=0)? For instance if an initiator sends a SCSI Command CBD=="Rewind" with the R bit set to 0 and there no media in the drive. Then the Target sends a SCSI Response with S=1 and CHECK CONDITION in the Status Field. Then it seems the target should put the sense data at the end of the message, but the Initiator is not expecting any Input. Please clarify my fuzzy understanding. Thank you. Mike Donohoe Quantum | ATL From owner-ips@ece.cmu.edu Fri Jul 13 17:21:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13336 for ; Fri, 13 Jul 2001 17:21:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DJDWL17242 for ips-outgoing; Fri, 13 Jul 2001 15:13:32 -0400 (EDT) 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 f6DJDVg17238 for ; Fri, 13 Jul 2001 15:13:31 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0S4Q1B>; Fri, 13 Jul 2001 15:13:25 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A29@corpmx14.us.dg.com> From: Black_David@emc.com To: mdonohoe@atlp.com, ips@ece.cmu.edu Subject: RE: iSCSI Check Condition Date: Fri, 13 Jul 2001 15:09:28 -0400 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 The short answer is "Autosense is REQUIRED", see section 2.4.5 of -06. If CHECK CONDITION comes back, the Initiator MUST look for the sense data even if the Initiator doesn't expect any response data from a successful command execution, and hence the Target sends the sense data back with the response. --David > -----Original Message----- > From: Mike Donohoe [SMTP:mdonohoe@atlp.com] > Sent: Friday, July 13, 2001 12:54 PM > To: 'ips@ece.cmu.edu' > Subject: iSCSI Check Condition > > > Based on the iSCSI 06 spec what is the proper way to handle a check > condition when the Initiator is not expecting Input (R=0)? > > For instance if an initiator sends a SCSI Command CBD=="Rewind" with > the R bit set to 0 and there no media in the drive. Then the Target sends > a > SCSI Response with S=1 and CHECK CONDITION in the Status Field. Then it > seems the target should put the sense data at the end of the message, but > the Initiator is not expecting any Input. > > Please clarify my fuzzy understanding. > > Thank you. > > Mike Donohoe > Quantum | ATL From owner-ips@ece.cmu.edu Fri Jul 13 18:23:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20800 for ; Fri, 13 Jul 2001 18:23:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DKLm521891 for ips-outgoing; Fri, 13 Jul 2001 16:21:48 -0400 (EDT) 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 f6DKLlg21887 for ; Fri, 13 Jul 2001 16:21:47 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA27127; Fri, 13 Jul 2001 16:21:40 -0400 (EDT) Message-ID: <3B4F571F.17616B98@cisco.com> Date: Fri, 13 Jul 2001 15:16:31 -0500 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: iSCSI: Draft-06+ Linux driver on SourceForge Content-Type: multipart/mixed; boundary="------------319A05C653D337161B2B4BD5" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------319A05C653D337161B2B4BD5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cisco has now released a draft-06+ Linux driver on SourceForge. The home page is at: http://sourceforge.net/projects/linux-iscsi There are currently two versions of the driver available for download: linux-iscsi-1.8.7.5.tgz - Draft-0 (July 2000) driver linux-iscsi-2.0.1.5.tgz - Draft-06+ driver Enjoy, Mark --------------319A05C653D337161B2B4BD5 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: sferris@cisco.com Received: from cisco.com (sferris@sferris-lnx.cisco.com [161.44.68.89]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA08963 for ; Fri, 13 Jul 2001 15:43:04 -0400 (EDT) Sender: sferris Message-ID: <3B4F4F48.F9BC0414@cisco.com> Date: Fri, 13 Jul 2001 14:43:04 -0500 From: "Scott M. Ferris" X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: mbakke@cisco.com Subject: SourceForge Content-Type: text/plain; charset=us-ascii X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit As Matt mentioned, draft-6 is on sourceforge now. Project Page: http://sourceforge.net/projects/linux-iscsi Draft-6 tarball: http://prdownloads.sourceforge.net/linux-iscsi/linux-iscsi-2.0.1.5.tgz -- Scott M. Ferris sferris@cisco.com --------------319A05C653D337161B2B4BD5-- From owner-ips@ece.cmu.edu Fri Jul 13 19:20:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27270 for ; Fri, 13 Jul 2001 19:20:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DMD6528992 for ips-outgoing; Fri, 13 Jul 2001 18:13:06 -0400 (EDT) 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 f6DMD5g28988 for ; Fri, 13 Jul 2001 18:13:05 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 45A4A13DA for ; Fri, 13 Jul 2001 18:13:00 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 144744CD for ; Fri, 13 Jul 2001 16:13:04 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id PAA01888 for ; Fri, 13 Jul 2001 15:13:03 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA6FFA for ; Fri, 13 Jul 2001 15:13:00 -0700 Message-ID: <3B4F7263.CDA707BD@agilent.com> Date: Fri, 13 Jul 2001 15:12:51 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs should not have a CmdSN References: <277DD60FB639D511AC0400B0D068B71E070A2C@corpmx14.us.dg.com> 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: > > What about flow control of commands arriving at the > Target and associated Target resource management? > > This sounds like yet another use for "immediate" > delivery, which I don't recall being > resolved to everyone's satisfaction in prior > discussion. You're right about the flow control. The immediate commands have the same flow control problem, because in their case, the CmdSN is not advanced. From 1.2.2.1: "Commands meant for immediate delivery are marked as such through an immediate delivery flag. They carry the same CmdSN as that which would have been given to a non-immediate command but the CmdSN is not advanced for immediate commands." -Matt From owner-ips@ece.cmu.edu Fri Jul 13 19:23:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27596 for ; Fri, 13 Jul 2001 19:23:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DLwOs28117 for ips-outgoing; Fri, 13 Jul 2001 17:58:24 -0400 (EDT) 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 f6DLwNg28112 for ; Fri, 13 Jul 2001 17:58:23 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7J5AV>; Fri, 13 Jul 2001 17:56:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A2C@corpmx14.us.dg.com> From: Black_David@emc.com To: matt_wakeley@agilent.com, ips@ece.cmu.edu Subject: RE: iSCSI: NOPs should not have a CmdSN Date: Fri, 13 Jul 2001 17:54:19 -0400 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 What about flow control of commands arriving at the Target and associated Target resource management? This sounds like yet another use for "immediate" delivery, which I don't recall being resolved to everyone's satisfaction in prior discussion. --David > -----Original Message----- > From: Matt Wakeley [SMTP:matt_wakeley@agilent.com] > Sent: Friday, July 13, 2001 5:45 PM > To: IPS Reflector > Subject: iSCSI: NOPs should not have a CmdSN > > Normally on an active connection, when a command response is received, the > initiator can acknowledge the response by setting ExpStatSN in the next > command sent. > > However, on a relative inactive connection, it may be some time before the > next command is sent. But the initiator should acknowledge the command > response in a timely fashion so the target can de-allocate the "replay" > resources for the command. The initiator does this by sending NOP. > > However, the NOP requires a CmdSN. CmdSN is managed on a session wide > basis. > StatSN is managed on a connection basis. In the case where there are > multiple > connections active in the session on different iSCSI NICs, the session > manager > that resides in the host manages the CmdSN. Therefore, if the connection > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on an > idle > connection, it must ask the session manager to do so, since it doesn't > have > visibility to the next CmdSN. > > To resolve this complexity, I propose removing CmdSN from the NOP. I see > no > reason why NOPs need to be processed "in order" across the session. > > -Matt Wakeley > Agilent Technologies From owner-ips@ece.cmu.edu Fri Jul 13 20:26:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05618 for ; Fri, 13 Jul 2001 20:26:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DMY5a00349 for ips-outgoing; Fri, 13 Jul 2001 18:34:05 -0400 (EDT) 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 f6DMY4g00344 for ; Fri, 13 Jul 2001 18:34:04 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jul 13 18:32:58 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jul 13 18:33:27 EDT 2001 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 SAA04451; Fri, 13 Jul 2001 18:33:00 -0400 (EDT) Message-ID: <3B4F771C.D46D6131@research.bell-labs.com> Date: Fri, 13 Jul 2001 18:33:00 -0400 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: Black_David@emc.com CC: matt_wakeley@agilent.com, ips@ece.cmu.edu Subject: Re: iSCSI: NOPs should not have a CmdSN References: <277DD60FB639D511AC0400B0D068B71E070A2C@corpmx14.us.dg.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 (cmdSN allocation) was *not* a problem in previous versions (e.g. see NopOut PDU in draft 4), since CmdSN=0 was used to indicate immediate delivery. With the introduction of the immediate flag, we now require an explicit cmdSN to be allocated. As for flow control, shouldn't we make the assumption that immediate commands are executed synchronously (at sender and receiver) and hence there can be only 1 outstanding immediate command ? Currently this is achieved by assigning "maxCmdSN+1" but given the problem Matt pointed out, maybe we should explicitly say cmdSN must be ignored when immediate flag is set. -Sandeep Black_David@emc.com wrote: > > What about flow control of commands arriving at the > Target and associated Target resource management? > > This sounds like yet another use for "immediate" > delivery, which I don't recall being > resolved to everyone's satisfaction in prior > discussion. > > --David > > > -----Original Message----- > > From: Matt Wakeley [SMTP:matt_wakeley@agilent.com] > > Sent: Friday, July 13, 2001 5:45 PM > > To: IPS Reflector > > Subject: iSCSI: NOPs should not have a CmdSN > > > > Normally on an active connection, when a command response is received, the > > initiator can acknowledge the response by setting ExpStatSN in the next > > command sent. > > > > However, on a relative inactive connection, it may be some time before the > > next command is sent. But the initiator should acknowledge the command > > response in a timely fashion so the target can de-allocate the "replay" > > resources for the command. The initiator does this by sending NOP. > > > > However, the NOP requires a CmdSN. CmdSN is managed on a session wide > > basis. > > StatSN is managed on a connection basis. In the case where there are > > multiple > > connections active in the session on different iSCSI NICs, the session > > manager > > that resides in the host manages the CmdSN. Therefore, if the connection > > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on an > > idle > > connection, it must ask the session manager to do so, since it doesn't > > have > > visibility to the next CmdSN. > > > > To resolve this complexity, I propose removing CmdSN from the NOP. I see > > no > > reason why NOPs need to be processed "in order" across the session. > > > > -Matt Wakeley > > Agilent Technologies From owner-ips@ece.cmu.edu Fri Jul 13 21:07:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10248 for ; Fri, 13 Jul 2001 21:07:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6DNi4H04320 for ips-outgoing; Fri, 13 Jul 2001 19:44:04 -0400 (EDT) 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 f6DNi3g04315 for ; Fri, 13 Jul 2001 19:44:03 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3NYYD>; Fri, 13 Jul 2001 19:45:53 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A2E@corpmx14.us.dg.com> From: Black_David@emc.com To: sandeepj@research.bell-labs.com, ips@ece.cmu.edu Subject: RE: iSCSI: NOPs should not have a CmdSN Date: Fri, 13 Jul 2001 19:39:58 -0400 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 for flow control, shouldn't we make the assumption that > immediate commands are executed synchronously (at sender > and receiver) and hence there can be only 1 outstanding > immediate command ? I think this recreates Matt's problem because it requires contacting the session manager to get permission to send the only immediate command - Matt would need at least an immediate command per connection to avoid having to ask permission in this fashion. I suspect this increases the importance of a flow control solution for immediate commands. > Currently this is achieved by assigning > "maxCmdSN+1" but given the problem Matt pointed out, maybe we > should explicitly say cmdSN must be ignored when immediate flag > is set. There's another reason why that might be a good thing to do. In Section 1.2.2.1, near the bottom of page 12, the -06 draft says: For immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1. The target MUST silently ignore any command outside this range The CmdSN in an immediate command will be used by a non-immediate command, so suppose that CmdSN is 6. Receipt of non-immediate command whose CmdSN is 6 (e.g., via a different connection) sets ExpCmdSN at the Target to a larger value, 7 in this example, causing the immediate command to be ignored because its CmdSN (6) is smaller than ExpCmdSN (7). That doesn't strike me as the right result. What is that "MUST silently ignore" protecting us from? Comments? --David > -----Original Message----- > From: Sandeep Joshi [SMTP:sandeepj@research.bell-labs.com] > Sent: Friday, July 13, 2001 6:33 PM > To: Black_David@emc.com > Cc: matt_wakeley@agilent.com; ips@ece.cmu.edu > Subject: Re: iSCSI: NOPs should not have a CmdSN > > > This (cmdSN allocation) was *not* a problem in previous versions (e.g. > see NopOut PDU in draft 4), since CmdSN=0 was used to indicate > immediate delivery. > > With the introduction of the immediate flag, we now require an > explicit cmdSN to be allocated. > > As for flow control, shouldn't we make the assumption that > immediate commands are executed synchronously (at sender > and receiver) and hence there can be only 1 outstanding > immediate command ? Currently this is achieved by assigning > "maxCmdSN+1" but given the problem Matt pointed out, maybe we > should explicitly say cmdSN must be ignored when immediate flag > is set. > > -Sandeep > > Black_David@emc.com wrote: > > > > What about flow control of commands arriving at the > > Target and associated Target resource management? > > > > This sounds like yet another use for "immediate" > > delivery, which I don't recall being > > resolved to everyone's satisfaction in prior > > discussion. > > > > --David > > > > > -----Original Message----- > > > From: Matt Wakeley [SMTP:matt_wakeley@agilent.com] > > > Sent: Friday, July 13, 2001 5:45 PM > > > To: IPS Reflector > > > Subject: iSCSI: NOPs should not have a CmdSN > > > > > > Normally on an active connection, when a command response is received, > the > > > initiator can acknowledge the response by setting ExpStatSN in the > next > > > command sent. > > > > > > However, on a relative inactive connection, it may be some time before > the > > > next command is sent. But the initiator should acknowledge the > command > > > response in a timely fashion so the target can de-allocate the > "replay" > > > resources for the command. The initiator does this by sending NOP. > > > > > > However, the NOP requires a CmdSN. CmdSN is managed on a session wide > > > basis. > > > StatSN is managed on a connection basis. In the case where there are > > > multiple > > > connections active in the session on different iSCSI NICs, the session > > > manager > > > that resides in the host manages the CmdSN. Therefore, if the > connection > > > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on > an > > > idle > > > connection, it must ask the session manager to do so, since it doesn't > > > have > > > visibility to the next CmdSN. > > > > > > To resolve this complexity, I propose removing CmdSN from the NOP. I > see > > > no > > > reason why NOPs need to be processed "in order" across the session. > > > > > > -Matt Wakeley > > > Agilent Technologies From owner-ips@ece.cmu.edu Fri Jul 13 21:58:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16727 for ; Fri, 13 Jul 2001 21:58:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6E0U5a06803 for ips-outgoing; Fri, 13 Jul 2001 20:30:05 -0400 (EDT) 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 f6E0U4g06799 for ; Fri, 13 Jul 2001 20:30:04 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jul 13 20:28:57 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jul 13 20:29:25 EDT 2001 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 UAA07138; Fri, 13 Jul 2001 20:28:58 -0400 (EDT) Message-ID: <3B4F924A.E3F520E6@research.bell-labs.com> Date: Fri, 13 Jul 2001 20:28:58 -0400 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: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs should not have a CmdSN References: <277DD60FB639D511AC0400B0D068B71E070A2E@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Right!..there is still a synchronization problem to get hold of that immediate command slot at the session level. As regards this statement.. > For immediate commands, > the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1. > The target MUST silently ignore any command outside this range This was introduced to enable the initiator to send an immediate command even when the queue is full (max+1 is allowed) This was required for abort tasks. One more thing to note in all this is (i believe) Abort Task management PDUs now have a refCmdSN field (cmdSN of original task) If we could explicitly state the requirements under which immediate commands will be used, maybe we can solve this problem better instead of imposing general constraints on how to deal with the immediate commands, cmdSNs and flow control problems. Are these the only possible cases ? a) Ping commands - can we allow one immediate command per connection and ignore cmdSN field (and solve the problem David pointed out) b) Abort Task commands - do not allocate a cmdSN to only allow one outstanding command OR allow a prenegotiated number (ugh..one more queue to manage!) -Sandeep Black_David@emc.com wrote: > > > As for flow control, shouldn't we make the assumption that > > immediate commands are executed synchronously (at sender > > and receiver) and hence there can be only 1 outstanding > > immediate command ? > > I think this recreates Matt's problem because it requires > contacting the session manager to get permission to send > the only immediate command - Matt would need at least an > immediate command per connection to avoid having to > ask permission in this fashion. I suspect this increases > the importance of a flow control solution for immediate > commands. > > > Currently this is achieved by assigning > > "maxCmdSN+1" but given the problem Matt pointed out, maybe we > > should explicitly say cmdSN must be ignored when immediate flag > > is set. > > There's another reason why that might be a good thing > to do. In Section 1.2.2.1, near the bottom of > page 12, the -06 draft says: > > For immediate commands, > the CmdSN field can take any value from ExpCmdSN to MaxCmdSN+1. > The target MUST silently ignore any command outside this range > > > The CmdSN in an immediate command will be used by a > non-immediate command, so suppose that CmdSN is 6. > Receipt of non-immediate command whose CmdSN is 6 > (e.g., via a different connection) sets ExpCmdSN at > the Target to a larger value, 7 in this example, > causing the immediate command to be ignored because > its CmdSN (6) is smaller than ExpCmdSN (7). That > doesn't strike me as the right result. What is > that "MUST silently ignore" protecting us from? > > Comments? > --David > > > -----Original Message----- > > From: Sandeep Joshi [SMTP:sandeepj@research.bell-labs.com] > > Sent: Friday, July 13, 2001 6:33 PM > > To: Black_David@emc.com > > Cc: matt_wakeley@agilent.com; ips@ece.cmu.edu > > Subject: Re: iSCSI: NOPs should not have a CmdSN > > > > > > This (cmdSN allocation) was *not* a problem in previous versions (e.g. > > see NopOut PDU in draft 4), since CmdSN=0 was used to indicate > > immediate delivery. > > > > With the introduction of the immediate flag, we now require an > > explicit cmdSN to be allocated. > > > > As for flow control, shouldn't we make the assumption that > > immediate commands are executed synchronously (at sender > > and receiver) and hence there can be only 1 outstanding > > immediate command ? Currently this is achieved by assigning > > "maxCmdSN+1" but given the problem Matt pointed out, maybe we > > should explicitly say cmdSN must be ignored when immediate flag > > is set. > > > > -Sandeep > > > > Black_David@emc.com wrote: > > > > > > What about flow control of commands arriving at the > > > Target and associated Target resource management? > > > > > > This sounds like yet another use for "immediate" > > > delivery, which I don't recall being > > > resolved to everyone's satisfaction in prior > > > discussion. > > > > > > --David > > > > > > > -----Original Message----- > > > > From: Matt Wakeley [SMTP:matt_wakeley@agilent.com] > > > > Sent: Friday, July 13, 2001 5:45 PM > > > > To: IPS Reflector > > > > Subject: iSCSI: NOPs should not have a CmdSN > > > > > > > > Normally on an active connection, when a command response is received, > > the > > > > initiator can acknowledge the response by setting ExpStatSN in the > > next > > > > command sent. > > > > > > > > However, on a relative inactive connection, it may be some time before > > the > > > > next command is sent. But the initiator should acknowledge the > > command > > > > response in a timely fashion so the target can de-allocate the > > "replay" > > > > resources for the command. The initiator does this by sending NOP. > > > > > > > > However, the NOP requires a CmdSN. CmdSN is managed on a session wide > > > > basis. > > > > StatSN is managed on a connection basis. In the case where there are > > > > multiple > > > > connections active in the session on different iSCSI NICs, the session > > > > manager > > > > that resides in the host manages the CmdSN. Therefore, if the > > connection > > > > manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on > > an > > > > idle > > > > connection, it must ask the session manager to do so, since it doesn't > > > > have > > > > visibility to the next CmdSN. > > > > > > > > To resolve this complexity, I propose removing CmdSN from the NOP. I > > see > > > > no > > > > reason why NOPs need to be processed "in order" across the session. > > > > > > > > -Matt Wakeley > > > > Agilent Technologies From owner-ips@ece.cmu.edu Sat Jul 14 03:12:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06955 for ; Sat, 14 Jul 2001 03:12:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6E396c15406 for ips-outgoing; Fri, 13 Jul 2001 23:09:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6E0sIg08093 for ; Fri, 13 Jul 2001 20:54:18 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 014973740; Fri, 13 Jul 2001 20:54:07 -0400 (EDT) From: "Dev - Platys" To: "Matt Wakeley" , "IPS Reflector" Subject: RE: iSCSI: NOPs should not have a CmdSN Date: Fri, 13 Jul 2001 17:57:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3B4F6BF4.977EA4EC@agilent.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >To resolve this complexity, I propose removing CmdSN from the NOP. I see no >reason why NOPs need to be processed "in order" across the session. I agree with this proposal. Deva Platys Communications -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Matt Wakeley Sent: Friday, July 13, 2001 2:45 PM To: IPS Reflector Subject: iSCSI: NOPs should not have a CmdSN Normally on an active connection, when a command response is received, the initiator can acknowledge the response by setting ExpStatSN in the next command sent. However, on a relative inactive connection, it may be some time before the next command is sent. But the initiator should acknowledge the command response in a timely fashion so the target can de-allocate the "replay" resources for the command. The initiator does this by sending NOP. However, the NOP requires a CmdSN. CmdSN is managed on a session wide basis. StatSN is managed on a connection basis. In the case where there are multiple connections active in the session on different iSCSI NICs, the session manager that resides in the host manages the CmdSN. Therefore, if the connection manager on an iSCSI NIC wants to send a NOP to acknowledge StatSN on an idle connection, it must ask the session manager to do so, since it doesn't have visibility to the next CmdSN. To resolve this complexity, I propose removing CmdSN from the NOP. I see no reason why NOPs need to be processed "in order" across the session. -Matt Wakeley Agilent Technologies From owner-ips@ece.cmu.edu Sat Jul 14 04:01:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12166 for ; Sat, 14 Jul 2001 04:01:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6E6OTl25449 for ips-outgoing; Sat, 14 Jul 2001 02:24:29 -0400 (EDT) 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 f6E6ORg25444 for ; Sat, 14 Jul 2001 02:24:27 -0400 (EDT) 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 IAA242018 for ; Sat, 14 Jul 2001 08:24:12 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6E6OCm213714 for ; Sat, 14 Jul 2001 08:24:12 +0200 Importance: Normal Subject: Re: iSCSI Check Condition To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 14 Jul 2001 09:30:11 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 14/07/2001 08:24:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk How is that initiator is not expecting status? Any SCSI command (including rewind) ends with status. Julo Mike Donohoe on 13-07-2001 19:54:23 Please respond to Mike Donohoe To: "'ips@ece.cmu.edu'" cc: Subject: iSCSI Check Condition Based on the iSCSI 06 spec what is the proper way to handle a check condition when the Initiator is not expecting Input (R=0)? For instance if an initiator sends a SCSI Command CBD=="Rewind" with the R bit set to 0 and there no media in the drive. Then the Target sends a SCSI Response with S=1 and CHECK CONDITION in the Status Field. Then it seems the target should put the sense data at the end of the message, but the Initiator is not expecting any Input. Please clarify my fuzzy understanding. Thank you. Mike Donohoe Quantum | ATL From owner-ips@ece.cmu.edu Sat Jul 14 12:40:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07347 for ; Sat, 14 Jul 2001 12:40:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6EF4AU01379 for ips-outgoing; Sat, 14 Jul 2001 11:04:10 -0400 (EDT) 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 f6EF48g01375 for ; Sat, 14 Jul 2001 11:04:08 -0400 (EDT) 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 RAA352306 for ; Sat, 14 Jul 2001 17:03:57 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6EF3vW48490 for ; Sat, 14 Jul 2001 17:03:57 +0200 Importance: Normal Subject: RE: iSCSI: NOPs should not have a CmdSN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 14 Jul 2001 18:09:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 14/07/2001 18:03:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The need to reject immediate commands came up several times during recovery discussions. NOP with CmdsN was there to allow checking the "delivery machine" end-to-end. The text for CmdSN in case of retry had also some points that needed clarification. Here is the (more liberal) text for numbering commands: 1.1.1.1 Command Numbering and Acknowledging iSCSI supports ordered command delivery within a session. All commands (initiator-to-target PDUs) are numbered. Any SCSI activity is related to a task (SAM-2). The task is identified by the Initiator Task Tag for the life of the task. Commands in transit from the initiator to the target layer are numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN (Command-Sequence-Number). The numbering is session-wide. All outgoing iSCSI PDUs that have a task association, except Data-Out, carry this number. CmdSNs are allocated by the initiator iSCSI within a 32-bit unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSN SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32. Commands meant for immediate delivery are marked as such through an immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not advanced for commands marked for immediate delivery. If immediate delivery is used with task management commands, these commands may reach the SCSI target task management before the tasks they are supposed to act upon. However, their CmdSN is a good reference for what commands the immediate command was supposed to act upon; to achieve this function the task management command MUST be the same CmdSN as that which would have been given to the next non-immediate command. Not covered in this document are the means by which one may request immediate delivery for a command or by which iSCSI will decide by itself to mark a PDU for immediate delivery. Please note that the number of commands used for immediate delivery is not limited and their delivery to execution is not acknowledged through the numbering scheme. Immediate commands can be rejected by the iSCSI target due to lack of resources. An iSCSI target MUST be able to handle at least one immediate task management command and one immediate non-task-management iSCSI request at any time. Except for the commands marked for immediate delivery the iSCSI target layer MUST deliver the commands for execution in the order specified by CmdSN. Commands marked for immediate delivery may be handed over by the iSCSI target layer for execution as soon as detected. iSCSI may avoid delivering some command for execution if so required by some prior SCSI or iSCSI action (e.g., clear task set Task Management request received before all the commands it was supposed to act on). The initiator and target are assumed to have three registers, unique session wide, that define the numbering mechanism: - CmdSN - the current command Sequence Number advanced by 1 on each command shipped except for commands marked for immediate delivery. - ExpCmdSN - the next expected command by the target. The target acknowledges all commands up to but not including this number. The target iSCSI layer sets the ExpCmdSN to the largest non-immediate CmdSN that it is able to deliver for execution plus 1 (no holes in the CmdSN sequence). - MaxCmdSN - the maximum number to be shipped. The queuing capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. MaxCmdSN and ExpCmdSN fields are processed as follows: -if the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), they are both ignored -if the PDU MaxCmdSN is less than the local MaxCmdSN (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), it is ignored; else it updates the local MaxCmdSN -if the PDU ExpCmdSN is less than the local ExpCmdSN (in Serial Arithmetic Sense and with a difference bounded by 2**31-1), it is ignored; else it updates the local ExpCmdSN This sequence is required as updates may arrive out of order because they travel on different TCP connections. The target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above the last ExpCmdSN. For non-immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN. The target MUST silently ignore any non-immediate command outside this range or non-immediate duplicates within the range that have not been flagged with the retry bit (the X bit in the opcode). iSCSI initiators and targets MUST support the command numbering scheme. A numbered iSCSI command will not change its allocated CmdSN regardless of the number of times and circumstances in which it is reissued. At the target, it is assumed that CmdSN is relevant only while the command has not created any execution state (can't find the Initiator Task Tag). Afterwards CmdSN becomes irrelevant. Testing for execution state is assumed to precede any other action at the target and is followed by ordering and delivery if no execution state is found or delivery if execution state is found. Immediate commands can't be retried unless there is execution state available at the target for them (they are rejected for retry if the target can't find the Initiator Task Tag). Julo From owner-ips@ece.cmu.edu Sat Jul 14 17:53:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09964 for ; Sat, 14 Jul 2001 17:53:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6EJsZO16612 for ips-outgoing; Sat, 14 Jul 2001 15:54:35 -0400 (EDT) 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 f6EJsYg16608 for ; Sat, 14 Jul 2001 15:54:34 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 50D0B13D9 for ; Sat, 14 Jul 2001 15:54:29 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 0C358CF for ; Sat, 14 Jul 2001 13:54:33 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id MAA11746 for ; Sat, 14 Jul 2001 12:54:31 -0700 (PDT) Received: from agilent.com (cos1nai132041.cos.agilent.com [141.184.132.41]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with SMTP id AAA1B34 for ; Sat, 14 Jul 2001 12:54:29 -0700 Message-ID: <3B50A372.4126C63D@agilent.com> Date: Sat, 14 Jul 2001 12:54:26 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: NOPs should not have a CmdSN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit To improve clarity, I suggest wording along the lines of "The CmdSN is reserved for Non task management immediate commands. Immediate task management commands MUST use the next valid CmdSN..." -Matt Julian Satran wrote: > Commands meant for immediate delivery are marked as such through an > immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not > advanced for commands marked for immediate delivery. > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to achieve > this function the task management command MUST be the same CmdSN as that > which would have been given to the next non-immediate command. From owner-ips@ece.cmu.edu Sun Jul 15 05:04:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21314 for ; Sun, 15 Jul 2001 05:04:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6F4BEO11814 for ips-outgoing; Sun, 15 Jul 2001 00:11:14 -0400 (EDT) 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 f6F4BCg11810 for ; Sun, 15 Jul 2001 00:11:12 -0400 (EDT) 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 GAA75818 for ; Sun, 15 Jul 2001 06:11:05 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6F4B4W175472 for ; Sun, 15 Jul 2001 06:11:04 +0200 Importance: Normal Subject: Re: iSCSI: NOPs should not have a CmdSN To: Matt Wakeley Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sun, 15 Jul 2001 07:17:02 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 15/07/2001 06:11:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Matt, The current wording enables the use of CmdSN as the vendor sees fit and attaches meaning only where it is required. This way you can invent text commands that use CmdSN! Julo Please respond to Matt Wakeley To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: NOPs should not have a CmdSN To improve clarity, I suggest wording along the lines of "The CmdSN is reserved for Non task management immediate commands. Immediate task management commands MUST use the next valid CmdSN..." -Matt Julian Satran wrote: > Commands meant for immediate delivery are marked as such through an > immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not > advanced for commands marked for immediate delivery. > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to achieve > this function the task management command MUST be the same CmdSN as that > which would have been given to the next non-immediate command. From owner-ips@ece.cmu.edu Sun Jul 15 11:12:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00841 for ; Sun, 15 Jul 2001 11:12:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6FDXxe19567 for ips-outgoing; Sun, 15 Jul 2001 09:33:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6F5Tag15696 for ; Sun, 15 Jul 2001 01:29:36 -0400 (EDT) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Sat, 14 Jul 2001 22:29:33 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from nt-irva-0701.broadcom.com (nt-irva-0701 [10.5.10.97]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id WAA20985; Sat, 14 Jul 2001 22:29:33 -0700 (PDT) Received: by nt-irva-0701.broadcom.com with Internet Mail Service ( 5.5.2650.21) id <3P74DHR0>; Sat, 14 Jul 2001 22:29:34 -0700 Message-ID: <8DC1D21AADB9D411A6A000508BC7405A6A156D@nt-irva-0701.broadcom.com> From: "Uri Elzur" To: "Matt Wakeley" , "IPS Reflector" Subject: RE: Preliminary London dates/times Date: Sat, 14 Jul 2001 22:29:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 174FF5B727369-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Maybe we can have one meeting dedicated to iSCSI issues and the other for FCIP/iFCP this will minimize the effect to some extent. I still hope these meeting times will change Uri -----Original Message----- From: Matt Wakeley [mailto:matt_wakeley@agilent.com] Sent: Tuesday, July 10, 2001 2:00 PM To: IPS Reflector Subject: Re: Preliminary London dates/times cool! 2 days of meetings, and 3 days of company paid london vacation! [I love how efficient this IETF organization is] -Matt Black_David@emc.com wrote: > > This should appear on the IETF web site tomorrow, but here > are the preliminary meeting times for the IP Storage WG > during the London IETF meeting week. > > WARNING: These are SUBJECT TO CHANGE until > the final agenda is posted sometime after July 16th. > > Monday, August 6th, 1930-2200 > Friday, August 10th, 0900-1130 > > 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Jul 15 15:30:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19079 for ; Sun, 15 Jul 2001 15:30:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6FI40P03834 for ips-outgoing; Sun, 15 Jul 2001 14:04:00 -0400 (EDT) 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 f6FI3xg03828 for ; Sun, 15 Jul 2001 14:03:59 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id D2A5E10C0 for ; Sun, 15 Jul 2001 14:03:53 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 75868A12 for ; Sun, 15 Jul 2001 12:03:57 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id LAA13852 for ; Sun, 15 Jul 2001 11:03:56 -0700 (PDT) Received: from agilent.com (cos1nai131191.cos.agilent.com [141.184.131.191]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with SMTP id AAA3026 for ; Sun, 15 Jul 2001 11:03:54 -0700 Message-ID: <3B51DB07.A3E3F00D@agilent.com> Date: Sun, 15 Jul 2001 11:03:51 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iSCSI: NOPs should not have a CmdSN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The text is not clear if CmdSN is advanced for task management commands (I think it should be). I don't understand what you mean by "invent text commands that use CmdSN!". Text commands already use CmdSN. -Matt Julian Satran wrote: > > Matt, > > The current wording enables the use of CmdSN as the vendor sees fit and > attaches meaning only where > it is required. This way you can invent text commands that use CmdSN! > > Julo > > Please respond to Matt Wakeley > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: NOPs should not have a CmdSN > > To improve clarity, I suggest wording along the lines of "The CmdSN is > reserved for Non task management immediate commands. Immediate task > management commands MUST use the next valid CmdSN..." > > -Matt > > Julian Satran wrote: > > > Commands meant for immediate delivery are marked as such through an > > immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not > > advanced for commands marked for immediate delivery. > > > If immediate delivery is used with task management commands, these > > commands may reach the SCSI target task management before the tasks > they > > are supposed to act upon. However, their CmdSN is a good reference > for > > what commands the immediate command was supposed to act upon; to > achieve > > this function the task management command MUST be the same CmdSN as > that > > which would have been given to the next non-immediate command. From owner-ips@ece.cmu.edu Sun Jul 15 15:33:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19401 for ; Sun, 15 Jul 2001 15:33:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6FHvaO03492 for ips-outgoing; Sun, 15 Jul 2001 13:57:36 -0400 (EDT) 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.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6FHvZg03487 for ; Sun, 15 Jul 2001 13:57:35 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id DCB9F14B5 for ; Sun, 15 Jul 2001 11:57:34 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 86BDD715 for ; Sun, 15 Jul 2001 11:57:34 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id KAA13818 for ; Sun, 15 Jul 2001 10:57:33 -0700 (PDT) Received: from agilent.com (cos1nai131191.cos.agilent.com [141.184.131.191]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with SMTP id AAA2F7B for ; Sun, 15 Jul 2001 10:57:31 -0700 Message-ID: <3B51D987.28F6A5C1@agilent.com> Date: Sun, 15 Jul 2001 10:57:27 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: Preliminary London dates/times References: <8DC1D21AADB9D411A6A000508BC7405A6A156D@nt-irva-0701.broadcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit There are no "FC" related topics, because there is a T11 (FC) meeting going on the same week. All "FC" related discussion was moved to a different meeting. Why not move *all* IPS meetings to that meeting, and not have any IPS meetings during IETF? -Matt Uri Elzur wrote: > > Maybe we can have one meeting dedicated to iSCSI issues and the other for > FCIP/iFCP this will minimize the effect to some extent. I still hope these > meeting times will change > > Uri > > -----Original Message----- > From: Matt Wakeley [mailto:matt_wakeley@agilent.com] > Sent: Tuesday, July 10, 2001 2:00 PM > To: IPS Reflector > Subject: Re: Preliminary London dates/times > > cool! 2 days of meetings, and 3 days of company paid london vacation! > > [I love how efficient this IETF organization is] > > -Matt > > Black_David@emc.com wrote: > > > > This should appear on the IETF web site tomorrow, but here > > are the preliminary meeting times for the IP Storage WG > > during the London IETF meeting week. > > > > WARNING: These are SUBJECT TO CHANGE until > > the final agenda is posted sometime after July 16th. > > > > Monday, August 6th, 1930-2200 > > Friday, August 10th, 0900-1130 > > > > 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 > > --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Jul 15 22:20:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04869 for ; Sun, 15 Jul 2001 22:20:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6FLifP15228 for ips-outgoing; Sun, 15 Jul 2001 17:44:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.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 f6FLieg15224 for ; Sun, 15 Jul 2001 17:44:40 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA54246; Sun, 15 Jul 2001 16:39:18 -0500 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6FLici136950; Sun, 15 Jul 2001 15:44:38 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: Preliminary London dates/times To: Matt Wakeley Cc: IPS Reflector X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 15 Jul 2001 14:44:13 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/15/2001 03:44:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Easy, folks, Matt is correct that the IPS section of the meeting in London is all iSCSI. We have 5 hours, and we are allocating the topics into that schedule, and guess what, all that time is needed for what we need to close on. David is trying to get the meeting times closer together. But if not, I am sure that many of us can use the time in between for many useful activities. . . . 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 Internet address: hufferd@us.ibm.com "Matt Wakeley" @ece.cmu.edu on 07/15/2001 10:57:27 AM Please respond to Matt Wakeley Sent by: owner-ips@ece.cmu.edu To: IPS Reflector cc: Subject: Re: Preliminary London dates/times There are no "FC" related topics, because there is a T11 (FC) meeting going on the same week. All "FC" related discussion was moved to a different meeting. Why not move *all* IPS meetings to that meeting, and not have any IPS meetings during IETF? -Matt Uri Elzur wrote: > > Maybe we can have one meeting dedicated to iSCSI issues and the other for > FCIP/iFCP this will minimize the effect to some extent. I still hope these > meeting times will change > > Uri > > -----Original Message----- > From: Matt Wakeley [mailto:matt_wakeley@agilent.com] > Sent: Tuesday, July 10, 2001 2:00 PM > To: IPS Reflector > Subject: Re: Preliminary London dates/times > > cool! 2 days of meetings, and 3 days of company paid london vacation! > > [I love how efficient this IETF organization is] > > -Matt > > Black_David@emc.com wrote: > > > > This should appear on the IETF web site tomorrow, but here > > are the preliminary meeting times for the IP Storage WG > > during the London IETF meeting week. > > > > WARNING: These are SUBJECT TO CHANGE until > > the final agenda is posted sometime after July 16th. > > > > Monday, August 6th, 1930-2200 > > Friday, August 10th, 0900-1130 > > > > 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 > > --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 16 09:12:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04558 for ; Mon, 16 Jul 2001 09:12:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GBMQL07901 for ips-outgoing; Mon, 16 Jul 2001 07:22:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from SANSRV1.SAN-RAD.CO.IL ([212.199.104.226]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6GBM3g07852 for ; Mon, 16 Jul 2001 07:22:05 -0400 (EDT) content-class: urn:content-classes:message Subject: ISCSI MIB MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 16 Jul 2001 14:22:56 +0200 Disposition-Notification-To: "Michele Hallak - Stamler" X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Message-ID: <838D8D2617300146B7F47E4D9AE7FF101124F8@SANSRV1.SAN-RAD.CO.IL> Thread-Topic: ISCSI MIB Thread-Index: AcEN8gFc2wkVyXjsEdWQRQACsy5SCw== From: "Michele Hallak - Stamler" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f6GBM8g07855 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, I'm new in the storage group and in iSCSI specially. Are there any reason why the iSCSI MIB is almost read-only? Why a manager cannot create a target for example? Thanks for enlightning me, Michele From owner-ips@ece.cmu.edu Mon Jul 16 11:13:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00133 for ; Mon, 16 Jul 2001 11:13:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GDVB915187 for ips-outgoing; Mon, 16 Jul 2001 09:31:11 -0400 (EDT) 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 f6GDV9g15181 for ; Mon, 16 Jul 2001 09:31:09 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA23498 for ; Mon, 16 Jul 2001 09:31:03 -0400 (EDT) Message-ID: <3B52EB5A.A55FFC42@cisco.com> Date: Mon, 16 Jul 2001 08:25:46 -0500 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: Re: iSCSI: SLP Template References: <3B4DE111.F2D60838@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 am planning on one additional change to the SLP template, which is the removal of the ability to register a default target. Only individual, named targets will be registered. -- Mark Mark Bakke wrote: > > I am planning to submit a new iSCSI SLP template next > Wednesday, to meet the deadline for discussion at the > London IETF meeting. > > For those who wish to comment on the last draft, it's at: > > http://search.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-00.txt > > Here are the change I plan to make to the draft this week. > Most are minor edits. > > 1. Fix examples (change from fqn. to iqn.) > > 2. Add a portal-group tag (aggregation tag) to the iSCSI > target template. > > 3. Fix up references to indicate new draft revisions. > > 4. Add commentary on using Unicast SLP, as discussed in the > prior SendTargets thread. > > 5. Reference and show how to use the SLP notification mechanism > from RFC 3082. This will likely require an interation or two of > discussion. > > Anyway, please send any other comments you might have, especially > if you see something missing. > > Thanks, > > Mark -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 11:14:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00459 for ; Mon, 16 Jul 2001 11:14:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GDbmL15599 for ips-outgoing; Mon, 16 Jul 2001 09:37:48 -0400 (EDT) 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 f6GDblg15595 for ; Mon, 16 Jul 2001 09:37:47 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA03941; Mon, 16 Jul 2001 09:37:33 -0400 (EDT) Message-ID: <3B52ECE0.D3CF467B@cisco.com> Date: Mon, 16 Jul 2001 08:32:16 -0500 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: Glen Turner CC: IPS Subject: Re: iSCSI Naming: iqn format specification References: <3B4CC17F.DCAD14F4@cisco.com> <3B4CF076.F7C725D1@aarnet.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Turner wrote: > > Mark Bakke wrote: > > > > - Not everyone has or needs one for other purposes; might cause > > extra load on IANA-assigned name space, especially if end users, > > researchers, or university projects start applying for them. > > In the past year, IANA has assigned about 3,000 enterprise > > numbers. > > I'd suggest altering the syntax to allow for OIDs, not just > IANA-assigned enterprise numbers. Otherwise people with ISO- > assigned numbers are going to end up holding multiple OID > allocations, which begins to be administratively nightmareish. > > This also fixes the "load on IANA" problem. Actually, the load on IANA problem is probably not all that bad. Most companies, particularly hardware or software manufacturers, that want to protect themselves in this way already have an enterprise number to use in their MIB. > As a real example, OIDs are required for LDAP schema and each > organisation can be expected to have a unique LDAP scehema (such > as Example Corp having an examplePerson schema). To reduce the > load on allocation bodies, AARNet already sub-allocates OIDs to > Australian universities out of its ISO allocated space for use > in universities' private LDAP schema and any private SNMP MIBs. I agree that OIDs would in theory be more flexible, since they include enterprise numbers, but in practise most everyone who will care about this has an enterprise number anyway, and they are easy to obtain. I would rather leave it simple. > Because of the OID/LDAP linkage, I'd expect DNS registries to > be the ultimate allocators of OIDs. > > > ... Since a component of a > > DNS name cannot start with a digit, there is no risk of confusing > > the two. > > Not so, this requirement was removed some time ago. Consider > http://www.3com.com/. I'll fix my text; I meant to say that the first component (com, org, ...) cannot start with a digit. The 3com example is still OK, as John had shown. > It would thus be better to list the namespace explicitly rather > than make any assumptions about DNS names. Especially as DNS > naming is going to go through some major changes to allow for > multilingual names. > > > - Less transcribable - OUI normally expressed as six-digit hex > > number; schemes such as MAC address and EUI-64 are expressed > > as 12 to 16-digit numbers. > > OUIs have a OID form, so the OID form should should be either be required > or forbidden to prevent confusion. OUIs have been removed as a possibility; anyone wanting to use an OUI should use the eui. format. > It probably best to treat the OUI as a 12 or 16 hexdigit number. > Using just the OUI is problematic for huge organisations, as they > then need to track iSCSI namespace use internally. Assigning > a "MAC address" (OUI + 3 octets) to the iSCSI team is easy > administratively. > > Finally, we should use the URI name and format for the namespace > where a URI format exists. This is simply for consistency. > > For example: > backwardsdns:au.edu.example.faculty > oid:1.32.43.5.3.2.43.2.2.34 > oui:2e319c65786e I had suggested this before, in my draft on iSCSI URNs; the IESG completely shot this down, and I'm still not sure why. Anyway, I don't have the energy to push the URN/URI thing any further. > Regards, > Glen > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 11:42:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05123 for ; Mon, 16 Jul 2001 11:42:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GEIPF18705 for ips-outgoing; Mon, 16 Jul 2001 10:18:25 -0400 (EDT) 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 f6GEINg18700 for ; Mon, 16 Jul 2001 10:18:23 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3PBWA>; Mon, 16 Jul 2001 10:20:14 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A34@corpmx14.us.dg.com> From: Black_David@emc.com To: matt_wakeley@agilent.com Cc: ips@ece.cmu.edu Subject: RE: Preliminary London dates/times Date: Mon, 16 Jul 2001 10:14:06 -0400 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 > There are no "FC" related topics, because there is a T11 (FC) meeting going on > the same week. All "FC" related discussion was moved to a different meeting. > Why not move *all* IPS meetings to that meeting, and not have any IPS meetings > during IETF? I share some of Matt's frustration with the London logistics - between the T11 conflict, the London location making corporate travel restrictions harder to deal with, and the Monday to Friday gap between the currently scheduled IPS sessions, this is a distinct step down from what we've gotten used to from the past two IETF meetings. As John noted, I've been trying to do something about the Monday to Friday gap between meeting sessions - something will either happen or not n the next few days as the meeting slot assignments become final. I've been keeping this quiet because publicly bashing the overworked staff at the IETF secretariat is generally not productive (e.g., want to try to hold an IPS WG meeting in a closet?). One of the reasons for IETF meeting weeks is that there are issues that span working groups and areas in the IETF - for IPS and iSCSI, these include security, framing, and discovery, just to name three issues that we're actively working on. Having people with expertise and experience in these related topics in the same place at the same time is conducive to making progress on them. This is considered to be crucially important by those with some familiarity with the IETF (including yours truly) and pays off regularly, sometimes in ways that one would not expect in advance. Remember that it's not just up to the visibly active members of the IPS WG to decide what goes into our RFCs - we have IPS WG Last Call, IETF Last Call, and IESG Approval to go through, and wider exposure of what we're doing helps get technical issues identified and raised earlier in the standards development process. Also, FWIW ... if we cancel the IPS meetings in London, the ADs will cancel the August interim meeting for us, leaving us in a position of having to beg for one 2-2.5 hour slot in Salt Lake in December. Needless to say, that's not a desirable outcome. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 16 12:42:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18064 for ; Mon, 16 Jul 2001 12:42:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GCodZ12711 for ips-outgoing; Mon, 16 Jul 2001 08:50:39 -0400 (EDT) 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 f6GCocg12707 for ; Mon, 16 Jul 2001 08:50:38 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA17103; Mon, 16 Jul 2001 08:50:30 -0400 (EDT) Message-ID: <3B52E1DA.A364B829@cisco.com> Date: Mon, 16 Jul 2001 07:45:14 -0500 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: Michele Hallak - Stamler CC: ips@ece.cmu.edu Subject: Re: ISCSI MIB References: <838D8D2617300146B7F47E4D9AE7FF101124F8@SANSRV1.SAN-RAD.CO.IL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michele- Targets (and the logical units that are behind them) are created at the SCSI level; iSCSI only provides addressing for these. Since we don't have a way to create and destroy targets and LUs at the SCSI level (there's no SCSI MIB yet), there's not much point in allowing SETs in iSCSI, either. Most people are counting on using other interfaces, such as CIM, for doing this type of configuration, rather than using SNMP. With any luck, we'll have some sort of effort (probably within SNIA) to define CIM models for these. -- Mark Michele Hallak - Stamler wrote: > > Hi, > I'm new in the storage group and in iSCSI specially. > Are there any reason why the iSCSI MIB is almost read-only? > Why a manager cannot create a target for example? > Thanks for enlightning me, > > Michele -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 12:48:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19684 for ; Mon, 16 Jul 2001 12:48:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GCVAG11566 for ips-outgoing; Mon, 16 Jul 2001 08:31:10 -0400 (EDT) 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 f6GCV5g11559 for ; Mon, 16 Jul 2001 08:31:05 -0400 (EDT) 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 OAA142480 for ; Mon, 16 Jul 2001 14:30:56 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6GCUtE67832 for ; Mon, 16 Jul 2001 14:30:55 +0200 Importance: Normal Subject: Re: iSCSI: Iterating long text responses To: Mark Bakke Cc: "IPS X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Mon, 16 Jul 2001 15:24:53 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 16/07/2001 14:30:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think that both 4 and 5 involve in fact some state to be kept at the target between PDUs sent in something related to to a "task control block" if we assume that all the text commands carry the same ITT. 4 enables the initiator to reuse its parse buffer while 5 requires the initiator to allocate a buffer for all the text responses (or keep the pipe closed). 4 is simpler than 5. If you add to 4 a handle that the initiator has to give back the target next time (the bookmark) then the target does not have to keep state. A 0 bookmark says start from the top. It is very much like an offset (that was mentioned) but it is generic and opaque. Regards, Julo Mark Bakke on 29-06-2001 23:18:20 Please respond to Mark Bakke To: IPS cc: Subject: iSCSI: Iterating long text responses Initiator developers- Please respond to the questions at the end. Thanks, Mark The current iSCSI draft allows text command and response PDUs of up to 4096 bytes. While we don't see any real problems for the command PDU size, commands such as SendTargets can easily exceed the response size. There are several ways we can fix this. The first two solutions require no differences in the current iSCSI text command and response; the latter three involve the use of the F bit. 1. Assume that such commands are done on a "special" connection or are handled completely in software, and allow its response PDU to be as large as it needs to be. This one appears too restrictive to be a solid solution. It will also weaken any data digests done on the longer PDU. 2. Create an iterative SendTargets key (and do the same for any other text commands that need this), that would allow the initiator to request the "next target" or "next address". This would work, but would require any new command that needed a large response to implement an iterator. It also means that each part of the response from the iterator would have to fit in the 4k PDU. The remainder of these require that only one text command sequence be outstanding on a connection at a given time. They use the F bit to indicate the last PDU of the sequence. Note that connection allegiance is assumed for the entire sequence, and text commands are never retried on another connection; a new command is issued instead. 3. Do a text-response R2T, where the initiator controls when the next partial response is sent. This would be more generic: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) I->T Text Command (with some indicator that we want more) T->I Text Response (next PDU, F bit cleared) ... I->T Text Command (with indicator that we want more) T->I Text Response (last PDU, F bit set) The main problem with this is that the target must keep track of the state of its responses; if the initiator just stops asking, it may have to keep a buffered response around until it times out, the connection is dropped, or another text command comes along. 4. Allow multiple response PDUs to a single text command: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) T->I Text Response (next PDU, F bit cleared) ... T->I Text Response (last PDU, F bit set) Basically, we are doing (3) without the R2T. The initiator, upon sending the text command, must be prepared either to accept as many PDUs as come back, or throw them away if it can't handle them. This solution is a lot like #1, but with the response spread across 4k PDUs. Also note that this (and the following scheme) avoid the problem of the target keeping state; it sends ALL of the response PDUs without the initiator asking for them. 5. Do #4, but allow the initiator to specify the amount of data it is willing to accept: I->T Text Command (F bit set, AcceptResponseLength=4096) T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) In the above example, we have created a new text command field: AcceptResponseLength And in the text response PDU: TotalResponseLength The initiator indicated it was willing to accept a 4k response. The target returned the first 4k in the text response, but set the F bit since it was at its limit. It also returned a TotalResponseLength field. Since this was greater than the AcceptResponseLength, the initiator knows the amount of buffer space it will need to get the full response. It can then choose whether it will re-send the command, and if so, can give it a large enough response length: I->T Text Command (F bit set, AcceptResponseLength=12288) T->I Text Response (first PDU, F bit clear) T->I Text Response (next PDU, F bit clear) T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) Note that most initiators will probably send an AcceptResponseLength of the largest response they would normally accept, and that most target responses will fit in one or a few PDUs anyway. #5 is really a compromise between #3 and #4; the target has the benefit of being less statefull, and the initiator has the benefit of controlling the amount of data it receives. I would like to recommend either #4 or #5. I think that #5 is probably the safest solution, but #4 may not be a problem for anyone. Assuming that none of the implementors of initiators have a problem with #4, I would pick that. If they do have a problem with it, we should go with #5. Targets probably don't care much whether we do #4 or #5. Initiator developers- Please indicate which solution (#4 or #5) appeals to you. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 13:53:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04496 for ; Mon, 16 Jul 2001 13:53:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GG0ce26527 for ips-outgoing; Mon, 16 Jul 2001 12:00:38 -0400 (EDT) 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 f6GG0Zg26521 for ; Mon, 16 Jul 2001 12:00:35 -0400 (EDT) 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 LAA32624 for ; Mon, 16 Jul 2001 11:52:32 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.96.1.0) with ESMTP id f6GG0Wi226444 for ; Mon, 16 Jul 2001 10:00:32 -0600 Importance: Normal Subject: Re: iSCSI: Iterating long text responses To: "Julian Satran" Cc: "IPS From: "Jim Hafner" Date: Mon, 16 Jul 2001 09:00:28 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/16/2001 09:00:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, On the other hand, 5 is closer to a READ operation (and aren't we talking about something like an iSCSI read). For both 4 and 5, the only state needed between PDUs is within the context of the same command (as is the case for a read), not between commands. 5 is a bit more efficient in that the target only sends (and prepares to send) the amont of data requested. And in 4, there's extra wire traffic for no reason (when the initiator isn't prepared for all the data). Admittedly, it's not a lot, but ... How does use of a bookmark not imply state? Doesn't the target have to keep the reference of the bookmark to the data between commands? Is the bookmark valid only for the one initiator or for all initiators? What happens if the data set changes between commands? What if the bookmark is no longer valid? I think 5 is the right approach. Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/16/2001 05:24:53 am Sent by: owner-ips@ece.cmu.edu To: Mark Bakke cc: "IPS Subject: Re: iSCSI: Iterating long text responses I think that both 4 and 5 involve in fact some state to be kept at the target between PDUs sent in something related to to a "task control block" if we assume that all the text commands carry the same ITT. 4 enables the initiator to reuse its parse buffer while 5 requires the initiator to allocate a buffer for all the text responses (or keep the pipe closed). 4 is simpler than 5. If you add to 4 a handle that the initiator has to give back the target next time (the bookmark) then the target does not have to keep state. A 0 bookmark says start from the top. It is very much like an offset (that was mentioned) but it is generic and opaque. Regards, Julo Mark Bakke on 29-06-2001 23:18:20 Please respond to Mark Bakke To: IPS cc: Subject: iSCSI: Iterating long text responses Initiator developers- Please respond to the questions at the end. Thanks, Mark The current iSCSI draft allows text command and response PDUs of up to 4096 bytes. While we don't see any real problems for the command PDU size, commands such as SendTargets can easily exceed the response size. There are several ways we can fix this. The first two solutions require no differences in the current iSCSI text command and response; the latter three involve the use of the F bit. 1. Assume that such commands are done on a "special" connection or are handled completely in software, and allow its response PDU to be as large as it needs to be. This one appears too restrictive to be a solid solution. It will also weaken any data digests done on the longer PDU. 2. Create an iterative SendTargets key (and do the same for any other text commands that need this), that would allow the initiator to request the "next target" or "next address". This would work, but would require any new command that needed a large response to implement an iterator. It also means that each part of the response from the iterator would have to fit in the 4k PDU. The remainder of these require that only one text command sequence be outstanding on a connection at a given time. They use the F bit to indicate the last PDU of the sequence. Note that connection allegiance is assumed for the entire sequence, and text commands are never retried on another connection; a new command is issued instead. 3. Do a text-response R2T, where the initiator controls when the next partial response is sent. This would be more generic: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) I->T Text Command (with some indicator that we want more) T->I Text Response (next PDU, F bit cleared) ... I->T Text Command (with indicator that we want more) T->I Text Response (last PDU, F bit set) The main problem with this is that the target must keep track of the state of its responses; if the initiator just stops asking, it may have to keep a buffered response around until it times out, the connection is dropped, or another text command comes along. 4. Allow multiple response PDUs to a single text command: I->T Text Command (F bit set) T->I Text Response (first PDU, F bit cleared) T->I Text Response (next PDU, F bit cleared) ... T->I Text Response (last PDU, F bit set) Basically, we are doing (3) without the R2T. The initiator, upon sending the text command, must be prepared either to accept as many PDUs as come back, or throw them away if it can't handle them. This solution is a lot like #1, but with the response spread across 4k PDUs. Also note that this (and the following scheme) avoid the problem of the target keeping state; it sends ALL of the response PDUs without the initiator asking for them. 5. Do #4, but allow the initiator to specify the amount of data it is willing to accept: I->T Text Command (F bit set, AcceptResponseLength=4096) T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) In the above example, we have created a new text command field: AcceptResponseLength And in the text response PDU: TotalResponseLength The initiator indicated it was willing to accept a 4k response. The target returned the first 4k in the text response, but set the F bit since it was at its limit. It also returned a TotalResponseLength field. Since this was greater than the AcceptResponseLength, the initiator knows the amount of buffer space it will need to get the full response. It can then choose whether it will re-send the command, and if so, can give it a large enough response length: I->T Text Command (F bit set, AcceptResponseLength=12288) T->I Text Response (first PDU, F bit clear) T->I Text Response (next PDU, F bit clear) T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) Note that most initiators will probably send an AcceptResponseLength of the largest response they would normally accept, and that most target responses will fit in one or a few PDUs anyway. #5 is really a compromise between #3 and #4; the target has the benefit of being less statefull, and the initiator has the benefit of controlling the amount of data it receives. I would like to recommend either #4 or #5. I think that #5 is probably the safest solution, but #4 may not be a problem for anyone. Assuming that none of the implementors of initiators have a problem with #4, I would pick that. If they do have a problem with it, we should go with #5. Targets probably don't care much whether we do #4 or #5. Initiator developers- Please indicate which solution (#4 or #5) appeals to you. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 15:43:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25733 for ; Mon, 16 Jul 2001 15:43:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GHqp705136 for ips-outgoing; Mon, 16 Jul 2001 13:52:51 -0400 (EDT) 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 f6GHqog05131 for ; Mon, 16 Jul 2001 13:52:50 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0SW7KK>; Mon, 16 Jul 2001 13:52:44 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A36@corpmx14.us.dg.com> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: NOPs should not have a CmdSN Date: Mon, 16 Jul 2001 13:48:34 -0400 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 > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to achieve > this function the task management command MUST be the same CmdSN as that > which would have been given to the next non-immediate command. I hope this is only a wording issue, but I'm going to supply a long explanation just in case. I'm concerned that "to achieve this function" may be read as modifying the subsequent MUST, especially in combination with the sentence prior to it. To help explain the above text, it would be good to start by adding a few sentences describing what SAM-2 requires for behavior of task management commands: - SAM-2 assumes that all commands are delivered to the Target in the order that they were issued by the Initiator. - Therefore all task management commands MUST exhibit behavior at the Initiator SCSI interface to iSCSI that is consistent with this ordered delivery. For example, if a command C is issued, followed by an Abort Task of C, two mis-ordering scenarios are possible: - The Abort Task reaches the Target before Command C. - The Abort Task reaches the Target after Command C, but the Abort Task response reaches the Initiator before the response to Command C. Both cases could result in the successful completion of Abort Task (no task to abort) being delivered to SCSI by the iSCSI Initiator followed by delivery of the response to Command C. This MUST NOT happen. Most of the MUSTs and MUST NOTs required to prevent this belong in the specification of task management, but some wording cleanups would help here: Old: > However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; New: To deal with this, the CmdSN in a task management command serves as a marker to indicated the command's position in the sequence of issued commands. Old: > to achieve > this function the task management command MUST be the same CmdSN > as that which would have been given to the next non-immediate command. New: The CmdSN for a task management command issued for immediate delivery MUST be the CmdSN that would be assigned to the next non-immediate command. Also, I have a serious concern about the following text: > Please note that the number of commands used for immediate delivery is > not limited and their delivery to execution is not acknowledged through > the numbering scheme. Immediate commands can be rejected by the iSCSI > target due to lack of resources. An iSCSI target MUST be able to handle > at least one immediate task management command and one immediate > non-task-management iSCSI request at any time. As written, that looks like a source of interoperability problems because it seems to allow a Target to silently ignore immediate commands in excess of one immediate task-management plus one immediate non-task management command. One of several things has to happen: (1) Targets MUST be able to handle any and all immediate commands fired at them over and above the resources devoted to non-immediate commands. (2) There is some static limit (e.g., the one plus one above) to the number of immediate commands that a target MUST handle. (3) Same as (2), but the limit is negotiated. (1) has nasty resource management consequences for the Target, but I think that's what the current text actually requires :-(. (2) looks like the easiest way out. The MUST for the target should be accompanied by a corresponding "MUST not issue concurrent immediate commands beyond one task-management and one non-task management command" plus some additional words about how the Initiator can determine when a subsequent immediate command would not be concurrent with previously issued ones. The simplest approach is to require responses to all immediate commands, including NOP - a more clever approach might be to take Matt's NOP case for updating CmdSN-related state and explain how the Initiator could determine that the NOP has been executed without requiring a response. In order to solve Matt's original problem, we would need to make that "one immediate task management command plus one non-immediate task management command" requirement apply *per connection*, not *per session* or *per target*. Thanks, --David > -----Original Message----- > From: Julian Satran [SMTP:Julian_Satran@il.ibm.com] > Sent: Saturday, July 14, 2001 11:10 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: NOPs should not have a CmdSN > > > The need to reject immediate commands came up several times during > recovery > discussions. > NOP with CmdsN was there to allow checking the "delivery machine" > end-to-end. > The text for CmdSN in case of retry had also some points that needed > clarification. > Here is the (more liberal) text for numbering commands: > > > 1.1.1.1 Command Numbering and Acknowledging > > iSCSI supports ordered command delivery within a session. All commands > (initiator-to-target PDUs) are numbered. > > Any SCSI activity is related to a task (SAM-2). The task is identified > by the Initiator Task Tag for the life of the task. > > Commands in transit from the initiator to the target layer are numbered > by iSCSI; the number is carried by the iSCSI PDU as CmdSN > (Command-Sequence-Number). The numbering is session-wide. All > outgoing > iSCSI PDUs that have a task association, except Data-Out, carry this > number. CmdSNs are allocated by the initiator iSCSI within a 32-bit > unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSN > SHOULD use Serial Number Arithmetic as defined in [RFC1982] where > SERIAL_BITS = 32. > > Commands meant for immediate delivery are marked as such through an > immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not > advanced for commands marked for immediate delivery. > > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks > they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to > achieve > this function the task management command MUST be the same CmdSN as > that > which would have been given to the next non-immediate command. > > Not covered in this document are the means by which one may request > immediate delivery for a command or by which iSCSI will decide by > itself > to mark a PDU for immediate delivery. > > Please note that the number of commands used for immediate delivery is > not limited and their delivery to execution is not acknowledged through > the numbering scheme. Immediate commands can be rejected by the iSCSI > target due to lack of resources. An iSCSI target MUST be able to handle > at least one immediate task management command and one immediate > non-task-management iSCSI request at any time. > > Except for the commands marked for immediate delivery the iSCSI target > layer MUST deliver the commands for execution in the order specified by > CmdSN. Commands marked for immediate delivery may be handed over by the > iSCSI target layer for execution as soon as detected. iSCSI may avoid > delivering some command for execution if so required by some prior SCSI > or iSCSI action (e.g., clear task set Task Management request received > before all the commands it was supposed to act on). > > The initiator and target are assumed to have three registers, unique > session wide, that define the numbering mechanism: > > - CmdSN - the current command Sequence Number advanced by 1 on each > command shipped except for commands marked for immediate delivery. > - ExpCmdSN - the next expected command by the target. The target > acknowledges all commands up to but not including this number. The > target iSCSI layer sets the ExpCmdSN to the largest non-immediate > CmdSN that it is able to deliver for execution plus 1 (no holes in > the CmdSN sequence). > - MaxCmdSN - the maximum number to be shipped. The queuing capacity > of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. > > ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. > > MaxCmdSN and ExpCmdSN fields are processed as follows: > > -if the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), they are > both ignored > -if the PDU MaxCmdSN is less than the local MaxCmdSN (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), it is > ignored; else it updates the local MaxCmdSN > -if the PDU ExpCmdSN is less than the local ExpCmdSN (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), it is > ignored; else it updates the local ExpCmdSN > > This sequence is required as updates may arrive out of order because > they travel on different TCP connections. > > The target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 > above the last ExpCmdSN. For non-immediate commands, the CmdSN field > can take any value from ExpCmdSN to MaxCmdSN. The target MUST silently > ignore any non-immediate command outside this range or non-immediate > duplicates within the range that have not been flagged with the retry > bit (the X bit in the opcode). > > iSCSI initiators and targets MUST support the command numbering scheme. > > A numbered iSCSI command will not change its allocated CmdSN regardless > of the number of times and circumstances in which it is reissued. At > the target, it is assumed that CmdSN is relevant only while the command > has not created any execution state (can't find the Initiator Task > Tag). > Afterwards CmdSN becomes irrelevant. Testing for execution state is > assumed to precede any other action at the target and is followed by > ordering and delivery if no execution state is found or delivery if > execution state is found. Immediate commands can't be retried unless > there is execution state available at the target for them (they are > rejected for retry if the target can't find the Initiator Task Tag). > > > Julo From owner-ips@ece.cmu.edu Mon Jul 16 15:45:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26174 for ; Mon, 16 Jul 2001 15:45:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GIDXI06699 for ips-outgoing; Mon, 16 Jul 2001 14:13:33 -0400 (EDT) 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 f6GIDWg06695 for ; Mon, 16 Jul 2001 14:13:32 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0SW8V6>; Mon, 16 Jul 2001 14:13:26 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A37@corpmx14.us.dg.com> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Naming: iqn format specification Date: Mon, 16 Jul 2001 14:09:13 -0400 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 A couple of comments on this: > Anyone wanting to ensure that their names > will never conflict with someone else's can add the enterprise number. Nice try, but not good enough. If this course is followed the enterprise number has to be REQUIRED independent of the whims of those who are creating the names so that this conflict can't happen, period. > > Finally, we should use the URI name and format for the namespace > > where a URI format exists. This is simply for consistency. > > > > For example: > > backwardsdns:au.edu.example.faculty > > oid:1.32.43.5.3.2.43.2.2.34 > > oui:2e319c65786e > > I had suggested this before, in my draft on iSCSI URNs; the IESG > completely shot this down, and I'm still not sure why. Anyway, > I don't have the energy to push the URN/URI thing any further. What the IESG shot down was the notion of WWUI as a new URN namespace into which other namespaces could be glued. Anyone whose reaction to this is "but it's functionally equivalent", has missed the point, and should be thankful that they don't spend all their time on naming issues ;-). The issues here are syntax, intent, and control; the IESG is not prepared to allow the IPS WG to define a new global namespace into which the IPS WG could decide to glue in other namespaces at its discretion. AFAIK, the IESG would be interested in things like an OUI URN definition (anyone want to write a draft? - it should be good for at least 15 minutes of fame). --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 16 17:32:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15053 for ; Mon, 16 Jul 2001 17:32:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GJn6R13874 for ips-outgoing; Mon, 16 Jul 2001 15:49:06 -0400 (EDT) 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 f6GJn5g13869 for ; Mon, 16 Jul 2001 15:49:05 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3P4Y4>; Mon, 16 Jul 2001 15:50:56 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A3A@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI security draft URL Date: Mon, 16 Jul 2001 15:44:48 -0400 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 Temporary URL until this hits the I-D servers: http://www.ultranet.com/~dlb237/draft-black-ips-iscsi-security-00.txt > -----Original Message----- > From: Black_David@emc.com [SMTP:Black_David@emc.com] > Sent: Thursday, July 12, 2001 9:37 PM > To: ips@ece.cmu.edu > Subject: iSCSI security draft > > I've taken my own advice and sent in a draft: > draft-black-iscsi-security-00.txt is coming soon to > an Internet-Draft server near you. I'll put it on > a web site somewhere and send a URL if the > secretariat doesn't get it processed by Monday. > > Please note that the following sentence appears > in the draft's Abstract: > > This draft is > an individual submission that the IP Storage WG is free to adopt, > modify, reject, fold, spindle, and/or mutilate as it sees fit. > > and that the draft is not intended to become an RFC, > although portions of it could wind up in places such > as a future version of the main iSCSI draft. > > The draft has a couple of purposes, (1) capturing > iSCSI security requirements and related considerations > in one place, and (2) providing more information on > how SRP could be used to provide keying material for > ESP. As a -00 version, the draft is somewhat drafty > (preliminary), and in particular I haven't had the > time to get any expert security review of the keying > mechanism (e.g., I'll be pleasantly surprised if > there isn't a security oversight somewhere in the > rekeying description). > > It would be wrong to assume that SRP is the most likely > keying mechanism for iSCSI's use of ESP just because I > wrote this draft. There are a bunch of other folks > working on coming up with a subset of IKE that would > be reasonable to use with iSCSI, and every so often I > hear musings about how it might be better to just drop > ESP and go back to inband digests (I don't agree, FWTW). > > In any case, because I've written this draft, Elizabeth > is now the designated referee (WG chair) for this keying > area of iSCSI security. I'll be happy to explain what's > in the draft and the associated rationale/reasoning, but > she'll be in charge of driving, determining and calling > consensus. While this will certainly be discussed in > London, I don't think a choice of keying mechanism will > be made until the interim meeting so that the FCIP and > iFCP folks who are interested in following iSCSI's > security direction can have their say. > > Enjoy and 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 > --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 16 18:11:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21075 for ; Mon, 16 Jul 2001 18:11:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GKhQ417819 for ips-outgoing; Mon, 16 Jul 2001 16:43:26 -0400 (EDT) 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 f6GKhOg17814 for ; Mon, 16 Jul 2001 16:43:24 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0SXG55>; Mon, 16 Jul 2001 16:43:19 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A3C@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: ALERT: CHANGED London dates/times Date: Mon, 16 Jul 2001 16:39:12 -0400 Importance: high X-Priority: 1 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 Breaking news ... as of right now, the IP Storage (ips) WG meeting dates/times in London are: MONDAY, August 6, 2001, 1930-2200 TUESDAY, August 7, 2001, 0900-1130 We can't go too late Mon because we have to start in bright and early Tue morning :-). I hope everyone paid attention to my warnings that these times were subject to change. This is supposed to become final in the next day or so. I'll send more email when it really is final. Thanks for everyone's patience with this, --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Mon Jul 16 18:17:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21946 for ; Mon, 16 Jul 2001 18:17:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GKXJx17113 for ips-outgoing; Mon, 16 Jul 2001 16:33:19 -0400 (EDT) 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 f6GKXGg17107 for ; Mon, 16 Jul 2001 16:33:17 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA25641; Mon, 16 Jul 2001 16:33:05 -0400 (EDT) Message-ID: <3B534E41.90228667@cisco.com> Date: Mon, 16 Jul 2001 15:27:45 -0500 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: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI Naming: iqn format specification References: <277DD60FB639D511AC0400B0D068B71E070A37@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit So, should we require the enterprise number? It's a whole lot cheaper than getting an OUI. Black_David@emc.com wrote: > > A couple of comments on this: > > > Anyone wanting to ensure that their names > > will never conflict with someone else's can add the enterprise number. > > Nice try, but not good enough. If this course is followed the > enterprise number has to be REQUIRED independent of the whims > of those who are creating the names so that this conflict can't > happen, period. > > > > Finally, we should use the URI name and format for the namespace > > > where a URI format exists. This is simply for consistency. > > > > > > For example: > > > backwardsdns:au.edu.example.faculty > > > oid:1.32.43.5.3.2.43.2.2.34 > > > oui:2e319c65786e > > > > I had suggested this before, in my draft on iSCSI URNs; the IESG > > completely shot this down, and I'm still not sure why. Anyway, > > I don't have the energy to push the URN/URI thing any further. > > What the IESG shot down was the notion of WWUI as a new URN > namespace into which other namespaces could be glued. Anyone > whose reaction to this is "but it's functionally equivalent", has missed > the point, and should be thankful that they don't spend all their time > on naming issues ;-). The issues here are syntax, intent, and > control; the IESG is not prepared to allow the IPS WG to define > a new global namespace into which the IPS WG could decide > to glue in other namespaces at its discretion. AFAIK, the IESG > would be interested in things like an OUI URN definition (anyone > want to write a draft? - it should be good for at least 15 minutes of > fame). > > --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 > --------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 18:19:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22158 for ; Mon, 16 Jul 2001 18:19:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GLVtO21389 for ips-outgoing; Mon, 16 Jul 2001 17:31:55 -0400 (EDT) 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 f6GLVsg21385 for ; Mon, 16 Jul 2001 17:31:54 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id C79BCC01 for ; Mon, 16 Jul 2001 17:31:49 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 27BE5B8 for ; Mon, 16 Jul 2001 15:31:53 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id OAA27609 for ; Mon, 16 Jul 2001 14:31:51 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA6EF3; Mon, 16 Jul 2001 14:31:48 -0700 Message-ID: <3B535D35.2CAB8763@agilent.com> Date: Mon, 16 Jul 2001 14:31:33 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran Cc: IPS Reflector Subject: iSCSI: SNACK wording clarification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The word SNACK should be defined (Selective Negative ACKnowledgement) The discussion of SNACK indicates that it is used for the "retransmission of status, data or R2T PDUs". The use of the word "status" can be confused to imply that only SCSI command status can be retransmitted. Instead, the word "response" should be used since SNACK is used to retransmit any PDU that advances StatSN (such as task management responses, text responses, NOP-IN). -Matt From owner-ips@ece.cmu.edu Mon Jul 16 20:48:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20908 for ; Mon, 16 Jul 2001 20:48:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GLSEA21163 for ips-outgoing; Mon, 16 Jul 2001 17:28:14 -0400 (EDT) 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 f6GLSDg21159 for ; Mon, 16 Jul 2001 17:28:14 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7L551>; Mon, 16 Jul 2001 17:26:39 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A3E@corpmx14.us.dg.com> From: Black_David@emc.com To: mbakke@cisco.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI Naming: iqn format specification Date: Mon, 16 Jul 2001 17:24:00 -0400 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 That would work - REQUIRE the enterprise number and possibly RECOMMEND that it be followed by the reverse DNS name for human-friendliness. --David > -----Original Message----- > From: Mark Bakke [SMTP:mbakke@cisco.com] > Sent: Monday, July 16, 2001 4:28 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI Naming: iqn format specification > > So, should we require the enterprise number? It's a whole > lot cheaper than getting an OUI. > > Black_David@emc.com wrote: > > > > A couple of comments on this: > > > > > Anyone wanting to ensure that their names > > > will never conflict with someone else's can add the enterprise number. > > > > Nice try, but not good enough. If this course is followed the > > enterprise number has to be REQUIRED independent of the whims > > of those who are creating the names so that this conflict can't > > happen, period. > > > > > > Finally, we should use the URI name and format for the namespace > > > > where a URI format exists. This is simply for consistency. > > > > > > > > For example: > > > > backwardsdns:au.edu.example.faculty > > > > oid:1.32.43.5.3.2.43.2.2.34 > > > > oui:2e319c65786e > > > > > > I had suggested this before, in my draft on iSCSI URNs; the IESG > > > completely shot this down, and I'm still not sure why. Anyway, > > > I don't have the energy to push the URN/URI thing any further. > > > > What the IESG shot down was the notion of WWUI as a new URN > > namespace into which other namespaces could be glued. Anyone > > whose reaction to this is "but it's functionally equivalent", has missed > > the point, and should be thankful that they don't spend all their time > > on naming issues ;-). The issues here are syntax, intent, and > > control; the IESG is not prepared to allow the IPS WG to define > > a new global namespace into which the IPS WG could decide > > to glue in other namespaces at its discretion. AFAIK, the IESG > > would be interested in things like an OUI URN definition (anyone > > want to write a draft? - it should be good for at least 15 minutes of > > fame). > > > > --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 > > --------------------------------------------------- > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Mon Jul 16 20:48:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20962 for ; Mon, 16 Jul 2001 20:48:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GLOil20851 for ips-outgoing; Mon, 16 Jul 2001 17:24:44 -0400 (EDT) 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 f6GLOgg20841 for ; Mon, 16 Jul 2001 17:24:42 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-139.cisco.com [161.44.68.139]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA28388; Mon, 16 Jul 2001 17:24:36 -0400 (EDT) From: "Ayman Ghanem" To: Cc: Subject: iSCSI: Login CmdSN Date: Mon, 16 Jul 2001 16:23:37 -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.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Draft-06-96 Section 2.10.7: "CmdSN is either the initial number of a session (for the first Login of a session - the "leading" login) .." Is it correct to understand this as the CmdSN used by the first command after the login cmd?. For example, I->login (CmdSN=1), leading connection T->login Rsp I->text (CmdSN=1), or should it have CmdSN=2? Also, in section 1.2.2.2: "During login, there is always only one outstanding command per connection". I think using "one outstanding task" is more appropriate here. Text commands during login phase have the same initiator task tag as the login cmd, but they shouldn't have the same CmdSN. -Ayman From owner-ips@ece.cmu.edu Mon Jul 16 23:29:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14967 for ; Mon, 16 Jul 2001 23:29:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6H1QO903131 for ips-outgoing; Mon, 16 Jul 2001 21:26:24 -0400 (EDT) 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 f6H1QMg03125 for ; Mon, 16 Jul 2001 21:26:22 -0400 (EDT) Received: from breinhold (lucent3.iol.unh.edu [132.177.125.48]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f6H1QJa18882 for ; Mon, 16 Jul 2001 21:26:20 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: Progress report from the ISCSI Group Test Period - Login is ugly Date: Mon, 16 Jul 2001 21:22:19 -0400 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 Three rounds of interoperability testing have been completed and the group of 30 companies is now in a debugging mode. The main problem points came up quickly and they are: login, login, and login. A short summary of the issues follows, detailed descriptions will be posted for list review: 1. CmdSN - If a login PDU is sent with CMDSN=5 and the next command is in the full feature phase is the CmdSN of that PDU 5 or 6? For the current test period we have chosen to use simply increment CmdSN. (we will send 6) 2. InitStatSN - This is essentially the same issue as CmdSN, however there is complexity with the multiple StatSNs that can come back as a result of the partial login response. The plan for the current test period is to treat this differently then CmdSN and use the value given in InitStatSN. This is in no way a reflection of what the implementers desired in future revs. of the specification. 3. There was mixed implementations in terms of the usage of the F bit in Command frames. Some following wording in rev 6 and some following wording in 6-96. 4. There was a lack of consistency in understanding what a "list" was. Key=value pairs such as InitialR2T = no were in some cases interpreted as list items and in some cases as something else ("binary options"). If the item was viewed as a list, then the expected form was initialR2T=no,yes. The implied meaning being that the device wanted to send initial data without an R2T, but supported the use of R2Ts. A device that sent initialR2T=no was understood to be saying "I will only work with devices that can accept initial write data w/o an R2T." In this view that default value only implies what is used if the key is missing from the negotiation. The other (major) view was that there are more things then lists and numeric keys. In this case the initialr2t=no is not a list and does not need to have all supported options with it. 5. Dependent keys - If a device does not like the value for a dependent parameter, such as IFMarkInt, that depends on FMarker, how is this handled? 6. What is the proper way for a target to force security negotiation when the initiator moves directly to operation phase? Does it reject the login and terminate the connection? or does it send Security parameters back anyways? 7. A number of vendors were not expecting the target to be able to initiate new key=value pairs. 8. During the security phase of login operational parameters may be ignored. There were different views as to what this implied (not sending the key=value pairs back, sending the values back but ignoring them once operation negotiation phase was entered. 9. The standard requires that key=value entries be "separated" by nulls. This means that the last one does not have to have a null. There was universal desire for all key=values to be terminated by a null. 10. Is the setting of F=1 persistent? If the initiator sends F=1 and the target comes back with new parameters is the initiator allowed to withdraw the F=1 setting in the next PDU it send. The large number of views on what the draft says relative to login suggest that we need to have more precise login behavior documentation. In particular a state table with well defined actions for the transitions between states should be specifies. The current draft 6-96 has a table, but lacks transition actions. The key=value negotiation process such employ a formal grammar the applied a well defined meaning to each of the identifiers and fixed the syntactical expressions. Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x??? From owner-ips@ece.cmu.edu Mon Jul 16 23:31:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15470 for ; Mon, 16 Jul 2001 23:31:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6H1GUf02654 for ips-outgoing; Mon, 16 Jul 2001 21:16:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6H1GSg02650 for ; Mon, 16 Jul 2001 21:16:29 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 157D2912 for ; Mon, 16 Jul 2001 19:16:14 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id A995226A for ; Mon, 16 Jul 2001 19:16:13 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id SAA04934 for ; Mon, 16 Jul 2001 18:16:12 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA188F for ; Mon, 16 Jul 2001 18:16:10 -0700 Message-ID: <3B5391CB.7C52943E@agilent.com> Date: Mon, 16 Jul 2001 18:15:55 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase References: <200107162226.RAA09889@isis.visi.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 think it's pretty obvious that it's your option #1: (the initiator supplies the initial CmdSN in the login PDU, and for every command PDU after that, the CmdSN gets incremented, just like in "full feature phase") 2.10.7 CmdSN says "CmdSN is either the initial number of a session..." [Julian, this should say "initial command number of a session"] So, the Login PDU defines the first CmdSN. 1.2.2.1 says "Commands in transit from the initiator to the target layer are numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN". Text commands are commands, so they are numbered also. It goes on to say "CmdSN - the current command Sequence Number advanced by 1 on each command shipped except for commands marked for immediate delivery." I agree that this needs to be cleaned up. CmdSN and StatSN should work during login just like they do during "full feature phase" - there is no reason why the should not, and making them always work the same removes complexity and interoperability problems. -Matt "Scott M. Ferris" wrote: > > At what point during the Login Phase of a leading connection (null > TSID) does a session exist? > > Section 2.10.7 describing CmdSN for the Login PDU indicates that > when TSID is null, CmdSN indicates the starting Command Sequence > number for this session. > > For interoperability, it is important to define precisely when a > session exists, so that all initiators and targets agree on when > CmdSNs are significant, and do not reject or ignore PDUs due to > differing assumptions of how the CmdSN numbering should be done during > the Login Phase. > > Some of the possible choices for session start are: > > 1) a session starts before the initiator sends anything, and the Login > PDU is the first PDU of a session. > > 2) a session starts when the initiator receives a (possibly partial) > Login Response with an accept status class and a non-zero TSID, and > the next PDU sent by the initiator is the first PDU of the session, > which uses the same CmdSN as the Login PDU. > > 3) a session starts when the initiator receives a Final Login > Response, and the next PDU sent by the initiator is the first PDU > of the session, which uses the same CmdSN as the Login PDU. > > After searching through draft 6, I was unable to find anything that > clearly indicated which if any of the above possibilities was correct, > or, if more than one is possible, how the initiator and target are > supposed to determine what CmdSN numbering scheme the other side is > using for the Login Phase. > > The UNH draft-6 initiator appears to use choice #1. The Cisco > draft-6 initiator and target use choice #2. This can cause the UNH > initiator to hang when trying to login to the Cisco target, since the > initiator may send a Text PDU with CmdSN 2, while the target is > waiting for a PDU with CmdSN 1. > > Section 1.2.2.2 states that "Status numbering starts after > Login. During login, there is always only one outstanding command per > connection and status numbering is not strictly needed but may be used > as a sanity check." > > A similar argument could be made that CmdSN is not needed during the > Login Phase, suggesting choice #3 may be the simplest. > > I also think section 1.2.2.2 is problematic, as it appears to > contradict itself by saying that status numbering is not used during > login, and then follows up saying status numbering may be used during > login. > > -- > Scott M. Ferris, > sferris@acm.org From owner-ips@ece.cmu.edu Tue Jul 17 01:23:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA07152 for ; Tue, 17 Jul 2001 01:23:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6GMQH324984 for ips-outgoing; Mon, 16 Jul 2001 18:26:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6GMQFg24972 for ; Mon, 16 Jul 2001 18:26:15 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 28D968176 for ; Mon, 16 Jul 2001 17:26:14 -0500 (CDT) Received: (from dreamcat@localhost) by isis.visi.com (8.8.8/8.8.8) id RAA09889 for ips@ece.cmu.edu; Mon, 16 Jul 2001 17:26:14 -0500 (CDT) Message-Id: <200107162226.RAA09889@isis.visi.com> Subject: iSCSI: CmdSN during the Login phase To: ips@ece.cmu.edu Date: Mon, 16 Jul 2001 17:26:13 -0500 (CDT) From: "Scott M. Ferris" X-Loop: sferris@acm.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 At what point during the Login Phase of a leading connection (null TSID) does a session exist? Section 2.10.7 describing CmdSN for the Login PDU indicates that when TSID is null, CmdSN indicates the starting Command Sequence number for this session. For interoperability, it is important to define precisely when a session exists, so that all initiators and targets agree on when CmdSNs are significant, and do not reject or ignore PDUs due to differing assumptions of how the CmdSN numbering should be done during the Login Phase. Some of the possible choices for session start are: 1) a session starts before the initiator sends anything, and the Login PDU is the first PDU of a session. 2) a session starts when the initiator receives a (possibly partial) Login Response with an accept status class and a non-zero TSID, and the next PDU sent by the initiator is the first PDU of the session, which uses the same CmdSN as the Login PDU. 3) a session starts when the initiator receives a Final Login Response, and the next PDU sent by the initiator is the first PDU of the session, which uses the same CmdSN as the Login PDU. After searching through draft 6, I was unable to find anything that clearly indicated which if any of the above possibilities was correct, or, if more than one is possible, how the initiator and target are supposed to determine what CmdSN numbering scheme the other side is using for the Login Phase. The UNH draft-6 initiator appears to use choice #1. The Cisco draft-6 initiator and target use choice #2. This can cause the UNH initiator to hang when trying to login to the Cisco target, since the initiator may send a Text PDU with CmdSN 2, while the target is waiting for a PDU with CmdSN 1. Section 1.2.2.2 states that "Status numbering starts after Login. During login, there is always only one outstanding command per connection and status numbering is not strictly needed but may be used as a sanity check." A similar argument could be made that CmdSN is not needed during the Login Phase, suggesting choice #3 may be the simplest. I also think section 1.2.2.2 is problematic, as it appears to contradict itself by saying that status numbering is not used during login, and then follows up saying status numbering may be used during login. -- Scott M. Ferris, sferris@acm.org From owner-ips@ece.cmu.edu Tue Jul 17 03:31:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14938 for ; Tue, 17 Jul 2001 03:31:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6H5w7S15703 for ips-outgoing; Tue, 17 Jul 2001 01:58:07 -0400 (EDT) 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 f6H5w4g15696 for ; Tue, 17 Jul 2001 01:58:05 -0400 (EDT) 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 HAA222954 for ; Tue, 17 Jul 2001 07:57:58 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6H5vva47642 for ; Tue, 17 Jul 2001 07:57:57 +0200 Importance: Normal Subject: RE: iSCSI: NOPs should not have a CmdSN To: Black_David@emc.com Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 17 Jul 2001 09:03:57 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 07:57:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Yes there are some obvious typos in the text and will fix some. As for your concern on resources - the commands will not be silently rejected - the reject is explicit. I am also considering extending the requirement for resources to one command/connection. Thanks for carefully reading. Regards, Julo Black_David@emc.com on 16-07-2001 20:48:34 Please respond to Black_David@emc.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI: NOPs should not have a CmdSN > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to achieve > this function the task management command MUST be the same CmdSN as that > which would have been given to the next non-immediate command. I hope this is only a wording issue, but I'm going to supply a long explanation just in case. I'm concerned that "to achieve this function" may be read as modifying the subsequent MUST, especially in combination with the sentence prior to it. To help explain the above text, it would be good to start by adding a few sentences describing what SAM-2 requires for behavior of task management commands: - SAM-2 assumes that all commands are delivered to the Target in the order that they were issued by the Initiator. - Therefore all task management commands MUST exhibit behavior at the Initiator SCSI interface to iSCSI that is consistent with this ordered delivery. For example, if a command C is issued, followed by an Abort Task of C, two mis-ordering scenarios are possible: - The Abort Task reaches the Target before Command C. - The Abort Task reaches the Target after Command C, but the Abort Task response reaches the Initiator before the response to Command C. Both cases could result in the successful completion of Abort Task (no task to abort) being delivered to SCSI by the iSCSI Initiator followed by delivery of the response to Command C. This MUST NOT happen. Most of the MUSTs and MUST NOTs required to prevent this belong in the specification of task management, but some wording cleanups would help here: Old: > However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; New: To deal with this, the CmdSN in a task management command serves as a marker to indicated the command's position in the sequence of issued commands. Old: > to achieve > this function the task management command MUST be the same CmdSN > as that which would have been given to the next non-immediate command. New: The CmdSN for a task management command issued for immediate delivery MUST be the CmdSN that would be assigned to the next non-immediate command. Also, I have a serious concern about the following text: > Please note that the number of commands used for immediate delivery is > not limited and their delivery to execution is not acknowledged through > the numbering scheme. Immediate commands can be rejected by the iSCSI > target due to lack of resources. An iSCSI target MUST be able to handle > at least one immediate task management command and one immediate > non-task-management iSCSI request at any time. As written, that looks like a source of interoperability problems because it seems to allow a Target to silently ignore immediate commands in excess of one immediate task-management plus one immediate non-task management command. One of several things has to happen: (1) Targets MUST be able to handle any and all immediate commands fired at them over and above the resources devoted to non-immediate commands. (2) There is some static limit (e.g., the one plus one above) to the number of immediate commands that a target MUST handle. (3) Same as (2), but the limit is negotiated. (1) has nasty resource management consequences for the Target, but I think that's what the current text actually requires :-(. (2) looks like the easiest way out. The MUST for the target should be accompanied by a corresponding "MUST not issue concurrent immediate commands beyond one task-management and one non-task management command" plus some additional words about how the Initiator can determine when a subsequent immediate command would not be concurrent with previously issued ones. The simplest approach is to require responses to all immediate commands, including NOP - a more clever approach might be to take Matt's NOP case for updating CmdSN-related state and explain how the Initiator could determine that the NOP has been executed without requiring a response. In order to solve Matt's original problem, we would need to make that "one immediate task management command plus one non-immediate task management command" requirement apply *per connection*, not *per session* or *per target*. Thanks, --David > -----Original Message----- > From: Julian Satran [SMTP:Julian_Satran@il.ibm.com] > Sent: Saturday, July 14, 2001 11:10 AM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: NOPs should not have a CmdSN > > > The need to reject immediate commands came up several times during > recovery > discussions. > NOP with CmdsN was there to allow checking the "delivery machine" > end-to-end. > The text for CmdSN in case of retry had also some points that needed > clarification. > Here is the (more liberal) text for numbering commands: > > > 1.1.1.1 Command Numbering and Acknowledging > > iSCSI supports ordered command delivery within a session. All commands > (initiator-to-target PDUs) are numbered. > > Any SCSI activity is related to a task (SAM-2). The task is identified > by the Initiator Task Tag for the life of the task. > > Commands in transit from the initiator to the target layer are numbered > by iSCSI; the number is carried by the iSCSI PDU as CmdSN > (Command-Sequence-Number). The numbering is session-wide. All > outgoing > iSCSI PDUs that have a task association, except Data-Out, carry this > number. CmdSNs are allocated by the initiator iSCSI within a 32-bit > unsigned counter (modulo 2**32). Comparisons and arithmetic on CmdSN > SHOULD use Serial Number Arithmetic as defined in [RFC1982] where > SERIAL_BITS = 32. > > Commands meant for immediate delivery are marked as such through an > immediate delivery flag. They MAY carry any CmdSN. The CmdSN is not > advanced for commands marked for immediate delivery. > > If immediate delivery is used with task management commands, these > commands may reach the SCSI target task management before the tasks > they > are supposed to act upon. However, their CmdSN is a good reference for > what commands the immediate command was supposed to act upon; to > achieve > this function the task management command MUST be the same CmdSN as > that > which would have been given to the next non-immediate command. > > Not covered in this document are the means by which one may request > immediate delivery for a command or by which iSCSI will decide by > itself > to mark a PDU for immediate delivery. > > Please note that the number of commands used for immediate delivery is > not limited and their delivery to execution is not acknowledged through > the numbering scheme. Immediate commands can be rejected by the iSCSI > target due to lack of resources. An iSCSI target MUST be able to handle > at least one immediate task management command and one immediate > non-task-management iSCSI request at any time. > > Except for the commands marked for immediate delivery the iSCSI target > layer MUST deliver the commands for execution in the order specified by > CmdSN. Commands marked for immediate delivery may be handed over by the > iSCSI target layer for execution as soon as detected. iSCSI may avoid > delivering some command for execution if so required by some prior SCSI > or iSCSI action (e.g., clear task set Task Management request received > before all the commands it was supposed to act on). > > The initiator and target are assumed to have three registers, unique > session wide, that define the numbering mechanism: > > - CmdSN - the current command Sequence Number advanced by 1 on each > command shipped except for commands marked for immediate delivery. > - ExpCmdSN - the next expected command by the target. The target > acknowledges all commands up to but not including this number. The > target iSCSI layer sets the ExpCmdSN to the largest non-immediate > CmdSN that it is able to deliver for execution plus 1 (no holes in > the CmdSN sequence). > - MaxCmdSN - the maximum number to be shipped. The queuing capacity > of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. > > ExpCmdSN and MaxCmdSN are derived from target-to-initiator PDU fields. > > MaxCmdSN and ExpCmdSN fields are processed as follows: > > -if the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), they are > both ignored > -if the PDU MaxCmdSN is less than the local MaxCmdSN (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), it is > ignored; else it updates the local MaxCmdSN > -if the PDU ExpCmdSN is less than the local ExpCmdSN (in Serial > Arithmetic Sense and with a difference bounded by 2**31-1), it is > ignored; else it updates the local ExpCmdSN > > This sequence is required as updates may arrive out of order because > they travel on different TCP connections. > > The target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 > above the last ExpCmdSN. For non-immediate commands, the CmdSN field > can take any value from ExpCmdSN to MaxCmdSN. The target MUST silently > ignore any non-immediate command outside this range or non-immediate > duplicates within the range that have not been flagged with the retry > bit (the X bit in the opcode). > > iSCSI initiators and targets MUST support the command numbering scheme. > > A numbered iSCSI command will not change its allocated CmdSN regardless > of the number of times and circumstances in which it is reissued. At > the target, it is assumed that CmdSN is relevant only while the command > has not created any execution state (can't find the Initiator Task > Tag). > Afterwards CmdSN becomes irrelevant. Testing for execution state is > assumed to precede any other action at the target and is followed by > ordering and delivery if no execution state is found or delivery if > execution state is found. Immediate commands can't be retried unless > there is execution state available at the target for them (they are > rejected for retry if the target can't find the Initiator Task Tag). > > > Julo From owner-ips@ece.cmu.edu Tue Jul 17 06:37:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07749 for ; Tue, 17 Jul 2001 06:37:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6H90BV03869 for ips-outgoing; Tue, 17 Jul 2001 05:00:11 -0400 (EDT) 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 f6H90Ag03864 for ; Tue, 17 Jul 2001 05:00:10 -0400 (EDT) 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 LAA267510 for ; Tue, 17 Jul 2001 11:00:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6H901a117072 for ; Tue, 17 Jul 2001 11:00:02 +0200 Importance: Normal Subject: Re: iSCSI: CmdSN during the Login phase To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 17 Jul 2001 12:06:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 12:00:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The issue of the leading connection goes beyon numbering. The leading connection login has to end (successfully) before any other login (if any) can start. Obviously CmdSN starts from the leading login. The text for CmdSN in Login now reads: 1.1.1 CmdSN CmdSN is either the initial command sequence number of a session (for the first Login of a session - the "leading" login) or the command sequence number in the command stream. All logins after the leading one can proceed in parallel. To achieve this "serialization" TSID is specified as valid only with the Login response with F bit on. The F-Bit text in the response reads: 1.1.1 F (Final) bit Final bit is set to one in the Final Login Response. A Final bit of 0 indicates a "partial" response, which means "more negotiation needed". A login response with a F bit set to 1 MUST NOT contain key=value pairs that may require additional answers from the initiator. And the TSID: 1.1.1 TSID The TSID is an initiator identifying tag set by the target. It MUST be valid only if the login is accepted and the F bit is 1 Julo "Scott M. Ferris" on 17-07-2001 01:26:13 Please respond to "Scott M. Ferris" To: ips@ece.cmu.edu cc: Subject: iSCSI: CmdSN during the Login phase At what point during the Login Phase of a leading connection (null TSID) does a session exist? Section 2.10.7 describing CmdSN for the Login PDU indicates that when TSID is null, CmdSN indicates the starting Command Sequence number for this session. For interoperability, it is important to define precisely when a session exists, so that all initiators and targets agree on when CmdSNs are significant, and do not reject or ignore PDUs due to differing assumptions of how the CmdSN numbering should be done during the Login Phase. Some of the possible choices for session start are: 1) a session starts before the initiator sends anything, and the Login PDU is the first PDU of a session. 2) a session starts when the initiator receives a (possibly partial) Login Response with an accept status class and a non-zero TSID, and the next PDU sent by the initiator is the first PDU of the session, which uses the same CmdSN as the Login PDU. 3) a session starts when the initiator receives a Final Login Response, and the next PDU sent by the initiator is the first PDU of the session, which uses the same CmdSN as the Login PDU. After searching through draft 6, I was unable to find anything that clearly indicated which if any of the above possibilities was correct, or, if more than one is possible, how the initiator and target are supposed to determine what CmdSN numbering scheme the other side is using for the Login Phase. The UNH draft-6 initiator appears to use choice #1. The Cisco draft-6 initiator and target use choice #2. This can cause the UNH initiator to hang when trying to login to the Cisco target, since the initiator may send a Text PDU with CmdSN 2, while the target is waiting for a PDU with CmdSN 1. Section 1.2.2.2 states that "Status numbering starts after Login. During login, there is always only one outstanding command per connection and status numbering is not strictly needed but may be used as a sanity check." A similar argument could be made that CmdSN is not needed during the Login Phase, suggesting choice #3 may be the simplest. I also think section 1.2.2.2 is problematic, as it appears to contradict itself by saying that status numbering is not used during login, and then follows up saying status numbering may be used during login. -- Scott M. Ferris, sferris@acm.org From owner-ips@ece.cmu.edu Tue Jul 17 08:43:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25202 for ; Tue, 17 Jul 2001 08:43:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HBEoR09457 for ips-outgoing; Tue, 17 Jul 2001 07:14:50 -0400 (EDT) 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 f6HBEng09453 for ; Tue, 17 Jul 2001 07:14:49 -0400 (EDT) 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 NAA42694 for ; Tue, 17 Jul 2001 13:14:41 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6HBEfa207168 for ; Tue, 17 Jul 2001 13:14:41 +0200 Importance: Normal Subject: Re: iSCSI: Login CmdSN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 17 Jul 2001 14:19:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 14:14:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In fact there is only one outstanding command. There can't be more than one outstanding text. Numbering is starting with the Login Command. Julo "Ayman Ghanem" on 17-07-2001 00:23:37 Please respond to "Ayman Ghanem" To: ips@ece.cmu.edu cc: Julian Satran/Haifa/IBM@IBMIL Subject: iSCSI: Login CmdSN Draft-06-96 Section 2.10.7: "CmdSN is either the initial number of a session (for the first Login of a session - the "leading" login) .." Is it correct to understand this as the CmdSN used by the first command after the login cmd?. For example, I->login (CmdSN=1), leading connection T->login Rsp I->text (CmdSN=1), or should it have CmdSN=2? Also, in section 1.2.2.2: "During login, there is always only one outstanding command per connection". I think using "one outstanding task" is more appropriate here. Text commands during login phase have the same initiator task tag as the login cmd, but they shouldn't have the same CmdSN. -Ayman From owner-ips@ece.cmu.edu Tue Jul 17 08:48:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA25869 for ; Tue, 17 Jul 2001 08:48:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HBhdI10590 for ips-outgoing; Tue, 17 Jul 2001 07:43:39 -0400 (EDT) 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 f6HBhag10585 for ; Tue, 17 Jul 2001 07:43:37 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id HAA05636 for ips@ece.cmu.edu; Tue, 17 Jul 2001 07:43:29 -0400 (EDT) Received: from compuserve.com (hil-qbu-ppz-vty23.as.wcom.net [206.175.101.23]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id HAA05598 for ; Tue, 17 Jul 2001 07:43:16 -0400 (EDT) Message-ID: <3B542595.714C691C@compuserve.com> Date: Tue, 17 Jul 2001 05:46:30 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: FCIP Annex E References: <277DD60FB639D511AC0400B0D068B71E0709E5@corpmx14.us.dg.com> 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: ..snip.. > In at attempt to make sure that we don't lose anything > important in removing this text from the FCIP draft, > here are some suggestions: > > E-4.3 FCIP's Interaction with FC and TCP {partial} > > This is about what happens when FCIP drops an FC frame > for some reason (one of the checks in 6.6.2.2 failed). > Annex D needs to place responsibility for recovery from > this event on the FC entity, which may defer to something > else (e.g., the FC entity may ignore this in favor of > FCP or SCSI retry). A sentence in 6.6.2.2. pointing > out where the responsibility for recovery lies and > giving possible examples would be a useful addition to > the last paragraph. The following sentence has been added at the end of 6.6.2.2: The burden for recovering from discarded data falls on the FC Entity and other components of the FC Fabric and is outside the scope of this specification. The following sentence has been added at the end of 6.6.2.3: The burden for recovering from discarded FCIP Frames falls on the FC Entity and other components of the FC Fabric and is outside the scope of this specification. The following sentence has been added at the end of 6.6.2.4: The burden for recovering from the discarding of FCIP Frames during the optional resynchronization process described in this section falls on the FC Entity and other components of the FC Fabric and is outside the scope of this specification. > E-5.3 TCP Connection Management > E-5.5 Multiple Connection Management > > Some of the information in these sections probably needs to > be in both FCIP and FC-BB-2. FCIP should contain information > describing how TCP connections may be mapped to FC port > connections (Section 7 in -03 is silent on this topic). > The first paragraph of E-5.3 and most of E-5.5 > fall into this category, although they should be generalized to > avoid references to ISLs, E ports and B ports. The connection > setup material in E-5.3 seems to be adequately covered in 7.1 > and its subsections. No changes have been made in FCIP in response to this comment. I am loath to add FC Port to the FCIP glossary. I can find nothing in the first paragraphs of E-5.3 and E-5.5 that are not covered in suitably general terms in section 8. > E-5.4.1 Determining loss of connectivity {partial} > > Somewhere, possibly in Annex D, making the FC entity > responsible for checking for loss of TCP connectivity > ought to be enhanced by giving the HLO SW_ILS as an > example of how this could be done without requiring it > to be used. No changes have been made in FCIP in response to this comment. This is 100% a Fibre Channel issue. If Fibre Channel does not want to test connectivity, that is Fibre Channel's business. If Fibre Channel wants to invent a replacement for the HLO SW_ILS (perhaps even one suited specifically to FCIP) why should it be the place of FCIP to mandate use of HLO? > E-5.6 Multi Virtual ISL Management > > This looks like an FC fabric topology issue, and hence > moving it to FC-BB-2 makes sense (IMHO). > > E-8.3 Corruption {partial} > > Most of this seems to be covered in 6.6.2.2, but noting that > FC has the option to begin transmitting a frame and terminate > that with an EOF invalidating the partially transmitted frame > should be added. Annex D does not appear to capture > the possible interactions between the FC and FCIP entities > in this area - some more explanation of possibilities and > responsibilities is needed. I believe that sufficient discussion of EOFa appears in section 6.6.2.4. > E-8.4 Timeouts {partial} > > The mechanism to deal with this is covered in 6.6.2.3, but > that section would be considerably more readable if it included > an explanation of what R_A_TOV and E_D_TOV govern and why only > R_A_TOV needs to be enforced in FCIP. It is intended that 04 change the usage of R_A_TOV to some other variable name, perhaps DLY_LIM (delay limit). The burden for computing DLY_LIM will be placed on the FC Entity, and DLY_LIM will be nothing more than the value enforced by the FCIP_DE as per 6.6.2.3. > E-10.1 Flow control on FC network > > Section 7.4 covers this topic, but calling out FC > Buffer-to-Buffer flow control as an example of how > arrival of frames from the fabric can be controlled > at the bottom of p.21 would improve readability. This will be carried forward as a note to the FCIP Authors. Thanks. Ralph... From owner-ips@ece.cmu.edu Tue Jul 17 12:42:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17353 for ; Tue, 17 Jul 2001 12:42:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HCnRO14444 for ips-outgoing; Tue, 17 Jul 2001 08:49:27 -0400 (EDT) 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 f6HCnNg14437 for ; Tue, 17 Jul 2001 08:49:23 -0400 (EDT) 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 OAA35324 for ; Tue, 17 Jul 2001 14:48:56 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6HCmoS89122 for ; Tue, 17 Jul 2001 14:48:55 +0200 Importance: Normal Subject: Re: iSCSI: SNACK wording clarification To: Matt Wakeley Cc: "IPS Reflector X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 17 Jul 2001 15:54:49 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 17/07/2001 14:48:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK - Julo "Matt Wakeley" on 17-07-2001 00:31:33 Please respond to Matt Wakeley To: Julian Satran/Haifa/IBM@IBMIL cc: IPS Reflector Subject: iSCSI: SNACK wording clarification The word SNACK should be defined (Selective Negative ACKnowledgement) The discussion of SNACK indicates that it is used for the "retransmission of status, data or R2T PDUs". The use of the word "status" can be confused to imply that only SCSI command status can be retransmitted. Instead, the word "response" should be used since SNACK is used to retransmit any PDU that advances StatSN (such as task management responses, text responses, NOP-IN). -Matt From owner-ips@ece.cmu.edu Tue Jul 17 16:10:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03139 for ; Tue, 17 Jul 2001 16:10:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HIExM05243 for ips-outgoing; Tue, 17 Jul 2001 14:14:59 -0400 (EDT) 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 f6HIEvg05239 for ; Tue, 17 Jul 2001 14:14:58 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id OAA08597 for ips@ece.cmu.edu; Tue, 17 Jul 2001 14:14:52 -0400 (EDT) Received: from compuserve.com (hil-qbu-ppz-vty14.as.wcom.net [206.175.101.14]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id OAA08534 for ; Tue, 17 Jul 2001 14:14:43 -0400 (EDT) Message-ID: <3B548162.FDC3D5E3@compuserve.com> Date: Tue, 17 Jul 2001 12:18:10 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.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 Subject: Re: FCIP Annex E References: <63616B261CEFD411834D00D0B7A86CF7113F79@LUCY> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The issues in E-5.5 are Fibre Channel issues not TCP issues. The choices regarding how to use TCP are driven by Fibre Channel choices not by TCP choices. TCP supplies only the rules and options from which the Fibre Channel side makes its choices. The nature of the choices belongs in FCIP, which choices to make when does not. E-5.5 contains far too much discussion of which choices to make when. I believe that 03 section 8 covers the organization of multiple TCP connections. Work in progress and targeted for 04 intends to address the QoS aspects of the question, but again only in terms of describing the kinds of options the FCIP Entity presents to the FC Entity. Only Fibre Channel knows the choices it needs to make and only Fibre Channel documents can successfully discuss those choices. Thanks. Ralph... Sudhir Srinivasan wrote: > > > It is intriguing why the FCIP draft authors are > reluctant to address the issues regarding E-5.5 > head-on. The issue has come up three separate > times on the reflector and the authors continue to > keep us in suspense. I understand the reasons for > working offline and posting the results in a new > revision but this issue has survived two revisions > now and promises to extend to -04 as well. In the > interest of developing a standard that isn't doomed > from day one wrt interoperability, I urge the > authors to clearly state what their stance is on > the rules in E-5.5. > > Thanks, > Sudhir > > > -----Original Message----- > > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > > Sent: Tuesday, July 17, 2001 7:47 AM > > > > > E-5.3 TCP Connection Management > > > E-5.5 Multiple Connection Management > > > > > > Some of the information in these sections probably needs to > > > be in both FCIP and FC-BB-2. FCIP should contain information > > > describing how TCP connections may be mapped to FC port > > > connections (Section 7 in -03 is silent on this topic). > > > The first paragraph of E-5.3 and most of E-5.5 > > > fall into this category, although they should be generalized to > > > avoid references to ISLs, E ports and B ports. The connection > > > setup material in E-5.3 seems to be adequately covered in 7.1 > > > and its subsections. > > > > No changes have been made in FCIP in response to this comment. > > > > I am loath to add FC Port to the FCIP glossary. I can find > > nothing in the first paragraphs of E-5.3 and E-5.5 that > > are not covered in suitably general terms in section 8. From owner-ips@ece.cmu.edu Tue Jul 17 17:22:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17437 for ; Tue, 17 Jul 2001 17:22:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HJTIG10657 for ips-outgoing; Tue, 17 Jul 2001 15:29:18 -0400 (EDT) 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 f6HJTGg10652 for ; Tue, 17 Jul 2001 15:29:17 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 4AF31AC1 for ; Tue, 17 Jul 2001 15:29:12 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 7A1121BD4 for ; Tue, 17 Jul 2001 13:29:15 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id MAA25715 for ; Tue, 17 Jul 2001 12:29:14 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA1F63; Tue, 17 Jul 2001 12:29:10 -0700 Message-ID: <3B5491F3.D731220C@agilent.com> Date: Tue, 17 Jul 2001 12:28:51 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Scott M. Ferris" Cc: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase References: <200107171747.MAA26163@isis.visi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Scott M. Ferris" wrote: > If the Login PDU is going to have a valid CmdSN rather than an > InitCmdSN, why does the Login Response have an InitStatSN rather than > a StatSN? Because the login may be adding another connection to a multiconnection session. In that case, it is not the initial CmdSN, it is the next valid CmdSN of the session. The StatSN is on a per connection basis, so everytime you open up a new connection, you have an initial StatSN. -Matt From owner-ips@ece.cmu.edu Tue Jul 17 17:23:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17646 for ; Tue, 17 Jul 2001 17:23:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HKDog14041 for ips-outgoing; Tue, 17 Jul 2001 16:13:50 -0400 (EDT) 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 f6HKDng14035 for ; Tue, 17 Jul 2001 16:13:49 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA00909; Tue, 17 Jul 2001 16:13:37 -0400 (EDT) Message-ID: <3B549B31.85EB5ABA@cisco.com> Date: Tue, 17 Jul 2001 15:08:17 -0500 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: Black_David@emc.com CC: ips@ece.cmu.edu Subject: Re: iSCSI Naming: iqn format specification References: <277DD60FB639D511AC0400B0D068B71E070A3E@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Works for me. Anyone wanting to do their own naming schemes would fall into three categories: 1. iSCSI hardware and software manufacturers Most iSCSI names would be generated by these folks; they would make them up either statically (based on a chassis number or something) or dynamically (based on user configuration, but not explicitly configured by the user), or a combination of the two. These have their own enterprise # anyway. 2. Service-minded end-users that want control over naming. These are sophisticated enough to want an enterprise number; I anticipate that only folks such as SSPs would want to do this sort of thing; most will leave the manufacturer-assigned names along. 3. Researchers building iSCSI experimental stuff These would not be concerned with being "iSCSI-compliant"; they would simply want to be reasonably sure that they won't conflict with other equipment in a lab environment. These folks could just use enterprise # 0, along with their reversed domain name, and be reasonably assured of this. We don't have to mention #3 in the spec, if that's a problem, since this decision of iSCSI-compliance would be up to the implementor -- Mark Black_David@emc.com wrote: > > That would work - REQUIRE the enterprise > number and possibly RECOMMEND that it be > followed by the reverse DNS name for > human-friendliness. --David > > > -----Original Message----- > > From: Mark Bakke [SMTP:mbakke@cisco.com] > > Sent: Monday, July 16, 2001 4:28 PM > > To: Black_David@emc.com > > Cc: ips@ece.cmu.edu > > Subject: Re: iSCSI Naming: iqn format specification > > > > So, should we require the enterprise number? It's a whole > > lot cheaper than getting an OUI. > > > > Black_David@emc.com wrote: > > > > > > A couple of comments on this: > > > > > > > Anyone wanting to ensure that their names > > > > will never conflict with someone else's can add the enterprise number. > > > > > > Nice try, but not good enough. If this course is followed the > > > enterprise number has to be REQUIRED independent of the whims > > > of those who are creating the names so that this conflict can't > > > happen, period. > > > > > > > > Finally, we should use the URI name and format for the namespace > > > > > where a URI format exists. This is simply for consistency. > > > > > > > > > > For example: > > > > > backwardsdns:au.edu.example.faculty > > > > > oid:1.32.43.5.3.2.43.2.2.34 > > > > > oui:2e319c65786e > > > > > > > > I had suggested this before, in my draft on iSCSI URNs; the IESG > > > > completely shot this down, and I'm still not sure why. Anyway, > > > > I don't have the energy to push the URN/URI thing any further. > > > > > > What the IESG shot down was the notion of WWUI as a new URN > > > namespace into which other namespaces could be glued. Anyone > > > whose reaction to this is "but it's functionally equivalent", has missed > > > the point, and should be thankful that they don't spend all their time > > > on naming issues ;-). The issues here are syntax, intent, and > > > control; the IESG is not prepared to allow the IPS WG to define > > > a new global namespace into which the IPS WG could decide > > > to glue in other namespaces at its discretion. AFAIK, the IESG > > > would be interested in things like an OUI URN definition (anyone > > > want to write a draft? - it should be good for at least 15 minutes of > > > fame). > > > > > > --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 > > > --------------------------------------------------- > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 17 17:26:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18350 for ; Tue, 17 Jul 2001 17:26:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HKfQQ16232 for ips-outgoing; Tue, 17 Jul 2001 16:41:26 -0400 (EDT) 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 f6HKfPg16228 for ; Tue, 17 Jul 2001 16:41:25 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA10060 for ; Tue, 17 Jul 2001 16:41:19 -0400 (EDT) Message-ID: <3B54A1B0.99344EF@cisco.com> Date: Tue, 17 Jul 2001 15:36:00 -0500 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: iSCSI: Discovery Sessions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Given the discussions on how to define discovery sessions for SendTargets, whether to call the thing that is logged in to a canonical, default, or well-known targets, as well as the discussions about other uses for a well-known target, we have what looks like a simper solution. Julian had suggested that we simply provide a text key at login that says DiscoverySession=yes to indicate that the session was to be used for SendTargets; no TargetName would need to be specified at all for the session. Since this was analogous to other "special" sessions, such as boot and copy manager sessions, we further combined these separate booleans into a SessionType. This means that rather than specifying the target "iscsi" in the login request, the initiator would instead specify: SessionType=Discovery That's it. The session has not been established to any particular target (it doesn't need one), the session type is as a discovery session, and the target can properly restrict the operations on the session to SendTargets. Anyway, this is a very minor change, but is a lot simpler to describe than the way we were doing it. It also leaves the use of the default target "iscsi" for other purposes. Here's the definition of SessionType, from -97: 32 SessionType Use: LO Who can send: Initiator SessionType= Default is Normal. The Initiator indicates the type of session it wants to create. The target can accept or reject it. A Boot Session indicates to the Target that the only purpose of this Session is boot. The target MAY restrict the type of iSCSI requests it accepts in such a Session to Logout, NOP-out, and SCSI read commands. Accepting other commands in this type of session is vendor-dependent. A target MAY reject a boot-session. A CopyManager session MAY indicates to the Target that the only purpose of this Session is a Copy Manager Function. The target MAY restrict the type of SCSI requests it accepts in such a Session. A target MAY reject a copy manager session. A Discovery session indicates to the Target that the only purpose of this Session is discovery. The only command accepted by a target in this type of session is a text command with a SendTargets key The above description replaces the CopyManagerSession, BootSession, and DiscoverySession keys. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 17 17:47:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22599 for ; Tue, 17 Jul 2001 17:47:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HL3ur18022 for ips-outgoing; Tue, 17 Jul 2001 17:03:56 -0400 (EDT) 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 f6HL3tg18017 for ; Tue, 17 Jul 2001 17:03:55 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 662F97B8 for ; Tue, 17 Jul 2001 17:03:50 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id BA294244 for ; Tue, 17 Jul 2001 15:03:50 -0600 (MDT) Received: from mail.rose.agilent.com (bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id OAA04851 for ; Tue, 17 Jul 2001 14:03:49 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA2BAA for ; Tue, 17 Jul 2001 14:03:46 -0700 Message-ID: <3B54A81F.57A41B60@agilent.com> Date: Tue, 17 Jul 2001 14:03:27 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase References: <200107162226.RAA09889@isis.visi.com> <3B5391CB.7C52943E@agilent.com> <3B54A4B9.35D2F1F8@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 Mark's proposal. -Matt Mark Bakke wrote: > > Given that this is being interpreted differently by enough > implementations, I would prefer to see us take a step back > and look at which of Scott's three options should make the > most sense. It looks like options #1 and #2 are what is > currently being implemented, regardless of what's specified. > > However, a connection technically can't really be part of a > session (sharing its work load) until it has completed a > successful login phase. There's also little reason for > numbering until the login phase is complete, since the login > and text responses during negotiation are synchronous, and > pertain only to the connection, rather than the session. > > I would recommend stating that a connection joins (or becomes, > if it's the first one) a session after the login response > with the F bit set is sent (on a target), or after the login > response with the F bit set is received (on an initiator), > and that CmdSN is not necessary until such a time, especially > since CmdSN is per-session, not per-connection. This is > identical to Scott's option 3. > > I think that defining it this way would remove any further > ambiguity on when a connection is part of a session. Since > it appears that most implementations will have to modify their > login code anyway, this shouldn't be too bad. > > -- > Mark From owner-ips@ece.cmu.edu Tue Jul 17 18:30:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28688 for ; Tue, 17 Jul 2001 18:30:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HL88p18376 for ips-outgoing; Tue, 17 Jul 2001 17:08:08 -0400 (EDT) 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 f6HL87g18372 for ; Tue, 17 Jul 2001 17:08:07 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA15661; Tue, 17 Jul 2001 17:07:50 -0400 (EDT) Message-ID: <3B54A7E7.981EA8E9@cisco.com> Date: Tue, 17 Jul 2001 16:02:31 -0500 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: "KRUEGER,MARJORIE (HP-Roseville,ex1)" CC: IPS Subject: Re: iSCSI: Discovery Sessions References: <6BD67FFB937FD411A04F00D0B74FE87802A091BC@xrose06.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I was working through history there. DiscoverySession, BootSesion, and CopyManagerSession are all gone. Only SessionType is needed. -- Mark "KRUEGER,MARJORIE (HP-Roseville,ex1)" wrote: > > .. snip .. > > > Julian had suggested that we simply provide a text key at > > login that says > > > > DiscoverySession=yes > > > > to indicate that the session was to be used for SendTargets; > > no TargetName would need to be specified at all for the session. > > > > Since this was analogous to other "special" sessions, such as > > boot and copy manager sessions, we further combined these > > separate booleans into a SessionType. > > > > This means that rather than specifying the target "iscsi" in > > the login request, the initiator would instead specify: > > > > SessionType=Discovery > > So which is it, "DiscoverySession" or "SessionType"? If both, why do we > need both? > > On another note, Appendix D should *clearly* indicate which of these keys > are mandatory to implement (which means offer and answer). > > Marjorie Krueger > Networked Storage Architecture > Networked Storage Solutions Org. > Hewlett-Packard -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 17 19:10:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07468 for ; Tue, 17 Jul 2001 19:10:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HLsh021758 for ips-outgoing; Tue, 17 Jul 2001 17:54:43 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6HLsgg21753 for ; Tue, 17 Jul 2001 17:54:42 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: Discovery Sessions In-Reply-To: Message from Mark Bakke of "Tue, 17 Jul 2001 15:36:00 CDT." <3B54A1B0.99344EF@cisco.com> References: <3B54A1B0.99344EF@cisco.com> Date: Tue, 17 Jul 2001 17:54:03 -0400 From: Stephen Bailey Message-Id: <20010717215440.F398A4E8A@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > Julian had suggested that we simply provide a text key at > login that says > > DiscoverySession=yes Amen. Steph From owner-ips@ece.cmu.edu Tue Jul 17 19:13:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08198 for ; Tue, 17 Jul 2001 19:13:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HLweu22042 for ips-outgoing; Tue, 17 Jul 2001 17:58:40 -0400 (EDT) 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 f6HLwdg22037 for ; Tue, 17 Jul 2001 17:58:39 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7NPHF>; Tue, 17 Jul 2001 17:57:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A4E@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: London: Call for agenda items Date: Tue, 17 Jul 2001 17:54:21 -0400 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 We're starting to assemble the London agenda. iSCSI draft authors, please coordinate your request for time with John Hufferd (iSCSI Technical Coordinator, hufferd@us.ibm.com). Anyone else wanting agenda time should send the request to me, including the purpose of the time and the associated Internet-Draft (if any). A couple of reminders: - London is primarily for iSCSI-related topics. FCIP and iFCP topics will be take up in the Orange County, CA interim meeting due to the conflict between the London IETF meetings and the T11 meetings. - Agenda time is to work on open issues. ASSUME THAT ATTENDEES HAVE READ THE DRAFTS! Time should not be used for presentations covering draft contents. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Tue Jul 17 20:04:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17313 for ; Tue, 17 Jul 2001 20:04:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HKYJK15663 for ips-outgoing; Tue, 17 Jul 2001 16:34:19 -0400 (EDT) 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 f6HKYHg15656 for ; Tue, 17 Jul 2001 16:34:17 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA00522 for ; Tue, 17 Jul 2001 16:34:11 -0400 (EDT) Message-ID: <3B54A004.EEC994B2@cisco.com> Date: Tue, 17 Jul 2001 15:28:52 -0500 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: iSCSI: Case-sensitivity in iSCSI names Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We are attempting to wrap up all of the issues surrounding the creation and comparison of iSCSI initiator and target names. One of these is whether the names are case-sensitive. The last naming & discovery draft stated that the names are case-insensitive; this was to allow better transcribability in cases where names were communicated outside the automated discovery processes. This comes at some expense, particularly since these names are defined to allow UTF-8 encoding of international character sets. Initiators and targets would have to include code to compare these sets. To simplify implementation and interoperability, it has been recommended that we make iSCSI names case-sensitive instead. I am fine with doing this, and I think that we could even get some of the usability back by adding these rules: - iSCSI names MUST be case-sensitive, and compared strictly byte-for-byte. - iSCSI names SHOULD be generated in a case-insensitive manner. I'm not sure how to properly word the latter, but the intent is that someone generating the names would not produce both: iqn.9.com.cisco.myiscsithing and iqn.9.com.cisco.MyIscsiThing since a user would be likely to confuse these. Again, it doesn't affect the protocol itself, just its usability. Any thoughts? Will it hurt anyone's plans if iSCSI names were case-sensitive? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 17 20:04:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17323 for ; Tue, 17 Jul 2001 20:04:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HKsP517252 for ips-outgoing; Tue, 17 Jul 2001 16:54:25 -0400 (EDT) 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 f6HKsOg17248 for ; Tue, 17 Jul 2001 16:54:24 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA26887; Tue, 17 Jul 2001 16:54:17 -0400 (EDT) Message-ID: <3B54A4B9.35D2F1F8@cisco.com> Date: Tue, 17 Jul 2001 15:48:57 -0500 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: Matt Wakeley CC: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase References: <200107162226.RAA09889@isis.visi.com> <3B5391CB.7C52943E@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 Given that this is being interpreted differently by enough implementations, I would prefer to see us take a step back and look at which of Scott's three options should make the most sense. It looks like options #1 and #2 are what is currently being implemented, regardless of what's specified. However, a connection technically can't really be part of a session (sharing its work load) until it has completed a successful login phase. There's also little reason for numbering until the login phase is complete, since the login and text responses during negotiation are synchronous, and pertain only to the connection, rather than the session. I would recommend stating that a connection joins (or becomes, if it's the first one) a session after the login response with the F bit set is sent (on a target), or after the login response with the F bit set is received (on an initiator), and that CmdSN is not necessary until such a time, especially since CmdSN is per-session, not per-connection. This is identical to Scott's option 3. I think that defining it this way would remove any further ambiguity on when a connection is part of a session. Since it appears that most implementations will have to modify their login code anyway, this shouldn't be too bad. -- Mark Matt Wakeley wrote: > > I think it's pretty obvious that it's your option #1: (the initiator supplies > the initial CmdSN in the login PDU, and for every command PDU after that, the > CmdSN gets incremented, just like in "full feature phase") > > 2.10.7 CmdSN says "CmdSN is either the initial number of a session..." > [Julian, this should say "initial command number of a session"] > > So, the Login PDU defines the first CmdSN. > > 1.2.2.1 says "Commands in transit from the initiator to the target layer are > numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN". Text > commands are commands, so they are numbered also. > > It goes on to say "CmdSN - the current command Sequence Number advanced by 1 > on each command shipped except for commands marked for immediate delivery." > > I agree that this needs to be cleaned up. CmdSN and StatSN should work during > login just like they do during "full feature phase" - there is no reason why > the should not, and making them always work the same removes complexity and > interoperability problems. > > -Matt > > "Scott M. Ferris" wrote: > > > > At what point during the Login Phase of a leading connection (null > > TSID) does a session exist? > > > > Section 2.10.7 describing CmdSN for the Login PDU indicates that > > when TSID is null, CmdSN indicates the starting Command Sequence > > number for this session. > > > > For interoperability, it is important to define precisely when a > > session exists, so that all initiators and targets agree on when > > CmdSNs are significant, and do not reject or ignore PDUs due to > > differing assumptions of how the CmdSN numbering should be done during > > the Login Phase. > > > > Some of the possible choices for session start are: > > > > 1) a session starts before the initiator sends anything, and the Login > > PDU is the first PDU of a session. > > > > 2) a session starts when the initiator receives a (possibly partial) > > Login Response with an accept status class and a non-zero TSID, and > > the next PDU sent by the initiator is the first PDU of the session, > > which uses the same CmdSN as the Login PDU. > > > > 3) a session starts when the initiator receives a Final Login > > Response, and the next PDU sent by the initiator is the first PDU > > of the session, which uses the same CmdSN as the Login PDU. > > > > After searching through draft 6, I was unable to find anything that > > clearly indicated which if any of the above possibilities was correct, > > or, if more than one is possible, how the initiator and target are > > supposed to determine what CmdSN numbering scheme the other side is > > using for the Login Phase. > > > > The UNH draft-6 initiator appears to use choice #1. The Cisco > > draft-6 initiator and target use choice #2. This can cause the UNH > > initiator to hang when trying to login to the Cisco target, since the > > initiator may send a Text PDU with CmdSN 2, while the target is > > waiting for a PDU with CmdSN 1. > > > > Section 1.2.2.2 states that "Status numbering starts after > > Login. During login, there is always only one outstanding command per > > connection and status numbering is not strictly needed but may be used > > as a sanity check." > > > > A similar argument could be made that CmdSN is not needed during the > > Login Phase, suggesting choice #3 may be the simplest. > > > > I also think section 1.2.2.2 is problematic, as it appears to > > contradict itself by saying that status numbering is not used during > > login, and then follows up saying status numbering may be used during > > login. > > > > -- > > Scott M. Ferris, > > sferris@acm.org -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 17 20:04:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17325 for ; Tue, 17 Jul 2001 20:04:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HHllI03447 for ips-outgoing; Tue, 17 Jul 2001 13:47:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from corb.mc.mpls.visi.com (corb.mc.mpls.visi.com [208.42.156.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6HHljg03443 for ; Tue, 17 Jul 2001 13:47:45 -0400 (EDT) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by corb.mc.mpls.visi.com (Postfix) with ESMTP id 710B2816D; Tue, 17 Jul 2001 12:47:40 -0500 (CDT) Received: (from dreamcat@localhost) by isis.visi.com (8.8.8/8.8.8) id MAA26163; Tue, 17 Jul 2001 12:47:40 -0500 (CDT) Message-Id: <200107171747.MAA26163@isis.visi.com> Subject: Re: iSCSI: CmdSN during the Login phase In-Reply-To: from Julian Satran at "Jul 17, 2001 12:06:04 pm" To: Julian Satran Date: Tue, 17 Jul 2001 12:47:40 -0500 (CDT) Cc: ips@ece.cmu.edu From: "Scott M. Ferris" X-Loop: sferris@acm.org X-Mailer: ELM [version 2.4ME+ PL66 (25)] 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 Julian Satran wrote: > The issue of the leading connection goes beyon numbering. The leading > connection login has to end (successfully) before any other login (if any) > can start. Obviously CmdSN starts from the leading login. > > The text for CmdSN in Login now reads: > > 1.1.1 CmdSN > > CmdSN is either the initial command sequence number of a session (for > the first Login of a session - the "leading" login) or the command > sequence number in the command stream. That text in 1.1.1 by itself is not sufficient to convince me that CmdSN starts from the leading login. It also needs to be made clear that the leading Login PDU is considered part of the session. In earlier drafts, the Login PDU had a field called InitCmdRN, and the text seemed to imply the InitCmdRN (and InitStatRN of the Login response) refered only to subsequent PDUs, not the current PDU. If the Login PDU is going to have a valid CmdSN rather than an InitCmdSN, why does the Login Response have an InitStatSN rather than a StatSN? The naming is inconsistent, and the InitStatSN text in 2.11.5 still reads to me as if the InitStatSN refers only to subsequent PDUs, and is telling the initiator what StatSN the target will start with later, not acting as a StatSN itself. It would seem more consistent for the Login Response to have a StatSN it could use. Perhaps that is already the intended meaning, and I'm just finding 2.11.5 unclear. Somewhere in the draft, I'd like to see a precise definition of when a session starts. I don't think that either defat 06 or 06-97 is sufficiently clear on that point. By putting a CmdSN on the leading Login PDU and calling it the initial CmdSN of a session, a session appears to be defined as existing before any PDUs are sent, which seems rather odd to me, and not what I would have expected. It seems more natural to me to define a session as existing after a successful leading Login. I suppose a session could be defined as existing as soon as the target receives a leading Login PDU, though I'm not sure that definition is consistent with section 1.2.1, which states that "A session is defined by a session ID that is composed of an initiator part and a target part." I read that as saying that a session exists when you have a session id, which contains an ISID and a TSID. To get a TSID, you need the initiator to send the target a Login PDU with an ISID. To get a Login PDU to the target, you need to already have a session, since the leading Login PDU is the first PDU of a session. There's a circular dependency there. That definition also seems inconsistent with the first paragraph of section 1.2.3, which seems to imply a connection becomes part of session only at the end of a login by placing "and mark the connection as belonging to an iSCSI session" last, after all of the other login activities. From just a numbering perspective, I agree that numbering starting from the Login PDU makes a lot of sense. The problems I have with the draft 06 (and 06-97) come from the definition of a session, since the CmdSN is defined as numbering PDUs in a session, not just numbering PDUs. -- Scott M. Ferris, sferris@acm.org From owner-ips@ece.cmu.edu Tue Jul 17 20:55:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA29612 for ; Tue, 17 Jul 2001 20:55:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HKxmv17669 for ips-outgoing; Tue, 17 Jul 2001 16:59:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6HKxkg17665 for ; Tue, 17 Jul 2001 16:59:46 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 22F351054; Tue, 17 Jul 2001 13:59:45 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 32FFF1F51B; Tue, 17 Jul 2001 13:59:37 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Jul 2001 13:59:37 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A091BC@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mark Bakke'" , IPS Subject: RE: iSCSI: Discovery Sessions Date: Tue, 17 Jul 2001 13:59:35 -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 .. snip .. > Julian had suggested that we simply provide a text key at > login that says > > DiscoverySession=yes > > to indicate that the session was to be used for SendTargets; > no TargetName would need to be specified at all for the session. > > Since this was analogous to other "special" sessions, such as > boot and copy manager sessions, we further combined these > separate booleans into a SessionType. > > This means that rather than specifying the target "iscsi" in > the login request, the initiator would instead specify: > > SessionType=Discovery So which is it, "DiscoverySession" or "SessionType"? If both, why do we need both? On another note, Appendix D should *clearly* indicate which of these keys are mandatory to implement (which means offer and answer). Marjorie Krueger Networked Storage Architecture Networked Storage Solutions Org. Hewlett-Packard From owner-ips@ece.cmu.edu Tue Jul 17 21:04:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01668 for ; Tue, 17 Jul 2001 21:04:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HNddb28711 for ips-outgoing; Tue, 17 Jul 2001 19:39:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from c007.snv.cp.net (c007-h013.c007.snv.cp.net [209.228.33.220]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6HNdbg28706 for ; Tue, 17 Jul 2001 19:39:37 -0400 (EDT) Received: (cpmta 8515 invoked from network); 17 Jul 2001 16:39:30 -0700 Received: from adsl-63-202-160-80.dsl.snfc21.pacbell.net (HELO littlejoy) (63.202.160.80) by smtp.telocity.com (209.228.33.220) with SMTP; 17 Jul 2001 16:39:30 -0700 X-Sent: 17 Jul 2001 23:39:30 GMT From: "Douglas Otis" To: , Subject: RE: London: Call for agenda items Date: Tue, 17 Jul 2001 16:37:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <277DD60FB639D511AC0400B0D068B71E070A4E@corpmx14.us.dg.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Unless I missed something, iSCSI is still at the same revision as the last interim meeting. Will there be an updated draft presented prior to the meeting? It is difficult to understand the consensus that has be reached just upon examining the reflector. Is there a document that reflects these current changes? Doug > We're starting to assemble the London agenda. iSCSI > draft authors, please coordinate your request for time > with John Hufferd (iSCSI Technical Coordinator, > hufferd@us.ibm.com). Anyone else wanting agenda time > should send the request to me, including the purpose > of the time and the associated Internet-Draft (if any). > > A couple of reminders: > - London is primarily for iSCSI-related topics. FCIP and > iFCP topics will be take up in the Orange County, > CA interim meeting due to the conflict between > the London IETF meetings and the T11 meetings. > - Agenda time is to work on open issues. ASSUME THAT > ATTENDEES HAVE READ THE DRAFTS! Time should not > be used for presentations covering draft contents. > > 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 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Tue Jul 17 23:20:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24026 for ; Tue, 17 Jul 2001 23:20:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6HMoIQ25703 for ips-outgoing; Tue, 17 Jul 2001 18:50:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6HMoFg25687 for ; Tue, 17 Jul 2001 18:50:15 -0400 (EDT) Received: from breinhold (lucent3.iol.unh.edu [132.177.125.48]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f6HMoDg14320 for ; Tue, 17 Jul 2001 18:50:13 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: Iscsi Group Test Period - End of 2nd day Date: Tue, 17 Jul 2001 18:46:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C10EF0.BFF81110" 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 This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C10EF0.BFF81110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Report from the iSCSI InterOperability Front: The second day of testing settled down significantly from the first, at least in terms of new issues relative to the iSCSI specification. Login is clearly a problem area but a set of simple rules has been adopted to allow implementors to move on to other elements of iSCSI interoperability. In terms of progress we have completed 10 rounds of testing. The new issues identified today are: 1. Case sensistivity - Are target names case sensative (does iSCSI = ISCSI). This issue has already been picked up as a mailing list thread. 2. The issue of what the iSCSI target represents/can represent also caused interoperability problems. Some devices wish to be simple and return "iscsi" in response to the SendTargets key. This is not acceptable to some initiators. 3. Padding was an issue in a large number of interoperability failures - causing the iSCSI stream to get out of sync. Although there is no debate over what the standard says it may be desirable to further underscore the padding process. 4. If a text command is sent with F=1 and the target replies with a text command with no additional keys but does not set F=1 is this an error? (The consensus is no, but this behavior is not desirable.) A larger number of SCSI issues were observed in the testing process, which is an indication that progress was being made. The attached pdf was distributed as a guide to login. Barry Reinhold Principal Architect Trebia Networks barry.reinhold@trebia.com 603-868-5144/603-659-0885/978-929-0830 x138 ------=_NextPart_000_000B_01C10EF0.BFF81110 Content-Type: application/pdf; name="target-login3.pdf" Content-Disposition: attachment; filename="target-login3.pdf" Content-Transfer-Encoding: quoted-printable %PDF-1.2 =0D%=E2=E3=CF=D3 =0D8 0 obj=0D<<=0D/Length 9 0 R=0D/Filter /FlateDecode =0D>>=0Dstream H=89=B5W=DBn=1BG=0C=FD=02=FD=C3 = =0F=81Sx7s=BF<=F8=A5I]=A0(Z=A3v=DF=0C=08=82=BDq=1C(R = =C9M=F3=F7=E5=0C9=B7=B5=A3=BAi=0B=03=868=CB=1D=EE=1C=1E=1Er=F8=E8=0C=FB=CC= =16=82=FD=14=FF}`=0B=CE=E2=DFo?=B2=85=14L;9=1A=F6=91-=82=A2=DFk=B6=B8d=0B= =E3=EA#=F8=AD=B8=A5=07=DF_-=B4=1E=A5=81=C7.n=CD=AE=DE=D2=8E=BB;=B6x}=CE=99= =90=B0=F8n1=F0Q=08=EF=E1=F7=0D=B6=AD=E5=F8=98=9F=82=91%=A8=DF=AA=A4=9D=A4= R*3=B6J=89v=C7=BD=EA=82=B6=B0=BD=BAIT7=A9%=81;W=EC@=A5=03n=882=00r=FE=B0^= =B3=F3 = =A8=B3=9B=9036=12=A1hP=B0-|=17=EFW=FB=82_>=10=9F=EB77=BD6H=FB=F8,=B6=A8=0F= W=B8=E0=F0=8D=18]Z[v=08=BD=D5=F9=B6[=B5u=A4-}YV=85=C7=EA#\=91=08=A7=FC=11= =9A = =A0=D9Kv=BB%)r=C7=D8E=DC=1A=8CH)=10(=0F=B9}x=9D#=82n=E0=0B=A5=86=1F1=FB%=DB= l=0F=D7'=85=DC=B7=18=DF=A8ZdC$=8E=ECJ=1A=D8=DDJ=1A=B2Qv=AAFv=97=8D=D6=87=03= CC=AFj=85=D0=C5=CEV=FC=D9=ABZ=DD~=A6j=CA=AA=B6=E9=FE=FF=B26D/)=C7=DA=168w= 9=A6q=F2h=06N=8B=AC=C46=04=BC=98=B7=0F=0A= =02=92X=AAe=10=A0X2=87=900=9Fi=D3=8Fn=BAv=1D\0=A28=80!=FB=1EW=03=CC=A79=A3=0A= =19B!=83=F9=1B2=F4=B9&=F1Wa=FCz=AE=1F=0F6Z8Ru=ED=DB=85uYP=81g=F5=861=A1ZM= g=C0=B5rKPA=D57=D0A=B5=96=F7=F9=CE=90=BC=BD=9Bu=87=12b~K=C8=C4L=CD=C1P=86= =E7W=83:=B1=C3\=D3=F5V'=8A=B4K/=9F15vRK=BD=957R=EB=B9n=D1]=B6=8A=1B=3D=07= =1Dj%qkC = =AF=F4=B1=F0=CFh,5=F3X=E3=D0)=9B=16=D0~=D5=97eS=E1:=DEWUS=DE=A0O=F9=A3|pM= y=E7/=FB=07=D5=CD[=E6=19=EF=BB=EA.=B8$=B7=EE*V=D4=FE=BF=D3y=14_-=B3=8E;=99= t=99=16=D6eA=85=A2=D7=D06=AB=D5=F4=82=90'W=13d"=B7=AFo=A0=83=1B{[=A1=85=DE= r=D6=0FJ=88Bn=E3#Kt=1Ap=BE=91=DA=A0=CC=85[=D6=1C=E5=16Q;=CF=AA=C2=1C=91=8B= =CD=A31=BE\q`=1E=EE/*yA=8B=16P-=1E=03=8Ak=15P=ADg=80j=D5=03=0A= }=A2=02=AA=FC=0C=D0=12b=06=A82=EE=DFhE=1D=3DU=1E=3D=9F=00=B4=0E=E1$=BF\=8D= =CF=1A=BD=A1=D9=A6x=83=F3]=1E=9F1=F1=CE=86]=A8Mv~F=E2=DF=DF<=E6S=AF=A0=E0= =91=B0=A0=05=A9=E7=B0=D7=E7=82 =9D=AF=3D|=84=BB=96=CB=C3=1At = =D2=C9=AB=D5=EEn:=B0=9F=E3g=B0=8B=DD=F6f=DA=EF39=FE=02o=A8=B2=8E=0Dendstr= eam=0Dendobj=0D9 0 obj=0D1519=0Dendobj=0D4 0 obj=0D<<=0D/Type = /Page=0D/Parent 5 0 R=0D/Resources <<=0D/Font <<=0D/F0 6 0 R =0D/F1 10 0 = R =0D>>=0D/ProcSet 2 0 R=0D>>=0D/Contents 8 0 R=0D>>=0Dendobj=0D6 0 = obj=0D<<=0D/Type /Font=0D/Subtype /TrueType=0D/Name /F0=0D/BaseFont = /Arial=0D/FirstChar 32=0D/LastChar 255=0D/Widths [ 278 278 355 556 556 = 889 667 191 333 333 389 584 278 333 278 278 =0D556 556 556 556 556 556 = 556 556 556 556 278 278 584 584 584 556 =0D1015 667 667 722 722 667 611 = 778 722 278 500 667 556 833 722 778 =0D667 778 722 667 611 722 667 944 = 667 667 611 278 278 278 469 556 =0D333 556 556 500 556 556 278 556 556 = 222 222 500 222 833 556 556 =0D556 556 333 500 278 556 500 722 500 500 = 500 334 260 334 584 750 =0D556 750 222 556 333 1000 556 556 333 1000 667 = 333 1000 750 611 750 =0D750 222 222 333 333 350 556 1000 333 1000 500 = 333 944 750 500 667 =0D278 333 556 556 556 556 260 556 333 737 370 556 = 584 333 737 552 =0D400 549 333 333 333 576 537 278 333 333 365 556 834 = 834 834 611 =0D667 667 667 667 667 667 1000 722 667 667 667 667 278 278 = 278 278 =0D722 722 778 778 778 778 778 584 778 722 722 722 722 667 667 = 611 =0D556 556 556 556 556 556 889 500 556 556 556 556 278 278 278 278 = =0D556 556 556 556 556 556 556 549 611 556 556 556 556 500 556 500 = =0D]=0D/Encoding /WinAnsiEncoding=0D/FontDescriptor 7 0 = R=0D>>=0Dendobj=0D7 0 obj=0D<<=0D/Type /FontDescriptor=0D/FontName = /Arial=0D/Flags 32=0D/FontBBox [ -250 -212 1208 1000 ]=0D/MissingWidth = 276=0D/StemV 80=0D/StemH 80=0D/ItalicAngle 0=0D/CapHeight 905=0D/XHeight = 453=0D/Ascent 905=0D/Descent -212=0D/Leading 150=0D/MaxWidth = 1007=0D/AvgWidth 441=0D>>=0Dendobj=0D10 0 obj=0D<<=0D/Type = /Font=0D/Subtype /TrueType=0D/Name /F1=0D/BaseFont = /Arial,Bold=0D/FirstChar 32=0D/LastChar 255=0D/Widths [ 278 333 474 556 = 556 889 722 238 333 333 389 584 278 333 278 278 =0D556 556 556 556 556 = 556 556 556 556 556 333 333 584 584 584 611 =0D975 722 722 722 722 667 = 611 778 722 278 556 722 611 833 722 778 =0D667 778 722 667 611 722 667 = 944 667 667 611 333 278 333 584 556 =0D333 556 611 556 611 556 333 611 = 611 278 278 556 278 889 611 611 =0D611 611 389 556 333 611 556 778 556 = 556 500 389 280 389 584 750 =0D556 750 278 556 500 1000 556 556 333 1000 = 667 333 1000 750 611 750 =0D750 278 278 500 500 350 556 1000 333 1000 = 556 333 944 750 500 667 =0D278 333 556 556 556 556 280 556 333 737 370 = 556 584 333 737 552 =0D400 549 333 333 333 576 556 278 333 333 365 556 = 834 834 834 611 =0D722 722 722 722 722 722 1000 722 667 667 667 667 278 = 278 278 278 =0D722 722 778 778 778 778 778 584 778 722 722 722 722 667 = 667 611 =0D556 556 556 556 556 556 889 556 556 556 556 556 278 278 278 = 278 =0D611 611 611 611 611 611 611 549 611 611 611 611 611 556 611 556 = =0D]=0D/Encoding /WinAnsiEncoding=0D/FontDescriptor 11 0 = R=0D>>=0Dendobj=0D11 0 obj=0D<<=0D/Type /FontDescriptor=0D/FontName = /Arial,Bold=0D/Flags 16416=0D/FontBBox [ -250 -212 1160 1000 = ]=0D/MissingWidth 322=0D/StemV 153=0D/StemH 153=0D/ItalicAngle = 0=0D/CapHeight 905=0D/XHeight 453=0D/Ascent 905=0D/Descent = -212=0D/Leading 150=0D/MaxWidth 967=0D/AvgWidth 479=0D>>=0Dendobj=0D2 0 = obj=0D[ /PDF /Text ]=0Dendobj=0D5 0 obj=0D<<=0D/Kids [4 0 R ]=0D/Count = 1=0D/Type /Pages=0D/MediaBox [ 0 0 792 612 ]=0D>>=0Dendobj=0D1 0 = obj=0D<<=0D/Creator = =0D/CreationDate (D:20010717183748)=0D/Title = =0D= /Author =0D/Producer (Acrobat = PDFWriter 4.05 for Windows NT)=0D>>=0Dendobj=0D3 0 obj=0D<<=0D/Pages 5 0 = R=0D/Type /Catalog=0D>>=0Dendobj=0Dxref=0D0 12=0D0000000000 65535 f = =0D0000004571 00000 n =0D0000004456 00000 n =0D0000004968 00000 n = =0D0000001634 00000 n =0D0000004487 00000 n =0D0000001764 00000 n = =0D0000002849 00000 n =0D0000000019 00000 n =0D0000001614 00000 n = =0D0000003102 00000 n =0D0000004193 00000 n =0Dtrailer=0D<<=0D/Size = 12=0D/Root 3 0 R=0D/Info 1 0 R=0D/ID = [<6aecafdf89b6d12690f8e98704e9f428><6aecafdf89b6d12690f8e98704e9f428>]=0D= >>=0Dstartxref=0D5017=0D%%EOF=0D ------=_NextPart_000_000B_01C10EF0.BFF81110 Content-Type: application/pdf; name="Initiator-login3.pdf" Content-Disposition: attachment; filename="Initiator-login3.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDSXi48/TDQogDTggMCBvYmoNPDwNL0xlbmd0aCA5IDAgUg0vRmlsdGVyIC9GbGF0 ZURlY29kZSANPj4Nc3RyZWFtDQpIia1X224byRH9Av5DYx8MeSFO+n4J4JfYcZBg4WhjLfZFgDCm RhJ3aVImR1b896m+VF+GpCQrhgGZ1VNd3V2XU6e+kBmzRBlBjCKigz/bgdyS38mazKgXH0CB/Mv/ +QNWiP/3n3/4Tf6jMqrjinwmM0creUVmH8ns18ctKNlaiLJ0slj42/lMcqIs7RQh5+/S5u0Nmf3l PSWMw+L1bE47xqyF3wv4SM4fyMnHsd+Or8n5H7O/n4NdFw7SOh2kOasW4knKqlYpLQjBi9IXWIZ3 g5y+MhEuG5aK2+DWWc2Ge4crah6uCL85cyZe9MNwsxmX/TiQ3bC43y7Hb+ShX47kerPF6/8aDZrk 3xCi4IuOMhYsnsBrb4b43hiWuQznEu+lcJHsJ+einzpqtIx3GIf/jpdn73673A6LYfl1uLo4ef+G Xrwmr4JFSuYunem3CSpqT+O1L6826yHoz5VgRGjcAqdSqgU+nQrD07GLO7LYrNfDYlxu1mTYjf2n 1XJ3O1wR8ors2wVXaBGcILhIQTKUVwsxSFrrViktMCmaxNKSeVkoHR30bppTXDQvzaFKr/S75kym zeFtMibhyb/vhm3vX9Wv0IWtomI6ap712/7zMA7bXc7WlIiM4xuFrRZWeUFaLDXlWCWVZE5rPpkd 77xsy46oYLpWFlGK2nhgaw4Wbsns+ucZ16mMwn9wihCiWohX4c60SmmhCRnUFddRz4agaB+IFosg YllHJDjwruTBrSG3BBMqxmq1uVmuyR2AwDKFIBcShzf7ytQOww6hpiIaOfHFF+PLeawkbjCT94qJ a6wlyxWWw/rqMpzuK4qESjolH1Myv92sfbG93Xy+W0HQ3/z0bdj9dPF6r8y8cUNlsg7nuARrb99e wgkjeUPOwyZfanPu6tTSuK+6EFb4xcnkJgdPppLhuzTV0QxeGU6uLx3QtU1XHpKnZGuVA5UOI4q6 pMFj8ilGG0l2+BUElXVNWwwxFT1A2nAs4o6HR8THUJpSPwd21pvxosW0Eh6W0i44ySZIg5+Sm0PB TygK0S9Rez/xmrSt16Td91qlA56QauI1eFclKVp5TbGJ17L57DVBmT8XcJWXklISU48y6qqK2u8S pwT8N97vLherfreLXeMAdk+9RxXPKcbMczJ1moCnJHgX/Ykv5CrBTOQMSW5bfNExDiSeNECKn0XX yjZJ/ifqNqayQ6UIxqTJJILKaiFeQ2rbKqUFoavgB+JDI+qy7lB7ogCpmU8Y56Z8Av2XulVIj7nK UPEjmAHkfUsNjKuh52gtlXhJ6bITvNuT3Dqq0uEgoStBip9NLSnW4VcQeNatTe0XQNqNBWBsTk8h U3qSZ1UApCc9AOihT+kMRjqEDoy+Io8jDt4qFI2iFiGHGnGwaNqiwFdTiw1a8mphlReExY4dw1Dk Eoa0lsIgrMw7kglZS1A7OQzC2Kxr2+NKGBwlwplM8w897uDblGgKPsktDSo6kKBS0bbgc8pkWWPB w8+24Iv5fHNpAlnSOXteyrGfTbB9YrCq5UPDjgc+CqGHW70yGYd54uVPYi1ORg7ZpTSyWsCs8RlQ 64S6FQ5BTsLcp1LMK1FEISmX+q2sNd63GtP5/3D/S4Fsro/V6PHcnUvq3xKfkuNgMpXUkh3vuE81 xfiawKybQFPmChXiMnnlWf0b5PhfHC95KIAXUFVInC++jhIkcQIUKoxlvmwbmq+sd5CksuYkVmdO Irk7GtVnOSjPAvEk4WQ1Twjqsqciw4+eOuiZkBmPYDZMhDkZgVZFY/e7gayxT19lmxCKCZiXkhM8 VBiXNMC40yjFYhOa1p+jZF1DJwT1r4QR6iCXMKJwCZs6Xr4jmc6z8xC0yUyrhSw20HF3eb4lfrQi 15stGfvtzTCmVA25KpEbTlkJtTbPIpnBk+PVvBcQ8J3W0Vsu9y9bL6zKgsaeBv25q+WPJFuJa5/9 AiVpIA07YgS0aSTe4VcQWNadHFfNMJZwW1OR0vSfboloN/o0JIJGqc2TSsPDLxfIqQSaUF0rsyhF bZq1a3PNQ2RlJwOzyrE0TB8tYQxl7nfCTRve85gQq+on3pRBt+Epej7CSW4iXOtAjTiZNDSaaCVX RZjSrFubaniODlVIWU03f0CSs9gDAdq7cHdmaZHj+5iUrUqUmRQNTrgA7VyhwydQwVQpc2YzPt6v VuT9AJ0EkPzstt8NE89zhkQAgodSe69KI1QfQ6bAVDKRqEKWRZSiNlKF1lzte/A6LGPnmu1hzSHW f5j0s6Okv6ZHNCGF0fXCKi9Ar8R8MbySarTB0UcbD5GAq2VHUDCJu6Kc8Cdqa93mYzmi8klYSoNR 7oGqzCrUuEfbVmoIXExIQaaxvnfbY+h1WrWWIz07eRb6UqA1XPF9HHgCHOcCMMSDGPaYl7c+PW17 1mVfcYl880Dbi1AWknLOMtNkrH5A1RkhkbgzceawKQkMr+RVlgG9MW9whWHaxIlG2KAeBiSBmGRa oVasrdTZEsg6VPTB+vmxJHafZlJGM/JQIdj3cdgKMwlyWblPlJ/HZeci1NOU67kM41TppmiWB6sm NrX2/O/o9wg0EqOdsDYtlAYtKOumFMBp3KRM1AloKiC5vMCzBdFKtW5jqmn/1BMfoWTd5VjI+hQ+ fmC4rXv+nAm+nwFOlEbpjjOIpxKsGmcZN91eIL8b/tz+TPRUHFkeB1XczRRunzRcoFdxpPyAp8eN CUoaMJJp+pyiFp0qKhafeHKWkWoCOyLmeIadJGd4gJGkAR3BLDJjF78nDhlgJw0wEXZqoVWtLeWE QvIWu6Y/gLNqYVUWBG70zLdIJe3TWma+TLKyI7IhVksIrUlbqKxN2wMnBA9gpKZPDUy+lAb7GOKc 9P0keM5htoBkw8YDs0mdnx8247D7K57jUItKnitBmtQcWQeFdbX06bWLA922X++S3AMB7D9tvg5k vIVf2+3mYXdK+kX8OvZ/DmvS7/JBmPO+uHU+iwmXzurJdtjdr0ayuQ4Gy1HhpE/DavOQT9o+7Lpg +fznWMesNAzGU8PgXXApmZPz7f1AHm7hQt7A1fB1uRgIcFfoFaS/ig/sV6Tq5eOmMg/tSNUuXDfl ma4QkS45kKYoiW7Snp59lwZ1cqACeRXYtyh3bo+FjBvS3o9OoNXm7ZKquF12JHe+6Q2PQeyfwzd/ 7doFvIApM8n0pwHseMMxXop7jNAFABlBuLqegae1YWhDGJtq5p/rpX8O5N8vnmSQs+1mMewyjP0P CGdBGw1lbmRzdHJlYW0NZW5kb2JqDTkgMCBvYmoNMjQzNQ1lbmRvYmoNNCAwIG9iag08PA0vVHlw ZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwNL0ZvbnQgPDwNL0YwIDYgMCBSIA0v RjEgMTAgMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMgOCAwIFINPj4NZW5kb2Jq DTYgMCBvYmoNPDwNL1R5cGUgL0ZvbnQNL1N1YnR5cGUgL1RydWVUeXBlDS9OYW1lIC9GMA0vQmFz ZUZvbnQgL0FyaWFsDS9GaXJzdENoYXIgMzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjc4IDI3 OCAzNTUgNTU2IDU1NiA4ODkgNjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4 IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0 IDU4NCA1NTYgDTEwMTUgNjY3IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2 NyA1NTYgODMzIDcyMiA3NzggDTY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2 NyA2MTEgMjc4IDI3OCAyNzggNDY5IDU1NiANMzMzIDU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1 NiA1NTYgMjIyIDIyMiA1MDAgMjIyIDgzMyA1NTYgNTU2IA01NTYgNTU2IDMzMyA1MDAgMjc4IDU1 NiA1MDAgNzIyIDUwMCA1MDAgNTAwIDMzNCAyNjAgMzM0IDU4NCA3NTAgDTU1NiA3NTAgMjIyIDU1 NiAzMzMgMTAwMCA1NTYgNTU2IDMzMyAxMDAwIDY2NyAzMzMgMTAwMCA3NTAgNjExIDc1MCANNzUw IDIyMiAyMjIgMzMzIDMzMyAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTAwIDMzMyA5NDQgNzUwIDUw MCA2NjcgDTI3OCAzMzMgNTU2IDU1NiA1NTYgNTU2IDI2MCA1NTYgMzMzIDczNyAzNzAgNTU2IDU4 NCAzMzMgNzM3IDU1MiANNDAwIDU0OSAzMzMgMzMzIDMzMyA1NzYgNTM3IDI3OCAzMzMgMzMzIDM2 NSA1NTYgODM0IDgzNCA4MzQgNjExIA02NjcgNjY3IDY2NyA2NjcgNjY3IDY2NyAxMDAwIDcyMiA2 NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IA03MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3 NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgDTU1NiA1NTYgNTU2IDU1NiA1 NTYgNTU2IDg4OSA1MDAgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggMjc4IDI3OCANNTU2IDU1NiA1 NTYgNTU2IDU1NiA1NTYgNTU2IDU0OSA2MTEgNTU2IDU1NiA1NTYgNTU2IDUwMCA1NTYgNTAwIA1d DS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nDS9Gb250RGVzY3JpcHRvciA3IDAgUg0+Pg1lbmRv YmoNNyAwIG9iag08PA0vVHlwZSAvRm9udERlc2NyaXB0b3INL0ZvbnROYW1lIC9BcmlhbA0vRmxh Z3MgMzINL0ZvbnRCQm94IFsgLTI1MCAtMjEyIDEyMDggMTAwMCBdDS9NaXNzaW5nV2lkdGggMjc2 DS9TdGVtViA4MA0vU3RlbUggODANL0l0YWxpY0FuZ2xlIDANL0NhcEhlaWdodCA5MDUNL1hIZWln aHQgNDUzDS9Bc2NlbnQgOTA1DS9EZXNjZW50IC0yMTINL0xlYWRpbmcgMTUwDS9NYXhXaWR0aCAx MDA3DS9BdmdXaWR0aCA0NDENPj4NZW5kb2JqDTEwIDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0 eXBlIC9UcnVlVHlwZQ0vTmFtZSAvRjENL0Jhc2VGb250IC9BcmlhbCxCb2xkDS9GaXJzdENoYXIg MzINL0xhc3RDaGFyIDI1NQ0vV2lkdGhzIFsgMjc4IDMzMyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIz OCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IA01NTYgNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NTYgNTU2IDU1NiA1NTYgMzMzIDMzMyA1ODQgNTg0IDU4NCA2MTEgDTk3NSA3MjIgNzIyIDcy MiA3MjIgNjY3IDYxMSA3NzggNzIyIDI3OCA1NTYgNzIyIDYxMSA4MzMgNzIyIDc3OCANNjY3IDc3 OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAzMzMgMjc4IDMzMyA1ODQgNTU2 IA0zMzMgNTU2IDYxMSA1NTYgNjExIDU1NiAzMzMgNjExIDYxMSAyNzggMjc4IDU1NiAyNzggODg5 IDYxMSA2MTEgDTYxMSA2MTEgMzg5IDU1NiAzMzMgNjExIDU1NiA3NzggNTU2IDU1NiA1MDAgMzg5 IDI4MCAzODkgNTg0IDc1MCANNTU2IDc1MCAyNzggNTU2IDUwMCAxMDAwIDU1NiA1NTYgMzMzIDEw MDAgNjY3IDMzMyAxMDAwIDc1MCA2MTEgNzUwIA03NTAgMjc4IDI3OCA1MDAgNTAwIDM1MCA1NTYg MTAwMCAzMzMgMTAwMCA1NTYgMzMzIDk0NCA3NTAgNTAwIDY2NyANMjc4IDMzMyA1NTYgNTU2IDU1 NiA1NTYgMjgwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3MzcgNTUyIA00MDAgNTQ5IDMz MyAzMzMgMzMzIDU3NiA1NTYgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQgODM0IDgzNCA2MTEgDTcy MiA3MjIgNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2NyA2NjcgNjY3IDY2NyAyNzggMjc4IDI3 OCAyNzggDTcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcy MiA2NjcgNjY3IDYxMSANNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDU1NiA1NTYgNTU2IDU1 NiA1NTYgMjc4IDI3OCAyNzggMjc4IA02MTEgNjExIDYxMSA2MTEgNjExIDYxMSA2MTEgNTQ5IDYx MSA2MTEgNjExIDYxMSA2MTEgNTU2IDYxMSA1NTYgDV0NL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcNL0ZvbnREZXNjcmlwdG9yIDExIDAgUg0+Pg1lbmRvYmoNMTEgMCBvYmoNPDwNL1R5cGUgL0Zv bnREZXNjcmlwdG9yDS9Gb250TmFtZSAvQXJpYWwsQm9sZA0vRmxhZ3MgMTY0MTYNL0ZvbnRCQm94 IFsgLTI1MCAtMjEyIDExNjAgMTAwMCBdDS9NaXNzaW5nV2lkdGggMzIyDS9TdGVtViAxNTMNL1N0 ZW1IIDE1Mw0vSXRhbGljQW5nbGUgMA0vQ2FwSGVpZ2h0IDkwNQ0vWEhlaWdodCA0NTMNL0FzY2Vu dCA5MDUNL0Rlc2NlbnQgLTIxMg0vTGVhZGluZyAxNTANL01heFdpZHRoIDk2Nw0vQXZnV2lkdGgg NDc5DT4+DWVuZG9iag0yIDAgb2JqDVsgL1BERiAvVGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0v S2lkcyBbNCAwIFIgXQ0vQ291bnQgMQ0vVHlwZSAvUGFnZXMNL01lZGlhQm94IFsgMCAwIDc5MiA2 MTIgXQ0+Pg1lbmRvYmoNMSAwIG9iag08PA0vQ3JlYXRvciA8RkVGRjAwNEQwMDY5MDA2MzAwNzIw MDZGMDA3MzAwNkYwMDY2MDA3NDAwMjAwMDU2MDA2OTAwNzMwMDY5MDA2RjAwMjAwMDJEMDAyMDAw NUIwMDZDMDA2RjAwNjcwMDY5MDA2RTAwMzMwMDJFMDA3NjAwNzMwMDY0MDAzQTAwNjkwMDZFMDA2 OTAwNzQwMDY5MDA2MTAwNzQwMDZGMDA3MjAwNUQ+DS9DcmVhdGlvbkRhdGUgKEQ6MjAwMTA3MTcx ODM3MDQpDS9UaXRsZSA8RkVGRjAwNTYwMDY5MDA3MzAwNjkwMDZGMDAyRDAwNkMwMDZGMDA2NzAw NjkwMDZFMDAzMzAwMkUwMDUwMDA0NDAwNDY+DS9BdXRob3IgPEZFRkYwMDYyMDA3MjAwNjUwMDY5 MDA2RTAwNjgwMDZGMDA2QzAwNjQ+DS9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0ZXIgNC4wNSBm b3IgV2luZG93cyBOVCkNPj4NZW5kb2JqDTMgMCBvYmoNPDwNL1BhZ2VzIDUgMCBSDS9UeXBlIC9D YXRhbG9nDT4+DWVuZG9iag14cmVmDTAgMTINMDAwMDAwMDAwMCA2NTUzNSBmIA0wMDAwMDA1NDg3 IDAwMDAwIG4gDTAwMDAwMDUzNzIgMDAwMDAgbiANMDAwMDAwNTg5NiAwMDAwMCBuIA0wMDAwMDAy NTUwIDAwMDAwIG4gDTAwMDAwMDU0MDMgMDAwMDAgbiANMDAwMDAwMjY4MCAwMDAwMCBuIA0wMDAw MDAzNzY1IDAwMDAwIG4gDTAwMDAwMDAwMTkgMDAwMDAgbiANMDAwMDAwMjUzMCAwMDAwMCBuIA0w MDAwMDA0MDE4IDAwMDAwIG4gDTAwMDAwMDUxMDkgMDAwMDAgbiANdHJhaWxlcg08PA0vU2l6ZSAx Mg0vUm9vdCAzIDAgUg0vSW5mbyAxIDAgUg0vSUQgWzw3ZjgxZjQwMjhiMzAxZGQ0ZmZjZjgzYTI3 OWQ1ZmUwOT48N2Y4MWY0MDI4YjMwMWRkNGZmY2Y4M2EyNzlkNWZlMDk+XQ0+Pg1zdGFydHhyZWYN NTk0NQ0lJUVPRg0= ------=_NextPart_000_000B_01C10EF0.BFF81110-- From owner-ips@ece.cmu.edu Wed Jul 18 05:15:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04374 for ; Wed, 18 Jul 2001 05:15:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6I8CdE28396 for ips-outgoing; Wed, 18 Jul 2001 04:12:39 -0400 (EDT) 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 f6I8Ccg28392 for ; Wed, 18 Jul 2001 04:12:38 -0400 (EDT) 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 KAA337270 for ; Wed, 18 Jul 2001 10:12:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6I8CUm42204 for ; Wed, 18 Jul 2001 10:12:30 +0200 Importance: Normal Subject: RE: London: Call for agenda items To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 11:18:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 11:12:29 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk rev. 07 will be issued this week. Julo "Douglas Otis" on 18-07-2001 02:37:36 Please respond to "Douglas Otis" To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: RE: London: Call for agenda items David, Unless I missed something, iSCSI is still at the same revision as the last interim meeting. Will there be an updated draft presented prior to the meeting? It is difficult to understand the consensus that has be reached just upon examining the reflector. Is there a document that reflects these current changes? Doug > We're starting to assemble the London agenda. iSCSI > draft authors, please coordinate your request for time > with John Hufferd (iSCSI Technical Coordinator, > hufferd@us.ibm.com). Anyone else wanting agenda time > should send the request to me, including the purpose > of the time and the associated Internet-Draft (if any). > > A couple of reminders: > - London is primarily for iSCSI-related topics. FCIP and > iFCP topics will be take up in the Orange County, > CA interim meeting due to the conflict between > the London IETF meetings and the T11 meetings. > - Agenda time is to work on open issues. ASSUME THAT > ATTENDEES HAVE READ THE DRAFTS! Time should not > be used for presentations covering draft contents. > > 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 > --------------------------------------------------- > > From owner-ips@ece.cmu.edu Wed Jul 18 05:17:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04860 for ; Wed, 18 Jul 2001 05:17:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6I7lDk27038 for ips-outgoing; Wed, 18 Jul 2001 03:47:13 -0400 (EDT) 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 f6I7lBg27034 for ; Wed, 18 Jul 2001 03:47:11 -0400 (EDT) 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 JAA12860 for ; Wed, 18 Jul 2001 09:47:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6I7l4m47704 for ; Wed, 18 Jul 2001 09:47:04 +0200 Importance: Normal Subject: Re: iSCSI: CmdSN during the Login phase To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 10:53:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 10:47:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Why should one use a different mechanism during login than anywhere else? Besides Login sequencing for non leading connections is important for recovery (login of a new connection has to come after the logout of the old). CmdsN starts from the leading login (the leading login is guaranteed to be serialized) and is following it every command/request that is non-immediate is counted. Julo Mark Bakke on 17-07-2001 23:48:57 Please respond to Mark Bakke To: Matt Wakeley cc: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase Given that this is being interpreted differently by enough implementations, I would prefer to see us take a step back and look at which of Scott's three options should make the most sense. It looks like options #1 and #2 are what is currently being implemented, regardless of what's specified. However, a connection technically can't really be part of a session (sharing its work load) until it has completed a successful login phase. There's also little reason for numbering until the login phase is complete, since the login and text responses during negotiation are synchronous, and pertain only to the connection, rather than the session. I would recommend stating that a connection joins (or becomes, if it's the first one) a session after the login response with the F bit set is sent (on a target), or after the login response with the F bit set is received (on an initiator), and that CmdSN is not necessary until such a time, especially since CmdSN is per-session, not per-connection. This is identical to Scott's option 3. I think that defining it this way would remove any further ambiguity on when a connection is part of a session. Since it appears that most implementations will have to modify their login code anyway, this shouldn't be too bad. -- Mark Matt Wakeley wrote: > > I think it's pretty obvious that it's your option #1: (the initiator supplies > the initial CmdSN in the login PDU, and for every command PDU after that, the > CmdSN gets incremented, just like in "full feature phase") > > 2.10.7 CmdSN says "CmdSN is either the initial number of a session..." > [Julian, this should say "initial command number of a session"] > > So, the Login PDU defines the first CmdSN. > > 1.2.2.1 says "Commands in transit from the initiator to the target layer are > numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN". Text > commands are commands, so they are numbered also. > > It goes on to say "CmdSN - the current command Sequence Number advanced by 1 > on each command shipped except for commands marked for immediate delivery." > > I agree that this needs to be cleaned up. CmdSN and StatSN should work during > login just like they do during "full feature phase" - there is no reason why > the should not, and making them always work the same removes complexity and > interoperability problems. > > -Matt > > "Scott M. Ferris" wrote: > > > > At what point during the Login Phase of a leading connection (null > > TSID) does a session exist? > > > > Section 2.10.7 describing CmdSN for the Login PDU indicates that > > when TSID is null, CmdSN indicates the starting Command Sequence > > number for this session. > > > > For interoperability, it is important to define precisely when a > > session exists, so that all initiators and targets agree on when > > CmdSNs are significant, and do not reject or ignore PDUs due to > > differing assumptions of how the CmdSN numbering should be done during > > the Login Phase. > > > > Some of the possible choices for session start are: > > > > 1) a session starts before the initiator sends anything, and the Login > > PDU is the first PDU of a session. > > > > 2) a session starts when the initiator receives a (possibly partial) > > Login Response with an accept status class and a non-zero TSID, and > > the next PDU sent by the initiator is the first PDU of the session, > > which uses the same CmdSN as the Login PDU. > > > > 3) a session starts when the initiator receives a Final Login > > Response, and the next PDU sent by the initiator is the first PDU > > of the session, which uses the same CmdSN as the Login PDU. > > > > After searching through draft 6, I was unable to find anything that > > clearly indicated which if any of the above possibilities was correct, > > or, if more than one is possible, how the initiator and target are > > supposed to determine what CmdSN numbering scheme the other side is > > using for the Login Phase. > > > > The UNH draft-6 initiator appears to use choice #1. The Cisco > > draft-6 initiator and target use choice #2. This can cause the UNH > > initiator to hang when trying to login to the Cisco target, since the > > initiator may send a Text PDU with CmdSN 2, while the target is > > waiting for a PDU with CmdSN 1. > > > > Section 1.2.2.2 states that "Status numbering starts after > > Login. During login, there is always only one outstanding command per > > connection and status numbering is not strictly needed but may be used > > as a sanity check." > > > > A similar argument could be made that CmdSN is not needed during the > > Login Phase, suggesting choice #3 may be the simplest. > > > > I also think section 1.2.2.2 is problematic, as it appears to > > contradict itself by saying that status numbering is not used during > > login, and then follows up saying status numbering may be used during > > login. > > > > -- > > Scott M. Ferris, > > sferris@acm.org -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 08:21:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10251 for ; Wed, 18 Jul 2001 08:21:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6I414p14135 for ips-outgoing; Wed, 18 Jul 2001 00:01:04 -0400 (EDT) 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 f6I412g14130 for ; Wed, 18 Jul 2001 00:01:02 -0400 (EDT) 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 XAA24160 for ; Tue, 17 Jul 2001 23:53:00 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6I411Z213714 for ; Tue, 17 Jul 2001 22:01:01 -0600 Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Tue, 17 Jul 2001 05:00:57 +0100 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/17/2001 09:01:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Though we (NDT) had originally thought that having the names case-insensitive (because many names would be derived from IPnames, which are case insensitive), perhaps your suggestion is the simplest solution (both for implementation and specifictation). In short, I have no objections to making the name case-sensitive for all the reasons you mentioned. Jim Hafner Mark Bakke @ece.cmu.edu on 07/17/2001 09:28:52 PM Sent by: owner-ips@ece.cmu.edu To: IPS cc: Subject: iSCSI: Case-sensitivity in iSCSI names We are attempting to wrap up all of the issues surrounding the creation and comparison of iSCSI initiator and target names. One of these is whether the names are case-sensitive. The last naming & discovery draft stated that the names are case-insensitive; this was to allow better transcribability in cases where names were communicated outside the automated discovery processes. This comes at some expense, particularly since these names are defined to allow UTF-8 encoding of international character sets. Initiators and targets would have to include code to compare these sets. To simplify implementation and interoperability, it has been recommended that we make iSCSI names case-sensitive instead. I am fine with doing this, and I think that we could even get some of the usability back by adding these rules: - iSCSI names MUST be case-sensitive, and compared strictly byte-for-byte. - iSCSI names SHOULD be generated in a case-insensitive manner. I'm not sure how to properly word the latter, but the intent is that someone generating the names would not produce both: iqn.9.com.cisco.myiscsithing and iqn.9.com.cisco.MyIscsiThing since a user would be likely to confuse these. Again, it doesn't affect the protocol itself, just its usability. Any thoughts? Will it hurt anyone's plans if iSCSI names were case-sensitive? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 10:38:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06450 for ; Wed, 18 Jul 2001 10:38:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ID3kb26803 for ips-outgoing; Wed, 18 Jul 2001 09:03:46 -0400 (EDT) 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 f6IAw3g19345 for ; Wed, 18 Jul 2001 06:58:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24731; Wed, 18 Jul 2001 06:57:08 -0400 (EDT) Message-Id: <200107181057.GAA24731@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-mib-00.txt Date: Wed, 18 Jul 2001 06:57:08 -0400 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 : Definition of Managed Objects for FCIP Author(s) : S. Akkala et al. Filename : draft-ietf-ips-fcip-mib-00.txt Pages : Date : 17-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a FCIP device, as defined in [FCIP]. This MIB is defined such that it can be viewed as an extension to the existing FC Management Framework Integration MIB, as specified in [FCMGMT]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-mib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcip-mib-00.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-mib-00.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: <20010717132834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcip-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcip-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132834.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Jul 18 10:41:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07295 for ; Wed, 18 Jul 2001 10:41:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IE2U500939 for ips-outgoing; Wed, 18 Jul 2001 10:02:30 -0400 (EDT) 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 f6IE2Sg00934 for ; Wed, 18 Jul 2001 10:02:28 -0400 (EDT) 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 QAA121124 for ; Wed, 18 Jul 2001 16:02:22 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IE2Lb176698 for ; Wed, 18 Jul 2001 16:02:21 +0200 Importance: Normal Subject: RE: London: Call for agenda items To: "Robert D. Russell" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 17:08:23 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 16:02:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, In fact most of my mail requested us to stay at 02 to differentiate from 06. But I am still open (until tomorrow!). Julo "Robert D. Russell" on 18-07-2001 16:48:38 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: London: Call for agenda items Julian: Hopefully the version number in this new rev will go back to 1, not 2 -- your call for comments on this did not get many comments (at least not on the mailing list), but those that did comment seemed mostly to favor staying at version 1 during the draft stage. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > rev. 07 will be issued this week. Julo > > "Douglas Otis" on 18-07-2001 02:37:36 > > Please respond to "Douglas Otis" > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: RE: London: Call for agenda items > > > > > David, > > Unless I missed something, iSCSI is still at the same revision as the last > interim meeting. Will there be an updated draft presented prior to the > meeting? It is difficult to understand the consensus that has be reached > just upon examining the reflector. Is there a document that reflects these > current changes? > > Doug > > > We're starting to assemble the London agenda. iSCSI > > draft authors, please coordinate your request for time > > with John Hufferd (iSCSI Technical Coordinator, > > hufferd@us.ibm.com). Anyone else wanting agenda time > > should send the request to me, including the purpose > > of the time and the associated Internet-Draft (if any). > > > > A couple of reminders: > > - London is primarily for iSCSI-related topics. FCIP and > > iFCP topics will be take up in the Orange County, > > CA interim meeting due to the conflict between > > the London IETF meetings and the T11 meetings. > > - Agenda time is to work on open issues. ASSUME THAT > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > be used for presentations covering draft contents. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 18 12:28:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06319 for ; Wed, 18 Jul 2001 12:28:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IExs905192 for ips-outgoing; Wed, 18 Jul 2001 10:59:54 -0400 (EDT) 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 f6IExqg05187 for ; Wed, 18 Jul 2001 10:59:52 -0400 (EDT) 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 KAA24704; Wed, 18 Jul 2001 10:51:50 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6IExo939662; Wed, 18 Jul 2001 08:59:50 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: Mark Bakke Cc: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 17 Jul 2001 22:53:56 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/18/2001 08:59:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, You are talking about things that are entered by administrators. They will have a lot of finger checks. I do not see why we would like to encourage admin problems by making these things Case Sensitive. Imagine, one administrator trying to tell another over the phone, what the name should be used. I would vote for Case insensitive names. . . . 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 Internet address: hufferd@us.ibm.com Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM Sent by: owner-ips@ece.cmu.edu To: IPS cc: Subject: iSCSI: Case-sensitivity in iSCSI names We are attempting to wrap up all of the issues surrounding the creation and comparison of iSCSI initiator and target names. One of these is whether the names are case-sensitive. The last naming & discovery draft stated that the names are case-insensitive; this was to allow better transcribability in cases where names were communicated outside the automated discovery processes. This comes at some expense, particularly since these names are defined to allow UTF-8 encoding of international character sets. Initiators and targets would have to include code to compare these sets. To simplify implementation and interoperability, it has been recommended that we make iSCSI names case-sensitive instead. I am fine with doing this, and I think that we could even get some of the usability back by adding these rules: - iSCSI names MUST be case-sensitive, and compared strictly byte-for-byte. - iSCSI names SHOULD be generated in a case-insensitive manner. I'm not sure how to properly word the latter, but the intent is that someone generating the names would not produce both: iqn.9.com.cisco.myiscsithing and iqn.9.com.cisco.MyIscsiThing since a user would be likely to confuse these. Again, it doesn't affect the protocol itself, just its usability. Any thoughts? Will it hurt anyone's plans if iSCSI names were case-sensitive? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 12:32:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07123 for ; Wed, 18 Jul 2001 12:32:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IEpvx04653 for ips-outgoing; Wed, 18 Jul 2001 10:51:57 -0400 (EDT) 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 f6IEptg04645 for ; Wed, 18 Jul 2001 10:51:55 -0400 (EDT) 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 QAA131516 for ; Wed, 18 Jul 2001 16:51:48 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IEpmC147806 for ; Wed, 18 Jul 2001 16:51:48 +0200 Importance: Normal Subject: RE: London: Call for agenda items To: "Robert D. Russell" Cc: "ips X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 17:57:49 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 16:51:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, There should be two criteria: substantial change after a plugfest :-) Whatever happens first. Hopefully there won't be many soon. Julo "Robert D. Russell" on 18-07-2001 17:31:43 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips Subject: RE: London: Call for agenda items Julian: Ok. In the future, what criteria will be used to determine when the version number changes? My personal opinion is still that draft 7 is really just a refinement and clarification of ambiguities in draft 6, and does not add any major features that justify a version change. However, ... Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > Robert, > > In fact most of my mail requested us to stay at 02 to differentiate from > 06. > But I am still open (until tomorrow!). > > Julo > > "Robert D. Russell" on 18-07-2001 16:48:38 > > Please respond to "Robert D. Russell" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: London: Call for agenda items > > > > > Julian: > > Hopefully the version number in this new rev will go back to 1, > not 2 -- your call for comments on this did not get many comments > (at least not on the mailing list), but those that did comment > seemed mostly to favor staying at version 1 during the draft > stage. > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Wed, 18 Jul 2001, Julian Satran wrote: > > > rev. 07 will be issued this week. Julo > > > > "Douglas Otis" on 18-07-2001 02:37:36 > > > > Please respond to "Douglas Otis" > > > > To: Black_David@emc.com, ips@ece.cmu.edu > > cc: > > Subject: RE: London: Call for agenda items > > > > > > > > > > David, > > > > Unless I missed something, iSCSI is still at the same revision as the > last > > interim meeting. Will there be an updated draft presented prior to the > > meeting? It is difficult to understand the consensus that has be reached > > just upon examining the reflector. Is there a document that reflects > these > > current changes? > > > > Doug > > > > > We're starting to assemble the London agenda. iSCSI > > > draft authors, please coordinate your request for time > > > with John Hufferd (iSCSI Technical Coordinator, > > > hufferd@us.ibm.com). Anyone else wanting agenda time > > > should send the request to me, including the purpose > > > of the time and the associated Internet-Draft (if any). > > > > > > A couple of reminders: > > > - London is primarily for iSCSI-related topics. FCIP and > > > iFCP topics will be take up in the Orange County, > > > CA interim meeting due to the conflict between > > > the London IETF meetings and the T11 meetings. > > > - Agenda time is to work on open issues. ASSUME THAT > > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > > be used for presentations covering draft contents. > > > > > > 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 > > > --------------------------------------------------- > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 18 13:11:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14590 for ; Wed, 18 Jul 2001 13:11:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IFkkP09016 for ips-outgoing; Wed, 18 Jul 2001 11:46:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pdc.dinocom.com (dns1.dinocom.com [66.59.159.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IFkig09012 for ; Wed, 18 Jul 2001 11:46:44 -0400 (EDT) Received: from perfisan4 ([207.139.124.36] unverified) by pdc.dinocom.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 11:46:28 -0400 Reply-To: From: "Trang Nguyen" To: "Julian Satran" , "Matt Wakeley" Cc: "IPS Reflector Subject: RE: iSCSI: SNACK wording clarification Date: Wed, 18 Jul 2001 11:48:58 -0400 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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-OriginalArrivalTime: 18 Jul 2001 15:46:29.0541 (UTC) FILETIME=[CF9C8550:01C10FA0] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi everyone, I just went across the Sequence Errors section in the iSCSI I-D yesterday. Since I am new to the group, please accept my apology if the following questions have been already asked. "6.3 Sequence Errors When an initiator receives an iSCSI data PDU with an out-of-order DataSN or a SCSI command response PDU with an ExpDataSN implying missing data PDUs it MAY request the missing data PDUs through a data SNACK PDU or handle this case as a connection failure. In its turn, the target MUST either reject the SNACK with a Reject PDU with a reason-code of Data-SNACK-Reject or resend the data PDU. When an initiator receives an iSCSI status PDU with an out-of-order StatSN implying missing responses, it MUST either request the missing response PDUs through a status SNACK or handle this case as a connection failure. The target MUST reissue the missing responses. As a side effect of receiving the missing responses, the initiator may discover missing data PDUs. The initiator MUST NOT acknowledge (either explicitly through ExpStatSN or implicitly through a status SNACK) the received responses until it has completed receiving all the data PDUs of a SCSI command. " My questions are: 1. In the iSCSI I-D: "iSCSI uses Command and Status numbering schemes and a Data sequencing scheme. It supports ordered command delivery within a session. All commands (initiator-to-target) are numbered". As I understand it means that the iSCSI initiator won't deliver the next PDU until it receives the acknowledgement from the target (through StatSN, ExpCmdSN). Also, the target executes the PDU with sequence number it expects. It won't execute the out-ot-order PDU. Am I understanding it right? 2. From the section 6.3 "Sequence Errors", I have the impression that iSCSI can send multiple PDUs without waiting for the acknowledgement. If it's true, then it conflicts with the question 1? If it's true, then does iSCSI need a timer to time every PDU it deliver? The iSCSI I-D doesn't mention about the timer at all. Thank you, Trang Nguyen From owner-ips@ece.cmu.edu Wed Jul 18 13:18:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15742 for ; Wed, 18 Jul 2001 13:18:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IFaaK08219 for ips-outgoing; Wed, 18 Jul 2001 11:36:36 -0400 (EDT) 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 f6IFaYg08215 for ; Wed, 18 Jul 2001 11:36:35 -0400 (EDT) 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 RAA44068; Wed, 18 Jul 2001 17:36:28 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IFaRC85076; Wed, 18 Jul 2001 17:36:27 +0200 Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: "John Hufferd" Cc: "Mark Bakke , "IPS X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 18:42:29 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 17:36:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Case insesitive is bad for I18N Julo "John Hufferd" on 18-07-2001 08:53:56 Please respond to "John Hufferd" To: Mark Bakke cc: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names Mark, You are talking about things that are entered by administrators. They will have a lot of finger checks. I do not see why we would like to encourage admin problems by making these things Case Sensitive. Imagine, one administrator trying to tell another over the phone, what the name should be used. I would vote for Case insensitive names. . . . 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 Internet address: hufferd@us.ibm.com Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM Sent by: owner-ips@ece.cmu.edu To: IPS cc: Subject: iSCSI: Case-sensitivity in iSCSI names We are attempting to wrap up all of the issues surrounding the creation and comparison of iSCSI initiator and target names. One of these is whether the names are case-sensitive. The last naming & discovery draft stated that the names are case-insensitive; this was to allow better transcribability in cases where names were communicated outside the automated discovery processes. This comes at some expense, particularly since these names are defined to allow UTF-8 encoding of international character sets. Initiators and targets would have to include code to compare these sets. To simplify implementation and interoperability, it has been recommended that we make iSCSI names case-sensitive instead. I am fine with doing this, and I think that we could even get some of the usability back by adding these rules: - iSCSI names MUST be case-sensitive, and compared strictly byte-for-byte. - iSCSI names SHOULD be generated in a case-insensitive manner. I'm not sure how to properly word the latter, but the intent is that someone generating the names would not produce both: iqn.9.com.cisco.myiscsithing and iqn.9.com.cisco.MyIscsiThing since a user would be likely to confuse these. Again, it doesn't affect the protocol itself, just its usability. Any thoughts? Will it hurt anyone's plans if iSCSI names were case-sensitive? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 14:14:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26882 for ; Wed, 18 Jul 2001 14:14:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IGIYg11654 for ips-outgoing; Wed, 18 Jul 2001 12:18:34 -0400 (EDT) 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 [192.151.27.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IGIWg11647 for ; Wed, 18 Jul 2001 12:18:32 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id C0AAE1F584; Wed, 18 Jul 2001 12:18:25 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 526AD1F518; Wed, 18 Jul 2001 12:18:25 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id <36R3YV97>; Wed, 18 Jul 2001 12:18:25 -0400 Message-ID: <499DC368E25AD411B3F100902740AD65BC5BA1@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "'Jeff Chase (E-mail)'" , "HAAGENS,RANDY (HP-Roseville,ex1)" , "WENDT,JIM (HP-Roseville,ex1)" Subject: F2F Mtg Summary for Framing and Error Recovery Date: Wed, 18 Jul 2001 12:18:22 -0400 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 a quick summary of the outcome from the June 27-28 Design Teams Face-to-Face meeting in Palo Alto in the two focal areas: Framing and Error Recovery. The bulk of the meeting was spent discussing framing scenarios, requirements, and alternatives. As soon as the slide decks make it onto Julian's web site, I'll email out that info. Regards, Jim Wendt Networked Storage Architecture / NSSO Hewlett-Packard Company jim_wendt@hp.com 916-785-5198 --------------------------------------------------------------- F2F Meeting Summary for Framing and Error Recovery Design Teams Face-to-Face Meeting / June 27-28 Palo Alto ---------------- Framing: The Bottom Line ---------------------- To cut to the chase, the following rough proposal was generated for handling ULP Framing for iSCSI: A) Proposed changes to "ULP Framing for TCP" I-D are: 1) Modify I-D to include two framing modes: - "Marker mode" for unmodified TCP stacks - "PDU-alignment mode" for modified TCP stacks 2) ULP is responsible for negotiating use of framing protocol and enabling framing behavior on the TCP connection in an unambiguous manner 3) The framing protocol usage, framing mode, and framing operational parameters are negotiated separately in each direction on a TCP connection. Thus there are "Senders" and "Receivers" on a framing TCP connection. An iSCSI Initiator or Target is both a Sender and a Receiver with respect to an framing TCP connection. 4) ULP is responsible for negotiating use of a specific framing mode over the TCP connection by having the receiver request highest framing mode desired from sender (first PDU-alignment, then Marker, then none) and having the sender comply: - if receiver requests, and sender supports, PDU-alignment mode, then sender MUST enable PDU-alignment mode - else if receiver requests, and sender supports, Marker mode, then sender MUST enable Marker mode - else don't use framing protocol 5) ULP is responsible for negotiating framing operational parameters: - Marker period (in Marker mode) - Receiver maximum PDU size (in Marker mode) - Framing keys (in PDU-alignment mode) - ULP packing behavior (in PDU-alignment mode) 6) Change the marker fields to be 16-bits rather than 32-bits (and refer to as "offsets" rather than "pointers") *) An updated version of the "ULP Framing for TCP I-D" reflecting these changes has been posted (7/9/01) to TSVWG for comments (draft-ietf-tsvwg-tcp-ulp-frame-00) B) Proposed changes to iSCSI spec are: 1) Remove Markers appendix from iSCSI spec (Appendix D. Synch and Steering with Fixed Interval Markers) 2) iSCSI spec adds wording to the effect of: * iSCSI initiator and target framing behavior over a TCP connection is defined in draft-ietf-tsvwg-tcp-ulp-frame-00 (or eventual RFC#) * an iSCSI initiator or target is both a sender and receiver with respect to framing behavior * an iSCSI framing sender MUST implement Marker mode, and MAY implement PDU-alignment mode, as defined in * an iSCSI framing receiver MAY implement PDU-alignment mode, or Marker mode, or both, or none as defined in * an iSCSI receiver on a framing TCP connection dictates use of the highest framing mode desired from sender as follows: - if receiver requests, and sender supports, PDU-alignment mode, then sender MUST enable PDU-alignment mode - else if receiver requests, and sender supports, Marker mode, then sender MUST enable Marker mode - else framing behavior is disabled * Perhaps there is some description of probable framing scenarios capturing the most likely combinations of the following attributes: - initiator or target - software implementation or hardware implementation - unmodified or modified TCP stack - sender AND receiver framing behaviors (no framing, or Marker mode, or PDU-Alignment mode) - values for framing operational parameters 3) > Still need to determine iSCSI mechanism for turning on Framing protocol Marker mode operation 4) > Still need to determine iSCSI mechanism for negotiating framing operational parameters: - Framing mode (if both Marker and PDU Alignment mode are supported) - Marker period (in Marker mode) - Receiver maximum PDU size (in Marker mode) - Framing keys (in PDU-alignment mode, if supported) - ULP packing behavior (in PDU-alignment mode, if supported) ----------- The reasoning for these proposed changes is as follows: 1) Re: Merge Marker mode into "ULP Framing for TCP" I-D a) The TCP-related framing work already has mindshare in TSVWG and this work is embodied in the current framing I-D. Rather than dilute the framing effort with additional I-Ds, all framing related work should be collected into a modified version of the existing framing I-D. b) Other ULPs may also find Marker mode useful in software-only unmodified-TCP client scenarios c) The framing I-D appears to be a reasonable literary vehicle for documenting the collection of framing schemes. The I-D could be extended in the future to include a byte or word stuffing frame marker method such as COBS. d) A single framing I-D may help to encourage a single consistent interface with the ULP regardless of which framing mode is employed. e) The iSCSI spec can simply reference the one framing I-D. 2) Re: Make Marker mode mandatory for all iSCSI implementations, and PDU-Alignment mode optional for all iSCSI implementations. a) This allows interoperation of software-only, UNMODIFIED-TCP-stack clients with hardware-accelerated, small-buffer-memory storage arrays. This applies to both 1Gbps-client/1Gbps-array and 1Gbps-client/10Gbps-array scenarios. b) One potentially compelling application for iSCSI involves software-only implementations on mainstream desktops and laptops operating over unmodified TCP stacks to access centralized storage arrays. c) Software implementations are likely to exist far into the future. Individual software-only clients may not operate at 10Gbps, but will be combined together with other clients that aggregate to 10Gbps. d) The only framing mechanisms that can operate completely above a client TCP and not require any modification to the client's standard TCP stack are the interval-based (Marker mode, periodic PDU alignment, fixed length PDU) and byte-stuffing (COBS) framing schemes. All other framing mechanisms (including PDU-Alignment mode) require modification to the client's TCP stack. e) The processing overhead for a client software implementation to insert Markers is small compared to the processing overhead of a byte-stuffing scheme. f) Receivers are allowed to dictate the sender's framing behavior because it is the receiver that is impacted by the presence or absence of framing behavior on the connection. g) Hardware-accelerated receivers can be implemented with minimal buffer memory, meaning that they always rely on framing-based direct data placement processing, only if it is known in advance that every client the receiver could potentially interoperate with is capable of providing the necessary framing-based behavior. These hardware-accelerated receivers will request, and expect that, the sender insert markers (or PDU-Alignment if supported). h) Since a software-implemented receiver may incur extra data movements in processing markers, these receivers can request, and expect that, a sender NOT insert markers, if desired. i) Marker mode doesn't completely eliminate the need for buffer memory on the receiver. The receiver still needs to use "eddy buffers" that temporarily hold incoming data after a dropped segment containing a ULP header up until the next ULP header is located in the packet stream, and which exist for as long as the original ULP header segment is outstanding. But Marker mode does greatly reduce the amount of memory needed as compared to a traditional TCP receiver's reassembly memory requirements (often equal to number-of-connections X round-trip-pipe-size). The Marker mode small memory requirements are dependent upon the period of the marker, and the size of the ULP PDUs being restricted to a reasonably small value. The larger that either one is, the larger the eddy buffer memory requirements. Also, an eddy buffer is required each time a ULP header is dropped, so that multiple ULP header drops in close proximity may cause multiple eddy buffers to be temporarily pending on a connection. j) The PDU-alignment framing mode is preferred. However, it may be several years before all of the different software TCP/IP implementations will be able to support framing behavior. ----------- Open Issues: 1) Acceptability of the PDU-Alignment framing mode's reliance on "key+length" matching across resegmenting middleboxes - In PDU-Alignment mode each TCP segment payload contains one complete framing PDU (consisting of an 8 byte framing header followed by one or more complete ULP PDUs). Thus, every TCP segment has the TCP header followed immediately by the framing header. - In certain cases a single framing PDU must be broken across multiple TCP segments (such as dynamic Path MTU reductions), resulting in TCP segments where a framing header doesn't immediately follow the TCP header. - The framing I-D defines sender behaviors that allow PDU-alignment mode to function deterministically and correctly in all cases where the TCP segmentation flowing from sender to receiver is not altered. - If the TCP segmentation from sender to receiver is altered by an intermediary (resegmenting middlebox), and a framing-header-containing segment drop or reordering has occurred such that the receiver is attempting to locate the next framing header in the segment stream, then the receiver must examine the first 8 bytes of each incoming TCP segment payload for a valid framing header containing valid Key(6B) and Length(2B) fields. - A false-positive occurs if, upon resegmentation by a middlebox, the receiver gets a TCP segment in which the first 8 bytes of the payload indicate a valid framing header (the first 6 bytes match the previously exchanged random key value, and the next 2 bytes contain a valid length), yet the TCP segment payload isn't actually a framing header. - While it is felt that the probability of a false-positive in these resegmenting-middlebox scenarios will be sufficiently low, further analysis work may be may be required in this area. - Note that this mechanism is NOT a scanning technique for locating start-of-frame across an arbitrary byte stream. It only provides an indication of PDU alignment or not. The first 8 bytes of the TCP segment payload are examined to determine if the segment contains the start of a ULP PDU. 2) None of the current framing schemes take TCP data integrity into account. It either needs to be decided: a) how to detect when a data integrity problem occurs within a framing header, and what to do about it (even if it just kills the TCP connection), b) or that a sufficient level of data integrity needs to be provided for all protocols running over TCP via a more holistic approach. 3) Do Markers work at 10Gbps - The feasibility of markers at 10Gbps has been questioned. It would be beneficial to hear specifics regarding why Markers won't work at 10Gbps. Markers don't allow for a no-memory direct data placement NIC since eddy-buffers are required. So, support for clients with unmodified TCP stacks comes at a cost, which is the cost of supporting eddy buffers on the NIC. - One question is whether the eddy buffers can be contained entirely in the ASIC or need to be in off-chip memory. ---------------- Error Recovery: The Bottom Line ---------------------- 1) Information was presented regarding estimated iSCSI header and data digest error rates, and possible approaches to iSCSI error recovery. The error rates info is summarized as follows: a) "Good Internet" - 1500 byte MTU / 8192 byte iSCSI PDU - TCP checksum mismatch 1 in 90,000 - Checksum escape 1 in 135M to 1 in 10B - For bandwidth of 30Mbps @ 100msec RTT > 8 to 600 digest errors per year > 1 header digest every 2 months to 10 years - For bandwidth of 300Mbps @ 10msec RTT > 80 to 6,000 digest errors per year > 1 to 70 header digest errors per year b) "Bad Internet" - 1500 byte MTU / 8192 byte iSCSI PDU - TCP checksum mismatch 1 in 11,000 - Checksum escape 1 in 16M to 1 in 1B - For bandwidth of 10Mbps @ 100msec RTT > .5 to 33 digest errors per week > 26 to 1,650 digest errors per year > 0.3 to 20 header digest errors per year - For bandwidth of 100Mbps @ 10msec RTT > 5 to 335 digest errors per week > 260 to 16,500 digest errors per year > 3 to 200 header digest errors per year c) 1Gbps iSCSI connection - assuming current TCP yields 70% bandwidth utilization - at 100msec > packet loss less than 1 in 50M > .5 to 40 digest errors per year > 1 header digest error every 2..100 years - at 10msec > packet loss less than 1 in 500,000 > 60 to 4,000 digest errors per year > 1 to 40 header digest errors per year d) 10Gbps iSCSI connection - assuming current TCP yields 70% bandwidth utilization - at 100msec > packet loss less than 1 in 5 billion > 1 digest error every 3 mo to 10 years > 1 header digest error every 20 to 1000 years - at 10msec > packet loss less than 1 in 50M > 6 to 400 digest errors per year > 1 header digest error every 3 mo to 12 years e) The frequency of framing header corruption escaping the TCP checksum mechanism is on the order of the frequency of the iSCSI header escaping, but depends on the mechanism used as well as the MSS and iSCSI PDU sizes: - Markers (at 2k intervals) - 1/3 as likely as iSCSI headers. - Framing (w/o chunking) - 1.5 times as likely - Framing (w/ chunks) - 1/2 as likely as iSCSI headers. These assumed an 8k iSCSI PDU size, except for Framing (w/o chunking), which assumed a 1k iSCSI PDU to fit in a single segment. All schemes had a framing header size of 8 bytes, and assumed an MSS of 1460. 2) No definitive conclusions were reached during the F2F in regards to Error Recovery mechanisms. - Further work needs to be done in this area. - Mallikarjun Chadalapaka, Mark Bakke, and others can help move the work forward in this area. 2) It would be valuable to collect information regarding TCP checksum mismatch rates on production systems. If anyone has access to fairly busy systems and can collect the following information, you can forward it to Mark Bakke (mbakke@cisco.com). You'll want to collect three data items: a) sysUpTime b) tcpInSegs - total number of inbound TCP segments c) tcpInErrs - total number of inbound TCP segments with errors (most likely checksum mismatches, but some implementations may count other error discards here as well) ---------------- Slide Decks ------------------------------------ Sorry, but these materials aren't on the web yet. Hopefully they will be in the next week or two. I'll email when they are available on a server somewhere. * "iSCSI Framing Presentation" - slides/spreadsheet - Matt Wakeley * "TCP Framing Discussion" - slides - Jim Wendt * "Recovering From iSCSI Digest Errors" - slides - Mark Bakke * "Expected iSCSI digest error rates on Internet connections" - spreadsheet - Mark Bakke * CRC and checksum performance - slides - Jonathan Stone ---------------- Framing Discussion Summary ---------------------- /iSCSI usage scenarios A wide variance of usage scenarios were strongly represented: * High-speed short-distance storage LANs * High-speed long-distance storage WANs * Multitudes of low-end clients using software iSCSI client implementations and unmodified software TCP stacks * Multiple first-generation 1Gbps clients aggregating to next-generation 10Gbps storage arrays * A variety of IP networks and paths with potential for both TCP-level resegmenting middleboxes and dynamic changes in Path MTU. /Memory-based solutions * It was felt that 1Gbps memory-based solutions are feasible and may be cost-competitive (e.g. there is no usage of direct data placement nor framing mechanisms in this case) * There were different opinions regarding whether 10Gbps memory-based solutions would be cost-competitive or feasible for 10Gbps. * There was discussion regarding the comparative cost of memory-based and no-memory iSCSI HBAs and infrastructure relative to Fibre Channel * There were concerns regarding next-generation 10Gbps storage arrays that want to support first-generation clients. The next-generation 10Gbps storage arrays can only implement no-memory solutions if the first-generation clients were mandated to implement support for framing (thus making direct data placement possible on the storage array). * Hybrid schemes were discussed where a next-generation 10Gbps storage array would contain a moderate amount of memory to handle non-framing first-generation clients while using full framing and direct data placement with no memory buffers for 10Gbps clients * Matt Wakeley has created a spreadsheet for high-speed memory subsystem costs /Direct data placement alternatives * Discussion of various levels at which direct data placement information can ride: - Above TCP (iSCSI task tags, RDMA protocol) - At transport (TCP RDMA option) - Below transport (TAF) /iSCSI layering scenarios and evolution * iSCSI can be layered: - over normal TCP - over Markers over normal TCP - over Framing TCP - over RDMA+chunking over Framing TCP * Layering iSCSI over RDMA+chunking doesn't seem likely for first-generation iSCSI implementations /Framing alternatives * Framing mechanism classes: - Intervalic (Periodic Markers, Periodically aligned headers, Fixed size ULP PDUs) - Framing aware TCP (ala ULP Framing over TCP I-D) - TCP message boundary indications (Reserved bit, TCP option, URG pointer, PSH bit, etc) - Byte stuffing (COBS, 7B/8B, etc) * Framing mechanism characteristics: - sender TCP modifications required? - receiver memory requirements (full TCP receive window, eddy buffers, IP reassembly buffers) - level of TCP changes (none, behavioral, header fields) - support ULP PDU > TCP MSS - software processing overhead - hardware implementation complexity - handle dynamic Path MTU changes - handle resegmenting TCP middlebox - require [dynamic] chunking above TCP - emit short segments more often than typical - added protocol bytes overhead - tied to TCP sequence number processing - increase probability of segment drops - TCP aesthetics /Markers and ULP Framing merge * Proposal to merge Marker mechanism into current "ULP Framing for TCP I-D" and have iSCSI mandate implementation of Marker mode * See "Framing: The Bottom Line" section above ---------------- Error Recovery Discussion Summary --------------- /Mark Bakke slides and spreadsheet * Mark presented slides and a spreadsheet discussing: - expected iSCSI header and data digest error rates given link bandwidth, RTT, probability of segment drop, and probability of TCP checksum escape - recommended iSCSI error handling approaches for Header digest and data digest errors - - /Discussion regarding iSCSI error recovery complexity * It was felt that 90% of the recovery complexity already exists for the sake of session recovery (aftet a TCP connection failure) and if only "within-command" recovery was eliminated, it wouldn't substantially simplify the protocol or its specification. However, this assertion needs to be validated. * It was felt that complete command recovery would probably be a dequate for the expected error incidence (not a noticable impact), but it hasn't been shown how adopting this approach would reduce complexity. /Discussion re: IPSec SA's * There was some discussion regarding use of IPSec and concerns that the set of Security Associations would not fit into on-chip memory, forcing the SAs to be cached in off-chip memory. /Jonathan Stone slides * Jonathan presented data analysis from his soon-to-be-completed dissertation regarding the nature of empirically-observed transport-level errors, and the error detection performance of CRC and checksum algorithms on such. ---------------- List of Attendees ----------------------- Mark Bakke, Stephen Bailey, Uri Elzur, Somesh Gupta, Randy Haagens, John Hufferd, Jim Pinkerton, Venkat Rangan, Allyn Romanow, Costa Sapuntzakis, Julian Satran, Jonathan Stone, Matt Wakeley, Jim Wendt, Jim Williams -------------------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 18 15:53:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17987 for ; Wed, 18 Jul 2001 15:53:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IDmqI29771 for ips-outgoing; Wed, 18 Jul 2001 09:48:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IDmog29767 for ; Wed, 18 Jul 2001 09:48:50 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA22915; Wed, 18 Jul 2001 09:48:38 -0400 (EDT) Date: Wed, 18 Jul 2001 09:48:38 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: RE: London: Call for agenda items In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Hopefully the version number in this new rev will go back to 1, not 2 -- your call for comments on this did not get many comments (at least not on the mailing list), but those that did comment seemed mostly to favor staying at version 1 during the draft stage. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > rev. 07 will be issued this week. Julo > > "Douglas Otis" on 18-07-2001 02:37:36 > > Please respond to "Douglas Otis" > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: RE: London: Call for agenda items > > > > > David, > > Unless I missed something, iSCSI is still at the same revision as the last > interim meeting. Will there be an updated draft presented prior to the > meeting? It is difficult to understand the consensus that has be reached > just upon examining the reflector. Is there a document that reflects these > current changes? > > Doug > > > We're starting to assemble the London agenda. iSCSI > > draft authors, please coordinate your request for time > > with John Hufferd (iSCSI Technical Coordinator, > > hufferd@us.ibm.com). Anyone else wanting agenda time > > should send the request to me, including the purpose > > of the time and the associated Internet-Draft (if any). > > > > A couple of reminders: > > - London is primarily for iSCSI-related topics. FCIP and > > iFCP topics will be take up in the Orange County, > > CA interim meeting due to the conflict between > > the London IETF meetings and the T11 meetings. > > - Agenda time is to work on open issues. ASSUME THAT > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > be used for presentations covering draft contents. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 18 15:53:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17996 for ; Wed, 18 Jul 2001 15:53:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IELKV02273 for ips-outgoing; Wed, 18 Jul 2001 10:21:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IELIg02268 for ; Wed, 18 Jul 2001 10:21:18 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA24201; Wed, 18 Jul 2001 10:21:14 -0400 (EDT) Date: Wed, 18 Jul 2001 10:21:14 -0400 From: "Robert D. Russell" To: Mark Bakke cc: Matt Wakeley , ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase In-Reply-To: <3B54A4B9.35D2F1F8@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark: I respectfully disagree with your recommendation to go with option 3. The experience here at the plugfest seems to be that option 1 is easiest to work with since it involves no special case code -- the cmdsn is incremented on every command sent. Period. A simple statement to that effect in the standard is much, much prefered than a long chain of "technical" reasoning that readers have to follow through to the end to infer what the final result should be. I believe simplicity is the key to interoperability, and the standard mechanisms should be designed to be simple. There is indeed a reason to number commands during login -- because then they are treated the same as any other commands and you don't need special purpose code during login to deal with that part of shipping the commands. I.e., you keep it uniform and simple, no special cases. This allows code to be reused and debugged once. As a final point, most implementations will NOT have to be modified to implement option 1 -- they now already do that. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Tue, 17 Jul 2001, Mark Bakke wrote: > > Given that this is being interpreted differently by enough > implementations, I would prefer to see us take a step back > and look at which of Scott's three options should make the > most sense. It looks like options #1 and #2 are what is > currently being implemented, regardless of what's specified. > > However, a connection technically can't really be part of a > session (sharing its work load) until it has completed a > successful login phase. There's also little reason for > numbering until the login phase is complete, since the login > and text responses during negotiation are synchronous, and > pertain only to the connection, rather than the session. > > I would recommend stating that a connection joins (or becomes, > if it's the first one) a session after the login response > with the F bit set is sent (on a target), or after the login > response with the F bit set is received (on an initiator), > and that CmdSN is not necessary until such a time, especially > since CmdSN is per-session, not per-connection. This is > identical to Scott's option 3. > > I think that defining it this way would remove any further > ambiguity on when a connection is part of a session. Since > it appears that most implementations will have to modify their > login code anyway, this shouldn't be too bad. > > -- > Mark > > Matt Wakeley wrote: > > > > I think it's pretty obvious that it's your option #1: (the initiator supplies > > the initial CmdSN in the login PDU, and for every command PDU after that, the > > CmdSN gets incremented, just like in "full feature phase") > > > > 2.10.7 CmdSN says "CmdSN is either the initial number of a session..." > > [Julian, this should say "initial command number of a session"] > > > > So, the Login PDU defines the first CmdSN. > > > > 1.2.2.1 says "Commands in transit from the initiator to the target layer are > > numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN". Text > > commands are commands, so they are numbered also. > > > > It goes on to say "CmdSN - the current command Sequence Number advanced by 1 > > on each command shipped except for commands marked for immediate delivery." > > > > I agree that this needs to be cleaned up. CmdSN and StatSN should work during > > login just like they do during "full feature phase" - there is no reason why > > the should not, and making them always work the same removes complexity and > > interoperability problems. > > > > -Matt > > > > "Scott M. Ferris" wrote: > > > > > > At what point during the Login Phase of a leading connection (null > > > TSID) does a session exist? > > > > > > Section 2.10.7 describing CmdSN for the Login PDU indicates that > > > when TSID is null, CmdSN indicates the starting Command Sequence > > > number for this session. > > > > > > For interoperability, it is important to define precisely when a > > > session exists, so that all initiators and targets agree on when > > > CmdSNs are significant, and do not reject or ignore PDUs due to > > > differing assumptions of how the CmdSN numbering should be done during > > > the Login Phase. > > > > > > Some of the possible choices for session start are: > > > > > > 1) a session starts before the initiator sends anything, and the Login > > > PDU is the first PDU of a session. > > > > > > 2) a session starts when the initiator receives a (possibly partial) > > > Login Response with an accept status class and a non-zero TSID, and > > > the next PDU sent by the initiator is the first PDU of the session, > > > which uses the same CmdSN as the Login PDU. > > > > > > 3) a session starts when the initiator receives a Final Login > > > Response, and the next PDU sent by the initiator is the first PDU > > > of the session, which uses the same CmdSN as the Login PDU. > > > > > > After searching through draft 6, I was unable to find anything that > > > clearly indicated which if any of the above possibilities was correct, > > > or, if more than one is possible, how the initiator and target are > > > supposed to determine what CmdSN numbering scheme the other side is > > > using for the Login Phase. > > > > > > The UNH draft-6 initiator appears to use choice #1. The Cisco > > > draft-6 initiator and target use choice #2. This can cause the UNH > > > initiator to hang when trying to login to the Cisco target, since the > > > initiator may send a Text PDU with CmdSN 2, while the target is > > > waiting for a PDU with CmdSN 1. > > > > > > Section 1.2.2.2 states that "Status numbering starts after > > > Login. During login, there is always only one outstanding command per > > > connection and status numbering is not strictly needed but may be used > > > as a sanity check." > > > > > > A similar argument could be made that CmdSN is not needed during the > > > Login Phase, suggesting choice #3 may be the simplest. > > > > > > I also think section 1.2.2.2 is problematic, as it appears to > > > contradict itself by saying that status numbering is not used during > > > login, and then follows up saying status numbering may be used during > > > login. > > > > > > -- > > > Scott M. Ferris, > > > sferris@acm.org > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > From owner-ips@ece.cmu.edu Wed Jul 18 16:02:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20372 for ; Wed, 18 Jul 2001 16:02:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IE2Ol00932 for ips-outgoing; Wed, 18 Jul 2001 10:02:24 -0400 (EDT) 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 f6IE2Lg00918 for ; Wed, 18 Jul 2001 10:02:21 -0400 (EDT) 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 QAA165460 for ; Wed, 18 Jul 2001 16:02:13 +0200 Received: from d12ml001.de.ibm.com (d12ml001_cs0 [9.165.223.33]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6IE2CC141620 for ; Wed, 18 Jul 2001 16:02:12 +0200 Importance: Normal Subject: RE: London: Call for agenda items To: "Robert D. Russell" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 18 Jul 2001 17:08:14 +0300 X-MIMETrack: Serialize by Router on D12ML001/12/M/IBM(Release 5.0.6 |December 14, 2000) at 18/07/2001 16:02:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, In fact most of my mail requested us to stay at 02 to differentiate from 06. But I am still open (until tomorrow!). Julo "Robert D. Russell" on 18-07-2001 16:48:38 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: London: Call for agenda items Julian: Hopefully the version number in this new rev will go back to 1, not 2 -- your call for comments on this did not get many comments (at least not on the mailing list), but those that did comment seemed mostly to favor staying at version 1 during the draft stage. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > rev. 07 will be issued this week. Julo > > "Douglas Otis" on 18-07-2001 02:37:36 > > Please respond to "Douglas Otis" > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: RE: London: Call for agenda items > > > > > David, > > Unless I missed something, iSCSI is still at the same revision as the last > interim meeting. Will there be an updated draft presented prior to the > meeting? It is difficult to understand the consensus that has be reached > just upon examining the reflector. Is there a document that reflects these > current changes? > > Doug > > > We're starting to assemble the London agenda. iSCSI > > draft authors, please coordinate your request for time > > with John Hufferd (iSCSI Technical Coordinator, > > hufferd@us.ibm.com). Anyone else wanting agenda time > > should send the request to me, including the purpose > > of the time and the associated Internet-Draft (if any). > > > > A couple of reminders: > > - London is primarily for iSCSI-related topics. FCIP and > > iFCP topics will be take up in the Orange County, > > CA interim meeting due to the conflict between > > the London IETF meetings and the T11 meetings. > > - Agenda time is to work on open issues. ASSUME THAT > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > be used for presentations covering draft contents. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 18 16:02:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20377 for ; Wed, 18 Jul 2001 16:02:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IEVmd03060 for ips-outgoing; Wed, 18 Jul 2001 10:31:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IEVlg03056 for ; Wed, 18 Jul 2001 10:31:47 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA24527; Wed, 18 Jul 2001 10:31:43 -0400 (EDT) Date: Wed, 18 Jul 2001 10:31:43 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips Subject: RE: London: Call for agenda items In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Ok. In the future, what criteria will be used to determine when the version number changes? My personal opinion is still that draft 7 is really just a refinement and clarification of ambiguities in draft 6, and does not add any major features that justify a version change. However, ... Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > Robert, > > In fact most of my mail requested us to stay at 02 to differentiate from > 06. > But I am still open (until tomorrow!). > > Julo > > "Robert D. Russell" on 18-07-2001 16:48:38 > > Please respond to "Robert D. Russell" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: RE: London: Call for agenda items > > > > > Julian: > > Hopefully the version number in this new rev will go back to 1, > not 2 -- your call for comments on this did not get many comments > (at least not on the mailing list), but those that did comment > seemed mostly to favor staying at version 1 during the draft > stage. > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Wed, 18 Jul 2001, Julian Satran wrote: > > > rev. 07 will be issued this week. Julo > > > > "Douglas Otis" on 18-07-2001 02:37:36 > > > > Please respond to "Douglas Otis" > > > > To: Black_David@emc.com, ips@ece.cmu.edu > > cc: > > Subject: RE: London: Call for agenda items > > > > > > > > > > David, > > > > Unless I missed something, iSCSI is still at the same revision as the > last > > interim meeting. Will there be an updated draft presented prior to the > > meeting? It is difficult to understand the consensus that has be reached > > just upon examining the reflector. Is there a document that reflects > these > > current changes? > > > > Doug > > > > > We're starting to assemble the London agenda. iSCSI > > > draft authors, please coordinate your request for time > > > with John Hufferd (iSCSI Technical Coordinator, > > > hufferd@us.ibm.com). Anyone else wanting agenda time > > > should send the request to me, including the purpose > > > of the time and the associated Internet-Draft (if any). > > > > > > A couple of reminders: > > > - London is primarily for iSCSI-related topics. FCIP and > > > iFCP topics will be take up in the Orange County, > > > CA interim meeting due to the conflict between > > > the London IETF meetings and the T11 meetings. > > > - Agenda time is to work on open issues. ASSUME THAT > > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > > be used for presentations covering draft contents. > > > > > > 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 > > > --------------------------------------------------- > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 18 17:00:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01986 for ; Wed, 18 Jul 2001 17:00:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IJcGs27851 for ips-outgoing; Wed, 18 Jul 2001 15:38:16 -0400 (EDT) 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 f6IJcFg27847 for ; Wed, 18 Jul 2001 15:38:15 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA18942; Wed, 18 Jul 2001 15:38:06 -0400 (EDT) Message-ID: <3B55E45C.CB38D089@cisco.com> Date: Wed, 18 Jul 2001 14:32:44 -0500 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: Julian Satran CC: "IPS Subject: Re: iSCSI: Iterating long text responses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The "bookmark" solution that Julian had mentioned is currently in the -98 version of the iSCSI draft at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-06-98.txt This solution is more akin to #3, since the target does need to keep track of bookmarks, and the initiator requests each piece. This doesn't seem quite as simple as #5, but it will work. Simple targets that will not return enough addresses to fill a 4k text response PDU would not have to implement the bookmarks at all. Anyway, this is a change from what we had been discussing on the list, so it's worth looking at, and would perhaps be a good thing to do a consensus call on so we can put this thing to rest either way. -- Mark Julian Satran wrote: > > I think that both 4 and 5 involve in fact some state to be kept at the > target between PDUs sent in something related to > to a "task control block" if we assume that all the text commands carry the > same ITT. > 4 enables the initiator to reuse its parse buffer while 5 requires the > initiator to allocate a buffer for all the text responses (or keep the pipe > closed). > 4 is simpler than 5. If you add to 4 a handle that the initiator has to > give back the target next time (the bookmark) > then the target does not have to keep state. > A 0 bookmark says start from the top. It is very much like an offset (that > was mentioned) but it is generic and opaque. > > Regards, > Julo > > Mark Bakke on 29-06-2001 23:18:20 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: Iterating long text responses > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" connection > or are handled completely in software, and allow its response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that needed > a large response to implement an iterator. It also means that > each part of the response from the iterator would have to fit > in the 4k PDU. > > The remainder of these require that only one text command sequence > be outstanding on a connection at a given time. They use the F > bit to indicate the last PDU of the sequence. Note that connection > allegiance is assumed for the entire sequence, and text commands > are never retried on another connection; a new command is issued > instead. > > 3. Do a text-response R2T, where the initiator controls when the > next partial response is sent. This would be more generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep track > of the state of its responses; if the initiator just stops asking, > it may have to keep a buffered response around until it times out, > the connection is dropped, or another text command comes along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if it > can't handle them. This solution is a lot like #1, but with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the problem > of the target keeping state; it sends ALL of the response PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > Note that most initiators will probably send an AcceptResponseLength > of the largest response they would normally accept, and that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target has the > benefit of being less statefull, and the initiator has the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 is > probably the safest solution, but #4 may not be a problem for anyone. > > Assuming that none of the implementors of initiators have a problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 17:01:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02134 for ; Wed, 18 Jul 2001 17:01:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IJPEa26713 for ips-outgoing; Wed, 18 Jul 2001 15:25:14 -0400 (EDT) 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 f6IJP8g26696 for ; Wed, 18 Jul 2001 15:25:08 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id DDB67627 for ; Wed, 18 Jul 2001 15:25:03 -0400 (EDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 078AC4D2 for ; Wed, 18 Jul 2001 13:25:06 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id MAA11353 for ; Wed, 18 Jul 2001 12:25:05 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA4C9A for ; Wed, 18 Jul 2001 12:25:02 -0700 Message-ID: <3B55E276.AECD2A84@agilent.com> Date: Wed, 18 Jul 2001 12:24:38 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: Framing Formats References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod Harrison wrote: > > Mike, > > We have (1) now. No we don't. iSCSI PDUs are variable in length. > -----Original Message----- > From: Mike Parkhurst [mailto:mike@integrix.com] > Sent: Tuesday, July 10, 2001 11:07 PM > To: ips@ece.cmu.edu > Cc: 'Rod Harrison' > Subject: RE: Framing Formats > > If the iSCSI protocol is going to take on the responsibility > of insuring > a reliable data stream then there are only two alternatives. > > 1) Fixed length commands with padding. [ I'm assuming Mike really meant fixed length PDUs - what is a fixed length command? ] -Matt From owner-ips@ece.cmu.edu Wed Jul 18 17:02:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02252 for ; Wed, 18 Jul 2001 17:02:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IJGvO26083 for ips-outgoing; Wed, 18 Jul 2001 15:16:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IJGtg26077 for ; Wed, 18 Jul 2001 15:16:56 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id D5B7C7C5 for ; Wed, 18 Jul 2001 13:16:54 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 74BBA333 for ; Wed, 18 Jul 2001 13:16:54 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id MAA10987 for ; Wed, 18 Jul 2001 12:16:53 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA4B9D for ; Wed, 18 Jul 2001 12:16:50 -0700 Message-ID: <3B55E089.7258E8E6@agilent.com> Date: Wed, 18 Jul 2001 12:16:25 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IPS Reflector Subject: Re: iSCSI: SNACK wording clarification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Trang Nguyen wrote: > My questions are: > > 1. In the iSCSI I-D: "iSCSI uses Command and Status numbering schemes and a > Data sequencing scheme. It supports ordered command delivery within a > session. All commands (initiator-to-target) are numbered". As I understand > it means that the iSCSI initiator won't deliver the next PDU until it > receives the acknowledgement from the target (through StatSN, ExpCmdSN). That is incorrect. The initiator may send up to MaxCmdSN-CmdSN commands. > Also, the target executes the PDU with sequence number it expects. It won't > execute the out-ot-order PDU. Am I understanding it right? That part you got correct. > 2. From the section 6.3 "Sequence Errors", I have the impression that iSCSI > can send multiple PDUs without waiting for the acknowledgement. That's correct. -Matt From owner-ips@ece.cmu.edu Wed Jul 18 17:06:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02846 for ; Wed, 18 Jul 2001 17:06:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IJVt027288 for ips-outgoing; Wed, 18 Jul 2001 15:31:55 -0400 (EDT) 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 f6IJVsg27284 for ; Wed, 18 Jul 2001 15:31:54 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA10328; Wed, 18 Jul 2001 15:31:33 -0400 (EDT) Message-ID: <3B55E2D3.9C0DB7C5@cisco.com> Date: Wed, 18 Jul 2001 14:26:11 -0500 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: "WENDT,JIM (HP-Roseville,ex1)" CC: "'ips@ece.cmu.edu'" , "'Jeff Chase (E-mail)'" , "HAAGENS,RANDY (HP-Roseville,ex1)" Subject: Re: F2F Mtg Summary for Framing and Error Recovery References: <499DC368E25AD411B3F100902740AD65BC5BA1@xrose03.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim- The error recovery slides and spreadsheet are now available on Julian's web site at: http://www.haifa.il.ibm.com/satran/ips/PaloAlto-MarkBakke-crc-recovery.pdf http://www.haifa.il.ibm.com/satran/ips/PaloAlto-MarkBakke-iSCSI-errors.xls They make a lot of assumptions; please enjoy them responsibly. -- Mark "WENDT,JIM (HP-Roseville,ex1)" wrote: > > Here is a quick summary of the outcome from the June 27-28 Design > Teams Face-to-Face meeting in Palo Alto in the two focal areas: > Framing and Error Recovery. The bulk of the meeting was spent > discussing framing scenarios, requirements, and alternatives. > > As soon as the slide decks make it onto Julian's web site, > I'll email out that info. > > Regards, > Jim Wendt > Networked Storage Architecture / NSSO > Hewlett-Packard Company > jim_wendt@hp.com 916-785-5198 > > --------------------------------------------------------------- > F2F Meeting Summary for Framing and Error Recovery > Design Teams Face-to-Face Meeting / June 27-28 Palo Alto > > ---------------- Framing: The Bottom Line ---------------------- > > To cut to the chase, the following rough proposal was generated > for handling ULP Framing for iSCSI: > > A) Proposed changes to "ULP Framing for TCP" I-D are: > 1) Modify I-D to include two framing modes: > - "Marker mode" for unmodified TCP stacks > - "PDU-alignment mode" for modified TCP stacks > > 2) ULP is responsible for negotiating use of framing protocol > and enabling framing behavior on the TCP connection in an > unambiguous manner > > 3) The framing protocol usage, framing mode, and framing > operational parameters are negotiated separately in each > direction on a TCP connection. Thus there are "Senders" > and "Receivers" on a framing TCP connection. An iSCSI > Initiator or Target is both a Sender and a Receiver > with respect to an framing TCP connection. > > 4) ULP is responsible for negotiating use of a specific > framing mode over the TCP connection by having the > receiver request highest framing mode desired from sender > (first PDU-alignment, then Marker, then none) and having > the sender comply: > - if receiver requests, and sender supports, PDU-alignment > mode, then sender MUST enable PDU-alignment mode > - else if receiver requests, and sender supports, Marker > mode, then sender MUST enable Marker mode > - else don't use framing protocol > > 5) ULP is responsible for negotiating framing operational > parameters: > - Marker period (in Marker mode) > - Receiver maximum PDU size (in Marker mode) > - Framing keys (in PDU-alignment mode) > - ULP packing behavior (in PDU-alignment mode) > > 6) Change the marker fields to be 16-bits rather than 32-bits > (and refer to as "offsets" rather than "pointers") > > *) An updated version of the "ULP Framing for TCP I-D" > reflecting these changes has been posted (7/9/01) to TSVWG > for comments (draft-ietf-tsvwg-tcp-ulp-frame-00) > > B) Proposed changes to iSCSI spec are: > 1) Remove Markers appendix from iSCSI spec (Appendix D. Synch > and Steering with Fixed Interval Markers) > > 2) iSCSI spec adds wording to the effect of: > * iSCSI initiator and target framing behavior over a TCP > connection is defined in draft-ietf-tsvwg-tcp-ulp-frame-00 > (or eventual RFC#) > * an iSCSI initiator or target is both a sender and receiver > with respect to framing behavior > * an iSCSI framing sender MUST implement Marker mode, and > MAY implement PDU-alignment mode, as defined in > * an iSCSI framing receiver MAY implement PDU-alignment > mode, or Marker mode, or both, or none as defined in > * an iSCSI receiver on a framing TCP connection dictates > use of the highest framing mode desired from sender as > follows: > - if receiver requests, and sender supports, PDU-alignment > mode, then sender MUST enable PDU-alignment mode > - else if receiver requests, and sender supports, Marker > mode, then sender MUST enable Marker mode > - else framing behavior is disabled > * Perhaps there is some description of probable framing > scenarios capturing the most likely combinations of > the following attributes: > - initiator or target > - software implementation or hardware implementation > - unmodified or modified TCP stack > - sender AND receiver framing behaviors (no framing, > or Marker mode, or PDU-Alignment mode) > - values for framing operational parameters > > 3) > Still need to determine iSCSI mechanism for turning on > Framing protocol Marker mode operation > > 4) > Still need to determine iSCSI mechanism for negotiating > framing operational parameters: > - Framing mode (if both Marker and PDU Alignment mode > are supported) > - Marker period (in Marker mode) > - Receiver maximum PDU size (in Marker mode) > - Framing keys (in PDU-alignment mode, if supported) > - ULP packing behavior (in PDU-alignment mode, if > supported) > > ----------- > The reasoning for these proposed changes is as follows: > > 1) Re: Merge Marker mode into "ULP Framing for TCP" I-D > a) The TCP-related framing work already has mindshare > in TSVWG and this work is embodied in the current > framing I-D. Rather than dilute the framing effort > with additional I-Ds, all framing related work > should be collected into a modified version of the > existing framing I-D. > > b) Other ULPs may also find Marker mode useful in > software-only unmodified-TCP client scenarios > > c) The framing I-D appears to be a reasonable literary > vehicle for documenting the collection of framing > schemes. The I-D could be extended in the future to > include a byte or word stuffing frame marker method > such as COBS. > > d) A single framing I-D may help to encourage a single > consistent interface with the ULP regardless of which > framing mode is employed. > > e) The iSCSI spec can simply reference the one framing I-D. > > 2) Re: Make Marker mode mandatory for all iSCSI implementations, > and PDU-Alignment mode optional for all iSCSI implementations. > > a) This allows interoperation of software-only, > UNMODIFIED-TCP-stack clients with hardware-accelerated, > small-buffer-memory storage arrays. This applies to both > 1Gbps-client/1Gbps-array and 1Gbps-client/10Gbps-array > scenarios. > > b) One potentially compelling application for iSCSI involves > software-only implementations on mainstream desktops and > laptops operating over unmodified TCP stacks to access > centralized storage arrays. > > c) Software implementations are likely to exist far into the > future. Individual software-only clients may not operate > at 10Gbps, but will be combined together with other clients > that aggregate to 10Gbps. > > d) The only framing mechanisms that can operate completely > above a client TCP and not require any modification to > the client's standard TCP stack are the interval-based > (Marker mode, periodic PDU alignment, fixed length PDU) > and byte-stuffing (COBS) framing schemes. All other > framing mechanisms (including PDU-Alignment mode) > require modification to the client's TCP stack. > > e) The processing overhead for a client software > implementation to insert Markers is small compared to > the processing overhead of a byte-stuffing scheme. > > f) Receivers are allowed to dictate the sender's framing > behavior because it is the receiver that is impacted > by the presence or absence of framing behavior on the > connection. > > g) Hardware-accelerated receivers can be implemented with > minimal buffer memory, meaning that they always rely on > framing-based direct data placement processing, only if > it is known in advance that every client the receiver > could potentially interoperate with is capable of > providing the necessary framing-based behavior. These > hardware-accelerated receivers will request, and expect > that, the sender insert markers (or PDU-Alignment if > supported). > > h) Since a software-implemented receiver may incur extra > data movements in processing markers, these receivers > can request, and expect that, a sender NOT insert > markers, if desired. > > i) Marker mode doesn't completely eliminate the need for > buffer memory on the receiver. The receiver still needs > to use "eddy buffers" that temporarily hold incoming data > after a dropped segment containing a ULP header up until > the next ULP header is located in the packet stream, and > which exist for as long as the original ULP header segment > is outstanding. But Marker mode does greatly reduce the > amount of memory needed as compared to a traditional TCP > receiver's reassembly memory requirements (often equal to > number-of-connections X round-trip-pipe-size). The Marker > mode small memory requirements are dependent upon the > period of the marker, and the size of the ULP PDUs being > restricted to a reasonably small value. The larger that > either one is, the larger the eddy buffer memory > requirements. Also, an eddy buffer is required each time > a ULP header is dropped, so that multiple ULP header drops > in close proximity may cause multiple eddy buffers to be > temporarily pending on a connection. > > j) The PDU-alignment framing mode is preferred. However, it > may be several years before all of the different software > TCP/IP implementations will be able to support framing > behavior. > > ----------- > Open Issues: > > 1) Acceptability of the PDU-Alignment framing mode's reliance > on "key+length" matching across resegmenting middleboxes > - In PDU-Alignment mode each TCP segment payload contains > one complete framing PDU (consisting of an 8 byte > framing header followed by one or more complete ULP > PDUs). Thus, every TCP segment has the TCP header > followed immediately by the framing header. > - In certain cases a single framing PDU must be broken > across multiple TCP segments (such as dynamic Path MTU > reductions), resulting in TCP segments where a framing > header doesn't immediately follow the TCP header. > - The framing I-D defines sender behaviors that allow > PDU-alignment mode to function deterministically and > correctly in all cases where the TCP segmentation > flowing from sender to receiver is not altered. > - If the TCP segmentation from sender to receiver is > altered by an intermediary (resegmenting middlebox), > and a framing-header-containing segment drop or > reordering has occurred such that the receiver is > attempting to locate the next framing header in the > segment stream, then the receiver must examine the > first 8 bytes of each incoming TCP segment payload for > a valid framing header containing valid Key(6B) and > Length(2B) fields. > - A false-positive occurs if, upon resegmentation by a > middlebox, the receiver gets a TCP segment in which > the first 8 bytes of the payload indicate a valid > framing header (the first 6 bytes match the > previously exchanged random key value, and the next > 2 bytes contain a valid length), yet the TCP segment > payload isn't actually a framing header. > - While it is felt that the probability of a > false-positive in these resegmenting-middlebox scenarios > will be sufficiently low, further analysis work may be > may be required in this area. > - Note that this mechanism is NOT a scanning technique > for locating start-of-frame across an arbitrary byte > stream. It only provides an indication of PDU > alignment or not. The first 8 bytes of the TCP segment > payload are examined to determine if the segment > contains the start of a ULP PDU. > > 2) None of the current framing schemes take TCP data integrity > into account. It either needs to be decided: > a) how to detect when a data integrity problem occurs > within a framing header, and what to do about it > (even if it just kills the TCP connection), > b) or that a sufficient level of data integrity needs > to be provided for all protocols running over TCP > via a more holistic approach. > > 3) Do Markers work at 10Gbps > - The feasibility of markers at 10Gbps has been questioned. > It would be beneficial to hear specifics regarding why > Markers won't work at 10Gbps. Markers don't allow for a > no-memory direct data placement NIC since eddy-buffers > are required. So, support for clients with unmodified > TCP stacks comes at a cost, which is the cost of > supporting eddy buffers on the NIC. > - One question is whether the eddy buffers can be contained > entirely in the ASIC or need to be in off-chip memory. > > ---------------- Error Recovery: The Bottom Line ---------------------- > > 1) Information was presented regarding estimated iSCSI header and > data digest error rates, and possible approaches to iSCSI > error recovery. The error rates info is summarized as follows: > > a) "Good Internet" > - 1500 byte MTU / 8192 byte iSCSI PDU > - TCP checksum mismatch 1 in 90,000 > - Checksum escape 1 in 135M to 1 in 10B > - For bandwidth of 30Mbps @ 100msec RTT > > 8 to 600 digest errors per year > > 1 header digest every 2 months to 10 years > - For bandwidth of 300Mbps @ 10msec RTT > > 80 to 6,000 digest errors per year > > 1 to 70 header digest errors per year > > b) "Bad Internet" > - 1500 byte MTU / 8192 byte iSCSI PDU > - TCP checksum mismatch 1 in 11,000 > - Checksum escape 1 in 16M to 1 in 1B > - For bandwidth of 10Mbps @ 100msec RTT > > .5 to 33 digest errors per week > > 26 to 1,650 digest errors per year > > 0.3 to 20 header digest errors per year > - For bandwidth of 100Mbps @ 10msec RTT > > 5 to 335 digest errors per week > > 260 to 16,500 digest errors per year > > 3 to 200 header digest errors per year > > c) 1Gbps iSCSI connection > - assuming current TCP yields 70% bandwidth utilization > - at 100msec > > packet loss less than 1 in 50M > > .5 to 40 digest errors per year > > 1 header digest error every 2..100 years > - at 10msec > > packet loss less than 1 in 500,000 > > 60 to 4,000 digest errors per year > > 1 to 40 header digest errors per year > > d) 10Gbps iSCSI connection > - assuming current TCP yields 70% bandwidth utilization > - at 100msec > > packet loss less than 1 in 5 billion > > 1 digest error every 3 mo to 10 years > > 1 header digest error every 20 to 1000 years > - at 10msec > > packet loss less than 1 in 50M > > 6 to 400 digest errors per year > > 1 header digest error every 3 mo to 12 years > > e) The frequency of framing header corruption escaping the > TCP checksum mechanism is on the order of the frequency > of the iSCSI header escaping, but depends on the > mechanism used as well as the MSS and iSCSI PDU sizes: > - Markers (at 2k intervals) - 1/3 as likely as iSCSI > headers. > - Framing (w/o chunking) - 1.5 times as likely > - Framing (w/ chunks) - 1/2 as likely as iSCSI headers. > These assumed an 8k iSCSI PDU size, except for Framing > (w/o chunking), which assumed a 1k iSCSI PDU to fit in a > single segment. All schemes had a framing header size > of 8 bytes, and assumed an MSS of 1460. > > 2) No definitive conclusions were reached during the F2F in regards > to Error Recovery mechanisms. > - Further work needs to be done in this area. > - Mallikarjun Chadalapaka, Mark Bakke, and others can help > move the work forward in this area. > > 2) It would be valuable to collect information regarding TCP > checksum mismatch rates on production systems. If anyone has > access to fairly busy systems and can collect the following > information, you can forward it to Mark Bakke (mbakke@cisco.com). > You'll want to collect three data items: > a) sysUpTime > b) tcpInSegs - total number of inbound TCP segments > c) tcpInErrs - total number of inbound TCP segments with errors > (most likely checksum mismatches, but some implementations > may count other error discards here as well) > > ---------------- Slide Decks ------------------------------------ > > Sorry, but these materials aren't on the web yet. Hopefully > they will be in the next week or two. I'll email when they are > available on a server somewhere. > > * "iSCSI Framing Presentation" - slides/spreadsheet - Matt Wakeley > * "TCP Framing Discussion" - slides - Jim Wendt > * "Recovering From iSCSI Digest Errors" - slides - Mark Bakke > * "Expected iSCSI digest error rates on Internet connections" > - spreadsheet - Mark Bakke > * CRC and checksum performance - slides - Jonathan Stone > > ---------------- Framing Discussion Summary ---------------------- > > /iSCSI usage scenarios > A wide variance of usage scenarios were strongly represented: > * High-speed short-distance storage LANs > * High-speed long-distance storage WANs > * Multitudes of low-end clients using software iSCSI client > implementations and unmodified software TCP stacks > * Multiple first-generation 1Gbps clients aggregating to > next-generation 10Gbps storage arrays > * A variety of IP networks and paths with potential for both > TCP-level resegmenting middleboxes and dynamic changes in Path MTU. > > /Memory-based solutions > * It was felt that 1Gbps memory-based solutions are feasible and > may be cost-competitive (e.g. there is no usage of direct data > placement nor framing mechanisms in this case) > * There were different opinions regarding whether 10Gbps memory-based > solutions would be cost-competitive or feasible for 10Gbps. > * There was discussion regarding the comparative cost of memory-based > and no-memory iSCSI HBAs and infrastructure relative to Fibre Channel > * There were concerns regarding next-generation 10Gbps storage arrays > that want to support first-generation clients. The next-generation > 10Gbps storage arrays can only implement no-memory solutions if the > first-generation clients were mandated to implement support for > framing (thus making direct data placement possible on the storage > array). > * Hybrid schemes were discussed where a next-generation 10Gbps > storage array would contain a moderate amount of memory to handle > non-framing first-generation clients while using full framing and > direct data placement with no memory buffers for 10Gbps clients > * Matt Wakeley has created a spreadsheet for high-speed memory > subsystem costs > > /Direct data placement alternatives > * Discussion of various levels at which direct data placement > information can ride: > - Above TCP (iSCSI task tags, RDMA protocol) > - At transport (TCP RDMA option) > - Below transport (TAF) > > /iSCSI layering scenarios and evolution > * iSCSI can be layered: > - over normal TCP > - over Markers over normal TCP > - over Framing TCP > - over RDMA+chunking over Framing TCP > * Layering iSCSI over RDMA+chunking doesn't seem likely for > first-generation iSCSI implementations > > /Framing alternatives > * Framing mechanism classes: > - Intervalic (Periodic Markers, Periodically aligned headers, > Fixed size ULP PDUs) > - Framing aware TCP (ala ULP Framing over TCP I-D) > - TCP message boundary indications (Reserved bit, TCP option, > URG pointer, PSH bit, etc) > - Byte stuffing (COBS, 7B/8B, etc) > * Framing mechanism characteristics: > - sender TCP modifications required? > - receiver memory requirements (full TCP receive window, > eddy buffers, IP reassembly buffers) > - level of TCP changes (none, behavioral, header fields) > - support ULP PDU > TCP MSS > - software processing overhead > - hardware implementation complexity > - handle dynamic Path MTU changes > - handle resegmenting TCP middlebox > - require [dynamic] chunking above TCP > - emit short segments more often than typical > - added protocol bytes overhead > - tied to TCP sequence number processing > - increase probability of segment drops > - TCP aesthetics > > /Markers and ULP Framing merge > * Proposal to merge Marker mechanism into current "ULP Framing for > TCP I-D" and have iSCSI mandate implementation of Marker mode > * See "Framing: The Bottom Line" section above > > ---------------- Error Recovery Discussion Summary --------------- > > /Mark Bakke slides and spreadsheet > * Mark presented slides and a spreadsheet discussing: > - expected iSCSI header and data digest error rates given > link bandwidth, RTT, probability of segment drop, and > probability of TCP checksum escape > - recommended iSCSI error handling approaches for Header > digest and data digest errors > - > - > > /Discussion regarding iSCSI error recovery complexity > * It was felt that 90% of the recovery complexity already exists > for the sake of session recovery (aftet a TCP connection failure) > and if only "within-command" recovery was eliminated, it wouldn't > substantially simplify the protocol or its specification. > However, this assertion needs to be validated. > * It was felt that complete command recovery would probably be a > dequate for the expected error incidence (not a noticable impact), > but it hasn't been shown how adopting this approach would reduce > complexity. > > /Discussion re: IPSec SA's > * There was some discussion regarding use of IPSec and concerns > that the set of Security Associations would not fit into on-chip > memory, forcing the SAs to be cached in off-chip memory. > > /Jonathan Stone slides > * Jonathan presented data analysis from his soon-to-be-completed > dissertation regarding the nature of empirically-observed > transport-level errors, and the error detection performance of > CRC and checksum algorithms on such. > > ---------------- List of Attendees ----------------------- > > Mark Bakke, Stephen Bailey, Uri Elzur, Somesh Gupta, Randy Haagens, > John Hufferd, Jim Pinkerton, Venkat Rangan, Allyn Romanow, > Costa Sapuntzakis, Julian Satran, Jonathan Stone, Matt Wakeley, > Jim Wendt, Jim Williams > > -------------------------------------------------------------- -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 17:54:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13549 for ; Wed, 18 Jul 2001 17:54:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IKFSo01022 for ips-outgoing; Wed, 18 Jul 2001 16:15:28 -0400 (EDT) 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.6.9.33]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IKFQg01013 for ; Wed, 18 Jul 2001 16:15:26 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1.cos.agilent.com (Postfix) with ESMTP id 0BBF9727 for ; Wed, 18 Jul 2001 14:15:25 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 836F910DA for ; Wed, 18 Jul 2001 14:15:24 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id NAA12832 for ; Wed, 18 Jul 2001 13:15:23 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA52A1 for ; Wed, 18 Jul 2001 13:15:21 -0700 Message-ID: <3B55EE40.D13AE855@agilent.com> Date: Wed, 18 Jul 2001 13:14:56 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert, The question is, in the case of adding connections to (form) a multiple connection session, what CmdSN values do you use to start the new connection? If you use the next in line CmdSN for the session, you block all the SCSI commands the existing connections are sending while negotiating this new connection. -Matt "Robert D. Russell" wrote: > > Mark: > > I respectfully disagree with your recommendation to go with option 3. > > The experience here at the plugfest seems to be that option 1 is > easiest to work with since it involves no special case code -- > the cmdsn is incremented on every command sent. Period. > A simple statement to that effect in the standard is much, much > prefered than a long chain of "technical" reasoning that readers have to > follow through to the end to infer what the final result should be. > > I believe simplicity is the key to interoperability, and the standard > mechanisms should be designed to be simple. There is indeed a reason > to number commands during login -- because then they are treated the > same as any other commands and you don't need special purpose code > during login to deal with that part of shipping the commands. > I.e., you keep it uniform and simple, no special cases. > This allows code to be reused and debugged once. > > As a final point, most implementations will NOT have to be modified > to implement option 1 -- they now already do that. > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Tue, 17 Jul 2001, Mark Bakke wrote: > > > > > Given that this is being interpreted differently by enough > > implementations, I would prefer to see us take a step back > > and look at which of Scott's three options should make the > > most sense. It looks like options #1 and #2 are what is > > currently being implemented, regardless of what's specified. > > > > However, a connection technically can't really be part of a > > session (sharing its work load) until it has completed a > > successful login phase. There's also little reason for > > numbering until the login phase is complete, since the login > > and text responses during negotiation are synchronous, and > > pertain only to the connection, rather than the session. > > > > I would recommend stating that a connection joins (or becomes, > > if it's the first one) a session after the login response > > with the F bit set is sent (on a target), or after the login > > response with the F bit set is received (on an initiator), > > and that CmdSN is not necessary until such a time, especially > > since CmdSN is per-session, not per-connection. This is > > identical to Scott's option 3. > > > > I think that defining it this way would remove any further > > ambiguity on when a connection is part of a session. Since > > it appears that most implementations will have to modify their > > login code anyway, this shouldn't be too bad. > > > > -- > > Mark > > > > Matt Wakeley wrote: > > > > > > I think it's pretty obvious that it's your option #1: (the initiator supplies > > > the initial CmdSN in the login PDU, and for every command PDU after that, the > > > CmdSN gets incremented, just like in "full feature phase") > > > > > > 2.10.7 CmdSN says "CmdSN is either the initial number of a session..." > > > [Julian, this should say "initial command number of a session"] > > > > > > So, the Login PDU defines the first CmdSN. > > > > > > 1.2.2.1 says "Commands in transit from the initiator to the target layer are > > > numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN". Text > > > commands are commands, so they are numbered also. > > > > > > It goes on to say "CmdSN - the current command Sequence Number advanced by 1 > > > on each command shipped except for commands marked for immediate delivery." > > > > > > I agree that this needs to be cleaned up. CmdSN and StatSN should work during > > > login just like they do during "full feature phase" - there is no reason why > > > the should not, and making them always work the same removes complexity and > > > interoperability problems. > > > > > > -Matt > > > > > > "Scott M. Ferris" wrote: > > > > > > > > At what point during the Login Phase of a leading connection (null > > > > TSID) does a session exist? > > > > > > > > Section 2.10.7 describing CmdSN for the Login PDU indicates that > > > > when TSID is null, CmdSN indicates the starting Command Sequence > > > > number for this session. > > > > > > > > For interoperability, it is important to define precisely when a > > > > session exists, so that all initiators and targets agree on when > > > > CmdSNs are significant, and do not reject or ignore PDUs due to > > > > differing assumptions of how the CmdSN numbering should be done during > > > > the Login Phase. > > > > > > > > Some of the possible choices for session start are: > > > > > > > > 1) a session starts before the initiator sends anything, and the Login > > > > PDU is the first PDU of a session. > > > > > > > > 2) a session starts when the initiator receives a (possibly partial) > > > > Login Response with an accept status class and a non-zero TSID, and > > > > the next PDU sent by the initiator is the first PDU of the session, > > > > which uses the same CmdSN as the Login PDU. > > > > > > > > 3) a session starts when the initiator receives a Final Login > > > > Response, and the next PDU sent by the initiator is the first PDU > > > > of the session, which uses the same CmdSN as the Login PDU. > > > > > > > > After searching through draft 6, I was unable to find anything that > > > > clearly indicated which if any of the above possibilities was correct, > > > > or, if more than one is possible, how the initiator and target are > > > > supposed to determine what CmdSN numbering scheme the other side is > > > > using for the Login Phase. > > > > > > > > The UNH draft-6 initiator appears to use choice #1. The Cisco > > > > draft-6 initiator and target use choice #2. This can cause the UNH > > > > initiator to hang when trying to login to the Cisco target, since the > > > > initiator may send a Text PDU with CmdSN 2, while the target is > > > > waiting for a PDU with CmdSN 1. > > > > > > > > Section 1.2.2.2 states that "Status numbering starts after > > > > Login. During login, there is always only one outstanding command per > > > > connection and status numbering is not strictly needed but may be used > > > > as a sanity check." > > > > > > > > A similar argument could be made that CmdSN is not needed during the > > > > Login Phase, suggesting choice #3 may be the simplest. > > > > > > > > I also think section 1.2.2.2 is problematic, as it appears to > > > > contradict itself by saying that status numbering is not used during > > > > login, and then follows up saying status numbering may be used during > > > > login. > > > > > > > > -- > > > > Scott M. Ferris, > > > > sferris@acm.org > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > From owner-ips@ece.cmu.edu Wed Jul 18 17:55:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13993 for ; Wed, 18 Jul 2001 17:55:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IKauL02760 for ips-outgoing; Wed, 18 Jul 2001 16:36:56 -0400 (EDT) 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 f6IKatg02756 for ; Wed, 18 Jul 2001 16:36:55 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA01826; Wed, 18 Jul 2001 16:36:42 -0400 (EDT) Message-ID: <3B55F218.CCFD13C5@cisco.com> Date: Wed, 18 Jul 2001 15:31:20 -0500 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: Black_David@emc.com, ips@ece.cmu.edu Subject: Re: iSCSI Naming: iqn format specification References: <277DD60FB639D511AC0400B0D068B71E070A3E@corpmx14.us.dg.com> <3B549B31.85EB5ABA@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 To get the draft out, I am going to require the enterprise number. A second possibility exists; the reversed DNS name could be qualified by the date on which the iSCSI name was generated. Since two entities cannot own the same DNS name at the same time, the separate naming authorities would not generate these using the same dates. Anyone want dates instead of enterprise numbers? -- Mark Mark Bakke wrote: > > Works for me. Anyone wanting to do their own naming schemes would > fall into three categories: > > 1. iSCSI hardware and software manufacturers > > Most iSCSI names would be generated by these folks; they would > make them up either statically (based on a chassis number or > something) or dynamically (based on user configuration, but not > explicitly configured by the user), or a combination of the two. > > These have their own enterprise # anyway. > > 2. Service-minded end-users that want control over naming. > > These are sophisticated enough to want an enterprise number; I > anticipate that only folks such as SSPs would want to do this > sort of thing; most will leave the manufacturer-assigned names > along. > > 3. Researchers building iSCSI experimental stuff > > These would not be concerned with being "iSCSI-compliant"; they > would simply want to be reasonably sure that they won't conflict > with other equipment in a lab environment. These folks could just > use enterprise # 0, along with their reversed domain name, and be > reasonably assured of this. > > We don't have to mention #3 in the spec, if that's a problem, since > this decision of iSCSI-compliance would be up to the implementor > > -- > Mark > > Black_David@emc.com wrote: > > > > That would work - REQUIRE the enterprise > > number and possibly RECOMMEND that it be > > followed by the reverse DNS name for > > human-friendliness. --David > > > > > -----Original Message----- > > > From: Mark Bakke [SMTP:mbakke@cisco.com] > > > Sent: Monday, July 16, 2001 4:28 PM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI Naming: iqn format specification > > > > > > So, should we require the enterprise number? It's a whole > > > lot cheaper than getting an OUI. > > > > > > Black_David@emc.com wrote: > > > > > > > > A couple of comments on this: > > > > > > > > > Anyone wanting to ensure that their names > > > > > will never conflict with someone else's can add the enterprise number. > > > > > > > > Nice try, but not good enough. If this course is followed the > > > > enterprise number has to be REQUIRED independent of the whims > > > > of those who are creating the names so that this conflict can't > > > > happen, period. > > > > > > > > > > Finally, we should use the URI name and format for the namespace > > > > > > where a URI format exists. This is simply for consistency. > > > > > > > > > > > > For example: > > > > > > backwardsdns:au.edu.example.faculty > > > > > > oid:1.32.43.5.3.2.43.2.2.34 > > > > > > oui:2e319c65786e > > > > > > > > > > I had suggested this before, in my draft on iSCSI URNs; the IESG > > > > > completely shot this down, and I'm still not sure why. Anyway, > > > > > I don't have the energy to push the URN/URI thing any further. > > > > > > > > What the IESG shot down was the notion of WWUI as a new URN > > > > namespace into which other namespaces could be glued. Anyone > > > > whose reaction to this is "but it's functionally equivalent", has missed > > > > the point, and should be thankful that they don't spend all their time > > > > on naming issues ;-). The issues here are syntax, intent, and > > > > control; the IESG is not prepared to allow the IPS WG to define > > > > a new global namespace into which the IPS WG could decide > > > > to glue in other namespaces at its discretion. AFAIK, the IESG > > > > would be interested in things like an OUI URN definition (anyone > > > > want to write a draft? - it should be good for at least 15 minutes of > > > > fame). > > > > > > > > --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 > > > > --------------------------------------------------- > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 18:33:41 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21613 for ; Wed, 18 Jul 2001 18:33:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IL0i704682 for ips-outgoing; Wed, 18 Jul 2001 17:00:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IL0gg04675 for ; Wed, 18 Jul 2001 17:00:42 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id RAA11855; Wed, 18 Jul 2001 17:00:34 -0400 (EDT) Date: Wed, 18 Jul 2001 17:00:34 -0400 From: "Robert D. Russell" To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" cc: ips Subject: RE: London: Call for agenda items In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87802A091C5@xrose06.rose.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie: True there have been new opcodes, but there have been new opcodes before. My point is why start changing the version number NOW when we haven't been doing it before? By your reasoning, we should be up to version 7 now, not version 2. A problem with changing the version numbers is that the current scheme by which an initiator offers versions to a target is that there can be no holes in the offering. If the version numbers change too quickly it will be a lot of work to track the intermediate versions. A version change should be really significant, ie. at the IETF level, not at the draft level. We are still at the draft level. Bob Russell On Wed, 18 Jul 2001, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: > > My personal opinion is still that draft 7 is really just > > a refinement and clarification of ambiguities in draft 6, and does > > not add any major features that justify a version change. However, ... > > Not true, there are significant changes to opcodes and some change to header > fields between v6 and v7 - that should *at least* be a criteria for a > version number change! > > Marj > From owner-ips@ece.cmu.edu Wed Jul 18 19:33:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06983 for ; Wed, 18 Jul 2001 19:33:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IIaDX22689 for ips-outgoing; Wed, 18 Jul 2001 14:36:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IIaBg22684 for ; Wed, 18 Jul 2001 14:36:12 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id E4593134F for ; Wed, 18 Jul 2001 11:36:10 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 5B3BE1F50B for ; Wed, 18 Jul 2001 11:36:10 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Jul 2001 11:36:09 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A091C5@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips Subject: RE: London: Call for agenda items Date: Wed, 18 Jul 2001 11:36:05 -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 > My personal opinion is still that draft 7 is really just > a refinement and clarification of ambiguities in draft 6, and does > not add any major features that justify a version change. However, ... Not true, there are significant changes to opcodes and some change to header fields between v6 and v7 - that should *at least* be a criteria for a version number change! Marj From owner-ips@ece.cmu.edu Wed Jul 18 19:34:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07136 for ; Wed, 18 Jul 2001 19:34:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IIgRm23227 for ips-outgoing; Wed, 18 Jul 2001 14:42:27 -0400 (EDT) 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 f6IIgPg23223 for ; Wed, 18 Jul 2001 14:42:25 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3WV3SYRC>; Wed, 18 Jul 2001 14:44:16 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A58@corpmx14.us.dg.com> From: Black_David@emc.com To: ENDL_TX@computer.org, ips@ece.cmu.edu Subject: RE: FCIP Annex E Date: Wed, 18 Jul 2001 14:38:07 -0400 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 Picking up on the Annex E issues, a general theme running through my comments is that while much of the currently proposed text is sufficient to convey what's going on to a Fibre Channel expert, I think the FCIP spec should be accessible to someone who isn't. This means someone who hasn't waded through the various specs (at least half a dozen specs, easily over 1000 pages) and figured out which pieces are important vs. those that should be ignored (e.g., Class 1 service). I agree that detailed specification of Fibre Channel aspects (e.g., DLY_LIM calculation) belongs in FC-BB-2, but (non-normative) explanations of the purpose and rationale for inclusion of functionality in FCIP is in order for the FCIP spec, and such explanations will have to touch on FC concepts (e.g., an explanation of DLY_LIM is much clearer if it explains what R_A_TOV is and why violating it is a *really bad thing* in a Fibre Channel fabric). So, here are my comments going section by section: > > In at attempt to make sure that we don't lose anything > > important in removing this text from the FCIP draft, > > here are some suggestions: > > > > E-4.3 FCIP's Interaction with FC and TCP {partial} The proposed text additions look ok. > > E-5.3 TCP Connection Management > > E-5.5 Multiple Connection Management > > No changes have been made in FCIP in response to this comment. > > I am loath to add FC Port to the FCIP glossary. I can find > nothing in the first paragraphs of E-5.3 and E-5.5 that > are not covered in suitably general terms in section 8. I think Section 9 was intended. The concern I have is a that the coverage is a bit too general, e.g., what are "appropriate policies for mapping FC Frames to these connections"? It's not necessary to specify how to do this, but at least note what FC's frame ordering requirements are and provide an example of how to meet them across multiple connections. > > E-5.4.1 Determining loss of connectivity {partial} > > > > Somewhere, possibly in Annex D, making the FC entity > > responsible for checking for loss of TCP connectivity > > ought to be enhanced by giving the HLO SW_ILS as an > > example of how this could be done without requiring it > > to be used. > > No changes have been made in FCIP in response to this comment. > > This is 100% a Fibre Channel issue. If Fibre Channel does > not want to test connectivity, that is Fibre Channel's business. > If Fibre Channel wants to invent a replacement for the HLO > SW_ILS (perhaps even one suited specifically to FCIP) why > should it be the place of FCIP to mandate use of HLO? I didn't say "mandate", I said "as an example". The general point is that FC may have a keep-alive mechanism such as HLO that would obviate the need for any such mechanism at this level, and it should be made in the FCIP spec. Referencing HLO and the version of FC-SW that defines it *as an example* would help get the point across, without requiring any use of HLO (that sort of requirement is FC's business). > > E-8.3 Corruption {partial} > > > > Most of this seems to be covered in 6.6.2.2, but noting that > > FC has the option to begin transmitting a frame and terminate > > that with an EOF invalidating the partially transmitted frame > > should be added. > > I believe that sufficient discussion of EOFa appears in > section 6.6.2.4. 6.6.2.4 has very little on EOFa. I'd add essentially the above sentence so that the result is intelligible to someone who isn't already a Fibre Channel expert, and put in the appropriate section reference to the definition of EOFa in FC-PH (17.6.3). > > E-8.4 Timeouts {partial} > It is intended that 04 change the usage of R_A_TOV to some other > variable name, perhaps DLY_LIM (delay limit). The burden for > computing DLY_LIM will be placed on the FC Entity, and DLY_LIM > will be nothing more than the value enforced by the FCIP_DE > as per 6.6.2.3. That's a good approach, but I would still add non-normative text to point out the existence and purpose of R_A_TOV, which has to be considered by the FC Entity in this computation. Again this is explanatory text - FC-BB-2 is the place to specify details of how to calculation DLY_LIM from inputs such as R_A_TOV, but FCIP should explain why DLY_LIM exists. > > E-10.1 Flow control on FC network > > > > Section 7.4 covers this topic, but calling out FC > > Buffer-to-Buffer flow control as an example of how > > arrival of frames from the fabric can be controlled > > at the bottom of p.21 would improve readability. > > This will be carried forward as a note to the FCIP Authors. I would recommend putting in the example. --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 18 19:57:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11939 for ; Wed, 18 Jul 2001 19:57:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IMiU912185 for ips-outgoing; Wed, 18 Jul 2001 18:44:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IMiTg12180 for ; Wed, 18 Jul 2001 18:44:29 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id E9905B84 for ; Wed, 18 Jul 2001 16:44:27 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 941B0337 for ; Wed, 18 Jul 2001 16:44:27 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id PAA22496 for ; Wed, 18 Jul 2001 15:44:26 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA66D5 for ; Wed, 18 Jul 2001 15:44:23 -0700 Message-ID: <3B56112E.242091D1@agilent.com> Date: Wed, 18 Jul 2001 15:43:58 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: London: Call for agenda items References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert, Your idea kills any hope of interoperability if some vendors choose to ship products based on certain revisions of the draft - the current "0 vs 6" case in point. -Matt "Robert D. Russell" wrote: > > Marjorie: > > True there have been new opcodes, but there have been new opcodes > before. My point is why start changing the version number NOW > when we haven't been doing it before? By your reasoning, we should > be up to version 7 now, not version 2. > A problem with changing the version numbers is that the current > scheme by which an initiator offers versions to a target is that > there can be no holes in the offering. If the version numbers > change too quickly it will be a lot of work to track the > intermediate versions. A version change should be really significant, > ie. at the IETF level, not at the draft level. We are still at the > draft level. > Bob Russell > > On Wed, 18 Jul 2001, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: > > > > My personal opinion is still that draft 7 is really just > > > a refinement and clarification of ambiguities in draft 6, and does > > > not add any major features that justify a version change. However, ... > > > > Not true, there are significant changes to opcodes and some change to header > > fields between v6 and v7 - that should *at least* be a criteria for a > > version number change! > > > > Marj > > From owner-ips@ece.cmu.edu Wed Jul 18 19:57:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12031 for ; Wed, 18 Jul 2001 19:57:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IMvcR13158 for ips-outgoing; Wed, 18 Jul 2001 18:57:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IMvag13153 for ; Wed, 18 Jul 2001 18:57:36 -0400 (EDT) Received: from breinhold (lucent3.iol.unh.edu [132.177.125.48]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f6IMvZg20341 for ; Wed, 18 Jul 2001 18:57:35 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: The iSCSI Plugfest - update for Wednesday Date: Wed, 18 Jul 2001 18:53:30 -0400 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 The plugfest process has settled down to the detailed process of isolating implementation bugs. A significant percentage of the implementors are now able to connect and perform I/O operations - though this is often achieved by first compiling with -D "company Name" switches to handle the different issues that have already been discovered. New Issues: A detailed posting of the issues to date will (or has) be done by Bob Russell. In brief only one additional standards issues came to light that impacted interoperability in the days testing: 1. The current wording of the standard appears to allow for the transmission of IO data in response frames. This is actually being done in a few implementations. Although this was perhaps a vision at the start of the iSCSI effort there is little support for this. Most implementors were not prepared to handle this. Progress: Test progressed to round 17 and it appears that it is highly likely that developers will get a chance to test against all other parties by the end of the week. Two vendors were able to establish a multi connection session, getting through the login process and the start of IO. Two other vendors established an iSCSI session with header digests, completing the security phase of the login process. Some generic problem areas that come up: 0 Length data frames Target initiated text negotiation Response information in data PDUs. SCSI compatibility issues There was a UNH iSCSI consortium meeting at the end of the day 1. Overview of UNH iSCSI consortium 2. Discussion on dates/time for next plug fest 3. Election of steering team People flowing out at 7:00 -- sign that things are pretty good. 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 Wed Jul 18 19:59:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12320 for ; Wed, 18 Jul 2001 19:59:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6IMkm712430 for ips-outgoing; Wed, 18 Jul 2001 18:46:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6IMklg12426 for ; Wed, 18 Jul 2001 18:46:47 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id SAA13645 for ; Wed, 18 Jul 2001 18:46:46 -0400 (EDT) Date: Wed, 18 Jul 2001 18:46:46 -0400 From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iSCSI Plugfest at UNH Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk From: Bob Russell rdr@iol.unh.edu Bill Lynn bill_lynn@corp.adaptec.com Kalman Meth meth@il.ibm.com Barry Reinhold barry.reinhold@trebia.com Points that arose during the UNH Plugfest (July 16-20, 2001) where the Standard is unclear. (not in any particular order) -------------------------------------------------------------------------------- 1. Exactly what should happen if operational parameters are sent by the initiator during the security phase of login? In section 4.2 the standard says: "-The iSCSI parameter negotiation (non-security parameters) SHOULD start only after security is established. This should be performed using text commands." and: "When establishing the security context, any operational parameters sent before establishing a secure context MAY be ignored by both the target and the initiator." There is a problem with the meaning of "ignore" -- should the target: 1. not respond to these operational keys at all, or 2. respond with key=reject, or 3. respond with a valid value and then just not use these values. In this case, how does the initiator know whether or not the target is ignoring these parameters or not? A final note: The standard seems to allow the initiator to send operational parameters when establishing the security context, get back a valid value from the target, and then ignore the entire negotiation anyway. Is this legal? In this case, how does the target know that the initiator is ignoring these parameters? -------------------------------------------------------------------------------- 2. In section 2.8.3 the standard says "Many key=value pairs can be included in the Text block by separating them with null (0x00) delimiters." This implies that the last (or only) key=value pair is NOT terminated by a null delimiter. However, all C programs naturally treat key=value pairs as C strings which are always terminated by a null (0x00) delimiter. Therefore, to avoid a source of errors and to simplify implementations, please change the standard to require all key=value pairs MUST be TERMINATED by null (0x00) delimiters. NOTE: if this change is NOT made, then the standard needs to address the issue of what to do when a receiver receives a set of key=value pairs that is terminated by a final NULL. Should this be treated as a format error, or does that final NULL separate the last key from an empty key which the receiver should just ignore? The group consensus was unanimous that all key=value pairs MUST be TERMINATED by null (0x00) delimiters. -------------------------------------------------------------------------------- 3. Many key parameters can take only "yes" or "no" as valid values. However, section 1.2.4 "Text Mode Negotiation" discusses only "list" negotiation and "numerical" negotiation -- there is no discussion of "binary" or "boolean" negotiation. However, the examples never show the use of a list to negotiate any of these parameters. There are then two interpretations of how to negotiate these parameters: (a) Use the existing "list" negotiation mechanism for parameters that can take only "yes" or "no" as valid values. (1) If an initiator has a key named xxx for which it would prefer a "yes" setting, but can also operate correctly with a "no" setting, then the initiator must offer "xxx=yes,no" to the target and then the target must respond with "xxx=yes" if it wants to use the feature, "xxx=no" if it does not use the feature, "xxx=reject" if it does not support the feature, or "xxx=NotUnderstood" if it does not understand the key name xxx. (2) If an initiator has a key named xxx for which it can only utilize a "yes" setting, it offers the target "xxx=yes". The target must respond with "xxx=yes" if it can also use this feature, "xxx=reject" if it either cannot use or does not support this feature, or "xxx=NotUnderstood" if it does not understand the key name xxx. The reply "xxx=no" is explicitly disallowed. This is a very simple way to do this negotiation, and does not require any new mechanism in either the standard or an implementation that already does list negotiation. However, the standard should explicitly show an example similar to one of those just shown to make it clear that this is the way to do it. (b) Invent a new "binary" or "boolean" negotiation. This would require new wording in the standard and probably new code in addition to the "list" and "numeric" negotiation implementation code. In particular, with this method there is no obvious way for the initiator to indicate to the target that it can use either "yes" or "no" but would prefer "no", for example, because sending the string "xxx=no" could be interpreted either as "only no" or "no prefered but yes is also ok". This gets complicated by the default key values. If the required default is "yes", then offering "no" would appear to mean "no is prefered bu yes is also ok". If the required default is "no", then offering "no" would not appear to be necessary, (but is currently not explicitly prohibited and may be useful for implementations that simply send all keys) and would appear to mean "only no". The group consensus seemed to be that solution (a) is by far the simplest and therefore is prefered. -------------------------------------------------------------------------------- 4. It is not clear from the standard whether or not the value in the CmdSN field of an initial login command for a session (i.e., TSID=0) is "consumed" by its appearance in the login command or not. For example, suppose an intiator sends a login command with TSID=0 and CmdSN=123 and then waits for a response from the target. Should the Login Response from the target contain ExpCmdSN=123 or ExpCmdSN=124? Similarly, should the next command sent by the initiator after this login contain CmdSN=123 or CmdSN=124? The consensus seemed to be that ExpCmdSN=124 in the Login Response and CmdS124 in the next command, but the standard needs to make it explicit, perhaps with an example such as the one just given. This is being dealt with in a mailing list thread. -------------------------------------------------------------------------------- 5. Analagous with point 4, it is not clear how InitStatSN is handled by the login phase. If a login response contains a value of 123 in its InitStatSN field, is the value of the next response from the same target 123 or 124? For consistency with the handling of CmdSN it would appear that 124 is correct. However, this situation may be different because the field is called "InitStatSN", not "StatSN" as it is in other responses. At the plugfest the consensus was to use the value 124 for now, but that 123 MIGHT be better long term. A second issue is the fact that there can be two login responses in response to a login (the "login partial response" and the "login final response"), each of which carries an InitStatSN field. It is not clear if the value of the InitStatSN field in a login final response needs to be part of the sequence established by the InitStatSN field in a preceding login partial response, or whether the login final response can restart the sequence to an arbitrary value supplied in its InitStatSN field. The standard should make this explicit. At the plugfest the consensus was that the final response CAN restart the sequence. This is being dealt with in a mailing list thread. -------------------------------------------------------------------------------- 6. During text mode negotiation, if a format error occurs, what is the proper response? Section 6.1 "Format Errors" does not handle all cases. (a) During login, suppose the initiator offers a list and the target responds with a value that is not in the list (and is not "reject" or "Not Understood"). Is the initiator required to close the connection or can it just internally recover from the error (perhaps reporting the error through the "appropriate service response") and continue with the login? (b) During full-feature phase, suppose the initiator sends a text command that offers a list and the target responds with a value that is not in the list (and is not "reject" or "NotUnderstood"). Section 7.3 deals only with the situation when there is an outstanding task related to the PDU, but in this case there is no outstanding task. Therefore, is the proper response to just report the error through an appropriate service response and then ignore it? -------------------------------------------------------------------------------- 8. The last example in Appendix A "iSCSI Security and Integrity" illustrates a special case that should be elimiated. The last sentence of this example says: "Note that no SecurityContextComplete=yes is required since no security mechanism was chosen." But it would be simpler if the exchange of "SecurityContextComplete=yes" keys were required in this case. The reason they should be required is the following: Appendix B. starts by saying that "the parameters (keys) negotiated for security are: - Digests (HeaderDigest, DataDigest) - Authentication method (AuthMethod)" Thus as soon as the Initiator offers either the HeaderDigest or the DataDigest key, the security negotiation phase has been entered. Section 4.2 "Security and Integrity Negotiation" clearly indicates that the security sub-phase ends only when both sides have correctly executed the "SecurityContextComplete=yes" handshake. There is NO qualification in section 4.2 about the outcome of the negotiation -- i.e., one would reasonably conclude that selecting no digests and no authorization still requires the handshake, because the final selections were acheived through negotiation, and the handshake marks the end of the security negotiation subphase. The phrase in the standard that makes this example "legal" is in section 4.3, which says: "Operational parameter negotiation during the login MAY be done: . . . - starting immediately after the Login response with Final bit 0 if the initiator does offer security/integrity options but the target chose none." This clause overrides the rules of section 4.2 with a special case. Why bother with this special case? It complicates the logic in implementations, requires extra wording in the standard, and appears to offer no benefit. If it stays, there should be some indication in section 4.2 about it, or better yet, combine these sections so all this information is together in one place. As it is now, this is an error trap for implementors of both targets and initiators. -------------------------------------------------------------------------------- 9. the SCSI Command (section 2.3) contains R and W bits and an "Expected Data Transfer Length". The standard says in section 2.3.1: "b6 (R) set to 1 when input data is expected b5 (W) set to 1 when output data is expected" and in section 2.3.5: "the Expected Data Transfer Length field states the number of bytes of data involved in this SCSI operation." It then goes on to describe 2 cases: - W=1 with R=0, - W=0 with R=1. The problem is that some SCSI commands involve no data transfer (Test Unit Ready is an example). So in this case, the Expected Data Transfer Length field is set to 0. How should the R and W bits be set? - Should they both be set to 0? - are they "don't care" bits so that their value can be anything? (In the Test Unit Ready example, some implementations will set the R bit because the SCSI implementation interfacing with the iSCSI code uses a single bit to differentiate between read and write commands, and considers this a read command). The standard should make this explicit. -------------------------------------------------------------------------------- 10.Another problem related to setting the F bit on SCSI commands. Section 2.3 says: "b7 (F) set to 1 when no unsolicited SCSI Data-Out PDUs follow this PDU. For a write, if Expected Data Transfer Length is larger than the Length the target may solicit additional data through R2T." This does not explicitly say what happens on a read or on a command other than a write (point 9 above) or on a write with an expected data transfer length of 0. These commands do not allow unsolicited SCSI Data-Out PDUs to follow them, so one could infer that the F bit should be set to 1. However, the present wording can also be interpreted that because unsolicited SCSI Data-Out PDUs are not allowed to follow these commands, this explanation does not apply to them. The standard should explicitly state what happens in the case of these commands, rather than leave it up to an implication. -------------------------------------------------------------------------------- 11.In section 1.2.3 iSCSI Login there is the paragraph: "The login PDU includes a session ID that is composed of an initiator part ISID and a target part TSID. For a new session, the TSID is null. As part of the response, the target generates a TSID. >> Session specific parameters can be specified only for the first login of a >> session (TSID null) (e.g., the maximum number of connections that can >> be used for this session). Connection specific parameters, if any, >> can be specified for any login. Thus, a session is operational once it has at least one connection." The wording of the 2 sentences indicated by ">>" needs to be changed to explicitly indicate login phase, since as now worded in could be literally interpreted to mean login command only. Proposed rewording for those sentences: "Session specific parameters can be specified only during the login phase begun by a login command containing a null TSID (e.g., the maximum number of connections that can be used for this session). Connection specific parameters, if any, can be specified during the login phase begun by any login command. -------------------------------------------------------------------------------- 12.If unsolicited data is negotiated, it appears that it still does not have to be used. In practice this can lead to performance inefficiencies. Consider the following: - Unsolicited data has been negotiated to YES but immediate data is NO (although a problem still exists even if this is YES). - The initiator sends a SCSI command with F=0, W=1 and a large Expected Transfer Length field (greater than FirstBurstSize). - When the target receives this command, it knows that unsolicited data follows (because F=0), but does NOT know how much (there is a maximum determined by the negotiated FirstBurstSize, but there is no requirement that the initiator actually send this much). Therefore, the target cannot at this time send out an R2T to get the "rest" of the data -- it must wait to receive data PDUs until it gets the F=1 set on one of these data PDUs, and then compute the amount of data to ask for in the R2T. This may introduce needless delay. To avoid this situation, the standard should either: - require that when unsolicited data is to be sent, that the amount be min(Expected Transfer Length, FirstBurstSize), - alternatively, provide a field in the SCSI command that allows the initiator to indicate how much unsolicited data follows. -------------------------------------------------------------------------------- 13.Some keys are dependent on other keys. For example, the keys that determine the actual marker intervals (RFMarkInt, SFMarkInt) have meaning only if markers are in fact being used, as determined by the FMarker key. Typically an initiator will offer these three keys in the same message. If the target responds with FMarker=no, does it need to respond to the RFMarkInt and SFMarkInt keys, or can it just omit those from the response, since whatever values they contain will be meaningless anyway? -------------------------------------------------------------------------------- 14.The login phase involves many combinations and permutations that need to be clarified through a state diagram incorporated into the standard. One example is the situation that arises when an initiator sends a login command with F=1 and operational parameters but no security parameters (because the initiator does not want to utilize any security). The target, however, wishes to use security. There appear to be several valid responses the target can give: (a) It can reply with a login final response, F=1, Reject Code of 201 (Authentication failed) and then disconnect. (b) It can reply with a login partial response, F=0, status code 1 (if the login included the ITN) or 2 (if login did not include ITN) and offer its own security parameters. The consensus seems to be that login in its current form is too complex and needs to be simplified considerably. One possibility would be to standardize one or a small number of simple, "fast-path" logins that involve no (or very limited) negotiation and that together would cover the majority of situations. -------------------------------------------------------------------------------- 15.The issue of case sensitivity in names arose, and is being dealt with by a mailing list thread. There also seems to be cases where the Naming and Discovery document is in conflict with the iSCSI Standard. -------------------------------------------------------------------------------- 16.The issue of using a target name of "iscsi" for both discovery sessions and "simple" devices arose, and is being dealt with by a mailing list thread and new text in draft 6-98, which was not available at the time of the plugfest. -------------------------------------------------------------------------------- 17.Can the option "none" be offered as the first element in a key list if that is in fact the prefered option? The present wording in section 1.2.4 says nothing about where in the list it can be offered, so by implication it can be anywhere. However, the standard should be explicit on this point, since all examples (and apparently some earlier drafts required) indicate "none" as the last option offered. -------------------------------------------------------------------------------- 18.The login process is incredibly difficult to understand from the current standard. There are three major obstacles: (1) The information is spread out in at least 5 major sections of the document (section 1.2.3, section 2.3 and 2.4, section 4, Appendix A, and Appendix D.) (2) There is no state diagram to bring all this information together. (3) It is too complex in its current form. -------------------------------------------------------------------------------- 19.In Appendix A the Standard defines the crc-32C generator polynomial to be used by iSCSI but gives no example of its use. On the mailing list several people worked out an example with actual data and gave the actual result of the algorithm. Also on the mailing list several people contributed code to perform this computation. This information (the detailed worked out example and the code) should be made part of the standard in order to eliminate any sources of confusion and to allow implementors to check their own implementations against a reference. -------------------------------------------------------------------------------- 20.This is just an observation -- the iSCSI response sent by a target contains a Data Segment Length field and requires the SCSI response to carry sense and response data in the PDU itself. Any I/O data produced by the SCSI command itself should be carried in a separate Data-In command, not in the iSCSI response. This should be made explicit in the standard, especially because in earlier drafts it was apparently possible to do this. The group at the plugfest unanimously agrees that SCSI I/O data not be allowed in the iSCSI response, but would just like it to be stated explicitly in the standard. -------------------------------------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 18 20:57:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20190 for ; Wed, 18 Jul 2001 20:57:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ILNtD06438 for ips-outgoing; Wed, 18 Jul 2001 17:23:55 -0400 (EDT) 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 f6ILNsg06434 for ; Wed, 18 Jul 2001 17:23:54 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA26741; Wed, 18 Jul 2001 17:23:46 -0400 (EDT) Message-ID: <3B55FD1F.3695C31B@cisco.com> Date: Wed, 18 Jul 2001 16:18:23 -0500 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: Julian Satran CC: John Hufferd , "IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here are the new rules: - iSCSI names are case-sensitive. - iSCSI names are UTF-8 encoded. - iSCSI names are compared byte-for-byte; there is no need to translate them to upper or lower case. The above will keep iSCSI implementations simpler. Now, from the user side, we don't want to see conflicts like iqn.0.com.acme.foo42 and iqn.0.com.acme.Foo42 The above are technically not the same name to an iSCSI implementation. However, it would not be in anyone's best interest for acme.com to assign two names that are identical if they were both translated to lower case. So we need a few MUSTs, or at least SHOULDs, to make this easier on anyone having to type these in: - An iSCSI name MUST NOT be generated such that if converted to lower case, it conflicts with any other iSCSI name converted to lower case. - iSCSI names SHOULD be generated to use lower case of their appropriate character set. - An iSCSI implementation MAY accept an iSCSI name that, if converted to lower case, matches another iSCSI name that it recognized. The third rule depends on the first being implemented, and gives implementations the flexibility to do case-insensitive comparisons if they so choose. What do you think? Mark Julian Satran wrote: > > John, > > Case insesitive is bad for I18N > > Julo > > "John Hufferd" on 18-07-2001 08:53:56 > > Please respond to "John Hufferd" > > To: Mark Bakke > cc: IPS > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > Mark, > You are talking about things that are entered by administrators. They will > have a lot of finger checks. I do not see why we would like to encourage > admin problems by making these things Case Sensitive. Imagine, one > administrator trying to tell another over the phone, what the name should > be used. > > I would vote for Case insensitive names. > > . > . > . > 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 > Internet address: hufferd@us.ibm.com > > Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM > > Sent by: owner-ips@ece.cmu.edu > > To: IPS > cc: > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 18 21:12:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22140 for ; Wed, 18 Jul 2001 21:12:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ILahM07394 for ips-outgoing; Wed, 18 Jul 2001 17:36:43 -0400 (EDT) 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 f6ILagg07390 for ; Wed, 18 Jul 2001 17:36:42 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7PA82>; Wed, 18 Jul 2001 17:35:06 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A5B@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FINAL London Meeting times Date: Wed, 18 Jul 2001 17:32:24 -0400 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 The London meeting slot assignment is now final. --David MONDAY, August 6, 2001 1930-2200 Evening Sessions APP fax Internet Fax WG APP imapext Internet Message Access Protocol Extension WG OPS rap Resource Allocation Protocol WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC inch Extended Incident Handling BOF SUB-IP ccamp Common Control and Measurement Plane WG TSV ips IP Storage WG TSV rmt Reliable Multicast Transport WG TUESDAY, August 7, 2001 0900-1130 Morning Sessions APP opes Open Pluggable Edge Services WG IRTF smug Secure Multicast Group OPS eos Evolution of SNMP WG OPS ngtrans Next Generation Transition WG SEC secsh Secure Shell WG SUB-IP gsmp General Switch Management Protocol WG TSV ips IP Storage WG TSV sip Session Initiation Protocol WG From owner-ips@ece.cmu.edu Wed Jul 18 21:38:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27469 for ; Wed, 18 Jul 2001 21:38:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J0N4Y18519 for ips-outgoing; Wed, 18 Jul 2001 20:23:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6J0N3g18515 for ; Wed, 18 Jul 2001 20:23:03 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id UAA14856; Wed, 18 Jul 2001 20:23:01 -0400 (EDT) Date: Wed, 18 Jul 2001 20:23:01 -0400 From: "Robert D. Russell" To: Matt Wakeley cc: ips Subject: Re: London: Call for agenda items In-Reply-To: <3B56112E.242091D1@agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Matt: The problem is that there is no consensus version 1. Most current "draft 6" implementations are really implementing "draft 6+", where the "+" comes from the many corrections, additions, deletions, etc. that appeared on the mailing list after draft 6 was posted and that were necessary to make draft 6 workable. In particular, most are using the new opcodes because the opcodes published in draft 6 were a surprise, were widely disliked, and were replaced (twice) in subsequent mailings. There is no approved document that defines version 1. The best hope for interoperabilty is to produce a stable standard draft that can gain a reasonable consensus and then finalize the process. Bob On Wed, 18 Jul 2001, Matt Wakeley wrote: > Robert, > > Your idea kills any hope of interoperability if some vendors choose to ship > products based on certain revisions of the draft - the current "0 vs 6" case > in point. > > -Matt > > "Robert D. Russell" wrote: > > > > Marjorie: > > > > True there have been new opcodes, but there have been new opcodes > > before. My point is why start changing the version number NOW > > when we haven't been doing it before? By your reasoning, we should > > be up to version 7 now, not version 2. > > A problem with changing the version numbers is that the current > > scheme by which an initiator offers versions to a target is that > > there can be no holes in the offering. If the version numbers > > change too quickly it will be a lot of work to track the > > intermediate versions. A version change should be really significant, > > ie. at the IETF level, not at the draft level. We are still at the > > draft level. > > Bob Russell > > > > On Wed, 18 Jul 2001, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: > > > > > > My personal opinion is still that draft 7 is really just > > > > a refinement and clarification of ambiguities in draft 6, and does > > > > not add any major features that justify a version change. However, ... > > > > > > Not true, there are significant changes to opcodes and some change to header > > > fields between v6 and v7 - that should *at least* be a criteria for a > > > version number change! > > > > > > Marj > > > > From owner-ips@ece.cmu.edu Wed Jul 18 21:40:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28082 for ; Wed, 18 Jul 2001 21:40:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J0aR219352 for ips-outgoing; Wed, 18 Jul 2001 20:36:27 -0400 (EDT) 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 f6J0aQg19347 for ; Wed, 18 Jul 2001 20:36:26 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0S6H4Y>; Wed, 18 Jul 2001 20:36:20 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A5F@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: FCIP -03 comments Date: Wed, 18 Jul 2001 20:32:07 -0400 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, comments from a detailed review of the -03 version of FCIP. This is sufficiently extensive that I don't expect all of them to be addressed in the -04 version that is expected in the next two days. --David -- Section 2.1 Add at least FC-PH to the list of referenced documents Given the number of FC documents referenced, a few sentences describing their contents and relationship would be useful. -- Section 2.2 I don't like the tone of the first paragraph in Section 2.2. Can this be rephrased to talk about logical division of the problem between carrying FC frames over TCP/IP (IETF) vs. integration of TCP/IP that carry FC frames into FC fabrics and fabric operation/behavior over such links (T11)? The list of requirements for correct operation of an FC entity with an FCIP entity in Annex D needs to be exhaustive from the viewpoint of the FCIP entity (i.e., everything that the FCIP entity needs MUST be listed). Having split this between an FC entity and FCIP entity, this spec needs to be clear about who does what and how they interact. If this is not done, it will not be possible to independently evolve the IETF and T11 documents. It's ok to not list everything that the FC entity must do to work with the FC fabric, and pointing to FC documents in T11 for that info is fine. In the next to last paragraph, in Section 2.2, please use the term "programming interface" rather than just "interface" -- Section 4 Open Issues Based on an offline discussion with some of the authors, please add a note here that the synchronization recovery material, including the algorithm in Annex A is known to need revision. Indicate that the QoS/diffserv wording still needs revision. -- Section 5 Reword 2) and 3) to avoid implying that every FCIP entity is connected to every other reachable FCIP entity. That need not be the case in general. In connection with 10), someone needs to take a "to do" item to write the SLP templates and procedures. See the iSCSI SLP draft for an example. Delete 12 b). If an FCIP entity is operating with an external security gateway, only the interface on the public side of the gateway is compliant with this specification. The interface between the FCIP entity and the gateway is not compliant because it is lacking required security features - the FCIP entity *includes* the security gateway in this structure. Also, please use the word "confidentiality" rather than "privacy" to avoid confusion. Item 13) is not the entire story when more than one TCP connection is being used. This needs to be expanded to explain who's responsible for what in that case. -- Section 6.3 I think this section really needs a discussion about what the combination of an FCIP entity with an FC entity linked to a pair of corresponding peer entities could be from a Fibre Channel viewpoint. This is the place to say that: - it could be an inter-switch link, mentioning B and E ports with a possible reference to FC-BB2 - it could be a node to fabric link, N port to F port, with a reference to FC-PH - it could not be a link in an Arbitrated Loop because FCIP does not support the additional primitive signals and sequences required for an Arbitrated Loop with a reference Section 6 of FC-AL and FC-AL2. -- Section 6.4 An FC Fabric to IP Network interface product SHALL contain one FCIP Entity for each IP Address assigned to the product. This looks overspecified for a couple of reasons -- it prevents multiple FCIP entities on different TCP ports at the same IP address and it appears to force implementation of an FCIP entity on an interface intended solely for management traffic. Needless to say, this is overspecified - I'm guessing that the real requirement is that an FCIP entity MUST NOT span multiple IP addresses, but more than one FCIP entity MAY share an IP address by using different TCP ports. This has some slight effects on wording elsewhere, but I fail to see the reason for forbidding two FCIP entities behind a single IP address. -- Section 6.5 Last sentence needs to explain what "coordinate flow control" means, possibly by providing a (non-normative) example, or a pointer to Section 7.4. -- Figures 4-6 Should probably have an additional figure that shows at least one FCIP Entity, FC_LEP, and FC_DE in a single diagram. -- Section 6.6 Last sentence: Data bytes arriving at the Encapsulated Frame Receiver Portal SHOULD be transmitted to the FC Transmitter Portal as described in steps 5 through 7, but this MAY NOT always be the case. In its current form this does not express a useful requirement and hence the "SHOULD" and "MAY NOT" need to be lower case. I think words are needed here to say "MUST be transmitted in the absence of errors" and note that error detection and recovery MAY result in discarding frames without errors as a consequence of an error detected in an earlier frame. -- Section 6.6.1 Please add a diagram of the whole header in addition to the protocol-specific fields. -- Section 6.6.2.1 What is being said here is correct, but needs to be reworded. Reference the TCP RFC, note that it REQUIRES in order delivery, generation of TCP checksums and checking of TCP checksums, then say that hence any traffic passed from TCP to the FC_LEP will be in order and free of errors detectable by the TCP checksum. -- Section 6.6.2.2 Bytes delivered through the Encapsulated Frame Receiver Portal that are not correctly delimited as defined by the FC Frame Encapsulation [23] SHOULD NOT be forwarded on to the FC Entity. This sounds like a "MUST NOT" rather than a "SHOULD NOT". Is it ever acceptable to deliver malformed traffic to the FC Entity? Synchronization SHALL be verified by checking the validity and positioning of any combination of the following FC Frame Encapsulation information: "any combination of" is much too weak - checking only that the timestamp fields are plausible could result in the delivery of complete garbage. Some words may be needed here about the various error checks done at the FCIP entity, FC entity, and FC frame receiver (e.g., frame CRC). Use this to state the functional requirement of what the FCIP entity MUST check as as a minimum to ensure correct operation, and then offer the others as SHOULDs or MAYs. -- Section 6.6.2.3 Changes to this section were discussed as part of the Annex E discussion. -- Section 6.6.2.4 This section will change as part of the forthcoming synchronization revisions noted above. -- Section 7.1.1, and 7.1.2 It looks like the FCIP Entities are signaling/negotiating some parameters over a newly created TCP connection; the details of how this is done and requirements for doing it need to be specified. Some of this interaction is a bit funky - if some of these parameters are passed inband over the TCP connection, the result is that one has to accept the TCP connection request in order to get the parameters to decide whether to accept the TCP connection request. That wasn't what was intended, and hence some rewording is needed. -- Section 7.2 and subsections, Section 7.3 Think very carefully about how many of these are actually involved in FCIP interoperability, and delete the ones that aren't (e.g., 7.2.5). The standards status of TCP options can change independent of TCP, hence this sort of dependency needs to be minimized. If 7.2.4 remains, some explanation and/or reference to how to implement this is needed. Move the timeout "SHOULD" in Section 7.3 to the section on timeout management and delete the rest of 7.3. -- Section 7.4 Need an example of *how* an FC Entity could reduce the rate of FC Frame arrival (non-normative). I'm concerned that the last sentence of this section could be read as a modification to TCP's specified behavior. This discussion might be better phrased in terms of buffer resources available to a TCP connection - when the FC Entity can't accept frames at their initial arrival rate, the buffer fills up and TCP's window shrinks accordingly because the advertised window is based on the size of the buffer. -- Sections 8.2 and 8.4 Delete and/or modify these in accordance with the comment that if an external security gateway is used, it is logically a part of the FCIP Entity because the interface between the FCIP implementation and the security gateway will not conform to the security requirements of this specification. --------------------------------------------------- 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 18 21:43:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28675 for ; Wed, 18 Jul 2001 21:43:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J0gsB19740 for ips-outgoing; Wed, 18 Jul 2001 20:42:54 -0400 (EDT) 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 f6J0grg19736 for ; Wed, 18 Jul 2001 20:42:53 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <3XB7PFG9>; Wed, 18 Jul 2001 20:41:17 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070A60@corpmx14.us.dg.com> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI version numbers Date: Wed, 18 Jul 2001 20:38:35 -0400 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 Let me also point out that Matt's expectation of interoperability of implementations based on Internet-Drafts is misplaced. Vendors who ship products based on I-Ds do so at their own risk - there's more than enough warning that things are subject to change in the standard Internet-Draft boilerplate. My preference would be to hold the version number at 0 until the iSCSI spec is done. This will give vendors who have shipped to Internet-Draft versions an incentive to promptly update their code. If future plugfest events need to test multiple implementation variants, they can do roughly what was done this time - temporarily define the version numbers that will distinguish the variants *for that event only*. I would suggest use of *large* numbers for this purpose to avoid this sort of confusion in the future. 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: Robert D. Russell [SMTP:rdr@mars.iol.unh.edu] > Sent: Wednesday, July 18, 2001 8:23 PM > To: Matt Wakeley > Cc: ips > Subject: Re: London: Call for agenda items > > Matt: > > The problem is that there is no consensus version 1. > Most current "draft 6" implementations are really implementing > "draft 6+", where the "+" comes from the many corrections, > additions, deletions, etc. that appeared on the mailing list after > draft 6 was posted and that were necessary to make draft 6 workable. > In particular, most are using the new opcodes > because the opcodes published in draft 6 were a surprise, were widely > disliked, and were replaced (twice) in subsequent mailings. > There is no approved document that defines version 1. > The best hope for interoperabilty is to produce a stable standard > draft that can gain a reasonable consensus and then finalize the > process. > > Bob > > On Wed, 18 Jul 2001, Matt Wakeley wrote: > > > Robert, > > > > Your idea kills any hope of interoperability if some vendors choose to > ship > > products based on certain revisions of the draft - the current "0 vs 6" > case > > in point. > > > > -Matt > > > > "Robert D. Russell" wrote: > > > > > > Marjorie: > > > > > > True there have been new opcodes, but there have been new opcodes > > > before. My point is why start changing the version number NOW > > > when we haven't been doing it before? By your reasoning, we should > > > be up to version 7 now, not version 2. > > > A problem with changing the version numbers is that the current > > > scheme by which an initiator offers versions to a target is that > > > there can be no holes in the offering. If the version numbers > > > change too quickly it will be a lot of work to track the > > > intermediate versions. A version change should be really significant, > > > ie. at the IETF level, not at the draft level. We are still at the > > > draft level. > > > Bob Russell > > > > > > On Wed, 18 Jul 2001, KRUEGER,MARJORIE (HP-Roseville,ex1) wrote: > > > > > > > > My personal opinion is still that draft 7 is really just > > > > > a refinement and clarification of ambiguities in draft 6, and does > > > > > not add any major features that justify a version change. However, > ... > > > > > > > > Not true, there are significant changes to opcodes and some change > to header > > > > fields between v6 and v7 - that should *at least* be a criteria for > a > > > > version number change! > > > > > > > > Marj > > > > > > From owner-ips@ece.cmu.edu Thu Jul 19 01:22:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14983 for ; Thu, 19 Jul 2001 01:22:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J3VHY29884 for ips-outgoing; Wed, 18 Jul 2001 23:31:17 -0400 (EDT) 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 f6J3VEg29879 for ; Wed, 18 Jul 2001 23:31:15 -0400 (EDT) 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 FAA203260 for ; Thu, 19 Jul 2001 05:31:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6J3V7b186386 for ; Thu, 19 Jul 2001 05:31:07 +0200 Importance: Normal Subject: RE: iSCSI: SNACK wording clarification To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 06:37:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 06:31:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The CmdSN is used only to enable target to get the commands in order (if they are delivered). Comman arrival is acked throug ExpCmdSN. StatsN is a different and unrelated numbering. Julo "Trang Nguyen" on 18-07-2001 18:48:58 Please respond to tnguyen@perfisans.com To: Julian Satran/Haifa/IBM@IBMIL, "Matt Wakeley" cc: "IPS Reflector ; Thu, 19 Jul 2001 03:11:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J5a1k07399 for ips-outgoing; Thu, 19 Jul 2001 01:36:01 -0400 (EDT) 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 f6J5Zxg07394 for ; Thu, 19 Jul 2001 01:35:59 -0400 (EDT) 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 HAA198968; Thu, 19 Jul 2001 07:35:53 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6J5ZqI17342; Thu, 19 Jul 2001 07:35:52 +0200 Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: Mark Bakke Cc: "John Hufferd" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 08:41:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 08:35:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sensible decision. Case insensitive makes it hard for I18N on most languages (or simpler in the one like mine that has no case :-)) . And why is the recomendation 2 necessary? (just to kill iSCSI ? :-)) Julo Mark Bakke on 19-07-2001 00:18:23 Please respond to Mark Bakke To: Julian Satran/Haifa/IBM@IBMIL cc: John Hufferd/San Jose/IBM@IBMUS, "IPS > John, > > Case insesitive is bad for I18N > > Julo > > "John Hufferd" on 18-07-2001 08:53:56 > > Please respond to "John Hufferd" > > To: Mark Bakke > cc: IPS > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > Mark, > You are talking about things that are entered by administrators. They will > have a lot of finger checks. I do not see why we would like to encourage > admin problems by making these things Case Sensitive. Imagine, one > administrator trying to tell another over the phone, what the name should > be used. > > I would vote for Case insensitive names. > > . > . > . > 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 > Internet address: hufferd@us.ibm.com > > Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM > > Sent by: owner-ips@ece.cmu.edu > > To: IPS > cc: > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 19 05:23:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06190 for ; Thu, 19 Jul 2001 05:23:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J82Bq15331 for ips-outgoing; Thu, 19 Jul 2001 04:02:11 -0400 (EDT) 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 f6J829g15323 for ; Thu, 19 Jul 2001 04:02:09 -0400 (EDT) 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 DAA76704; Thu, 19 Jul 2001 03:54:07 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6J8289247346; Thu, 19 Jul 2001 02:02:08 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI Naming: iqn format specification To: Mark Bakke Cc: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 19 Jul 2001 00:38:14 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/19/2001 02:02:07 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Every one can be their own authority with out have to work with some super entity to get a simple number that is unique when combined with the reverse DNS. Dates are ideal for that. Simple, straight forward and really no problem. I vote for Date qualifications instead of Enterprise numbers. Perhaps a DDDYY or DDDYYY type format. . . . 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 Internet address: hufferd@us.ibm.com Mark Bakke @ece.cmu.edu on 07/18/2001 01:31:20 PM Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI Naming: iqn format specification To get the draft out, I am going to require the enterprise number. A second possibility exists; the reversed DNS name could be qualified by the date on which the iSCSI name was generated. Since two entities cannot own the same DNS name at the same time, the separate naming authorities would not generate these using the same dates. Anyone want dates instead of enterprise numbers? -- Mark Mark Bakke wrote: > > Works for me. Anyone wanting to do their own naming schemes would > fall into three categories: > > 1. iSCSI hardware and software manufacturers > > Most iSCSI names would be generated by these folks; they would > make them up either statically (based on a chassis number or > something) or dynamically (based on user configuration, but not > explicitly configured by the user), or a combination of the two. > > These have their own enterprise # anyway. > > 2. Service-minded end-users that want control over naming. > > These are sophisticated enough to want an enterprise number; I > anticipate that only folks such as SSPs would want to do this > sort of thing; most will leave the manufacturer-assigned names > along. > > 3. Researchers building iSCSI experimental stuff > > These would not be concerned with being "iSCSI-compliant"; they > would simply want to be reasonably sure that they won't conflict > with other equipment in a lab environment. These folks could just > use enterprise # 0, along with their reversed domain name, and be > reasonably assured of this. > > We don't have to mention #3 in the spec, if that's a problem, since > this decision of iSCSI-compliance would be up to the implementor > > -- > Mark > > Black_David@emc.com wrote: > > > > That would work - REQUIRE the enterprise > > number and possibly RECOMMEND that it be > > followed by the reverse DNS name for > > human-friendliness. --David > > > > > -----Original Message----- > > > From: Mark Bakke [SMTP:mbakke@cisco.com] > > > Sent: Monday, July 16, 2001 4:28 PM > > > To: Black_David@emc.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI Naming: iqn format specification > > > > > > So, should we require the enterprise number? It's a whole > > > lot cheaper than getting an OUI. > > > > > > Black_David@emc.com wrote: > > > > > > > > A couple of comments on this: > > > > > > > > > Anyone wanting to ensure that their names > > > > > will never conflict with someone else's can add the enterprise number. > > > > > > > > Nice try, but not good enough. If this course is followed the > > > > enterprise number has to be REQUIRED independent of the whims > > > > of those who are creating the names so that this conflict can't > > > > happen, period. > > > > > > > > > > Finally, we should use the URI name and format for the namespace > > > > > > where a URI format exists. This is simply for consistency. > > > > > > > > > > > > For example: > > > > > > backwardsdns:au.edu.example.faculty > > > > > > oid:1.32.43.5.3.2.43.2.2.34 > > > > > > oui:2e319c65786e > > > > > > > > > > I had suggested this before, in my draft on iSCSI URNs; the IESG > > > > > completely shot this down, and I'm still not sure why. Anyway, > > > > > I don't have the energy to push the URN/URI thing any further. > > > > > > > > What the IESG shot down was the notion of WWUI as a new URN > > > > namespace into which other namespaces could be glued. Anyone > > > > whose reaction to this is "but it's functionally equivalent", has missed > > > > the point, and should be thankful that they don't spend all their time > > > > on naming issues ;-). The issues here are syntax, intent, and > > > > control; the IESG is not prepared to allow the IPS WG to define > > > > a new global namespace into which the IPS WG could decide > > > > to glue in other namespaces at its discretion. AFAIK, the IESG > > > > would be interested in things like an OUI URN definition (anyone > > > > want to write a draft? - it should be good for at least 15 minutes of > > > > fame). > > > > > > > > --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 > > > > --------------------------------------------------- > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 19 05:24:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06427 for ; Thu, 19 Jul 2001 05:24:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J82Ab15327 for ips-outgoing; Thu, 19 Jul 2001 04:02:10 -0400 (EDT) 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 f6J828g15318 for ; Thu, 19 Jul 2001 04:02:08 -0400 (EDT) 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 DAA76702 for ; Thu, 19 Jul 2001 03:54:05 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6J8269208744 for ; Thu, 19 Jul 2001 02:02:06 -0600 Importance: Normal Subject: RE: London: Call for agenda items To: "Julian Satran" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 18 Jul 2001 23:53:49 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/19/2001 02:02:06 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Based on what we see going on at UNH I think that each major version, should have a different version number in the protocol. We will have many more of these, lets not make it hard for the participants. . . . 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 Internet address: hufferd@us.ibm.com Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 07/18/2001 07:08:23 AM Sent by: owner-ips@ece.cmu.edu To: "Robert D. Russell" cc: "ips" Subject: RE: London: Call for agenda items Robert, In fact most of my mail requested us to stay at 02 to differentiate from 06. But I am still open (until tomorrow!). Julo "Robert D. Russell" on 18-07-2001 16:48:38 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: London: Call for agenda items Julian: Hopefully the version number in this new rev will go back to 1, not 2 -- your call for comments on this did not get many comments (at least not on the mailing list), but those that did comment seemed mostly to favor staying at version 1 during the draft stage. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 18 Jul 2001, Julian Satran wrote: > rev. 07 will be issued this week. Julo > > "Douglas Otis" on 18-07-2001 02:37:36 > > Please respond to "Douglas Otis" > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: RE: London: Call for agenda items > > > > > David, > > Unless I missed something, iSCSI is still at the same revision as the last > interim meeting. Will there be an updated draft presented prior to the > meeting? It is difficult to understand the consensus that has be reached > just upon examining the reflector. Is there a document that reflects these > current changes? > > Doug > > > We're starting to assemble the London agenda. iSCSI > > draft authors, please coordinate your request for time > > with John Hufferd (iSCSI Technical Coordinator, > > hufferd@us.ibm.com). Anyone else wanting agenda time > > should send the request to me, including the purpose > > of the time and the associated Internet-Draft (if any). > > > > A couple of reminders: > > - London is primarily for iSCSI-related topics. FCIP and > > iFCP topics will be take up in the Orange County, > > CA interim meeting due to the conflict between > > the London IETF meetings and the T11 meetings. > > - Agenda time is to work on open issues. ASSUME THAT > > ATTENDEES HAVE READ THE DRAFTS! Time should not > > be used for presentations covering draft contents. > > > > 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 > > --------------------------------------------------- > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 19 05:26:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06901 for ; Thu, 19 Jul 2001 05:26:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6J82EC15335 for ips-outgoing; Thu, 19 Jul 2001 04:02:14 -0400 (EDT) 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 f6J82Ag15330 for ; Thu, 19 Jul 2001 04:02:10 -0400 (EDT) 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 DAA09660; Thu, 19 Jul 2001 03:54:08 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6J8299239710; Thu, 19 Jul 2001 02:02:09 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: Mark Bakke Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 19 Jul 2001 00:40:50 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/19/2001 02:02:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I can live with this. . . . 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 Internet address: hufferd@us.ibm.com Mark Bakke @cisco.com on 07/18/2001 02:18:23 PM Sent by: mbakke@cisco.com To: Julian Satran/Haifa/IBM@IBMIL cc: John Hufferd/San Jose/IBM@IBMUS, "IPS > John, > > Case insesitive is bad for I18N > > Julo > > "John Hufferd" on 18-07-2001 08:53:56 > > Please respond to "John Hufferd" > > To: Mark Bakke > cc: IPS > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > Mark, > You are talking about things that are entered by administrators. They will > have a lot of finger checks. I do not see why we would like to encourage > admin problems by making these things Case Sensitive. Imagine, one > administrator trying to tell another over the phone, what the name should > be used. > > I would vote for Case insensitive names. > > . > . > . > 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 > Internet address: hufferd@us.ibm.com > > Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM > > Sent by: owner-ips@ece.cmu.edu > > To: IPS > cc: > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 19 07:35:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03225 for ; Thu, 19 Jul 2001 07:35:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JALZd04752 for ips-outgoing; Thu, 19 Jul 2001 06:21:35 -0400 (EDT) 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 f6JALXg04746 for ; Thu, 19 Jul 2001 06:21:33 -0400 (EDT) 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 MAA41844 for ; Thu, 19 Jul 2001 12:21:26 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JALPc105498 for ; Thu, 19 Jul 2001 12:21:26 +0200 Importance: Normal Subject: Re: The iSCSI Plugfest - update for Wednesday To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 13:27:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 13:21:25 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Status and Data where (and) are part of the standard. They are important to reduce the protocol overhead and performance of the software implementation is substantially reduced without it. It is clearly stated in several places (1.2, the Data-In PDU) etc. and has never changed (from version 0). As for the plugfest - congratulations - great work. Julo Please respond to "Barry Reinhold" To: "ISCSI" cc: Subject: The iSCSI Plugfest - update for Wednesday The plugfest process has settled down to the detailed process of isolating implementation bugs. A significant percentage of the implementors are now able to connect and perform I/O operations - though this is often achieved by first compiling with -D "company Name" switches to handle the different issues that have already been discovered. New Issues: A detailed posting of the issues to date will (or has) be done by Bob Russell. In brief only one additional standards issues came to light that impacted interoperability in the days testing: 1. The current wording of the standard appears to allow for the transmission of IO data in response frames. This is actually being done in a few implementations. Although this was perhaps a vision at the start of the iSCSI effort there is little support for this. Most implementors were not prepared to handle this. Progress: Test progressed to round 17 and it appears that it is highly likely that developers will get a chance to test against all other parties by the end of the week. Two vendors were able to establish a multi connection session, getting through the login process and the start of IO. Two other vendors established an iSCSI session with header digests, completing the security phase of the login process. Some generic problem areas that come up: 0 Length data frames Target initiated text negotiation Response information in data PDUs. SCSI compatibility issues There was a UNH iSCSI consortium meeting at the end of the day 1. Overview of UNH iSCSI consortium 2. Discussion on dates/time for next plug fest 3. Election of steering team People flowing out at 7:00 -- sign that things are pretty good. 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 Thu Jul 19 08:35:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14200 for ; Thu, 19 Jul 2001 08:35:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JBC9B07460 for ips-outgoing; Thu, 19 Jul 2001 07:12:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JBBeg07446 for ; Thu, 19 Jul 2001 07:11:40 -0400 (EDT) Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id KAA210124 for ; Thu, 19 Jul 2001 10:38:12 +0100 Received: from d06hubm3.portsmouth.uk.ibm.com (d06hubm3_tr0 [9.180.32.65]) by d06relay02.portsmouth.uk.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6J9kkG101268 for ; Thu, 19 Jul 2001 10:46:47 +0100 Importance: Normal Subject: Re: iSCSI Plugfest at UNH To: "Robert D. Russell" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 12:37:23 +0300 X-MIMETrack: Serialize by Router on D06HUBM3/06/H/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 10:46:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Most of those have already been taken care of - so here are some quick comments only. And thanks all for the excellent work. Julo "Robert D. Russell" on 19-07-2001 01:46:46 Please respond to "Robert D. Russell" To: ips@ece.cmu.edu cc: Subject: iSCSI Plugfest at UNH From: Bob Russell rdr@iol.unh.edu Bill Lynn bill_lynn@corp.adaptec.com Kalman Meth meth@il.ibm.com Barry Reinhold barry.reinhold@trebia.com Points that arose during the UNH Plugfest (July 16-20, 2001) where the Standard is unclear. (not in any particular order) -------------------------------------------------------------------------------- 1. Exactly what should happen if operational parameters are sent by the initiator during the security phase of login? In section 4.2 the standard says: "-The iSCSI parameter negotiation (non-security parameters) SHOULD start only after security is established. This should be performed using text commands." and: "When establishing the security context, any operational parameters sent before establishing a secure context MAY be ignored by both the target and the initiator." There is a problem with the meaning of "ignore" -- should the target: 1. not respond to these operational keys at all, or 2. respond with key=reject, or 3. respond with a valid value and then just not use these values. In this case, how does the initiator know whether or not the target is ignoring these parameters or not? A final note: The standard seems to allow the initiator to send operational parameters when establishing the security context, get back a valid value from the target, and then ignore the entire negotiation anyway. Is this legal? In this case, how does the target know that the initiator is ignoring these parameters? +++ It is standard practice (and legal) in most protocols to reset the operational parameters to previous values at the end of the security phase negotiation if the channel is becoming a secure channel WE have two options: a) assume that this happens at every SecurityContextComplete b) say explicitly that it happened - e.g., the target or initiator decide that the channel is now more secure than before and say explicitly something like OpParmReset=yes I will assume that is b that most of you want and I will say so in 7 unless I hear otherwise TODAY: here is the text: 01 OpParmReset Use: IO Who can send: Initiator and Target OpParmReset= OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before login. Either the initiator or target may choose to do so but only after and only if a SecurityContextComplete handshake is completed on the connection. The resetting should involve only parameters that where set during login on the connection in which the OpParmReset is issued. Please note that since either initiator or target may request this behavior there is no need to reply. and 4.3 reads: 1.1 Operational Parameter Negotiation During the Login Phase Operational parameter negotiation during the login MAY be done: - starting with the Login command if the initiator does not offer any security/ integrity option - starting immediately after the security/integrity negotiation if the initiator and target perform such a negotiation - starting immediately after the Login response with Final bit 0 if the initiator does offer security/integrity options but the target chose none. An operational parameter negotiation on a connection SHOULD not start before the security/integrity negotiation if such a negotiation exists. Operational parameters negotiated inadvertently before the security/integrity negotiation MAY be reset after the security/integrity negotiation at the explicit request of the initiator or target. ++++ ++++ -------------------------------------------------------------------------------- 2. In section 2.8.3 the standard says "Many key=value pairs can be included in the Text block by separating them with null (0x00) delimiters." This implies that the last (or only) key=value pair is NOT terminated by a null delimiter. However, all C programs naturally treat key=value pairs as C strings which are always terminated by a null (0x00) delimiter. Therefore, to avoid a source of errors and to simplify implementations, please change the standard to require all key=value pairs MUST be TERMINATED by null (0x00) delimiters. NOTE: if this change is NOT made, then the standard needs to address the issue of what to do when a receiver receives a set of key=value pairs that is terminated by a final NULL. Should this be treated as a format error, or does that final NULL separate the last key from an empty key which the receiver should just ignore? The group consensus was unanimous that all key=value pairs MUST be TERMINATED by null (0x00) delimiters. +++ the change is made +++ -------------------------------------------------------------------------------- 3. Many key parameters can take only "yes" or "no" as valid values. However, section 1.2.4 "Text Mode Negotiation" discusses only "list" negotiation and "numerical" negotiation -- there is no discussion of "binary" or "boolean" negotiation. However, the examples never show the use of a list to negotiate any of these parameters. There are then two interpretations of how to negotiate these parameters: (a) Use the existing "list" negotiation mechanism for parameters that can take only "yes" or "no" as valid values. (1) If an initiator has a key named xxx for which it would prefer a "yes" setting, but can also operate correctly with a "no" setting, then the initiator must offer "xxx=yes,no" to the target and then the target must respond with "xxx=yes" if it wants to use the feature, "xxx=no" if it does not use the feature, "xxx=reject" if it does not support the feature, or "xxx=NotUnderstood" if it does not understand the key name xxx. (2) If an initiator has a key named xxx for which it can only utilize a "yes" setting, it offers the target "xxx=yes". The target must respond with "xxx=yes" if it can also use this feature, "xxx=reject" if it either cannot use or does not support this feature, or "xxx=NotUnderstood" if it does not understand the key name xxx. The reply "xxx=no" is explicitly disallowed. This is a very simple way to do this negotiation, and does not require any new mechanism in either the standard or an implementation that already does list negotiation. However, the standard should explicitly show an example similar to one of those just shown to make it clear that this is the way to do it. (b) Invent a new "binary" or "boolean" negotiation. This would require new wording in the standard and probably new code in addition to the "list" and "numeric" negotiation implementation code. In particular, with this method there is no obvious way for the initiator to indicate to the target that it can use either "yes" or "no" but would prefer "no", for example, because sending the string "xxx=no" could be interpreted either as "only no" or "no prefered but yes is also ok". This gets complicated by the default key values. If the required default is "yes", then offering "no" would appear to mean "no is prefered bu yes is also ok". If the required default is "no", then offering "no" would not appear to be necessary, (but is currently not explicitly prohibited and may be useful for implementations that simply send all keys) and would appear to mean "only no". The group consensus seemed to be that solution (a) is by far the simplest and therefore is prefered. ++++ As an engineer I though always that booleans are numbers (even if expressed as yes and no). As such I assumed they are included in 1.2.4 under the numeric umbrela. I've added some wording about this to make unambiguous even for those that assumed yes and no to be only the English cahracter strings yes and no and negotiated as a list The negotiated values are determined by a function that is specific to each key (as with the rest of the numerics) usually AND or OR (the text for the keys is hopefully specific enough). I think also that boolean algebra is not a good subject for consensus. The rules have stated a long time ago. ++++ -------------------------------------------------------------------------------- 4. It is not clear from the standard whether or not the value in the CmdSN field of an initial login command for a session (i.e., TSID=0) is "consumed" by its appearance in the login command or not. For example, suppose an intiator sends a login command with TSID=0 and CmdSN=123 and then waits for a response from the target. Should the Login Response from the target contain ExpCmdSN=123 or ExpCmdSN=124? Similarly, should the next command sent by the initiator after this login contain CmdSN=123 or CmdSN=124? The consensus seemed to be that ExpCmdSN=124 in the Login Response and CmdS124 in the next command, but the standard needs to make it explicit, perhaps with an example such as the one just given. This is being dealt with in a mailing list thread. +++ it is worded clear and an example is included +++ -------------------------------------------------------------------------------- 5. Analagous with point 4, it is not clear how InitStatSN is handled by the login phase. If a login response contains a value of 123 in its InitStatSN field, is the value of the next response from the same target 123 or 124? For consistency with the handling of CmdSN it would appear that 124 is correct. However, this situation may be different because the field is called "InitStatSN", not "StatSN" as it is in other responses. At the plugfest the consensus was to use the value 124 for now, but that 123 MIGHT be better long term. A second issue is the fact that there can be two login responses in response to a login (the "login partial response" and the "login final response"), each of which carries an InitStatSN field. It is not clear if the value of the InitStatSN field in a login final response needs to be part of the sequence established by the InitStatSN field in a preceding login partial response, or whether the login final response can restart the sequence to an arbitrary value supplied in its InitStatSN field. The standard should make this explicit. At the plugfest the consensus was that the final response CAN restart the sequence. This is being dealt with in a mailing list thread. +++ changed to statsn and made numbering uniform from login +++ -------------------------------------------------------------------------------- 6. During text mode negotiation, if a format error occurs, what is the proper response? Section 6.1 "Format Errors" does not handle all cases. (a) During login, suppose the initiator offers a list and the target responds with a value that is not in the list (and is not "reject" or "Not Understood"). Is the initiator required to close the connection or can it just internally recover from the error (perhaps reporting the error through the "appropriate service response") and continue with the login? +++ the initiator is free as it sees fit - the initiator is the master of this phase It can drop or goon as it sees fit. I would suggest drop the connection but why should we specify this behavior+++ (b) During full-feature phase, suppose the initiator sends a text command that offers a list and the target responds with a value that is not in the list (and is not "reject" or "NotUnderstood"). Section 7.3 deals only with the situation when there is an outstanding task related to the PDU, but in this case there is no outstanding task. Therefore, is the proper response to just report the error through an appropriate service response and then ignore it? +++ Txt commands have an associated task (ITT) and are covered by 7.3 +++ -------------------------------------------------------------------------------- 8. The last example in Appendix A "iSCSI Security and Integrity" illustrates a special case that should be elimiated. The last sentence of this example says: "Note that no SecurityContextComplete=yes is required since no security mechanism was chosen." But it would be simpler if the exchange of "SecurityContextComplete=yes" keys were required in this case. The reason they should be required is the following: Appendix B. starts by saying that "the parameters (keys) negotiated for security are: - Digests (HeaderDigest, DataDigest) - Authentication method (AuthMethod)" Thus as soon as the Initiator offers either the HeaderDigest or the DataDigest key, the security negotiation phase has been entered. Section 4.2 "Security and Integrity Negotiation" clearly indicates that the security sub-phase ends only when both sides have correctly executed the "SecurityContextComplete=yes" handshake. There is NO qualification in section 4.2 about the outcome of the negotiation -- i.e., one would reasonably conclude that selecting no digests and no authorization still requires the handshake, because the final selections were acheived through negotiation, and the handshake marks the end of the security negotiation subphase. The phrase in the standard that makes this example "legal" is in section 4.3, which says: "Operational parameter negotiation during the login MAY be done: . . . - starting immediately after the Login response with Final bit 0 if the initiator does offer security/integrity options but the target chose none." This clause overrides the rules of section 4.2 with a special case. Why bother with this special case? It complicates the logic in implementations, requires extra wording in the standard, and appears to offer no benefit. If it stays, there should be some indication in section 4.2 about it, or better yet, combine these sections so all this information is together in one place. As it is now, this is an error trap for implementors of both targets and initiators. +++ I will add to 4.2: The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item (even if it is not selected). and fix the example to: In the next example, the initiator does offer security/integrity parameters on the Login PDU, but the target does not choose any (i.e., chooses the "none" values): I-> Login InitiatorName=iqn.com.os.hostid.77 TargetName=iqn.com.acme.diskarray.sn.88 HeaderDigest=crc-32C,none DataDigest=crc-32C,none AuthMethod:KRB5,SRP,none T-> Login-PR, HeaderDigest=none, DataDigest=none, AuthMethod=none I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes I-> Text ... iSCSI parameters T-> Text ... iSCSI parameters And at the end: I-> Text optional iSCSI parameters F bit set to 1 T-> Login "login accept" TargetName=iqn.com.acme.diskarray.sn.88 Note that SecurityContextComplete=yes is required although no security mechanism was chosen. ++++ -------------------------------------------------------------------------------- 9. the SCSI Command (section 2.3) contains R and W bits and an "Expected Data Transfer Length". The standard says in section 2.3.1: "b6 (R) set to 1 when input data is expected b5 (W) set to 1 when output data is expected" and in section 2.3.5: "the Expected Data Transfer Length field states the number of bytes of data involved in this SCSI operation." It then goes on to describe 2 cases: - W=1 with R=0, - W=0 with R=1. The problem is that some SCSI commands involve no data transfer (Test Unit Ready is an example). So in this case, the Expected Data Transfer Length field is set to 0. How should the R and W bits be set? - Should they both be set to 0? - are they "don't care" bits so that their value can be anything? (In the Test Unit Ready example, some implementations will set the R bit because the SCSI implementation interfacing with the iSCSI code uses a single bit to differentiate between read and write commands, and considers this a read command). The standard should make this explicit. +++ there is already some wording for it +++ -------------------------------------------------------------------------------- 10.Another problem related to setting the F bit on SCSI commands. Section 2.3 says: "b7 (F) set to 1 when no unsolicited SCSI Data-Out PDUs follow this PDU. For a write, if Expected Data Transfer Length is larger than the Length the target may solicit additional data through R2T." This does not explicitly say what happens on a read or on a command other than a write (point 9 above) or on a write with an expected data transfer length of 0. These commands do not allow unsolicited SCSI Data-Out PDUs to follow them, so one could infer that the F bit should be set to 1. However, the present wording can also be interpreted that because unsolicited SCSI Data-Out PDUs are not allowed to follow these commands, this explanation does not apply to them. The standard should explicitly state what happens in the case of these commands, rather than leave it up to an implication. +++ as above +++ -------------------------------------------------------------------------------- 11.In section 1.2.3 iSCSI Login there is the paragraph: "The login PDU includes a session ID that is composed of an initiator part ISID and a target part TSID. For a new session, the TSID is null. As part of the response, the target generates a TSID. >> Session specific parameters can be specified only for the first login of a >> session (TSID null) (e.g., the maximum number of connections that can >> be used for this session). Connection specific parameters, if any, >> can be specified for any login. Thus, a session is operational once it has at least one connection." The wording of the 2 sentences indicated by ">>" needs to be changed to explicitly indicate login phase, since as now worded in could be literally interpreted to mean login command only. Proposed rewording for those sentences: "Session specific parameters can be specified only during the login phase begun by a login command containing a null TSID (e.g., the maximum number of connections that can be used for this session). Connection specific parameters, if any, can be specified during the login phase begun by any login command. +++ OK (that is from the plugfest or personal?)+++ -------------------------------------------------------------------------------- 12.If unsolicited data is negotiated, it appears that it still does not have to be used. In practice this can lead to performance inefficiencies. Consider the following: - Unsolicited data has been negotiated to YES but immediate data is NO (although a problem still exists even if this is YES). - The initiator sends a SCSI command with F=0, W=1 and a large Expected Transfer Length field (greater than FirstBurstSize). - When the target receives this command, it knows that unsolicited data follows (because F=0), but does NOT know how much (there is a maximum determined by the negotiated FirstBurstSize, but there is no requirement that the initiator actually send this much). Therefore, the target cannot at this time send out an R2T to get the "rest" of the data -- it must wait to receive data PDUs until it gets the F=1 set on one of these data PDUs, and then compute the amount of data to ask for in the R2T. This may introduce needless delay. To avoid this situation, the standard should either: - require that when unsolicited data is to be sent, that the amount be min(Expected Transfer Length, FirstBurstSize), - alternatively, provide a field in the SCSI command that allows the initiator to indicate how much unsolicited data follows. +++ Should we really? A good driver will do what it can to optimize its use of resources while getting maximum performance. IMHO a warning to implementers will be enough and I will try to put it in.++++ -------------------------------------------------------------------------------- 13.Some keys are dependent on other keys. For example, the keys that determine the actual marker intervals (RFMarkInt, SFMarkInt) have meaning only if markers are in fact being used, as determined by the FMarker key. Typically an initiator will offer these three keys in the same message. If the target responds with FMarker=no, does it need to respond to the RFMarkInt and SFMarkInt keys, or can it just omit those from the response, since whatever values they contain will be meaningless anyway? +++ A rule might be required for the general case and I will try to specify one. However this specific example has no real dependencies to worry about. You may end up with some useless values or you may drop them if you are not supporting FMarker +++ -------------------------------------------------------------------------------- 14.The login phase involves many combinations and permutations that need to be clarified through a state diagram incorporated into the standard. One example is the situation that arises when an initiator sends a login command with F=1 and operational parameters but no security parameters (because the initiator does not want to utilize any security). The target, however, wishes to use security. There appear to be several valid responses the target can give: (a) It can reply with a login final response, F=1, Reject Code of 201 (Authentication failed) and then disconnect. (b) It can reply with a login partial response, F=0, status code 1 (if the login included the ITN) or 2 (if login did not include ITN) and offer its own security parameters. The consensus seems to be that login in its current form is too complex and needs to be simplified considerably. One possibility would be to standardize one or a small number of simple, "fast-path" logins that involve no (or very limited) negotiation and that together would cover the majority of situations. +++ A state diagram is a powerful representation for a small state space it is of no value in space that is large. You are in fact talking about a very limited state diagram and we will look at a way of specifying it. +++ -------------------------------------------------------------------------------- 15.The issue of case sensitivity in names arose, and is being dealt with by a mailing list thread. There also seems to be cases where the Naming and Discovery document is in conflict with the iSCSI Standard. +++ fixed +++ -------------------------------------------------------------------------------- 16.The issue of using a target name of "iscsi" for both discovery sessions and "simple" devices arose, and is being dealt with by a mailing list thread and new text in draft 6-98, which was not available at the time of the plugfest. -------------------------------------------------------------------------------- 17.Can the option "none" be offered as the first element in a key list if that is in fact the prefered option? The present wording in section 1.2.4 says nothing about where in the list it can be offered, so by implication it can be anywhere. However, the standard should be explicit on this point, since all examples (and apparently some earlier drafts required) indicate "none" as the last option offered. +++ 1.2.4 reads: During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. In "list" negotiation, the offering party sends a list of values for a key in its order of preference. What do we have add. I assume that if we add more text the amount of overlooked text will only increase +++ -------------------------------------------------------------------------------- 18.The login process is incredibly difficult to understand from the current standard. There are three major obstacles: (1) The information is spread out in at least 5 major sections of the document (section 1.2.3, section 2.3 and 2.4, section 4, Appendix A, and Appendix D.) (2) There is no state diagram to bring all this information together. (3) It is too complex in its current form. -------------------------------------------------------------------------------- 19.In Appendix A the Standard defines the crc-32C generator polynomial to be used by iSCSI but gives no example of its use. On the mailing list several people worked out an example with actual data and gave the actual result of the algorithm. Also on the mailing list several people contributed code to perform this computation. This information (the detailed worked out example and the code) should be made part of the standard in order to eliminate any sources of confusion and to allow implementors to check their own implementations against a reference. +++ added an example ++ -------------------------------------------------------------------------------- 20.This is just an observation -- the iSCSI response sent by a target contains a Data Segment Length field and requires the SCSI response to carry sense and response data in the PDU itself. Any I/O data produced by the SCSI command itself should be carried in a separate Data-In command, not in the iSCSI response. This should be made explicit in the standard, especially because in earlier drafts it was apparently possible to do this. The group at the plugfest unanimously agrees that SCSI I/O data not be allowed in the iSCSI response, but would just like it to be stated explicitly in the standard. +++ even in the current draft it is possible The last data PDU carries status BUT ONLY IF STATUS IS GOOD. Moreover 1.2 reads For performance reasons, iSCSI allows a "phase-collapse". A command and its associated data may be shipped together from initiator to target and data and responses may be shipped together from targets. +++ -------------------------------------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 19 10:20:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10368 for ; Thu, 19 Jul 2001 10:20:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JCS0k11847 for ips-outgoing; Thu, 19 Jul 2001 08:28:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JCRwg11842 for ; Thu, 19 Jul 2001 08:27:58 -0400 (EDT) Received: from breinhold ([24.128.216.253]) by chmls06.mediaone.net (8.11.1/8.11.1) with SMTP id f6JCRog23148; Thu, 19 Jul 2001 08:27:50 -0400 (EDT) From: "Barry Reinhold" To: "Julian Satran" , Subject: RE: The iSCSI Plugfest - update for Wednesday Date: Thu, 19 Jul 2001 08:23:47 -0400 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.00.2919.6700 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Am I to understand from this that iSCSI intends to support both (1) sending of status information in iSCSI data PDUs and also sending of data in iSCSI response PDUS? >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Thursday, July 19, 2001 6:27 AM >To: ips@ece.cmu.edu >Subject: Re: The iSCSI Plugfest - update for Wednesday > > > >Status and Data where (and) are part of the standard. >They are important to reduce the protocol overhead and performance of the >software implementation >is substantially reduced without it. > >It is clearly stated in several places (1.2, the Data-In PDU) etc. and has >never changed (from version 0). > >As for the plugfest - congratulations - great work. > >Julo > > > > >Please respond to "Barry Reinhold" > >To: "ISCSI" >cc: >Subject: The iSCSI Plugfest - update for Wednesday > > > > >The plugfest process has settled down to the detailed process of isolating >implementation bugs. A significant percentage of the implementors are now >able to connect and perform I/O operations - though this is often achieved >by first compiling with -D "company Name" switches to handle the different >issues that have already been discovered. > >New Issues: A detailed posting of the issues to date will (or has) be done >by Bob Russell. In brief only one additional standards issues came to >light >that impacted interoperability in the days testing: > >1. The current wording of the standard appears to allow for the >transmission >of IO data in response frames. This is actually being done in a few >implementations. Although this was perhaps a vision at the start of the >iSCSI effort there is little support for this. Most implementors were not >prepared to handle this. > >Progress: > >Test progressed to round 17 and it appears that it is highly likely that >developers will get a chance to test against all other parties by the end >of >the week. > >Two vendors were able to establish a multi connection session, getting >through the login process and the start of IO. > >Two other vendors established an iSCSI session with header digests, >completing the security phase of the login process. > >Some generic problem areas that come up: > >0 Length data frames >Target initiated text negotiation >Response information in data PDUs. >SCSI compatibility issues > >There was a UNH iSCSI consortium meeting at the end of the day > >1. Overview of UNH iSCSI consortium >2. Discussion on dates/time for next plug fest >3. Election of steering team > >People flowing out at 7:00 -- sign that things are pretty good. > > > >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 Thu Jul 19 12:17:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04889 for ; Thu, 19 Jul 2001 12:17:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JElFe21664 for ips-outgoing; Thu, 19 Jul 2001 10:47:15 -0400 (EDT) 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 f6JElEg21660 for ; Thu, 19 Jul 2001 10:47:14 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA10025; Thu, 19 Jul 2001 10:47:06 -0400 (EDT) Message-ID: <3B56F1A5.FD741ADA@cisco.com> Date: Thu, 19 Jul 2001 09:41:41 -0500 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: Julian Satran CC: John Hufferd , ips@ece.cmu.edu Subject: Re: iSCSI: Case-sensitivity in iSCSI names 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 Satran wrote: > > Sensible decision. Case insensitive makes it hard for I18N on most > languages (or simpler in the one > like mine that has no case :-)) . And why is the recomendation 2 necessary? > (just to kill iSCSI ? :-)) Sorry about that, I know you like "iSCSI" better than "iscsi". I wasn't really thinking about the default target (which we may have removed the need for). The second recommendation was only what I felt would be a best practise for those who are generating iSCSI names. If (even case-sensitive) names are generated such that, if they were all converted to the same case, some of them would match, this would only cause confusion. I was simply pointing out that such schemes ought to be avoided. BTW, the lower-case thing was only a SHOULD, so you can still use "iSCSI". :-) Anyway, I think that this will work fairly well. Mark > > Julo > > Mark Bakke on 19-07-2001 00:18:23 > > Please respond to Mark Bakke > > To: Julian Satran/Haifa/IBM@IBMIL > cc: John Hufferd/San Jose/IBM@IBMUS, "IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > Here are the new rules: > > - iSCSI names are case-sensitive. > - iSCSI names are UTF-8 encoded. > - iSCSI names are compared byte-for-byte; there is no need > to translate them to upper or lower case. > > The above will keep iSCSI implementations simpler. > > Now, from the user side, we don't want to see conflicts like > > iqn.0.com.acme.foo42 > > and > > iqn.0.com.acme.Foo42 > > The above are technically not the same name to an iSCSI > implementation. > > However, it would not be in anyone's best interest for > acme.com to assign two names that are identical if they > were both translated to lower case. > > So we need a few MUSTs, or at least SHOULDs, to make this > easier on anyone having to type these in: > > - An iSCSI name MUST NOT be generated such that if converted > to lower case, it conflicts with any other iSCSI name > converted to lower case. > > - iSCSI names SHOULD be generated to use lower case of their > appropriate character set. > > - An iSCSI implementation MAY accept an iSCSI name that, if > converted to lower case, matches another iSCSI name that it > recognized. > > The third rule depends on the first being implemented, and > gives implementations the flexibility to do case-insensitive > comparisons if they so choose. > > What do you think? > > Mark > > Julian Satran wrote: > > > > John, > > > > Case insesitive is bad for I18N > > > > Julo > > > > "John Hufferd" on 18-07-2001 08:53:56 > > > > Please respond to "John Hufferd" > > > > To: Mark Bakke > > cc: IPS > > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > > > Mark, > > You are talking about things that are entered by administrators. They > will > > have a lot of finger checks. I do not see why we would like to encourage > > admin problems by making these things Case Sensitive. Imagine, one > > administrator trying to tell another over the phone, what the name should > > be used. > > > > I would vote for Case insensitive names. > > > > . > > . > > . > > 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 > > Internet address: hufferd@us.ibm.com > > > > Mark Bakke @ece.cmu.edu on 07/17/2001 01:28:52 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: IPS > > cc: > > Subject: iSCSI: Case-sensitivity in iSCSI names > > > > We are attempting to wrap up all of the issues surrounding > > the creation and comparison of iSCSI initiator and target > > names. One of these is whether the names are case-sensitive. > > > > The last naming & discovery draft stated that the names are > > case-insensitive; this was to allow better transcribability > > in cases where names were communicated outside the automated > > discovery processes. > > > > This comes at some expense, particularly since these names > > are defined to allow UTF-8 encoding of international character > > sets. Initiators and targets would have to include code to > > compare these sets. > > > > To simplify implementation and interoperability, it has been > > recommended that we make iSCSI names case-sensitive instead. > > > > I am fine with doing this, and I think that we could even > > get some of the usability back by adding these rules: > > > > - iSCSI names MUST be case-sensitive, and compared strictly > > byte-for-byte. > > > > - iSCSI names SHOULD be generated in a case-insensitive > > manner. > > > > I'm not sure how to properly word the latter, but the intent > > is that someone generating the names would not produce both: > > > > iqn.9.com.cisco.myiscsithing > > > > and > > > > iqn.9.com.cisco.MyIscsiThing > > > > since a user would be likely to confuse these. Again, it doesn't > > affect the protocol itself, just its usability. > > > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > > case-sensitive? > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 19 12:17:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04943 for ; Thu, 19 Jul 2001 12:17:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JEwqu22538 for ips-outgoing; Thu, 19 Jul 2001 10:58:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JEwog22533 for ; Thu, 19 Jul 2001 10:58:51 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id KAA04525; Thu, 19 Jul 2001 10:58:47 -0400 (EDT) Date: Thu, 19 Jul 2001 10:58:47 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips Subject: Re: iSCSI Plugfest at UNH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: Thank you for changing the last example in Appendix A to require the SecurityContextComplete=yes handshake, and adding the phrase to 4.2: "The Security Context Complete handshake MUST be performed if any of the negotiating parties has offered a security/integrity item (even if it is not selected)." As part of this same change, you need to also delete the 3rd point in section 4.3 quoted below (deletion marked with X): > > Operational parameter negotiation during the login MAY be done: > > - starting with the Login command if the initiator does not offer > any security/ integrity option > - starting immediately after the security/integrity negotiation if > the initiator and target perform such a negotiation > X - starting immediately after the Login response with Final bit 0 if > X the initiator does offer security/integrity options but the target > X chose none. ------ > > +++ OK (that is from the plugfest or personal?)+++ It acually came up -- someone was arguing that as stated he had to include all session sepcific parameters in the first login command (literally). ------- refering to section 1.2.4: > What do we have add. I assume that if we add more text the amount of > overlooked text will only increase +++ What about the wording: In "list" negotiation, the offering party sends for each key a list of values (which may include "none") in its order of preference. Bob From owner-ips@ece.cmu.edu Thu Jul 19 13:15:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13593 for ; Thu, 19 Jul 2001 13:15:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JFYDR25390 for ips-outgoing; Thu, 19 Jul 2001 11:34:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JFYBg25379 for ; Thu, 19 Jul 2001 11:34:11 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA05672; Thu, 19 Jul 2001 11:34:09 -0400 (EDT) Date: Thu, 19 Jul 2001 11:34:09 -0400 From: "Robert D. Russell" To: Matt Wakeley cc: ips@ece.cmu.edu Subject: Re: iSCSI: CmdSN during the Login phase In-Reply-To: <3B55EE40.D13AE855@agilent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk > If you use the next in line CmdSN for the session, you block all the SCSI > commands the existing connections are sending while negotiating this new > connection. > > -Matt > I don't understand how the new negotiation blocks the existing connections in this case. The login negotiation involves exchanges of login, text commands, text responses and login responses that all share the same Initiator Task Tags, but NOT the same CmdSN -- each new command in this negotiation process carries a new CmdSN, and other connections can get their own CmdSN values without waiting for the full negotiation process to complete. Consider the following: 1. The TCP connection is established completely "in parallel" to the existing connections and has no effect on them. 2. If IPsec or other non-iSCSI security is being used, it is negotiated "in parallel" to the existing connections and has no effect on them. 3. The initiator now needs to send the login on the new connection, and for that it selects the "next" CmdSN, increments it by 1, and sends the login command. The next command on any other connection will use the incremented CmdSN and increment it in turn, etc. This command can still be sent on the other connection. It is true that the target cannot process this other command until the target has sent the first login response to the login command (because of the sequencing imposed by the CmdSN). However, the other connection is NOT blocked during the complete login negotiation phase, because each subsequent text command sent by the initiator uses the next CmdSN and is processed by the target AFTER any intervening commands on other connections. The commands in the login negotiation all have the same Initiator Task Tag, but not the same CmdSN. Therefore they do not prevent other connections from consuming CmdSN values. In fact, it is possible for several logins for additional connections to be going on simultaneously while commands are still flowing (and being processed) on the existing connections. Of course, the time needed by the target to process login and text commands should be kept to a minimum, which just reinforces the need to simplify the login negotiation process as much as possible. Bob Russell From owner-ips@ece.cmu.edu Thu Jul 19 13:49:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22902 for ; Thu, 19 Jul 2001 13:49:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JGOm429525 for ips-outgoing; Thu, 19 Jul 2001 12:24:48 -0400 (EDT) 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 f6JGOfg29516 for ; Thu, 19 Jul 2001 12:24:42 -0400 (EDT) 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 SAA184084 for ; Thu, 19 Jul 2001 18:24:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JGOYI64618 for ; Thu, 19 Jul 2001 18:24:34 +0200 Importance: Normal Subject: RE: The iSCSI Plugfest - update for Wednesday To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 19:30:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 19:24:34 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk No - only sending good status on Data-In PDU. And again this did not change from draft 00. Julo "Barry Reinhold" on 19-07-2001 15:23:47 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: The iSCSI Plugfest - update for Wednesday Julian, Am I to understand from this that iSCSI intends to support both (1) sending of status information in iSCSI data PDUs and also sending of data in iSCSI response PDUS? >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Thursday, July 19, 2001 6:27 AM >To: ips@ece.cmu.edu >Subject: Re: The iSCSI Plugfest - update for Wednesday > > > >Status and Data where (and) are part of the standard. >They are important to reduce the protocol overhead and performance of the >software implementation >is substantially reduced without it. > >It is clearly stated in several places (1.2, the Data-In PDU) etc. and has >never changed (from version 0). > >As for the plugfest - congratulations - great work. > >Julo > > > > >Please respond to "Barry Reinhold" > >To: "ISCSI" >cc: >Subject: The iSCSI Plugfest - update for Wednesday > > > > >The plugfest process has settled down to the detailed process of isolating >implementation bugs. A significant percentage of the implementors are now >able to connect and perform I/O operations - though this is often achieved >by first compiling with -D "company Name" switches to handle the different >issues that have already been discovered. > >New Issues: A detailed posting of the issues to date will (or has) be done >by Bob Russell. In brief only one additional standards issues came to >light >that impacted interoperability in the days testing: > >1. The current wording of the standard appears to allow for the >transmission >of IO data in response frames. This is actually being done in a few >implementations. Although this was perhaps a vision at the start of the >iSCSI effort there is little support for this. Most implementors were not >prepared to handle this. > >Progress: > >Test progressed to round 17 and it appears that it is highly likely that >developers will get a chance to test against all other parties by the end >of >the week. > >Two vendors were able to establish a multi connection session, getting >through the login process and the start of IO. > >Two other vendors established an iSCSI session with header digests, >completing the security phase of the login process. > >Some generic problem areas that come up: > >0 Length data frames >Target initiated text negotiation >Response information in data PDUs. >SCSI compatibility issues > >There was a UNH iSCSI consortium meeting at the end of the day > >1. Overview of UNH iSCSI consortium >2. Discussion on dates/time for next plug fest >3. Election of steering team > >People flowing out at 7:00 -- sign that things are pretty good. > > > >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 Thu Jul 19 13:54:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24374 for ; Thu, 19 Jul 2001 13:54:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JGSW329916 for ips-outgoing; Thu, 19 Jul 2001 12:28:32 -0400 (EDT) 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 f6JGSTg29912 for ; Thu, 19 Jul 2001 12:28:29 -0400 (EDT) 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 SAA73886 for ; Thu, 19 Jul 2001 18:28:23 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JGSMI77030 for ; Thu, 19 Jul 2001 18:28:22 +0200 Importance: Normal X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Subject: Re: iSCSI Plugfest at UNH To: "Robert D. Russell" , Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 19:34:27 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 19:28:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk +++ in text Thanks, Julo "Robert D. Russell" on 19-07-2001 17:58:47 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips Subject: Re: iSCSI Plugfest at UNH Julian: Thank you for changing the last example in Appendix A to require the SecurityContextComplete=yes handshake, and adding the phrase to 4.2: "The Security Context Complete handshake MUST be performed if any of the negotiating parties has offered a security/integrity item (even if it is not selected)." As part of this same change, you need to also delete the 3rd point in section 4.3 quoted below (deletion marked with X): > > Operational parameter negotiation during the login MAY be done: > > - starting with the Login command if the initiator does not offer > any security/ integrity option > - starting immediately after the security/integrity negotiation if > the initiator and target perform such a negotiation > X - starting immediately after the Login response with Final bit 0 if > X the initiator does offer security/integrity options but the target > X chose none. ------ +++ Done +++ > > +++ OK (that is from the plugfest or personal?)+++ It acually came up -- someone was arguing that as stated he had to include all session sepcific parameters in the first login command (literally). ------- refering to section 1.2.4: > What do we have add. I assume that if we add more text the amount of > overlooked text will only increase +++ What about the wording: In "list" negotiation, the offering party sends for each key a list of values (which may include "none") in its order of preference. +++ if that helps +++ Bob From owner-ips@ece.cmu.edu Thu Jul 19 15:05:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15662 for ; Thu, 19 Jul 2001 15:05:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JHJJo04403 for ips-outgoing; Thu, 19 Jul 2001 13:19:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6JHJHg04395 for ; Thu, 19 Jul 2001 13:19:17 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Jul 19 13:14:29 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Thu Jul 19 13:18:03 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id NAA12372 for ips@ece.cmu.edu; Thu, 19 Jul 2001 13:17:39 -0400 (EDT) Date: Thu, 19 Jul 2001 13:17:39 -0400 (EDT) Message-Id: <200107191717.NAA12372@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: "ips" Subject: Re: iSCSI Plugfest at UNH Sender: owner-ips@ece.cmu.edu Precedence: bulk > > +++ Should we really? A good driver will do what it can to optimize its use > > of resources while getting maximum performance. IMHO a warning to > > implementers will be enough and I will try to put it in.++++ Julian, Matthew Burnbridge explained this well at the plugfest meeting. The problem is that the target does not know if its dealing with a good initiator or a bad one. The protocol is introducing needless network delay (wait states!). Why wait for the final bit if the target has enough memory to handle all the data right away (and could send R2Ts *NOW*) ? Regards, -Sandeep > 12.If unsolicited data is negotiated, it appears that it still does not > have to be used. In practice this can lead to performance > inefficiencies. > > Consider the following: > - Unsolicited data has been negotiated to YES but immediate data > is NO (although a problem still exists even if this is YES). > > - The initiator sends a SCSI command with F=0, W=1 and a large > Expected Transfer Length field (greater than FirstBurstSize). > > - When the target receives this command, it knows that unsolicited > data follows (because F=0), but does NOT know how much (there > is a maximum determined by the negotiated FirstBurstSize, but > there > is no requirement that the initiator actually send this much). > Therefore, the target cannot at this time send out an R2T to get > the "rest" of the data -- it must wait to receive data PDUs > until it gets the F=1 set on one of these data PDUs, and then > compute the amount of data to ask for in the R2T. This may > introduce needless delay. > > To avoid this situation, the standard should either: > - require that when unsolicited data is to be sent, that the > amount be min(Expected Transfer Length, FirstBurstSize), > - alternatively, provide a field in the SCSI command that > allows the initiator to indicate how much unsolicited data > follows. > > > +++ Should we really? A good driver will do what it can to optimize its use > > of resources while getting maximum performance. IMHO a warning to > > implementers will be enough and I will try to put it in.++++ From owner-ips@ece.cmu.edu Thu Jul 19 15:42:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27737 for ; Thu, 19 Jul 2001 15:42:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JHxSU07642 for ips-outgoing; Thu, 19 Jul 2001 13:59:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JHxRg07637 for ; Thu, 19 Jul 2001 13:59:27 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id NAA09519; Thu, 19 Jul 2001 13:59:23 -0400 (EDT) Date: Thu, 19 Jul 2001 13:59:22 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Unsolicited data In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: The warning in section 8.6 of draft 06-99 still does not solve the problem and is in fact wrong. It now reads: "However negotiating an amount of unsolicited data for writes and sending less than the negotiated amount when the total data amount to be sent by a command is larger than the negotiated amount may negatively impact performance as the targets will not be able to ask for the remainder of the data." The problem is, even if the initiator DOES send the full negotiated amount, the target does NOT know this in advance and therefore cannot send out the R2T for the rest until getting the unsolicited data PDU with the F bit set to 1. In other words, even the very best implementation of an initiator does NOT solve the problem -- the target still does NOT know what is coming because the initiator can NOT tell him. Performance is ALWAYS impacted, regardless of what the initiator does. The simplest solution would be to REQUIRE the initiator to send the negotiated amount (after all, if he doesn't want to send that much every time then why did he negotiate that much?). Then the target will know, in advance, what is coming and send out the R2T for the rest of the data WITHOUT WAITING! This is where the performance gain is to be found. (In all of the above discussion I am assuming the Expected Transfer Length is greater than the First Burst Size. The acutal requirement for sending unsolicited data is that the initiator be required to send min(Expected Transfer Length, First Burst Size) as unsolicited data if unsolicited data has been negotiated.) Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Thu Jul 19 15:43:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28139 for ; Thu, 19 Jul 2001 15:43:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JIDW708848 for ips-outgoing; Thu, 19 Jul 2001 14:13:32 -0400 (EDT) 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 f6JIDUg08840 for ; Thu, 19 Jul 2001 14:13:30 -0400 (EDT) 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 UAA310554 for ; Thu, 19 Jul 2001 20:13:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6JIDMc129094 for ; Thu, 19 Jul 2001 20:13:23 +0200 Importance: Normal Subject: RE: The iSCSI Plugfest - update for Wednesday To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 19 Jul 2001 20:13:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 19/07/2001 21:13:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk That was never supported. The data space is reserved for sense & response. Julo "Barry Reinhold" on 19-07-2001 19:44:04 Please respond to "Barry Reinhold" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: The iSCSI Plugfest - update for Wednesday There is no problem with this feature. It is the sending of data in iscsi command response PDUs that was an issue. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Julian Satran >Sent: Thursday, July 19, 2001 12:31 PM >To: ips@ece.cmu.edu >Subject: RE: The iSCSI Plugfest - update for Wednesday > > > >No - only sending good status on Data-In PDU. And again this did not >change from draft 00. Julo > >"Barry Reinhold" on 19-07-2001 15:23:47 > >Please respond to "Barry Reinhold" > >To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu >cc: >Subject: RE: The iSCSI Plugfest - update for Wednesday > > > > >Julian, > Am I to understand from this that iSCSI intends to support both (1) >sending >of status information in iSCSI data PDUs and also sending of data in iSCSI >response PDUS? > >>-----Original Message----- >>From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >>Julian Satran >>Sent: Thursday, July 19, 2001 6:27 AM >>To: ips@ece.cmu.edu >>Subject: Re: The iSCSI Plugfest - update for Wednesday >> >> >> >>Status and Data where (and) are part of the standard. >>They are important to reduce the protocol overhead and performance of the >>software implementation >>is substantially reduced without it. >> >>It is clearly stated in several places (1.2, the Data-In PDU) etc. and has >>never changed (from version 0). >> >>As for the plugfest - congratulations - great work. >> >>Julo >> >> >> >> >>Please respond to "Barry Reinhold" >> >>To: "ISCSI" >>cc: >>Subject: The iSCSI Plugfest - update for Wednesday >> >> >> >> >>The plugfest process has settled down to the detailed process of isolating >>implementation bugs. A significant percentage of the implementors are now >>able to connect and perform I/O operations - though this is often achieved >>by first compiling with -D "company Name" switches to handle the different >>issues that have already been discovered. >> >>New Issues: A detailed posting of the issues to date will (or has) be done >>by Bob Russell. In brief only one additional standards issues came to >>light >>that impacted interoperability in the days testing: >> >>1. The current wording of the standard appears to allow for the >>transmission >>of IO data in response frames. This is actually being done in a few >>implementations. Although this was perhaps a vision at the start of the >>iSCSI effort there is little support for this. Most implementors were not >>prepared to handle this. >> >>Progress: >> >>Test progressed to round 17 and it appears that it is highly likely that >>developers will get a chance to test against all other parties by the end >>of >>the week. >> >>Two vendors were able to establish a multi connection session, getting >>through the login process and the start of IO. >> >>Two other vendors established an iSCSI session with header digests, >>completing the security phase of the login process. >> >>Some generic problem areas that come up: >> >>0 Length data frames >>Target initiated text negotiation >>Response information in data PDUs. >>SCSI compatibility issues >> >>There was a UNH iSCSI consortium meeting at the end of the day >> >>1. Overview of UNH iSCSI consortium >>2. Discussion on dates/time for next plug fest >>3. Election of steering team >> >>People flowing out at 7:00 -- sign that things are pretty good. >> >> >> >>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 Thu Jul 19 18:12:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28289 for ; Thu, 19 Jul 2001 18:12:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JKVYA19339 for ips-outgoing; Thu, 19 Jul 2001 16:31:34 -0400 (EDT) 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 f6JKVXg19335 for ; Thu, 19 Jul 2001 16:31:33 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA13142 for ; Thu, 19 Jul 2001 16:31:27 -0400 (EDT) Message-ID: <3B574307.E24947@cisco.com> Date: Thu, 19 Jul 2001 15:28:55 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: iSCSI Login Questions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian: Is the following valid (taking into account the changes requested from the UNH Plugfest)? I: Login: AuthMethod:none SecurityContextComplete=Yes I would assume not, that the initiator must wait until after the initial exchange of the AuthMethod, HeaderDigest, and DataDigest keys to send the SecurityContextComplete key. Also, if further simplification of the login process is desired, the working group might want to consider requiring the initiator to send the AuthMethod HeaderDigest and the DataDigest keys on the first login, so that the login sequence would always look like: I: Login: AuthMethod=a1,a2,aN HeaderDigest=hd1,hd2,hdN DataDigest=dd1,dd2,ddN T: LoginPR: AuthMethod=a1 HeaderDigest=hd1 DataDigest=dd1 ...Authentication phase, if needed I: Text: SecurityContextComplete=yes T: Text: SecurityContextComplete=yes ...Operational Parameter Negotiating phase ...Full Feature Phase Regards, Steve Senum From owner-ips@ece.cmu.edu Thu Jul 19 18:52:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06350 for ; Thu, 19 Jul 2001 18:52:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JLckp24154 for ips-outgoing; Thu, 19 Jul 2001 17:38:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraab.compuserve.com (ds-img-rel-2.compuserve.com [149.174.206.155]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JLchg24146 for ; Thu, 19 Jul 2001 17:38:43 -0400 (EDT) Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id RAA18553 for ips@ece.cmu.edu; Thu, 19 Jul 2001 17:38:37 -0400 (EDT) Received: from compuserve.com (hil-qbu-pti-vty4.as.wcom.net [206.175.105.4]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id RAA18492 for ; Thu, 19 Jul 2001 17:38:32 -0400 (EDT) Message-ID: <3B574F6A.F402663C@compuserve.com> Date: Thu, 19 Jul 2001 15:21:46 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.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 Subject: Re: FCIP -03 comments References: <277DD60FB639D511AC0400B0D068B71E070A5F@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Black_David@emc.com wrote: ..snip.. > -- Section 2.1 > > Add at least FC-PH to the list of referenced documents T11 adamantly holds the opinion that the combination of FC-PI and FC-FS replaces FC-PH. The seriousness with which this opinion is held can be seen in the T11 refusal to internationalize FC-PH. For this reason, FC-PH does not belong in FCIP. FC-PI describes electrical and optical interconnect technologies as they apply to Fibre Channel. It does not belong in FCIP. FC-FS is in the list in section 2.1, as well it should be, since it is where the FC Frame format is defined. > Given the number of FC documents referenced, > a few sentences describing their contents and > relationship would be useful. Will do > -- Section 2.2 > > I don't like the tone of the first paragraph in Section > 2.2. Can this be rephrased to talk about logical division > of the problem between carrying FC frames over TCP/IP > (IETF) vs. integration of TCP/IP that carry FC frames > into FC fabrics and fabric operation/behavior over such > links (T11)? Will do > The list of requirements for correct operation of an FC > entity with an FCIP entity in Annex D needs to be exhaustive > from the viewpoint of the FCIP entity (i.e., everything that > the FCIP entity needs MUST be listed). It will be. In rev 04, the sentence at issue will read: "The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in annex D." ..snip.. > In the next to last paragraph, in Section 2.2, please use > the term "programming interface" rather than just "interface" In response to previous comments on this topic, "API" has replaced several phrases such as the one mentioned above in the last two paragraphs of 2.2. Hopefully, rev 04 will meet with your approval. > -- Section 4 Open Issues > > Based on an offline discussion with some of the authors, please > add a note here that the synchronization recovery material, > including the algorithm in Annex A is known to need revision. > > Indicate that the QoS/diffserv wording still needs revision. The total rewrite of the QoS section is nearing completion and in all probability will appear in rev 04. > -- Section 5 > > Reword 2) and 3) to avoid implying that every FCIP entity is > connected to every other reachable FCIP entity. That need not > be the case in general. It appears to me that this is achieved by deleting "all" from 2) and changing "each pair" to "a pair" in 3). If this not sufficient more comments will arrive against rev 04. > In connection with 10), someone needs to take a "to do" item to > write the SLP templates and procedures. See the iSCSI SLP > draft for an example. Dave Peterson has started but not completed this task. Or possibly, Dave has completed the task but the FCIP Authors have not yet completed the review necessary to incorporate in FCIP. In any case, this is in progress and will be done, but not in time for rev 04. > Delete 12 b). If an FCIP entity is operating with an external > security gateway, only the interface on the public side of the > gateway is compliant with this specification. The interface > between the FCIP entity and the gateway is not compliant because > it is lacking required security features - the FCIP entity > *includes* the security gateway in this structure. Also, > please use the word "confidentiality" rather than "privacy" > to avoid confusion. Please post this as a separate issue because several of the FCIP Authors believe it is appropriate for FCIP and I cannot represent their opinions. > Item 13) is not the entire story when more than one TCP connection > is being used. This needs to be expanded to explain who's responsible > for what in that case. Unless the FCIP Authors over rule me, "On one TCP connection, ..." will be added at the beginning of the statement in 13). > -- Section 6.3 > > I think this section really needs a discussion about what the > combination of an FCIP entity with an FC entity linked to a > pair of corresponding peer entities could be from a Fibre > Channel viewpoint. This is the place to say that: > - it could be an inter-switch link, mentioning B > and E ports with a possible reference to FC-BB2 > - it could be a node to fabric link, N port to F port, with > a reference to FC-PH > - it could not be a link in an Arbitrated Loop because FCIP > does not support the additional primitive signals > and sequences required for an Arbitrated Loop with a > reference Section 6 of FC-AL and FC-AL2. I will propose the following text to the FCIP Authors: "In general, the combination of an FCIP Link and FC and FCIP Entities is intended to replace a Fibre Channel defined connection between Fibre Channel components. For example, this combination can be used in place of a hardwire connection between two Fibre Channel switches. There are limitations on the generally intended usage of the combination shown in figure 3. For example, the combination cannot be used to replace cable in a Fibre Channel Arbitrated Loop because loop primitive signals cannot be encapsulated for transmission over TCP. ..snip.. Owing to time constraints, I cannot process the comments beyond this point right now. Rather than delay the response, I am closing the message here. Ralph... From owner-ips@ece.cmu.edu Thu Jul 19 18:54:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06682 for ; Thu, 19 Jul 2001 18:54:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JKxbm21377 for ips-outgoing; Thu, 19 Jul 2001 16:59:37 -0400 (EDT) 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 f6JKxag21372 for ; Thu, 19 Jul 2001 16:59:36 -0400 (EDT) Received: from breinhold (mindtree2.iol.unh.edu [132.177.125.57]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6JKxPc18794 for ; Thu, 19 Jul 2001 16:59:25 -0400 (EDT) From: "Barry Reinhold" To: "ISCSI" Subject: Progress Report on iSCSI group test period Date: Thu, 19 Jul 2001 16:55:22 -0400 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 Not much to report relative to new iSCSI standards issues -- The rounds of testing broke down today as many vendors packed up early and went home. Only 5-10 die hards remain cleaning up bugs as of 5:00 P.M. This will be the last update. 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 Thu Jul 19 18:55:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06782 for ; Thu, 19 Jul 2001 18:55:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JM6gM26015 for ips-outgoing; Thu, 19 Jul 2001 18:06:42 -0400 (EDT) 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 f6JM6fg26010 for ; Thu, 19 Jul 2001 18:06:41 -0400 (EDT) Received: from breinhold (mindtree2.iol.unh.edu [132.177.125.57]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6JM6Wc27467; Thu, 19 Jul 2001 18:06:33 -0400 (EDT) From: "Barry Reinhold" To: "Steve Senum" , "ietf-ips" Subject: RE: iSCSI Login Questions Date: Thu, 19 Jul 2001 18:02:29 -0400 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) In-Reply-To: <3B574307.E24947@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve, I would think that this is valid independent of the changes that have been discussed at the UNH GTP. The initiator has all the information that it needs for security and is indicating that by setting securitycontextcomplete=yes. If the target responds with with AuthMethod=none and SecurityContextComplete=yes then full security phase is history. However, the initiator needs to be ready to allow the target to continue the negotiation. (i.e. if the initiator receives a PDU back with securitycontextcomplete=no it must continue to send text commands in the security phase even if it does not have any additional parameters it wishes to communicate.) The target may also respond to the AuthMethod=None with AuthMethod=Reject, or it might reject the login with a status of 0x0201 (Auth failed). All of these responses appear to be valid based on 6-97. It would probably benefit us to limit the choices here. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Steve Senum >Sent: Thursday, July 19, 2001 4:29 PM >To: ietf-ips >Subject: iSCSI Login Questions > > >Julian: > >Is the following valid (taking into account the >changes requested from the UNH Plugfest)? > >I: Login: AuthMethod:none SecurityContextComplete=Yes > >I would assume not, that the initiator must wait >until after the initial exchange of the AuthMethod, HeaderDigest, >and DataDigest keys to send the SecurityContextComplete >key. > >Also, if further simplification of the login process >is desired, the working group might want to consider requiring >the initiator to send the AuthMethod HeaderDigest and >the DataDigest keys on the first login, so that the >login sequence would always look like: > >I: Login: AuthMethod=a1,a2,aN > HeaderDigest=hd1,hd2,hdN > DataDigest=dd1,dd2,ddN >T: LoginPR: AuthMethod=a1 > HeaderDigest=hd1 DataDigest=dd1 >...Authentication phase, if needed >I: Text: SecurityContextComplete=yes >T: Text: SecurityContextComplete=yes >...Operational Parameter Negotiating phase >...Full Feature Phase > >Regards, >Steve Senum From owner-ips@ece.cmu.edu Thu Jul 19 18:57:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07037 for ; Thu, 19 Jul 2001 18:57:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JLckD24155 for ips-outgoing; Thu, 19 Jul 2001 17:38:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraab.compuserve.com (ds-img-rel-2.compuserve.com [149.174.206.155]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6JLchg24145 for ; Thu, 19 Jul 2001 17:38:43 -0400 (EDT) Received: (from mailgate@localhost) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id RAA18531 for ips@ece.cmu.edu; Thu, 19 Jul 2001 17:38:37 -0400 (EDT) Received: from compuserve.com (hil-qbu-pti-vty4.as.wcom.net [206.175.105.4]) by spdmraab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id RAA18456 for ; Thu, 19 Jul 2001 17:38:28 -0400 (EDT) Message-ID: <3B5743D5.FDC5C927@compuserve.com> Date: Thu, 19 Jul 2001 14:32:21 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.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 Subject: Re: FCIP Annex E References: <277DD60FB639D511AC0400B0D068B71E070A58@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, Depending on how the embedded responses below sit with you, we may be converging. Thanks. Ralph... Black_David@emc.com wrote: > > Picking up on the Annex E issues, a general theme running > through my comments is that while much of the currently > proposed text is sufficient to convey what's going on to a > Fibre Channel expert, I think the FCIP spec should be > accessible to someone who isn't. This means someone > who hasn't waded through the various specs (at least half > a dozen specs, easily over 1000 pages) and figured out > which pieces are important vs. those that should be > ignored (e.g., Class 1 service). I do not see how this is possible without adding a tutorial on Fibre Channel to FCIP. Most Fibre Channel tutorials are ten or more pages, and FCIP already has two pages of tutorial in Annex C. After all, Class 1 service could refer to an airplane ticket and a sentence such as: "Class 1 service can be ignored" already requires a Fibre Channel expert for there to be any hope of understanding the meaning. > I agree that detailed specification > of Fibre Channel aspects (e.g., DLY_LIM calculation) > belongs in FC-BB-2, but (non-normative) explanations > of the purpose and rationale for inclusion of functionality > in FCIP is in order for the FCIP spec, and such > explanations will have to touch on FC concepts > (e.g., an explanation of DLY_LIM is much clearer > if it explains what R_A_TOV is and why violating it > is a *really bad thing* in a Fibre Channel fabric). It seems to me that the simpler rational to explain is that the Fibre Channel routing and error recovery protocols require FC Frames to exit a receiving FCIP Entity within in a fixed interval from the time they entered a sending FCIP Entity, IP Network transit time included, or never exit the FCIP Entity. Mentioning the Fibre Channel specifics both obscures the matter of concern and obliges Fibre Channel to either forever maintain R_A_TOV as the one and only issue of merit in this matter or bother the IESG with a new revision of FCIP when it does. The straight forward explanation will be added at the beginning of 6.6.2.3 in rev 04. ..snip.. > The proposed text additions look ok. > > > > E-5.3 TCP Connection Management > > > E-5.5 Multiple Connection Management > > > > No changes have been made in FCIP in response to this comment. > > > > I am loath to add FC Port to the FCIP glossary. I can find > > nothing in the first paragraphs of E-5.3 and E-5.5 that > > are not covered in suitably general terms in section 8. > > I think Section 9 was intended. The concern I have is a that the > coverage is a bit too general, e.g., what are "appropriate policies > for mapping FC Frames to these connections"? It's not necessary > to specify how to do this, but at least note what FC's frame > ordering requirements are and provide an example of how to > meet them across multiple connections. Section 9, heavens no! Section 9 is undergoing a total rewrite for rev 04. Section 7 was intended, specifically the discussion of how the FCIP Entity maintains its knowledge of multiple connections in 7.1.1 and 7.1.2. > > > E-5.4.1 Determining loss of connectivity {partial} > > > > > > Somewhere, possibly in Annex D, making the FC entity > > > responsible for checking for loss of TCP connectivity > > > ought to be enhanced by giving the HLO SW_ILS as an > > > example of how this could be done without requiring it > > > to be used. > > > > No changes have been made in FCIP in response to this comment. > > > > This is 100% a Fibre Channel issue. If Fibre Channel does > > not want to test connectivity, that is Fibre Channel's business. > > If Fibre Channel wants to invent a replacement for the HLO > > SW_ILS (perhaps even one suited specifically to FCIP) why > > should it be the place of FCIP to mandate use of HLO? > > I didn't say "mandate", I said "as an example". The general > point is that FC may have a keep-alive mechanism such as HLO > that would obviate the need for any such mechanism at this > level, and it should be made in the FCIP spec. Referencing > HLO and the version of FC-SW that defines it *as an example* > would help get the point across, without requiring any use > of HLO (that sort of requirement is FC's business). If it is expected that all IETF standards track RFCs must discuss how they implement a keep-alive mechanism, then most certainly FCIP needs to explain why it does not need one. > > > E-8.3 Corruption {partial} > > > > > > Most of this seems to be covered in 6.6.2.2, but noting that > > > FC has the option to begin transmitting a frame and terminate > > > that with an EOF invalidating the partially transmitted frame > > > should be added. > > > > I believe that sufficient discussion of EOFa appears in > > section 6.6.2.4. > > 6.6.2.4 has very little on EOFa. I'd add essentially the above sentence > so that the result is intelligible to someone who isn't already a Fibre > Channel expert, and put in the appropriate section reference to the > definition of EOFa in FC-PH (17.6.3). In rev 04, a discussion of EOFa (cloned from FC-FS) will be added to C.1 and a cross reference to C.1 will be added at the sites where EOFa is used. > > > E-8.4 Timeouts {partial} > > > It is intended that 04 change the usage of R_A_TOV to some other > > variable name, perhaps DLY_LIM (delay limit). The burden for > > computing DLY_LIM will be placed on the FC Entity, and DLY_LIM > > will be nothing more than the value enforced by the FCIP_DE > > as per 6.6.2.3. > > That's a good approach, but I would still add non-normative > text to point out the existence and purpose of R_A_TOV, which has > to be considered by the FC Entity in this computation. Again this is > explanatory text - FC-BB-2 is the place to specify details of how to > calculation DLY_LIM from inputs such as R_A_TOV, but FCIP > should explain why DLY_LIM exists. I think the addition to 6.6.2.3 described above handles this issue in a manner appropriate to FCIP. ..snip.. From owner-ips@ece.cmu.edu Thu Jul 19 19:58:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22665 for ; Thu, 19 Jul 2001 19:58:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6JMOvj27259 for ips-outgoing; Thu, 19 Jul 2001 18:24:57 -0400 (EDT) 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 f6JMOug27252 for ; Thu, 19 Jul 2001 18:24:56 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA22305 for ; Thu, 19 Jul 2001 18:24:46 -0400 (EDT) Message-ID: <3B575D96.DA4706B6@cisco.com> Date: Thu, 19 Jul 2001 17:22:14 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI Login Questions 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, By my reading of the current draft, I don't think SecurityContextComplete=no is valid. Regards, Steve Senum Barry Reinhold wrote: > > Steve, > I would think that this is valid independent of the changes that have been > discussed at the UNH GTP. The initiator has all the information that it > needs for security and is indicating that by setting > securitycontextcomplete=yes. If the target responds with with > AuthMethod=none and SecurityContextComplete=yes then full security phase is > history. However, the initiator needs to be ready to allow the target to > continue the negotiation. (i.e. if the initiator receives a PDU back with > securitycontextcomplete=no it must continue to send text commands in the > security phase even if it does not have any additional parameters it wishes > to communicate.) The target may also respond to the AuthMethod=None with > AuthMethod=Reject, or it might reject the login with a status of 0x0201 > (Auth failed). > All of these responses appear to be valid based on 6-97. It would probably > benefit us to limit the choices here. > >-----Original Message----- > >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > >Steve Senum > >Sent: Thursday, July 19, 2001 4:29 PM > >To: ietf-ips > >Subject: iSCSI Login Questions > > > > > >Julian: > > > >Is the following valid (taking into account the > >changes requested from the UNH Plugfest)? > > > >I: Login: AuthMethod:none SecurityContextComplete=Yes > > > >I would assume not, that the initiator must wait > >until after the initial exchange of the AuthMethod, HeaderDigest, > >and DataDigest keys to send the SecurityContextComplete > >key. > > > >Also, if further simplification of the login process > >is desired, the working group might want to consider requiring > >the initiator to send the AuthMethod HeaderDigest and > >the DataDigest keys on the first login, so that the > >login sequence would always look like: > > > >I: Login: AuthMethod=a1,a2,aN > > HeaderDigest=hd1,hd2,hdN > > DataDigest=dd1,dd2,ddN > >T: LoginPR: AuthMethod=a1 > > HeaderDigest=hd1 DataDigest=dd1 > >...Authentication phase, if needed > >I: Text: SecurityContextComplete=yes > >T: Text: SecurityContextComplete=yes > >...Operational Parameter Negotiating phase > >...Full Feature Phase > > > >Regards, > >Steve Senum From owner-ips@ece.cmu.edu Fri Jul 20 01:11:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10763 for ; Fri, 20 Jul 2001 01:11:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K3iBh17081 for ips-outgoing; Thu, 19 Jul 2001 23:44:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6K3i9g17077 for ; Thu, 19 Jul 2001 23:44:09 -0400 (EDT) Received: from london ([192.168.1.1]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id UAA25167; Thu, 19 Jul 2001 20:43:05 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , "Robert D. Russell" Cc: "ips" Subject: iSCSI OpParamReset Date: Thu, 19 Jul 2001 20:44:14 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I have no fundamental objection to the introduction of the OpParamReset key, however please consider the following observation. It seems an implementer has two basic choices with respect to OpParamReset. 1) Add special case code in the login phase handling to remember the initial values that might get reset. 2) Obviate (1) by always sending OpParamReset. I suspect most implementers will go for option (2), if this is so we might as well mandate that behaviour and remove the need for key. - Rod ------------------------------------------------------------ -------------------- 1. Exactly what should happen if operational parameters are sent by the initiator during the security phase of login? In section 4.2 the standard says: "-The iSCSI parameter negotiation (non-security parameters) SHOULD start only after security is established. This should be performed using text commands." and: "When establishing the security context, any operational parameters sent before establishing a secure context MAY be ignored by both the target and the initiator." There is a problem with the meaning of "ignore" -- should the target: 1. not respond to these operational keys at all, or 2. respond with key=reject, or 3. respond with a valid value and then just not use these values. In this case, how does the initiator know whether or not the target is ignoring these parameters or not? A final note: The standard seems to allow the initiator to send operational parameters when establishing the security context, get back a valid value from the target, and then ignore the entire negotiation anyway. Is this legal? In this case, how does the target know that the initiator is ignoring these parameters? +++ It is standard practice (and legal) in most protocols to reset the operational parameters to previous values at the end of the security phase negotiation if the channel is becoming a secure channel WE have two options: a) assume that this happens at every SecurityContextComplete b) say explicitly that it happened - e.g., the target or initiator decide that the channel is now more secure than before and say explicitly something like OpParmReset=yes I will assume that is b that most of you want and I will say so in 7 unless I hear otherwise TODAY: here is the text: 01 OpParmReset Use: IO Who can send: Initiator and Target OpParmReset= OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before login. Either the initiator or target may choose to do so but only after and only if a SecurityContextComplete handshake is completed on the connection. The resetting should involve only parameters that where set during login on the connection in which the OpParmReset is issued. Please note that since either initiator or target may request this behavior there is no need to reply. and 4.3 reads: 1.1 Operational Parameter Negotiation During the Login Phase Operational parameter negotiation during the login MAY be done: - starting with the Login command if the initiator does not offer any security/ integrity option - starting immediately after the security/integrity negotiation if the initiator and target perform such a negotiation - starting immediately after the Login response with Final bit 0 if the initiator does offer security/integrity options but the target chose none. An operational parameter negotiation on a connection SHOULD not start before the security/integrity negotiation if such a negotiation exists. Operational parameters negotiated inadvertently before the security/integrity negotiation MAY be reset after the security/integrity negotiation at the explicit request of the initiator or target. ++++ TargetName=iqn.com.acme.diskarray.sn.88 HeaderDigest=crc-32C,none DataDigest=crc-32C,none AuthMethod:KRB5,SRP,none T-> Login-PR, HeaderDigest=none, DataDigest=none, AuthMethod=none I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes I-> Text ... iSCSI parameters T-> Text ... iSCSI parameters And at the end: I-> Text optional iSCSI parameters F bit set to 1 T-> Login "login accept" TargetName=iqn.com.acme.diskarray.sn.88 Note that SecurityContextComplete=yes is required although no security mechanism was chosen. ++++ From owner-ips@ece.cmu.edu Fri Jul 20 02:50:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26129 for ; Fri, 20 Jul 2001 02:50:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K5LKO23246 for ips-outgoing; Fri, 20 Jul 2001 01:21:20 -0400 (EDT) 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 f6K5LIg23241 for ; Fri, 20 Jul 2001 01:21:18 -0400 (EDT) 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 HAA170096 for ; Fri, 20 Jul 2001 07:21:12 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6K5LBJ76592 for ; Fri, 20 Jul 2001 07:21:11 +0200 Importance: Normal Subject: Re: iSCSI Plugfest at UNH To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 20 Jul 2001 08:23:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 08:21:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Correct, but the delay is introduced by the initiator in question and the bad behaving initiator is the only one to suffer the penalty. Nobody else is harmed. A badly behaved initiator may do many other things that can negatively impact it's performance. On the other hand if we insist on enforcing the negotiated limit we might end-up prohibiting legitimate behavior like using the unsolicited data as a variable length control section and have the R2T come from a device that paces (forces the rate) the initiator. Again we think that a variable length unsolicited data piece is legitimate and as long as the performance will be impacted only for the specific initiator we should abstain from imposing additional restrictions to it. As a side note I would like to point out that a clever target that has no restriction on data order (can work wit EMDP=1) can issue R2T immediately after seing that the immediate data are not enough to satisfy ExpectedDataLength in any case, and if realizing later that it misses data (the gap) it can request them with an additional R2T. And BTW - congratulations for your implementation - one of the firsts to use multiple connections flawlessly. Regards, Julo sandeepj@research.bell-labs.com (Sandeep Joshi) on 19-07-2001 20:17:39 Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) To: "ips" cc: Subject: Re: iSCSI Plugfest at UNH > > +++ Should we really? A good driver will do what it can to optimize its use > > of resources while getting maximum performance. IMHO a warning to > > implementers will be enough and I will try to put it in.++++ Julian, Matthew Burnbridge explained this well at the plugfest meeting. The problem is that the target does not know if its dealing with a good initiator or a bad one. The protocol is introducing needless network delay (wait states!). Why wait for the final bit if the target has enough memory to handle all the data right away (and could send R2Ts *NOW*) ? Regards, -Sandeep > 12.If unsolicited data is negotiated, it appears that it still does not > have to be used. In practice this can lead to performance > inefficiencies. > > Consider the following: > - Unsolicited data has been negotiated to YES but immediate data > is NO (although a problem still exists even if this is YES). > > - The initiator sends a SCSI command with F=0, W=1 and a large > Expected Transfer Length field (greater than FirstBurstSize). > > - When the target receives this command, it knows that unsolicited > data follows (because F=0), but does NOT know how much (there > is a maximum determined by the negotiated FirstBurstSize, but > there > is no requirement that the initiator actually send this much). > Therefore, the target cannot at this time send out an R2T to get > the "rest" of the data -- it must wait to receive data PDUs > until it gets the F=1 set on one of these data PDUs, and then > compute the amount of data to ask for in the R2T. This may > introduce needless delay. > > To avoid this situation, the standard should either: > - require that when unsolicited data is to be sent, that the > amount be min(Expected Transfer Length, FirstBurstSize), > - alternatively, provide a field in the SCSI command that > allows the initiator to indicate how much unsolicited data > follows. > > > +++ Should we really? A good driver will do what it can to optimize its use > > of resources while getting maximum performance. IMHO a warning to > > implementers will be enough and I will try to put it in.++++ From owner-ips@ece.cmu.edu Fri Jul 20 03:49:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09094 for ; Fri, 20 Jul 2001 03:49:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K6Kw926604 for ips-outgoing; Fri, 20 Jul 2001 02:20:58 -0400 (EDT) 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 f6K6Kug26597 for ; Fri, 20 Jul 2001 02:20:56 -0400 (EDT) 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 IAA180306 for ; Fri, 20 Jul 2001 08:20:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6K6Knt31038 for ; Fri, 20 Jul 2001 08:20:49 +0200 Importance: Normal Subject: Re: Unsolicited data To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 20 Jul 2001 09:26:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 09:20:48 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The warning is not wrong. Variable length unsolicited data might be a legitimate requirement is some applications. And a clever target can take care of that by issuing an R2T "in advance" and fill the gap (if any) later. However in order to let only consenting initiators and targets do this I will add the following text to 2.3.5 If the Expected Data Transfer Length is higher than the FirstBurstSize (the negotiated maximum amount of unsolicited data the target will accept) the initiator SHOULD send the maximum size of unsolicited data. The target MAY terminate in error a command for which the Expected Data Transfer Length is higher than the FirstBurstSize and for which the initiator sent less than FirstBurstSize unsolicited data. In addition 2.4.3 reads: This field contains iSCSI service response. Valid iSCSI service response codes are: 0x00 - Command Completed at Target 0x01 - Target Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited data rejected 0x04 - Not enough unsolicited data 0x05 - Command in progress 0x80-0xff - Reserved for Vendor-Unique Responses N.B. Response code 0x04 must be used only if the target does not support output (write) operations in which the total data length is higher than FirstBurstSize but the initiator sent less than first burst size and out-of-order R2Ts can't be used. The Response is used to report a Service Response. The exact mapping of the iSCSI response codes to SAM service response symbols is outside the scope of this document. Certain response codes MUST be associated by the target with a Check Condition Status as outlined in the next table: +--------+------------------------------+---------------------------+ | Code | Reason | with SCSI CHECK CONDITION | +--------+------------------------------+---------------------------+ |0x01 | Target Failure | ASC = 0x44 ASCQ = 0x00 | +--------+------------------------------+---------------------------+ |0x02 | Delivery Subsystem Failure | ASC = 0x47 ASCQ = 0x03 | +--------+------------------------------+---------------------------+ |0x03 | Unsolicited data rejected | ASC = 0x49 ASCQ = 0x00 | +--------+------------------------------+---------------------------+ |0x04 | Not enough unsolicited | ASC = 0x49 ASCQ = 0x00 | +--------+------------------------------+---------------------------+ |0x05 | SNACK rejected | ASC = 0x47 ASCQ = 0x03 | +--------+------------------------------+---------------------------+ As listed above, each defined response code MUST be used (under the conditions described in the 'Reason' field), only when the corresponding SCSI CHECK CONDITION is signaled, to convey additional protocol service information. A SCSI CHECK CONDITION with the ASC and ASCQ values as tabulated MUST be signaled by iSCSI targets for all the instances in this document referring to usage of one of the above defined response codes. Please note that a response of "Command Completed at Target" may also be associated with an error status. The warning will now read: 1.1 Unsolicited data and performance Unsolicited data on write are meant to reduce the effect of latency on throughput (no R2T is needed to start sending data). In addition immediate data are meant to reduce the protocol overhead (both bandwidth and execution time). However negotiating an amount of unsolicited data for writes and sending less than the negotiated amount when the total data amount to be sent by a command is larger than the negotiated amount may negatively impact performance and may not be supported by all the targets. Regards, Julo "Robert D. Russell" on 19-07-2001 20:59:22 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Unsolicited data Julian: The warning in section 8.6 of draft 06-99 still does not solve the problem and is in fact wrong. It now reads: "However negotiating an amount of unsolicited data for writes and sending less than the negotiated amount when the total data amount to be sent by a command is larger than the negotiated amount may negatively impact performance as the targets will not be able to ask for the remainder of the data." The problem is, even if the initiator DOES send the full negotiated amount, the target does NOT know this in advance and therefore cannot send out the R2T for the rest until getting the unsolicited data PDU with the F bit set to 1. In other words, even the very best implementation of an initiator does NOT solve the problem -- the target still does NOT know what is coming because the initiator can NOT tell him. Performance is ALWAYS impacted, regardless of what the initiator does. The simplest solution would be to REQUIRE the initiator to send the negotiated amount (after all, if he doesn't want to send that much every time then why did he negotiate that much?). Then the target will know, in advance, what is coming and send out the R2T for the rest of the data WITHOUT WAITING! This is where the performance gain is to be found. (In all of the above discussion I am assuming the Expected Transfer Length is greater than the First Burst Size. The acutal requirement for sending unsolicited data is that the initiator be required to send min(Expected Transfer Length, First Burst Size) as unsolicited data if unsolicited data has been negotiated.) Thanks, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Fri Jul 20 05:01:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26597 for ; Fri, 20 Jul 2001 05:01:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K7ahT01013 for ips-outgoing; Fri, 20 Jul 2001 03:36:43 -0400 (EDT) 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 f6K7afg01009 for ; Fri, 20 Jul 2001 03:36:41 -0400 (EDT) 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 JAA204106 for ; Fri, 20 Jul 2001 09:36:35 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6K7aYJ46230 for ; Fri, 20 Jul 2001 09:36:34 +0200 Importance: Normal Subject: Re: iSCSI OpParamReset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 20 Jul 2001 10:34:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 10:36:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I am also ambivalent about it. The reason I introduced it is that it is norm in secure environments to drop things that where negotiated before establishing the secure environment. However one of the parties may have already commited to some changes before the secure environment - dropping will not help too much in this case. As a more general think any parameters negotiated during login are supposed to be "removed in block" if the login fails. It looked to me that having to implement the atomic behavior for login anyhow (for recovery) adding OpParmReset will allow more freedom in the decision about what to drop and what can stay even when negotiated before security. Julo "Rod Harrison" on 20-07-2001 06:44:14 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, "Robert D. Russell" cc: "ips" Subject: iSCSI OpParamReset Julian, I have no fundamental objection to the introduction of the OpParamReset key, however please consider the following observation. It seems an implementer has two basic choices with respect to OpParamReset. 1) Add special case code in the login phase handling to remember the initial values that might get reset. 2) Obviate (1) by always sending OpParamReset. I suspect most implementers will go for option (2), if this is so we might as well mandate that behaviour and remove the need for key. - Rod ------------------------------------------------------------ -------------------- 1. Exactly what should happen if operational parameters are sent by the initiator during the security phase of login? In section 4.2 the standard says: "-The iSCSI parameter negotiation (non-security parameters) SHOULD start only after security is established. This should be performed using text commands." and: "When establishing the security context, any operational parameters sent before establishing a secure context MAY be ignored by both the target and the initiator." There is a problem with the meaning of "ignore" -- should the target: 1. not respond to these operational keys at all, or 2. respond with key=reject, or 3. respond with a valid value and then just not use these values. In this case, how does the initiator know whether or not the target is ignoring these parameters or not? A final note: The standard seems to allow the initiator to send operational parameters when establishing the security context, get back a valid value from the target, and then ignore the entire negotiation anyway. Is this legal? In this case, how does the target know that the initiator is ignoring these parameters? +++ It is standard practice (and legal) in most protocols to reset the operational parameters to previous values at the end of the security phase negotiation if the channel is becoming a secure channel WE have two options: a) assume that this happens at every SecurityContextComplete b) say explicitly that it happened - e.g., the target or initiator decide that the channel is now more secure than before and say explicitly something like OpParmReset=yes I will assume that is b that most of you want and I will say so in 7 unless I hear otherwise TODAY: here is the text: 01 OpParmReset Use: IO Who can send: Initiator and Target OpParmReset= OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before login. Either the initiator or target may choose to do so but only after and only if a SecurityContextComplete handshake is completed on the connection. The resetting should involve only parameters that where set during login on the connection in which the OpParmReset is issued. Please note that since either initiator or target may request this behavior there is no need to reply. and 4.3 reads: 1.1 Operational Parameter Negotiation During the Login Phase Operational parameter negotiation during the login MAY be done: - starting with the Login command if the initiator does not offer any security/ integrity option - starting immediately after the security/integrity negotiation if the initiator and target perform such a negotiation - starting immediately after the Login response with Final bit 0 if the initiator does offer security/integrity options but the target chose none. An operational parameter negotiation on a connection SHOULD not start before the security/integrity negotiation if such a negotiation exists. Operational parameters negotiated inadvertently before the security/integrity negotiation MAY be reset after the security/integrity negotiation at the explicit request of the initiator or target. ++++ TargetName=iqn.com.acme.diskarray.sn.88 HeaderDigest=crc-32C,none DataDigest=crc-32C,none AuthMethod:KRB5,SRP,none T-> Login-PR, HeaderDigest=none, DataDigest=none, AuthMethod=none I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes I-> Text ... iSCSI parameters T-> Text ... iSCSI parameters And at the end: I-> Text optional iSCSI parameters F bit set to 1 T-> Login "login accept" TargetName=iqn.com.acme.diskarray.sn.88 Note that SecurityContextComplete=yes is required although no security mechanism was chosen. ++++ From owner-ips@ece.cmu.edu Fri Jul 20 05:04:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27226 for ; Fri, 20 Jul 2001 05:04:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K7ahB01017 for ips-outgoing; Fri, 20 Jul 2001 03:36:43 -0400 (EDT) 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 f6K7aeg01008 for ; Fri, 20 Jul 2001 03:36:42 -0400 (EDT) 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 JAA357688 for ; Fri, 20 Jul 2001 09:36:34 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6K7aWJ129192 for ; Fri, 20 Jul 2001 09:36:32 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 20 Jul 2001 09:53:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 10:36:32 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, comments in text - Julo Steve Senum on 19-07-2001 23:28:55 Please respond to Steve Senum To: ietf-ips cc: Subject: iSCSI Login Questions Julian: Is the following valid (taking into account the changes requested from the UNH Plugfest)? I: Login: AuthMethod:none SecurityContextComplete=Yes I would assume not, that the initiator must wait until after the initial exchange of the AuthMethod, HeaderDigest, and DataDigest keys to send the SecurityContextComplete key. +++ It is correct because either the target will answer with T->Login AuthMethod:none SecurityContextComplete=Yes (accept and perhaps goon) or it wil send a login reject and drop the connection +++++ Also, if further simplification of the login process is desired, the working group might want to consider requiring the initiator to send the AuthMethod HeaderDigest and the DataDigest keys on the first login, so that the login sequence would always look like: I: Login: AuthMethod=a1,a2,aN HeaderDigest=hd1,hd2,hdN DataDigest=dd1,dd2,ddN T: LoginPR: AuthMethod=a1 HeaderDigest=hd1 DataDigest=dd1 ...Authentication phase, if needed I: Text: SecurityContextComplete=yes T: Text: SecurityContextComplete=yes ...Operational Parameter Negotiating phase ...Full Feature Phase +++ We will consider it +++ Regards, Steve Senum From owner-ips@ece.cmu.edu Fri Jul 20 05:48:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11183 for ; Fri, 20 Jul 2001 05:48:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6K8W5K03954 for ips-outgoing; Fri, 20 Jul 2001 04:32:05 -0400 (EDT) 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 f6K8W4g03950 for ; Fri, 20 Jul 2001 04:32:04 -0400 (EDT) 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 KAA165560; Fri, 20 Jul 2001 10:31:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6K8VqJ89460; Fri, 20 Jul 2001 10:31:52 +0200 Importance: Normal Subject: new iSCSI draft 07.txt To: internet-drafts@ietf.org Cc: bassoon@YOGI.PDL.CMU.EDU, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 20 Jul 2001 11:37:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 20/07/2001 11:31:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk On behalf of a group of authors from several organizations as part of the IPS working group I submit a revision of an IETF-draft for immediate publication. It specifies iSCSI - a SCSI Over TCP protocol and the file name is "draft-ietf-ips-iSCSI-07.txt". It completely replaces "draft-ietf-ips-iSCSI-06.txt". The draft can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-07.txt Julian Satran - IBM Research Laboratory at Haifa From owner-ips@ece.cmu.edu Fri Jul 20 10:05:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10617 for ; Fri, 20 Jul 2001 10:05:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KCTqi27615 for ips-outgoing; Fri, 20 Jul 2001 08:29:52 -0400 (EDT) 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 f6K9Zfg07353 for ; Fri, 20 Jul 2001 05:35:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05167; Fri, 20 Jul 2001 05:34:44 -0400 (EDT) Message-Id: <200107200934.FAA05167@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-ifcp-03.txt Date: Fri, 20 Jul 2001 05:34:44 -0400 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 : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-03.txt Pages : 78 Date : 19-Jul-01 This document specifies an architecture and gateway-to-gateway protocol for the implementation of Fibre Channel fabric functionality on a network in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of existing Fibre Channel storage products to an IP network by supporting the fabric services required by such devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-ifcp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-ifcp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719145648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145648.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 20 13:38:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08698 for ; Fri, 20 Jul 2001 13:38:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KFumC12750 for ips-outgoing; Fri, 20 Jul 2001 11:56:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraac.compuserve.com (ds-img-rel-3.compuserve.com [149.174.206.154]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6KFukg12745 for ; Fri, 20 Jul 2001 11:56:46 -0400 (EDT) Received: (from mailgate@localhost) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id LAA16294 for ips@ece.cmu.edu; Fri, 20 Jul 2001 11:56:40 -0400 (EDT) Received: from compuserve.com (hil-qbu-ptg-vty59.as.wcom.net [206.175.103.59]) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id LAA16246 for ; Fri, 20 Jul 2001 11:56:33 -0400 (EDT) Message-ID: <3B581F7F.B6ABDCB3@compuserve.com> Date: Fri, 20 Jul 2001 06:09:35 -0600 From: Ralph Weber Reply-To: ENDL_TX@computer.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 Subject: Re: FCIP -03 comments (part 2) References: <277DD60FB639D511AC0400B0D068B71E070A5F@corpmx14.us.dg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, This is a continuation of the response started in a previous message. Black_David@emc.com wrote: ..snip (see part 1).. > -- Section 6.4 > > An FC Fabric to IP Network interface product SHALL > contain one FCIP Entity for each IP Address assigned to the product. > > This looks overspecified for a couple of reasons -- it prevents > multiple FCIP entities on different TCP ports at the same IP > address and it appears to force implementation of an FCIP entity > on an interface intended solely for management traffic. Needless > to say, this is overspecified - I'm guessing that the real requirement > is that an FCIP entity MUST NOT span multiple IP addresses, but > more than one FCIP entity MAY share an IP address by using > different TCP ports. This has some slight effects on wording > elsewhere, but I fail to see the reason for forbidding two FCIP > entities behind a single IP address. The FCIP Authors have agreed to review this issue, but are not able to resolve it in time to meet the cutoff time at the Internet Drafts office. > -- Section 6.5 > > Last sentence needs to explain what "coordinate flow control" > means, possibly by providing a (non-normative) example, or > a pointer to Section 7.4. A cross reference to section 7.4 will be added in rev 04. > -- Figures 4-6 > > Should probably have an additional figure that shows > at least one FCIP Entity, FC_LEP, and FC_DE in a single > diagram. I don't know how to use stick figures to communicate the concept that there can be multiple FCIP_LEPs in which there are multiple FCIP_DEs in the confined line widths of an Internet Draft. I believe that any figure that fails to communicate that point is a disservice to the reader. I will add the requested figure only if it is described as a requirement for approval and then under protest. > -- Section 6.6 > > Last sentence: > > Data bytes arriving at the Encapsulated Frame Receiver Portal > SHOULD be transmitted to the FC Transmitter Portal as described in > steps 5 through 7, but this MAY NOT always be the case. > > In its current form this does not express a useful requirement > and hence the "SHOULD" and "MAY NOT" need to be lower case. I > think words are needed here to say "MUST be transmitted in the > absence of errors" and note that error detection and recovery > MAY result in discarding frames without errors as a consequence > of an error detected in an earlier frame. The FCIP Authors expressed similar concerns. In rev 04, they already have changed the cited sentence to read: "In the absence of errors, data bytes arriving at the Encapsulated Frame Receiver Portal SHALL be de-encapsulated and forwarded to the FC Transmitter Portal as described in steps 5 through 7." > -- Section 6.6.1 > > Please add a diagram of the whole header in addition to the > protocol-specific fields. I will do this in rev 05 provided it it confirmed that the IETF practice is to replicate requirements in multiple RFCs so that a change in one RFC requires several others to be revised concurrently. > -- Section 6.6.2.1 > > What is being said here is correct, but needs to be reworded. > Reference the TCP RFC, note that it REQUIRES in order delivery, > generation of TCP checksums and checking of TCP checksums, then > say that hence any traffic passed from TCP to the FC_LEP will > be in order and free of errors detectable by the TCP checksum. Will do > -- Section 6.6.2.2 > > Bytes delivered through the Encapsulated Frame Receiver Portal that > are not correctly delimited as defined by the FC Frame Encapsulation > [23] SHOULD NOT be forwarded on to the FC Entity. > > This sounds like a "MUST NOT" rather than a "SHOULD NOT". Is it ever > acceptable to deliver malformed traffic to the FC Entity? The FCIP Authors agreed with you and requested that 'SHOULD NOT' be changed to 'SHALL NOT'. > Synchronization SHALL be verified by checking the validity > and positioning of any combination of the following FC Frame > Encapsulation information: > > "any combination of" is much too weak - checking only that > the timestamp fields are plausible could result in the delivery > of complete garbage. Some words may be needed here about the > various error checks done at the FCIP entity, FC entity, and > FC frame receiver (e.g., frame CRC). Use this to state the > functional requirement of what the FCIP entity MUST check as > as a minimum to ensure correct operation, and then offer the > others as SHOULDs or MAYs. The FCIP Authors had similar problems with the cited text be changed to: "Synchronization SHALL be verified on each FCIP Frame. The validity and positioning of the following FCIP Frame information SHOULD be used to verify synchronization:" There is an open issue among the FCIP Authors regarding the need for specificity about what constitutes a loss of synchronization. This probably will result in additional changes in rev 05 (since the Internet Drafts deadline looms too close for resolution in 04). Examples of conditions that may be declared to be indicators of loss of synchronization are: a) failure of the comparison between length and -length b) two consecutive header errors in other fields There is a reluctance to standardize on one minimum list of validation criteria because several equally valid lists have been proposed. It is the determination of the FCIP Authors that choices of validation criteria have no effect on product interoperability and thus are not an absolute necessity in FCIP. > -- Section 6.6.2.3 > > Changes to this section were discussed as part of the Annex > E discussion. This section is heavily revised in rev 04. > -- Section 6.6.2.4 > > This section will change as part of the forthcoming synchronization > revisions noted above. Unfortunately, there will not be time to get these changes in rev 04. > -- Section 7.1.1, and 7.1.2 > > It looks like the FCIP Entities are signaling/negotiating some > parameters over a newly created TCP connection; the details of how this > is done and requirements for doing it need to be specified. Some of this > interaction is a bit funky - if some of these parameters are passed inband > over the TCP connection, the result is that one has to accept the TCP > connection request in order to get the parameters to decide whether to > accept the TCP connection request. That wasn't what was intended, and > hence some rewording is needed. The FCIP Authors agree with you but have been unable to get that work to the top of their to do list yet. > -- Section 7.2 and subsections, Section 7.3 > > Think very carefully about how many of these are actually involved > in FCIP interoperability, and delete the ones that aren't (e.g., > 7.2.5). The standards status of TCP options can change independent > of TCP, hence this sort of dependency needs to be minimized. If 7.2.4 > remains, some explanation and/or reference to how to implement this > is needed. Move the timeout "SHOULD" in Section 7.3 to the section > on timeout management and delete the rest of 7.3. After QoS the largest count of open issues markers for the FCIP Authors occur in this area. > -- Section 7.4 > > Need an example of *how* an FC Entity could reduce the rate of > FC Frame arrival (non-normative). I'm concerned that the last sentence > of this section could be read as a modification to TCP's specified > behavior. This discussion might be better phrased in terms of buffer > resources available to a TCP connection - when the FC Entity can't > accept frames at their initial arrival rate, the buffer fills up > and TCP's window shrinks accordingly because the advertised window > is based on the size of the buffer. I will note this as an open issue for the FCIP Authors. I will need their help constructing such an example. > -- Sections 8.2 and 8.4 > > Delete and/or modify these in accordance with the comment that > if an external security gateway is used, it is logically a part > of the FCIP Entity because the interface between the FCIP implementation > and the security gateway will not conform to the security requirements > of this specification. As with the note on 12 b) in section 5, please post this as a separate issue because several of the FCIP Authors believe the described behaviors are appropriate for FCIP and I cannot represent their opinions. Thanks. Ralph... From owner-ips@ece.cmu.edu Fri Jul 20 15:51:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20801 for ; Fri, 20 Jul 2001 15:51:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KIGSv23022 for ips-outgoing; Fri, 20 Jul 2001 14:16:28 -0400 (EDT) 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 f6KIGQg23016 for ; Fri, 20 Jul 2001 14:16:27 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA17046 for ; Fri, 20 Jul 2001 14:16:21 -0400 (EDT) Message-ID: <3B5874DB.1195A75D@cisco.com> Date: Fri, 20 Jul 2001 13:13:47 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions 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, Thanks for the reply. I have a few of more cases I would like to be sure of. Please comment on whether you think the given sequence is valid. Case 1: I-> Login AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes Case 2: I-> Login AuthMethod=none HeaderDigest=crc-32C,none DataDigest=crc-32C,none T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Case 3: I-> Login AuthMethod=none HeaderDigest=crc-32C,none DataDigest=crc-32C,none SecurityContextComplete=yes T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes Thanks, Steve Senum From owner-ips@ece.cmu.edu Fri Jul 20 17:58:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04503 for ; Fri, 20 Jul 2001 17:58:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KLG3a07969 for ips-outgoing; Fri, 20 Jul 2001 17:16:03 -0400 (EDT) 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 f6KLG2g07965 for ; Fri, 20 Jul 2001 17:16:02 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA21169 for ; Fri, 20 Jul 2001 17:15:56 -0400 (EDT) Message-ID: <3B589E44.8191C8D1@cisco.com> Date: Fri, 20 Jul 2001 16:10:28 -0500 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: iSCSI: New SLP Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A new version of the iSCSI SLP template draft is now available at: ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-slp-01.txt The following changes have been made since -00: 1. Fixed examples (change from fqn. to iqn.); add enterprise number (pending date discussion on list). 2. Added a portal-group tag (aggregation tag) to the iSCSI target template. 3. Fixed up references to indicate new draft revisions. 4. Added commentary on using Unicast SLP, as discussed in the prior SendTargets thread. 5. Made modifications to the wording of the SNS/SLP interaction stuff. I have relabled the generic term "storage name service" as "storage management service" to reflect its role, and instead of the text showing how to use either/or for discovery, the text now shows how a management service can provide the SLP SA on behalf of the targets it manages. 6. Removed the ability to register a default or canonical target. Each individual target must now be registered. I have not yet added references to SLP notification using RFC 3082. I think that we have to get that going as a separate discussion first. Given that there's a good bit of interest in this functionality from us iSCSI folks, and the SLP people are moving from proposed standard to draft standard, this will be a good time to do so. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 20 17:59:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04775 for ; Fri, 20 Jul 2001 17:59:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KKUNY02835 for ips-outgoing; Fri, 20 Jul 2001 16:30:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6KKULg02831 for ; Fri, 20 Jul 2001 16:30:21 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Jul 2001 15:30:15 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482630B0@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" Subject: iSCSI draft-07 Padding Date: Fri, 20 Jul 2001 15:27:36 -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 couldn't find anything in the latest iSCSI spec (draft-07) that prevents someone from issuing multiple padded PDU's for iSCSI Data In/Out segments. I guess I'm worried that someone could issue padded odd-length write/read data when it wasn't necessary. Example: When moving a 512 byte disk sector an initiator/target could legally issue 512 1-byte DataSegmentLength messages (each padded up to a 32-bit boundary). This isn't the sort of data stream one would expect, but it's allowed in the draft. This also leads into whether fixed or minimum length data segments (for all but the last) would be nice to include as part of the spec. It may result in a simpler software/hardware design. From owner-ips@ece.cmu.edu Fri Jul 20 18:01:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05212 for ; Fri, 20 Jul 2001 18:01:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KL67m07244 for ips-outgoing; Fri, 20 Jul 2001 17:06:07 -0400 (EDT) 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 f6KL66g07240 for ; Fri, 20 Jul 2001 17:06:06 -0400 (EDT) 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 QAA72542 for ; Fri, 20 Jul 2001 16:58:03 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6KL65562980 for ; Fri, 20 Jul 2001 15:06:05 -0600 Importance: Normal Subject: iSCSI: draft.ietf.ips-iscsi-name-disc-02.txt To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Kaladhar Voruganti" Date: Fri, 20 Jul 2001 22:06:03 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/20/2001 02:06:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk A new version of the naming and discovery IETF draft (version 2) has been produced. It will be available soon at the web site: http://www.haifa.il.ibm.com/satran/ips The key points described in this draft are: 1) iSCSI architecture figure and its description. 2) iSCSI naming mechanism. 3) iSCSI discovery mechanism. The SendTargets command details will now be available in the main iSCSI draft. Kaladhar Voruganti Storage Group Computer Science Department IBM Almaden Lab San Jose, CA From owner-ips@ece.cmu.edu Fri Jul 20 19:06:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26111 for ; Fri, 20 Jul 2001 19:06:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KLj2X09967 for ips-outgoing; Fri, 20 Jul 2001 17:45:02 -0400 (EDT) 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 f6KLj1g09963 for ; Fri, 20 Jul 2001 17:45:01 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA25827 for ; Fri, 20 Jul 2001 17:44:55 -0400 (EDT) Message-ID: <3B58A510.EC380E74@cisco.com> Date: Fri, 20 Jul 2001 16:39:28 -0500 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: iSCSI: New MIB draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A new version of the iSCSI MIB draft is available at: ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-02.txt A matching, informal UML model of the MIB is at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-02.pdf A matching table structure drawing is at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-02.pdf Changes from draft -01 include: - Simplified the definitions of the connection states - Added ISID, TSID, and CID - Added instance-level stats for digest, format, and connection errors. - Added portal group tags - Added session attributes to match -07. - Changed iscsiSsnType to iscsiSsnDirection; re-used iscsiSsnType. - Removed format errors from the session; a format error is a bug, and will destroy the session anyway. - Added notifications for login failures (initiator and target), and abnormal session failures caused by digest, connection, and/or format errors. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 20 19:09:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26968 for ; Fri, 20 Jul 2001 19:09:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KM3Zw11174 for ips-outgoing; Fri, 20 Jul 2001 18:03:35 -0400 (EDT) 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 f6KM3Yg11168 for ; Fri, 20 Jul 2001 18:03:34 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Fri, 20 Jul 2001 18:03:28 -0400 Message-ID: <25369470B6F0D41194820002B328BDD20266CD@ATLOPS> From: Sanjay Goyal To: "'Julian Satran'" Cc: ips@ece.cmu.edu, Sanjay Goyal Subject: RE: new iSCSI draft 07.txt Date: Fri, 20 Jul 2001 18:03:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi It is regarding Rev7.0, 6.1 Standard connection state diagram The transition condition from S12 to S13 seems illogical to me. After both sides close the connection, should not the state be S1. to me either the condition T18 is not correct or the transition to S13 is not correct. Please clarify the issue. Regards Sanjay Goyal -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 20, 2001 4:38 AM To: internet-drafts@ietf.org Cc: bassoon@YOGI.PDL.CMU.EDU; ips@ece.cmu.edu Subject: new iSCSI draft 07.txt On behalf of a group of authors from several organizations as part of the IPS working group I submit a revision of an IETF-draft for immediate publication. It specifies iSCSI - a SCSI Over TCP protocol and the file name is "draft-ietf-ips-iSCSI-07.txt". It completely replaces "draft-ietf-ips-iSCSI-06.txt". The draft can be found at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-07.txt Julian Satran - IBM Research Laboratory at Haifa From owner-ips@ece.cmu.edu Fri Jul 20 20:14:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24061 for ; Fri, 20 Jul 2001 20:14:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6KMjtg14096 for ips-outgoing; Fri, 20 Jul 2001 18:45:55 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6KMjsg14092 for ; Fri, 20 Jul 2001 18:45:54 -0400 (EDT) Received: from colosus2.cup.hp.com (colosus2.cup.hp.com [15.13.128.145]) by palrel2.hp.com (Postfix) with ESMTP id 5B564187B; Fri, 20 Jul 2001 15:45:53 -0700 (PDT) Received: from hp.com (IDENT:plabat@pl703521.cup.hp.com [15.13.133.216]) by colosus2.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id PAA04727; Fri, 20 Jul 2001 15:45:52 -0700 (PDT) Message-ID: <3B58B6D9.24AE565E@hp.com> Date: Fri, 20 Jul 2001 15:55:21 -0700 From: Pierre Labat Organization: Hewlett Packard iSCSI-SISL X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Michael Schoberg Cc: ips@ece.cmu.edu Subject: Re: iSCSI draft-07 Padding References: <3C7122FAF06DD5118ED60050047336482630B0@esply01.cnt.com> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael Schoberg wrote: > I couldn't find anything in the latest iSCSI spec (draft-07) that prevents > someone from issuing multiple padded PDU's for iSCSI Data In/Out segments. > I guess I'm worried that someone could issue padded odd-length write/read > data when it wasn't necessary. Example: When moving a 512 byte disk sector > an initiator/target could legally issue 512 1-byte DataSegmentLength > messages (each padded up to a 32-bit boundary). This isn't the sort of data > stream one would expect, but it's allowed in the draft. Michael, I think that the performance will be so poor that it will bury the vendor before he had time to sell anything. > > > This also leads into whether fixed or minimum length data segments (for all > but the last) would be nice to include as part of the spec. It may result > in a simpler software/hardware design. I don't like this idea. The protocol must have the flexibility to work with PDUs as small as needed to put one PDU per TCP segment. This will help a lot the hardware to deal with out of order or missing TCP segments at high rates. If we don't have this possibility we need to rely on an intermediate chuncking protocol that we don't have now, or on the markers but they moved as an annex. Hence to preserve all our chances to have a protocol that flies at 10G i would not put this minimum size limitation. Regards, Pierre From owner-ips@ece.cmu.edu Fri Jul 20 22:00:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA27685 for ; Fri, 20 Jul 2001 22:00:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6L0Usm20463 for ips-outgoing; Fri, 20 Jul 2001 20:30:54 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6L0Uqg20459 for ; Fri, 20 Jul 2001 20:30:52 -0400 (EDT) Received: from london ([147.11.45.213]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id RAA14707; Fri, 20 Jul 2001 17:30:43 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI Login Questions Date: Fri, 20 Jul 2001 17:31:52 -0700 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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I am in favour of Steve's suggestion. One thing that I think was clear to everyone who attended the plugfest is login complexity / flexibility must be reduced and simplified. If the spec were to mandate that the login PDU MUST only contain security parameters I believe we would make a significant move towards better login interoperability. The initiator should be allowed to indicate SecurityContextComplete in the login PDU, but only if it supports no security. i.e. I->T: Login SecurityContextComplete=yes or I->T: Login AuthMethod=none HeaderDigest=none DataDigest=none SecurityContextComplete=yes should both be allowed. But if the initiator is willing to negotiate security parameters it MUST NOT send the SecurityContextComplete=yes in the login PDU, which is the example given by Steve below. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Thursday, July 19, 2001 11:54 PM To: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions Steve, comments in text - Julo Steve Senum on 19-07-2001 23:28:55 Please respond to Steve Senum To: ietf-ips cc: Subject: iSCSI Login Questions Julian: Is the following valid (taking into account the changes requested from the UNH Plugfest)? I: Login: AuthMethod:none SecurityContextComplete=Yes I would assume not, that the initiator must wait until after the initial exchange of the AuthMethod, HeaderDigest, and DataDigest keys to send the SecurityContextComplete key. +++ It is correct because either the target will answer with T->Login AuthMethod:none SecurityContextComplete=Yes (accept and perhaps goon) or it wil send a login reject and drop the connection +++++ Also, if further simplification of the login process is desired, the working group might want to consider requiring the initiator to send the AuthMethod HeaderDigest and the DataDigest keys on the first login, so that the login sequence would always look like: I: Login: AuthMethod=a1,a2,aN HeaderDigest=hd1,hd2,hdN DataDigest=dd1,dd2,ddN T: LoginPR: AuthMethod=a1 HeaderDigest=hd1 DataDigest=dd1 ...Authentication phase, if needed I: Text: SecurityContextComplete=yes T: Text: SecurityContextComplete=yes ...Operational Parameter Negotiating phase ...Full Feature Phase +++ We will consider it +++ Regards, Steve Senum From owner-ips@ece.cmu.edu Fri Jul 20 23:42:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26294 for ; Fri, 20 Jul 2001 23:42:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6L2Kbh26652 for ips-outgoing; Fri, 20 Jul 2001 22:20:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6L2KZg26645 for ; Fri, 20 Jul 2001 22:20:35 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id B9D2C100B for ; Fri, 20 Jul 2001 19:20:34 -0700 (PDT) Received: from rose.hp.com (sindhu.rose.hp.com [15.9.210.155]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id TAA25624 for ; Fri, 20 Jul 2001 19:21:42 -0700 (PDT) Message-ID: <3B58E738.E49B116A@rose.hp.com> Date: Fri, 20 Jul 2001 19:21:44 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI state transitions Content-Type: multipart/mixed; boundary="------------270D8844FEF77645E1AF6117" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------270D8844FEF77645E1AF6117 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All: Excuse my posting of the (relatively small sized, 27KB) pdf file with the iSCSI state diagrams. I'll post a URL shortly, but I wanted to get this out sooner to give reviewers a graphical description of rev07, section 6. This was reviewed in the ERT forum, and the ASCII versions of this slide set were incorporated into rev07. Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard, Roseville cbm@rose.hp.com --------------270D8844FEF77645E1AF6117 Content-Type: application/pdf; name="iscsi_states.pdf" Content-Disposition: inline; filename="iscsi_states.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE2IDAg UiANL1Jlc291cmNlcyAyIDAgUiANL0NvbnRlbnRzIDMgMCBSIA0vUm90YXRlIDkwIA0vTWVk aWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1l bmRvYmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgXSANL0Zv bnQgPDwgL1RUMiAyMiAwIFIgL1RUNCAzMSAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgNDMg MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAv Q3M1IDIzIDAgUiA+PiANPj4gDWVuZG9iag0zIDAgb2JqDTw8IC9MZW5ndGggMTY5MiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieRX23LbNhB951fgkeyEMBZ39q1x0k4y 46QN+ebkQZXkRKkttZbSTL8j+eAubrxLrT2T1G3HMyZxeLC7OLsLQGfne0WWewL+b7/Mzn6o gbzdZ0A2JBOaKg7EqPBUkpHScEZu19lV9rjJzpqG47TmKmPEUiZJ6f8zonRFK84UURYoZ0yT 5iZjlPmPzPkp3Ujh3KXDgVnSfMwu81fr3wmjRQmMVjknF0Vp8GWBAOX5H0Tgi6aQQwAeRSLh LH5gULxpnmcsuXGglhxtMl5VpHkSHIsqOuZSB8c/Fhi7yhdv14R7E0+b7De0Iyy1vCKlQH/d wjRRglEp8WV5k509uwHyZJf95CxKg844x4VSWbkQlPTiaUGNBnKTxgoNS/+Q1klLrfUkydoR hg+KCt0C1xlwNN7xgUvKZWssDaMvnB8BkMHOdYeoYCgZBBXx6DGNl1mMKQHXWQw5AXE9yWAa Ro/L7OobVyoMCbTSpAwPrBeFIaN+KKiMBdIWoUsR5y5FPlsQi2OzL3S+dP82ZH9YHNYkJJuC dClylSZcit0crD2XYTcxX20Wb28XN/uieY8IxuD8K6WwNFyJGun4oURT3biarESKAAyECC4K wanAesRVqPz6evNLAVUH3BbgPr8vJODoQwC37iFzcl5wh74LaJyxCh+TwQK6T7/2iDIfOnpU gMFqJy+CzXVADx+D412YEqOJM9cBXAUqqQuuET0EQ7sUv9MTsBFcrUclhe4SIYMMrku+K7D1 NE4psT7y5bsNdiAWhLOI4/Wy4AI/Hz7crh+5IKULFlOe12FefLyM7ToqDqkqrG9XHbj1+H7z yWkzWrpUlpxqo02ItIWkEWNIC9ADCKjhmN0hS1RW3ROCu5OATjmWyTHULdDr73sir0G4z7gl MYOZQnG51e3e5rZSJDVgJ9F4Bf9fSvGRUm5PapWqolJVKSdWhlqa+B0qNavlf084GJcYzAon pp3YcNbCx/SqWGX7OieDouQxdqkAZpU+kqGUQXCHwMy8h6Eqi6oKJWSvHI8t8Wv16khUUEHU ri8AuL2nqlPBBGWWm5n0c2gd9jat9jKQ19Xf62Y+X5R8IuawhHTy7ZIzs1iGbufm8akYDaiH XI9JT3vqHOn0hHk9E3z3Jod7Njn8G0Q1D7PHv5w2035O+WInu1k/TKGObobtofa1NkNxUj41 ki8271eVb6xVTLyezBhJycf6DKa3t60jba51xWem2RQ60zP5OSX0dAfvCy1HQmvNH3Sdwl/U 6ZGkqZPT7la5cFJQMRL0gTT+fXfII+XI71aOadrppucj6f6Jpv/y0slJyTWporhkevayobmc yjX+FVPF1u3fyWd+wtQwvSum30QD5XzZa2codADa/Ojv+YSQiaaBIhzlEu+yxHFKQ1VOijfN 82M5Z8GknYpYmxlMT+Sv1QxNTmliInqdVOjdfYKkT5vs7HyvyHmNsPurzzHQ5wTIe8IwF+Qj QQ0uyOUbRlYZSEWlBQKVRFNAbjKpDeWsQ65bDhcVVbrPSUiPYwDrYMCJSMcRrKJy4CshPY40 VNsBJyI9jlXUDnwlpONILvGs6nMS0uNoPoonIR1HMTaKJyE9DreUDzkR6XEMG3Mi0nE0qmG8 zsIo/5aQHkdx/+xxIoIcXVG3b4PSVPm1J8QwkTgV9157nIh0HA4qVELLSUiPI2yon44TkR5H g1ezx4lIj2MlFXzAiUjHEcz4zHWchPQ4AttTDjgR6XFQKTvkRKTHiar2OJNcYNP66u9xItJx JIdRLhLS+ZJSjnKRkGk807x3nDrj2OeTQOdKpPZbwiTeriq7FRy3Olns2Goba2u1F8DQares 0eQTVhMyVWCyrDmrj3GjbBo8qklzhZurcnuj2y/jqwBnFU8QEAIT5o6Sm3gUgt/848XOnRjf k1fxvHhZlNgiObnw5wYjwVZrHbhLMdoS2u1CfaM2Ga2MP1Ya8jLs+hKPYjCk5KI7JD3jxe6w dhRcBQ+rwA4G251SJtz6viWRFdfKsNY5tDQA4WiX+aeywDWr/LOPvbMKVLsNvDtVeQo1HKqX +f6w2K72RQlAISdXO6eFzm+jJp8+bFfrq812vfrs1IGcRnHwWlD6q4HFg9sd1qDxc5Ta22+V dr9bccmb+rx+Rpa77Xa9PGx2W4KeD2tyuF1s9xsH7MnrHD8fVvR1MVr1JBeorM8F6JjplAvW 5sKadoGodWlxVdGZG5j8UJQaF4QjPOTy3dYN8dJwWPx8vfaLxNP4zwEAHwAFeQplbmRzdHJl YW0NZW5kb2JqDTQgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE2IDAgUiANL1Jl c291cmNlcyA1IDAgUiANL0NvbnRlbnRzIDYgMCBSIA0vUm90YXRlIDkwIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoN NSAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgXSANL0ZvbnQgPDwg L1RUMiAyMiAwIFIgL1RUNiAzNiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgNDMgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDIz IDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGggMjU3MSAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXS3PcxhG+76+YI+DigpjBDB68yZSdYipWFHN9 cJk5rLEgBWW5K+2ClPVD8n/T3V8PHpSSlCuVSyrF4gLT3dOPr3t6GpfX52Das7Hyd25Xl3+4 tebhvLKmN6uizIKzpgp4Bp+bdeVyc+pW96tvN6vLzcbRts39Kjd1lnuzlt/chLLJGpcHE2qb uTwvzeZxlWe5MHO2s+ZVoL0t021em82n1S/Jj92zybN0bfOsSZz5IV1X9LIlQuaSz6aglzKz iQXhQgWNy5WR2/Svmz+u8miGiaV3pDN3TWM2r2G4aNSw8yUMv03J95BsHzoywiq+26w+kp6i zmrXmHVB9qbAShOKPPOeXtrH1eXNozWvj6u/sEZfkTHnKNDMN+xC8AJeWWRVac1jXAdS7OXh a4Y2q2sR8vm4IvdtyIpyJOxX1pHySd46nzk/KotLtUX7lWA99OwnSoCiqNAGpavFuG5X6lMk 7FfqciRoPFFhXKrFdnX/DZdKTgJZU5o1HlQvgVwm/AhQrwUyFiGnyDlOkWTLanH057RMWv7p zXnYDp1BsjPrOUVcaQWnmPdQ7XGGeWOy67cPp+3jOd28Jwr5wPZDCFQaXKKVZ3mUaKwbrsmm iB7YysKDH9LCZQXVI0URkv2+/1tqm4lwSi2z36fe0uoJxAM/fGKuU8fUd6Dqjh2YUWFqJ9aH maBPloYuUltRtZs30NmBOnyC4SO2qDe6swNxB1Fzm7qSqAMUHaP/jKelg8C1rkgW5ZQIDxj4 lLxK6eiVtGVN9ZG073o6gVQQrJHWXZu6gtjD06m7YCc9O0spT26xTx9/FovUR8rYR0gJNxI8 eFngwFWBygtZEl/yya2iglu3VBNpRVo7M5y2aS3gs3dneScP6dQkENHFkbJjqYOcox9jP7OO nGAYLB0A55ceSIGG0QEuO3bg7wRGU5HBTbousyqxV4bCjKtTinzW9H7gBlaQWUoRpfoI3mBa EI5gH1SWfzuQ2kFUQl5pH0XgaS52Hoz5lBKIFZonUczjzP6uM3cJkq47foPlqzSnhVGXr1PW 8Nbc/pw2xHwjS3Pu4Ndwl4rKDHtIYRCYWeiAx9CrE4OGKN4f5xjsRfAzzJNG9G9ihViBrpmQ ruZIA9kicTOcC8GG74yGCpts5JJe0t4ozk3EuWGcmX1QWf7tQGrZ8yBHQ3imOw9cspUq/nWf MreXX1X/LiqwyS4DHE2iag6QjFoJDxGGP+Z4gLrPUKQobL5B+DWHP1aXRZw+KWZRe9FUs3OC K1yqNeI6RlxLZXGk8i+uIlKOk6KEtNA/Ut9InihsA4FHsHaaQeKx1HBh+B37zH26bqSdrQUa bmhcYA21HaIoJrWw2D4/B/7ZDmgH6q2olDAIFoBSvwClmEqinpVESegJIC7xM3gcOVhK5hxK omaACoGnBDgFiqGWMnD624GkxeCkGNxUDLWqlGJwUgwOit9N2yl4jrtM4hY2+TBXP0RIJ++g 8DOrorhLOmLzgvj3nSdcGT15t6ww6EnWxY3Zg6l95kHOox7cL/qGNql46M2velbN8A4tx+jO mZZBWgLeVZGEX0ST2g20ZyyJLx1YNLs2eiMrWHiee7gDx9zPOw7pouFEvGAntmA9zFum+jf2 tBngNui4uOw/NfCuSEd5ZV4xqAVAdQJqJXAI7cAoYigQZtt25zMHWkigLElxdm3XP0OuE9oO 0pe6uSP0o1+4+YroWAijYz6nC4sdE1AqdtBSX18LGK/QI8nXGv2PmQ+9rA5YkR87vPGdLk2q AUxMawdo6o8qfqnruYp+mBO3ICpNbZ4kL6r0dBIqHVPVprK68/TQLVR8ZSsr/DS3xnCqxwxq OUWgwWWq6y7pD5O/EvDosJ/5y0en4FaN9f6z6Jy60noaliQh9SIhQRNSJzXv90hIrQkpkZAS xjwSUgJNPybEwz8vCfEIx2tC6pgQj4TUyUJFP8yJWxCVpjZnCfER1aAJqaOs7tSEjCq+stVr QkZr1Ei6w2JXppvvXmpnqKlHvrAR4wNSDL9/eVO6cegfW6IMCVXSrNHB7YXZ0Du/OgazTC7i NUFCoKhoEflxgwfhiuWNbDgJnUcqj3GmTM4fZHUEazA7WXKfIgjao4rWOt3xpDwYyHZQ8FHI T2CqzgE9ETcrE9CUHXeEyx4sqNtBAPZaCME/6nxKPsL80qzKdvP9z0rbxQ+tKshnFg9m6xng 9Ob10+CONZQ0TVaUsisesr1gZblur8mFt5xNl5jvb8B8I+eU7MsvndQKA0jJoZRUzIHj5crh G1S23KXozuvoUBgdoi9OdaguZuevlNNHX6SJzXlEadg1BsF8e8Sa7jJ5ErB0HqX1FXx1dyAr lQYFee7TUkZD5bEkgTRAp2rSnZFKtz6aU4M2Oe38oHpOKhmNHOmqolntoIqUqkI9PFBFv3c8 sHLxWVx8mJP+dHxIbS3XF74mcCl+OQ2McwDvms0CXZw4DvOrOQ4C9r8wCXT/4vZn58YJYGuG 8caXGLvha9e8G4sntwvcalzzVnAr0DiqJW6Fnqon8AbzI7tewNcKXSHKHJTGflvxO3498dzO tCeZD8RHqygUQKFSFPCdwbNp1CLM/nmudAeiTmxWJ7Yi0VSNnvRDvzCBjzU7OnUEmfqyq3z8 nIpGDjHiL60AdStzVgHQ53BXU52GBd4OdRoE7waN2KIta9Vabsu2UBJ9/706i3WtPrr0zVuZ Wl6n7PBP8gsgG6lMPvEGL7e42a/nixvTPUNfF+ca1oqid5IBHRyt1mGTLDbswJsdkmp2SEaF 6kqay/AhnK2aOooeWEIidF63kXjuFqdQDXzZqsfvJb0Zh/knSEzKspn+rj7i/99HzKKw6wm4 cgGcBXCegGuSwB+4Y+XW+OClun1N37w/pfCaqyKgVOlditNRpY6vsU75ykRREdRcnzbgGrVo EPrOyqL8TmITuGphHMSUGNqiA+hgdzzQ52iiXprpEH89rBJhjbXAXxmN1AG6InDnjgiOOH2e gjDq0j1fbTTxsFd73iYq5pEJ9rXitBU1Bm4j8G4eboozOT+R9VhuAV4IAGku809UKUUmgznO XT06qCTpiU4adz3rFmNDVCuqZzvpoQO46IlSMKGKd1DVzAYYHoJ4hOEGYStGJvAIU3FXi/QT jU7Uwg/gnnnOqpIP0lqOoLGzcpawcderUIvHUWeNEAlR8KTkj0/dQnnkf0pLfKzNeHzAZa3+ qOwlHr3sOOzA69vtQqg/6qbRcqvP/rnTPeYuUdpvL4G45tkt8KTJZ9R8z1Njk9xA6s0/nWWb WYuUmZSR0afMpXTj7bCUjyKu2gpXb4l2VQITZv1HM2r9vzuj5sZ5s6b/3NCxKWtqkLakG186 5eM4fOkYVjM+SX97fXtjWi7PdqDaMOdhO9CJOm0P554JZyoGYg+7jE7T5v3qu83qHwMA+rhi OgplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE2 IDAgUiANL1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vUm90YXRlIDkwIA0v TWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+ IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgXSAN L0ZvbnQgPDwgL1RUMiAyMiAwIFIgL1RUNiAzNiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEg NDMgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDYgMCBSID4+IA0vQ29sb3JTcGFjZSA8 PCAvQ3M1IDIzIDAgUiA+PiANPj4gDWVuZG9iag05IDAgb2JqDTw8IC9MZW5ndGggMTM1MiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiexXzXLcNgy+6ylwJDMrmaRI/SSn 1M503Jm0aVY5JT1sJTqr1N5NV4odP0jetwBBar0ep80DdDKxiI/4I/ARps/OJwf9BDr8m/rs 7Oe1ho9TpmGErKwKZzTUjr/OKshro+Dgs6vspy476zqDZt1VpqAplIU8/FTgqrZojXLgGl0Y pSrobjJVqLCpKE5OkkPbnnCtGujusvfirb8FVchcq6IVBl7LvMbFBoHCiHsocVEVWmgGVlER jIobSss/ul8ylcIQWFmDPpVpW+guOHDZxsDGVhz4jcTcndh89GCDi1dd9jf6KZuiMS3kJcY7 HqwCV6rCWlz0N9nZ5Y2Gi332O3m0NQYzBg9a2JZScDYUryqLutJwk2SHjm342IZKWzRNULJq kTB97YqyWoDrTBt0ftTXxhbGLs6SGGOhfQS0ZT/XR8Sxo+RQu4jHiEnus5hTAq6zmHIC4nmS wyTGiH129YyoolChaCvI+YN8cZgy1g8LaiNBFhJSi4yhFoVu6UiOcZKV6OnHCNO8mT1wswtt qUXEtJJaTDbIPeowGYph3Hw8bG4m2X1CBHOg+M45pAZRtLakzxRNvCFOtmXKQNeaM3gtS1OU yEc8hRPX1+NfUrdH4CA1bX+SVqP0hcEdfayAc2kI3TIaLQbeTA6lPm59fqBoxWmgldQ1sh1+ ZZ+e0fmOA+/ZJGYTLT2DA6vCWpoK0Zkd7VP+VE+NF4G4HitZVsdGWC4D3ZKXEq9ehSY58kP0 2xFvIBKCPKLse2lK3J6/HPyKkrSULLZcrNkufn4LEXGOVGmOoBMaJPwhseQLVzukF3eJc1my KkvOao2UkDWm4GE+bGSD59rJUkxhhem5kB0pRGGPraF6TfBBBLyX6NAiPg+0U4mCFT/IlOYy 7rTBHKlKGu+HsU8kWNk4Y1QTZ8w3mVPNO0mXoBK6DePLiFxWJEZpRZOoEtBR7CN8qmy+q3yq G5pTPlLG0ot/NbBRfH70HjI+hNibXdye6DwWiRp87CMaGTFH256V9rudj8u4g02w3AS2g8H7 G1yTsR8SSLnukuukmh98SuHz/lE20e1t0oA/4+JeEiEh4VFv3kbZn6YfR0uYKukmmGbhnIot 9bIVu+FFSHN/CARH8oXvhrbQKeaIq7g5w1vpxCuu2Fq2CEWh4/SB9SgbpCNe4Lge0ew2ya2g +uDR7hkBT9szX6ktbnv28gJSTi+nqBoy6uHNBRq8w/9wh1c/eJ+3QJ81p3NOcFxfgk+hd3M4 akk3hhxfSQqZooSadc9CsXSd6E+jmGo1b8cJzi8v8DbZohYrSo4WwbvGhZf0yx4zNHhhZ7BY C20XvPfjid7AeqEIhAK2knAP426cR4lECi+H4AwrTXMxCBy1oLO5h312S5/dsc9xtnwL7anx 3jX4k14beJFznpqapRV0RkXIkMCquSSgfA7v+DC7APuvVFAc8r4PbaP5TPjA7KGx3wTl4BoZ RNKet2YYgjiyw6nfs2703M8wPgw1jOG8PQfcsMeZwf3DKMDuPUtRP0qsfpuw4DdaMQldICEp xfNs/eHRFeKxrZffy+/FNA4YUlMQi80qHvXix8ao0fIHxmgamKfK3xmjhnl/1P2vMfq0wf9j 9Okx2h6vV72MUfpt/XCQtnGQ0h0Om1SeNgxTerDwVhinKIYZqsNAbZPQMU2ANT2bB1Yv0hiM bxNGjgfeiaxuebSGCYLHqmm4El/ZZ+IrPvZzevADviQregLoqj75q0fpZRaGp6wY1+frS+hD N+dxv4vPWXy27KaRAHqS9PQOKXBa4rMV/xr5ZwB1EPGbCmVuZHN0cmVhbQ1lbmRvYmoNMTAg MCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDE2IDAgUiANL1Jlc291cmNlcyAxMSAw IFIgDS9Db250ZW50cyAxMiAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xMSAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgXSANL0ZvbnQgPDwgL1RUMiAyMiAw IFIgL1RUNCAzMSAwIFIgL1RUNiAzNiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgNDMgMCBS ID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNDYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1 IDIzIDAgUiA+PiANPj4gDWVuZG9iag0xMiAwIG9iag08PCAvTGVuZ3RoIDM5OTQgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImcF9tu28rxnV+xj2Rg0Xsn+dg4bpCDOmkt tUWQHAQKTVtMJSoVZSf5+85tScnJKdBCgJYzOzv3mZ29vBqDakdl6De22eXrpVEPY2ZUrzIX y2CNqgKvwWu1qKxWhy67z16ussvVysKx1X2mVV1qrxb0r1WITdlYHVSoTWm1jmq1y3SpaVOj nAVCAc62iDe6Vqtv2Yf8tntSuiwWRpdNbtVNsajgYw2I0uY/lIOPWJrcMOJCCJXVsqFN8fvq t0wnMYiM3gJPbZtGrV6xYNeIYOsjC/5rAbqHfP3QqUAsrlfZv4GPq8vaNmrhQN5sWFTB6dJ7 +Gh32eWbnVGv9tnfkKOvQJi1YGjpG1QheHJedGUVjdolOABjT4uv0bVlXROR1xME6ptQujgh tpmxwHymN9aX1k/MEiiy4LwgjGc+2xkTmFFiaILgRWKC20x0SohtJionhNiTGCZQJLbZ/QtM FQ0EZRPVghfIlwAqg//AoV4SZEpCDJG1GCKKlpHk6Mci5i3+9Wo8ro+d4mCXxmOIMNMchhjP QO5hhPFgftevHw7r3VisvgAGdED5IQRIDUzRyiM9p2jKG8zJxiUNTGVYg5vC2dJBPoIVId9u +38VppkRh8Lg9pfCG4AeGTng4nN1VVjEbhgrJ+54MzEszLz19YTQ5+eCLgpTQbart8yzY+zx Gwve8xHRRk52jLxjUrUsbATskRntk/7oTwOFgLkunnRxDoRnN2CV/KmA0otwZAH5kbebHioQ EgI5Aty1hXWwfXw8dBeopEdlIeT5ks/J8k7K1ViIHwqFUEJWYV7UpbMcFZLtU8nqFIx/FliV Bj1q0MChwxqu8idZDwpkYO9AQLXFwkOr2A+JTBBHbDEm7/eDEI5neDl+LCzg5CTx3YG9hnsT cdvw2hcV6AIxJ5cz+cdceArtD3CEweZFMbxacpO7Wdx+LJScGX4h9oBNr0m8lCi4ORP1knn9 nbQQxu+BiflDuwiaNV0a/nS8fCxYaFK2lwNq98gEE1dUVD3shdGkHGu+F+oHDhWh61z92oYz lr/W83hYM4vhTAvIQTsTcyj25yTSMqhbpAznVqMlt4uaygQIIiwI9IWH/2O/J2ig/zUTbLc/ sMpsrpi0Y/TYHiDGNu8/C/aEp+oL44kPg8cN00CGEieRwmK69ijkiHbTIWYv0qaDBD0xJHtM mJTkrnknLNcPJOOAxW+TRTvK7g4CDcuGcR3JZlbqceyHB0Jwfal29ovLf1J7mO3FHTC3o3N/ eff69fUr3vrEYt68JQVJPhN/430JwEatB47f6gUHLkytCTs/hq/7jqZC99zCmYpOYqkjir+P hUbVt8i5Yp+5HO2pyMUVtG1CHaEYCm7KSNgdSevHkcMU2F1OdvlfnUm4IgBqUAP1DbFa0P81 o6C0uJUT9f5AkGIdBmYuDsb/gfAUVJ9/Y+WhDOjQehjFaDGDDvOeKNMKX2Ej4UkmJ3GCTCBl JlCrP9+SLdfXEB/s23APQRqJFmI0BOdXvHakxf8bjZg//nEcWF4KAKZFcDAKzDeXrtKVYQIN AtC+FA4BCyY87QFuziSZNq4o3ZeFhuBFCB3kJyhbY9ygANWqWETY32Awa7AGicfCYWliwRAW UsWhUfj9hN+CR5IfCCscYHOZZeALK5Nq8aFoYEG6NX1xVW46Agbi26kkFBmtv9IWOJoY8FZb ODn/mQXLrqhBPKE/IsE29QmM+56qVHQZmBiUBEKTwPbEHOZDu/fFArlh6uBKTW1ywSAMaKel TEqe25/yfib5f/LohXilpFh1pfo5jLdMoNSbAe3kzAk4rXPmzIOjJAvtQbKYJmWLmYaR1Hfa 9VjQPNDxhUmFTP6gepFRpGYjiaDfFXghfd32LaQlVYDhCmjwnqwJwn8ogXtoD3x7YW/8zpLW iQEf7S5glLgh1IL+sWgNeg+Bbt3yqQ3xFC1HdXt99e4fgGqwLeE0dfueoE+v3r29Zq2P3Ajg kOK2YfJdB36lryVRn4p9gxFxJ3KfSTxv/oabPxx7KxGBTKjyTff8ouYBdKpofMGx34sFdoeR bp+OAbVHv7vksPUgaNn+TrRfGZjcr2lyJtwDaoaQpzGecMcLmtSw2cCkpg7CS8S3xHIjyORW or7m5bZAAe8/MQV6l/HYRjW9C/CO65Kqs6xElyS2p5b2T6fQiK6sUrIxo/GxbWkbphJ2UvLN I0ncqu3PVvvJahzvm1n4KK7zs7MGAsbk+skcEtmLY9Pu2e190nNlpKdrClge+4E+HnvWiQaO QJ0JbftMEGVUkJsmcF0FubVg91miBU60cDJlYFaW6QFy/jq1NbxO8FEYahic6pN3iPZzf7g1 /KQE9hqvE1q0co0tY02H4YaKp48YmjTzWyvnngn14Cp88/imKWsvT9LpIjubc1p8yMA1DvPV oWv3T90B0wSboKeoQ7emIZgvWJz51g8Hwe3I5utVdnk1Bsg0xc/e5VVm1G/KqC9Kl5VV35TR 6kZ9+F2ru8xWoKQ1KtLr0KhdZqMp63rG2KBLj7CusFInOIA3mmhUm02YqiZeiUOIFXMQGQmG E3VDZxPGaXPGYYInGQkzaSEcJi2f2dFmm8zVkXHwTmXbXGXZNsG4KFwNdaEJDk1IchOmNqyZ cAiVZg4iI8Ft5rVm2wTjYYQ75TDBk4yESVokDpOWz+xoszF7ufo5z3yTkrvx/yW5HSYpZImv 2ZXR1iR+l/nKimDGeDA+kJMj4SdYW1IIVBcMVgS6JXEIVcUcREaC2yxAILWfMQEn3BMOCZ5l TBjRInGYtHxmB4beNo65VnwW0hrcTZpEqEFMoCYyBaSgiZhyok+0wsVJKoVQcehdU0bU3LM8 Fxrm4H06UTWlI4xhf+lYGnsC28gcffKG9xgplGFp9cCziqyF9ehPL+lmSes2W0KU4PSJJRC3 OpUP891SJGvyciS+2+z+BdSQuLqZ6iGIUwSzBfYueFYB3BopLVy09IVU6IDtTANO9Yn9nNhR fO6DFL5gkD3iopR2RUr46KZzkbUXGkhmUQu1r6QPQbqL9nAwUiI4DlCI5JDoQBHAO3Azw1Hq xrmaMR4rBSisVJZ3DBsOGO5LSHVdapTqeLVNNSVflD4UKfkshR4DZMFzjuo10B4kX+1E90oc YcF8kmQ4ZchEKOrL1cpDq17d/+L6IXZY3mhP1CFdIz7S7XNDtxa4orYw1mpyDQxY+Y1lvAvA Bjqzj5bx1AgWEFvgrGC+d9bXvONxB1SxSRULelhUAvKRrkADZWP1yVVmpsmZ3ll5v7xavlEn 1xm/ho4HeNX2iBjhAQjbx7sSXl4sLk6WWzDb0tXp+OrEKrWzOGunhvYhX/6AycDnu897GPrU APMzTMQwc43qXh4hLj/Q2ADPXHqGHdN7Cc/RdAVPvx6H1EBvP7xZRXXCTNcxHfgP49W227YR RN/7FftIApHt5Z1+a10/GLBTIEoLBC0QsCRtC7AlgZSM+EP6v505Z1YiFdfpy5I7Ozv3nQuv DbEyeQ10vREGXS3LQHpQ1s2zu0RpnlpUe5YwdiTFsQ/IqNM/2uVXkb90v/yOv+UXaaBFyr+i WBuwpXbjGUaPSgq/gtgZNaNbAtPjKHVi3UlzdnGYcHwaOCWX7ubj11hbiE9xKiua3FJnB5ka pp1d/l2/AjnLKL10/LlWufLoCpvf0KT8IeLk4YBYXwD6+iuxPmofJ1epW07dcuhWim6L7ND2 mXK5KLdQ65tux9AJgh6j0TrQpXrG00GYePAdNFLSCCEJwEpZy4Am0Wnh4CUcEh14JgHhLSDQ NDMqUratZSD5OmnZxwNvT+Zo2ow18Z5P4kP0gJmLoEeVmL214dbBbJGqEaQCRJfxopKgc1cq H0FtvCi0x68YuwS6kVBJAcpWQYZit1y4EUvRUMN70Wqzn6FCoUeCmu22B22xTscvjjcGdEZ3 pcOGUHi0/aDCUxo76uzkbBZt2THagvZ3YskskoB1P685IBSI/izaPsW6WWFtxWWZ/WunLHKf 999iLVA6H2roPPGy4RspHRj1uyGOTie60XVP0E4HIUVpuB/d2ON8veMI80ouMq70QcA1Uafi rGZEdpsBOvABZIG9AfnpCWtJvp+SfAkwnY86nnwvDCajJLAkUSrY7+wdpT/MSjdrd8V0xPxz h8yzwHoTK8S1zahcC8qYRB9cIyr4/AjRFzPFGHD9lTB4oKIJEghYQc0qWtP0FVVIgumruekL mxSrSO2PexMaO8jIfyMDu2SBIWUJWXYO5CcoMVOBFINaHTKXmwhk5s8CU5KidjA/GNjMqhgH J1RHJxR0wirOEVLRYd7V3K95sUJetFf04xLznjOvCXrDm8jDp17yFXa67nfv+OktH3k6aaHp cO6lKRW+kf/hmvRd14Brx5PTqBEnNcExfu6ZEEl27z0/efopYr+zLM/QZf3X0/IHb9D6UkiF yUV0G1enr8DMa+Zw9w2FeqKZ9mYC19GwhkaF213fuZMnjljIQn0pQoa9kmAoo7vFjaRn1fVe CBXMG6U+o6cYFaPj1u029jP0htHGhRYIAEGr5OaDEVyBwJpAKY2A9k0giPDi/zCsXmL4saTT gDC7b9c3ku8TY+d5MnkEWR3snvrjK6iDwmK3NFreSdHzEvy6XsfaBLh+hSM8sTp67AccQsJn TWHaKvXy7NKoY93D/15fTikO4vZeK5tX2bwSLXnKZ7QxirfA3PDowTYzWruVZtBUal0xYXqC BNOteXZOoQOHBtC/ZU0CbGdUDqIsklKGh+iWSEEYD2nkUZ8EPYxozdWnUKE0FY1qmETKbK1Z dW3bXt8tAkkNEjXQR6uwrnveHIhgdOTpIV6GeAJsjRp3K9x+CTBl2PEEiUahmmgUrolGkdfT m+LZyARpCBeIp+4qDviL3AyxGmUTsLGf1BxjgxTvAyEi0pdII7plTC5O3qA/NHlpFXJBpm1e pq1dau8oYw+i0La1MQQ7G19GwO55wRCf4gsmL9SIZ+3gCmmUVq10uyrPuZH4hrtbu6THkt9x Z0PYw8YoIrdfsHMBc7c1GgOHLhPA7g3Pmij07+ytBuONcUKjsBR8DhDLOwwEC6w3mCaQ6mUe aNpHVNkea8fM70Y8VmmrdxwYNP1OW8ryyDGfcUzAsSbHEhxtmAHVBlVCuHUsWDVrAd51fYYc pzurjiKSIHRse0rmYs+yVE7LUs2yBLKxJf2aSd8j6ddI+jWTvjxZGbLA3CiOvL3ljqjr2ZEh smiWAlXgvm1np+OIMnfoWEorz7W1UDVaqNpE1uKc239jcqnR82lJLg8s58CTJPJnhNagPrYG 5aRbygN9XqZBrCaXFlHXn3/6dwBcre7gCmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwg DS9UeXBlIC9QYWdlIA0vUGFyZW50IDE2IDAgUiANL1Jlc291cmNlcyAxNCAwIFIgDS9Db250 ZW50cyAxNSAwIFIgDS9Sb3RhdGUgOTAgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9D cm9wQm94IFsgMCAwIDYxMiA3OTIgXSANPj4gDWVuZG9iag0xNCAwIG9iag08PCANL1Byb2NT ZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgXSANL0ZvbnQgPDwgL1RUMiAyMiAwIFIgL1RUNCAz MSAwIFIgL1RUNiAzNiAwIFIgPj4gDS9YT2JqZWN0IDw8IC9JbTEgNDMgMCBSID4+IA0vRXh0 R1N0YXRlIDw8IC9HUzEgNDYgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDIzIDAgUiA+ PiANPj4gDWVuZG9iag0xNSAwIG9iag08PCAvTGVuZ3RoIDI5MDUgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSImEV9tu20gSfedX9CM5sBj2jZe8ZRxP4EHGWY+0CyxmBoEi 05aykuWVmAT5kPzvnro0KXmzWRhwq6qrq+t6qvni8hjN6mgs/x1X2Ys3c2sejpk1G5P5uozO mibKGkNlZo2rzKHP7rOfF9mLxcLh2OI+q0xbVsHM+H9lYt2Vnauiia0tXVXVZrHLqrLizYru mREVcXZFfFu1ZvEl+yP/vf9sqrKY2arscmd+K2YNfizBKF3+1Xj8qEubW2FcqKBxlW5Utvhr 8WtWpWuIWQcHnZXrOrN4LRf7Ti92oZaL/1bA9pgvH3pTs4qrRfZv6PFt2brOzDzumxyrTfRV GQJ+rHbZi+udNa/32S1pDA0ucw6OlqEjE2Lg4NW+bGprdomOUBx4CS2FtmxbFgrVSMF8G0tf j4xtZh2UT/LWhdKFUVki9S6cV4YNomc7caIoSgptVL7emOhVpjYlxjZTkxND/UkKE6k3rrL7 n6hUKgiUXW1msqBeIkxG/BDQoAUyFiGlyDlKEWfLanFsjkWdr+jfxhyH5dAbSXZpA6WIKs1T iukMao8yTAfzu83y4bDcHYvFR3BgA90fY0RpUIk2geSlRFPdUE12PllgGysW/FZ4V3rUI7yI +Xa7+Vdhu4lxKCxtfyyCBfVJmI+0hNxcFo64a+HqiTvZTAoLO209nQiG/Pyii8I2qHZzIzp7 4Q5f5OK9HFFr9GQvzDsRNfPC1eAOomif7Kd4WjQC1bpG0tdTIoKEgbrkVYHWq3FkhvrIV+sN OhAFQRpB96vCeWwPnw79BRkZyFikPJ/LOV3eabuiX2bUMwbJqFskw9bNCBx8d5WwgpnI6mZ+ Ob82x/543OwftR6Gw/LxuBnA0GQ/KzpbwU3H6p38UFyqmtFJqiGoP1esJaRKHTRShHyFmqMi dp0vvTux1jbJWoIaitn1PQLkCayWj8WMov21aJEBs1eyl8WsmL1/fFTGitzRPQQtf1oKcRg2 q00iBkpDl28oqlRyzHwwm9ODKmqOfAFrr3M4KWfGOzZH81Z+vnvz5uq17L4XzvXNhRkKAtq1 Go0EyK9JkdBJ3VHkRzuJ6KerNP/UvKng3JhoJ6F7q4ZQeb0n5G9hSGnM1faIEidtxLowm4E0 vrpc0NRw+XWBVLj8H1cQJf+VvYb7MIFZ9zxAHOJGug8F3ChQwma1h5CDD/y/Rwrk9j2ffZQL WcMHVLpNGzv4lauoCj3whnn7ruhAkR/vr28kHaL9TkKw+El891MdKuYM695sSWeUOQgbYaD0 Nl2LUD/yksyMiS3S5oPsCjUeZGqHlvTsPcQfWI5tI4UhCQ1mSkCUBKASKNk2v+GjZtg/8AlR se2PqBLeX8vd0qbfM45u4xYrOQx4UdTpRQFpelLIgmZrqrJx32u2akIo30jQ5lBZNKhvxgS9 kYDqyL8BVhiguYgogQZAIo/JjPFhM3V7R+P9mQHnzU5Th67/dmNfmlcD5Y3aErF31ANIHPm7 L+hR88j/dQtWIpINMixbzDw+MbWXLa7KdLBNVUnq96eHzBdhLlWH6dGBHRcPHfuwxRS1FvrW PTPupBH0EjOsxSzOmAhu9nJhOfVqHHvVjWOWvHbJ60AzgFJcn3hNFSKVpVvkdUQPLHWLmfCa i0+2tBfloJ96MYz6RJNI98xbcpFLp+tdDQYfEYa6iayZSjpISdfAFAZ72u0FmsvT1rTdmGWf /PUvgZWtwJtF2NTVSbkV5V2uTb9SBHkUEFJn7CmwYEKsVSf9v1PeipKBxCyP+uNsd9gLGola ZbIZ4HQ5gU75f3Dmm/RyEJdOwYanzinvwLAxFNThAh4Y9yOQqGgCI+10RZdBzmJMCxA9nSLN qd7TvMcp7/E075Gr/RQZzd2BnjIJGUX7U8/E3RgBgYqQ8hnrFIFII8LnL2U2mnkvI4OwqxWI YNrci8BSyM2Wdz8JdUC31bmeNH8moa0IkVtM83ynH6tBlOkVCGST6z1HeVzhe+tJTx1UuL9T /ZSbn4tZDbG/y0fRXKh/FvT+ulBP9uLYgUYiKxQ6GfMZY3m0+fCVKXLSipdkkjqZLv6zOAtm PQ7tVt+I38gMGhCzkNc8Zi3FlZuQ4kq4TyIuLRu86ynA2DDKGkR+yUx6WLKNJKA7BN35rt9/ UglRv14+PTGjfyRzST4pluamn3wUaMdyBzMaMQu5nBGxcwiIIwQ0qWSal3hL64ClguY5h+8v RuVGUNkTPoVJhnuZX0pEfRZK90Twq/AM27Achp6V7bS/WHAQpEdmCvo/rM3y7EY1YydvrSce dVs8GWkaYHuLkd2omXX+aUClsvbrsi9lbjXJwAcdk8x7ROZJLk2DZ1PaBq8P+LaTafnsAc+P 61tLL+mrRfbi8hjN5dzIh9f8Et+Av2LwfjQ0680XPNjNb+aPvypzl9k6ypdl1/K6y1zlKCkj Z5vNwQPY0/drRx8SIoXpV59KJRk6T1+y2+kb9dwZ57vJmfSVmt86Mh5PhKBPBHzIov4xdJ23 NBjZ3cAdkd8kT52vIYBL8V0UxDDnyradOA4pT2tXT7TtGj65ykZO6/WkaLCNOJLuSDROxIp1 jRK1O9eQ6OkO5YxWqIbRymd+rLJ1ZhGnU5ldZl08k7KE0m7Smujp3pGjliUNyfJ0x+SbjUHS nyRSgSQNY8GMdyhntEI1jFY+82OVHakufvAoFStRGL5zzx6l4/dq0OfC/Ovuwx4dWGA03yx3 PVZ8/xB03PPY3hf0bjuY+SDjX5b+By9SG6J8f57eXpW+6zod775rElLdFiDQwBZrzWAstPml QGnjx+9Y6cl4xQId1u+897rp3dCMQA9F+W1BOugBeIkpbulrqwZ28HdCg4+ws9fH9GCvwqkW HCA9IaeH1fiIauURBWU3Z1oYjcejgY96esD88ur6LY5+F6C8AzBQzCye877+XwDltW29c1oi gVFkl/mq0SIRjkOweAU8VmGibdfxSbRU4rSBTyYNtvHMT3ckepV5NBnpGiVCc64h0eMdiZOs SBqSlc/9oLY9bX7xzbWdIqpwGFHbVhEV8C+4C3/q9lQqyRCyCsYKop6A5H9ha9NJHlwVStee 5CEhp0spoFHIAbdjCiIb4Jx0tkMYePV4zpOTnZjhfMMrUgBMsMQJFW4l3AOg04pxZUl3rSew rydiFJd8W9akM9qypdV7WQM+ERjhWtawolBRP7JMxdoRqhDktNqOUEGPICPao/7R8Kl1krpg pctp+NxwYSJOSHRjAGeRXq+vsRHSoLHtWAk6J9NgQQ2wk5WCsbccDJqVfMLHBK2oMwF7CZOt a6XxBiQ66h2+1mqy0Wu4Igfawk0OuMeXGJ0I3RiutpVwEXw1TsLl2VIbak1sChfplTpueOcH 4aI8UV/H03BFDZePJAxYt20r8Yo6xRVWaa/FmwOyTVv7cY4LKuS3YQSEKC3ix2q0OmOVQ9XI zekqBQSlq3oEBOF0MoaSgrbSVpUblCQ06FhR2o/V2WklJ/UjRw1I55OBz10gLPBOkCYN093E +U+jZZLlMAwC0RPlPRAyku6Uvv+2oQpiZ5elsSaG+hA5z93JAtODjKUthfZcJSj0d1goul6D jKWa2JulitLiuQN9/qBwcLxY2Ra08ffRvo7Zx8uG/tQ4+/yAGl1eY5z6d5Nu1HgmV1kcr/kQ 1eqsS01e6o3KaB+p9baMtTmvaJWw31VQRPHaEb5YTVYQkwllEHJgKE9Pb1B+isdJq5ZjRJMs 2vzvZBUZNCCmlOwgg4KC/mgmwSCrWSv23SmK+RguShd29ocMugYvcH0gi9+L32LsAzpxQXKD eA3lV4ejsjUuRHC8XJ6kBLmBHdfgWRGUfFKupOsbwVJfcBncuNpFdp2bG7qumuh18k0ZhtOY /Qe+biAsCmVuZHN0cmVhbQ1lbmRvYmoNMTYgMCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tp ZHMgWyAyMCAwIFIgMSAwIFIgNCAwIFIgNyAwIFIgMTAgMCBSIDEzIDAgUiBdIA0vQ291bnQg NiANPj4gDWVuZG9iag0xNyAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDAxMDUzMTE4 MTQyMCkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3RpbGxlciA0LjA1IGZvciBXaW5kb3dzKQ0v TW9kRGF0ZSAoRDoyMDAxMDUzMTE4MTg0MS0wNycwMCcpDS9UaXRsZSAoaVNDU0kgc3RhdGUg dHJhbnNpdGlvbnMpDS9TdWJqZWN0IChpU0NTSSBjb25uZWN0aW9uICYgc2Vzc2lvbiBzdGF0 ZXMpDS9BdXRob3IgKE1hbGxpa2FyanVuIENoYWRhbGFwYWthKQ0+PiANZW5kb2JqDTE5IDAg b2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDE2IDAgUiANPj4gDWVuZG9iag0yMCAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMTYgMCBSIA0vUmVzb3VyY2VzIDIxIDAg UiANL0NvbnRlbnRzIFsgMjYgMCBSIDI4IDAgUiAzMCAwIFIgMzQgMCBSIDM4IDAgUiA0MCAw IFIgNDIgMCBSIDQ1IDAgUiBdIA0vUm90YXRlIDkwIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDT4+IA1lbmRvYmoNMjEgMCBvYmoNPDwg DS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1hZ2VDIF0gDS9Gb250IDw8IC9UVDIgMjIgMCBS IC9UVDQgMzEgMCBSIC9UVDYgMzYgMCBSID4+IA0vWE9iamVjdCA8PCAvSW0xIDQzIDAgUiA+ PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDQ2IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAy MyAwIFIgPj4gDT4+IA1lbmRvYmoNMjIgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlw ZSAvVHJ1ZVR5cGUgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxNDkgDS9XaWR0aHMgWyAy NzggMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAyNzggMzMzIDI3OCAyNzggNTU2IDU1NiA1 NTYgNTU2IDU1NiANNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDAgMCAwIDAgMCA2Njcg NjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggDTAgMjc4IDAgMCA1NTYgODMzIDcyMiA3NzggNjY3 IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IA0wIDAgMCAwIDAgNTU2IDAg NTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgDTgzMyA1 NTYgNTU2IDU1NiA1NTYgMzMzIDUwMCAyNzggNTU2IDUwMCA3MjIgNTAwIDUwMCAwIDAgMCAw IDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMzMzIDM1 MCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbCANL0Zv bnREZXNjcmlwdG9yIDI0IDAgUiANPj4gDWVuZG9iag0yMyAwIG9iag1bIA0vQ2FsUkdCIDw8 IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIyMjIxIDIuMjIy MjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4zNTc2IDAu NzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0yNCAw IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdo dCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC02NjUgLTMyNSAy MDI4IDEwMzcgXSANL0ZvbnROYW1lIC9BcmlhbCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAw IA0+PiANZW5kb2JqDTI1IDAgb2JqDTkxNiANZW5kb2JqDTI2IDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggMjUgMCBSID4+IA1zdHJlYW0NCkiJdFXbbhs3EH3nV8zj bmFRHN6W+9gqRZEAbpvuvgV5ENayI1eXVlJq9O87Qw537SKBAXF5OJfDmTP0enMNMF0B8991 UutfBoSnq0LYg3JRB4vQhbIGb2DVWQOXnXpUP41qPY6W3MZHZSBp42GVfw2E2OvemgAhobbG RBiPymiTDw3nWfEukO/EOJoE44v61Pyx+weMbldodN9YuG9XHX1sCdC2+RccfUSNDRbgTgzB Gjkw2H4ePyhT0zAYvaWYxvY9jO9KYtdLYutjSfx7S9xDs33aQQnx86j+pjgu6WR7WDnKt1ws QnBGe08f01Gt3x8R3p3VR47oO0pmLV1U+54pBJ+LF53uIsKx7gMF9nnxiUurU8pG3sw7oo9B uzgDB4WWgi/2aL22fg5Wt5KL/AVAX+IcFiSUQDUgBsElY91PSjhV4KCEcgXkPjVg3UrGST3+ wFIxZKD7CKuykF4CUab6UUG9CGQWIbfIWm5R7haKOPbXNjYT/+zhetvedlCardFzi1hpjlvM PqQ97jA7Ng/77dNle7y24zMhxIHzhxBIGizRzrN9kWjVDWuyd5UBdlgY3LfOakd6pFuE5nDY /9livwCXFvn4ufVIu68FPPHiG9i0ltEvBRWPh3JYA7a4HP31ytA3bxPdtdiR2uHXEnNX0NtL SXwuLsJGPHcFfCimMLQ2Enorgc6VP9cTaRBY61JJF5dG+FIGnpIfWxq9SC4r0kczfdnTBJIg OCLtd1NrHR3fvl52d0zSM1lqeTMUP1l+k3GleVnxzAA1IyZqBsZueThkWHNTqZ/7YTO8h+l8 Ou2m2/58EjHcLtvTdc+AdJr48JtUFtrGqCOHxOR1Z0vsfC/jFrEMyM40/Wt+GjcDFE0MG5Ln B5LnMw12Z+EF0MA9fPps4IEqRiXjoeldHo2jorePZL4gBzVkrOPRSL2OPluhy1+L1WzTd/S8 MDKPz9vL0OQtl0G5TDNYIW9pagsjm8eRciUjjAqSGSUjjBJVvVilMr6z1WzTR+H4HUaOlFRa l2x5IzMjJ4yc6yUyZmZH5ejfSv8KYUaMMRNMXc5KVpEUYV5bzTZ9EI7EyBFxEihYTDV85/KF K+Kizas1HRFe9lx89pzUjHQpe9YIrMUcQXLU/aS8sTlWRTy6NxHm/ZyjIpVFjTCz/N89JnX9 drXp8lJtx++YVNtLtZfERhTpnVxGEK42Y6X/sSjyPwEGAIzdqPwNZW5kc3RyZWFtDWVuZG9i ag0yNyAwIG9iag05NzEgDWVuZG9iag0yOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29k ZSAvTGVuZ3RoIDI3IDAgUiA+PiANc3RyZWFtDQpIiYRVy24bNxTdz1dwSQYYhpfkkEPt0lox VASyEU3TAE0hTGUpVaFHIU8a9EP6v72PsSQ7LbrRHd73OTy0qxjBpggKirPJgdpVMQSbPXmi xSh6Nq+q77rKKYjWRVWLcSqmgiUuKWiDhYQf3b7Si2y636s6W9eUVhWbG+zV3WAgUWDaVZBa S05IYAva/Tee63OTQP1ZQXY2kMfTKFDeF163eE4ITux4XFULrPA2ttIjjFOKdY48hSM79ESb xpzWjVBDAQs8PI+F5AmJPJJOZ2nteZnzuSm89qo6e4IMDzkLMCc2JIcc0tkz+7RwwGpaAlxi aDi38fwFTmjYVVTXYt/SXvb1Zcxqge9tf/HklvemM2+TGybgcoZx37MnButaymgEMbTcyZfC WqD9iQHa15fEW4FrrG95Xxdf7kv4qC84691FS6+7LiqUxeZbVXkaEUlVJWONqKpGujDarSrd AevLWYhNUHUjOiOBdZ4il0AEFyTQcAnecRMzRbJzRSKsyTogAOQBsRbPJTwPZF6pQfpGnyNV AyZLdan9WB9zixvjE4ImnhtQL97YURZi9mfMjS0JMbPBI6Bw6AGJogQzdaCvlTRzOPNr9bN+ HPrDQ396UKvj4bBeDQafWtBbU3vb6uNBYXxYq4dt//nU780v3Q80OP0H2QAeN8ApsYnWxyuy BT3THmTw4q/9r8fddmWKVvN+v0b7qAw+VL3BX9BHE2zRJ7UY+NiLWT8+7XAB73EBT9ODR+Jf TMd3XkoZYYeSs0z/e2ECCq5oYAt6gjbbrNVbE53Dj/dokT09HROnPNjhLNvQlfCNXPEZx8am pkZBLwz6o/YT9dHgHxd9L+duafARtPonzAvofsPBmQEOmhofq1aftGnQbk3EzN34C2TWn5GG rHtxKizTm+OJs9XQywelYObwyfDK3av/JSG8JOEjgqfA/ZjQjaQsx8QfR3LuLxNYUXLFT9oa uSjEBeg44XXf3d3O5ku+zMV0Tqg84cbHKbgZtdeH7bCVYD8QQI1oGv2aSPTSQ6LL99/Lxwea cSMtBkkjPpgN1I2h96qfcfL0os4Cvdo5yf1l3UzU2zezd9gk6unNs+KzpF/UtlJbdJqoKV0+ 6BkjRDu/vW7x70TlM1G3OFFQyvqzueDbCL4vu11tAI/r8Yl8OdFxrf7As9e/8W8vpY8G/BML z0mAi4jLtYhbETH+59HtROE2d8sFdkz4Etg5Z0yoOzw6jXtFliwEnCC3R198exTBoWT4BhOB u0NmIt3fB+56M3YgFUNkGZMURcb/CDAAn1/FZA1lbmRzdHJlYW0NZW5kb2JqDTI5IDAgb2Jq DTk2NCANZW5kb2JqDTMwIDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGgg MjkgMCBSID4+IA1zdHJlYW0NCkiJdFTbbuM2EH3XV/CRXNRc3iXlLZukQYvdZFFriwZNYbiJ nLiI7UUst/2R/m/PzMiXdNEXkTMcnjlzZqjux6p7VznrXAiqe6gm2HrV/VX9qv8xk9jWttZT A2+j2zP18fb6+urS+GSTnpmJt0XffunMb90Rpd2jOFef4giK19602tG21WfqfHpnWuxuTMbR hfG0zD7BavX0eobQKZ9fSUBnJsVGre41RwzGgd38lY0nBPeCO9wbdr1XzAxBWYEr6rsUZr4Q SSf0zs0koY6pLHe4mfTNBaqjzafRfW2KDZqdWf908bN4L+/10niH3VrCl8Noz8UeNrK+ghFR mey5ZOLCekWichC7iEw1ZGpwz5PGWZ8RqNcfxbq9vp19f/7DGx+aMjZBpH/bwv+ghhFV/QJx o/4sZ93sghqbBbLoq/Mbsb8Y+n5+0+X62OX8JlWQVJFTNToSlkeqD4SCdt5JSxT0Ew0OnQBC 90f1vuuSAvuFtM0deiZC6ZvN0I9xQeKCxeS6g57fMjtTPDdZ06BgXkCspYYRse2SaVHbaN2s twq66meOkcivEvmV6+nl8hi+fmKneuRlx2e9GjZqoOZk/dyrrfFhTNroFRPoBVCGc8L0ydHu S4iHh7hvY/+n8RHS9uuB6c3Rt4QSqHuPCg+AhlO+S57fMV4MsKRANVrUnoK3473eyJ4xByFL 1wR+xXi9DId6PbXGuJ1YL4zLgHMQ3MqOv73at3t8flzfOPJ4xfSaF2ZCur2ysUHqrFfqcUn/ gqwXi14Oej7Yw0O+ufgHqipLjVkq2Q7zod/ixfG/grlG/Yx4z0BqeObYfn80ltuPCCdjHo+z 1EgnBmRFlVvKGvgH1GimGph60GumsN7B8CSh/p13VIX+Tomxk//pwJ0Djye+KZDUOS6WoB5H aFGB3Z41oKAdBy0gn9zmyL/5+tZyFSdvSWFeXUIbeHEqevwVGldUqDGADptuJZWm44Psanpp V10VQmNz8MrXmOri1QqebEuCp6D3GNMAbdlOyYaGbG8TVh9BGTcfquCKTRQRo22wBofVkZ1k xc+DsOkGnT9Uvg2M5dMY2WQbiUWOKILYNIztSxxzTCvfeBvLkdeq8nUU3NIyoxd4Mj8tXxxn eqkW76oP3bciBdfYQtr45A4i6S6OqkSokU5qXVURTEgn0ovUiLlw7pAyVxBTzWtIhdk9VBHI xJ08DTBi9GJH4Yh62R+wpiQ1Rt/YmlBDtHXgvF60C5gBxzVG9CeQyr7lTP9bYwwYhESDEGsL RajGfwUYAEVvvKUNZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iag08PCANL1R5cGUgL0ZvbnQg DS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDE0OCANL1dp ZHRocyBbIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDU1NiA1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgDTU1NiA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg NjExIDAgMCAwIDAgMCAwIDgzMyA3MjIgNzc4IDAgMCANNzIyIDAgNjExIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDU1NiA2MTEgMCAwIDU1NiAwIDAgMCAyNzggMCAwIA0yNzggMCA2MTEg NjExIDAgMCAzODkgNTU2IDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg DTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZyANL0Jhc2VGb250IC9BcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMzIg MCBSIA0+PiANZW5kb2JqDTMyIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9B c2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTEgDS9GbGFncyAzMiANL0Zv bnRCQm94IFsgLTYyOCAtMzc2IDIwMzQgMTA0OCBdIA0vRm9udE5hbWUgL0FyaWFsLEJvbGQg DS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTMzIA0+PiANZW5kb2JqDTMzIDAgb2JqDTY3MSAN ZW5kb2JqDTM0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzMgMCBS ID4+IA1zdHJlYW0NCkiJXFU7rtwwDOx1CpcvAVahKOrXBskJnm+wwEMQZO/fhhRJae3K5lgc zpCSHD7O/u38G36cJx7pOL8CRqqpHBRHonKcv8IDIgDk43yGj88ii3+fIbcRqacDU4+lpuPF CMUqCHIqpiNXnF+QWkwSF9C41Jn5DDlrLtYSO/EK5urC0GA+MzStwcyWARAJBKmxSeYorE3i FhtKDDHLs/UIM+MzCDZ1dYxpKpW3Yqvky7+w8yjmKsjX94A1m+BmFkWoWEHiJpEIbxH4mUY2 oXkSp+oWkds0V1COKEIHTsGJreZpYEymBCpJBWs7EqSZw63lryKUP5SpLkNWWqCZPvX+PGWK pFMELslLjoc+YFqrAJVLV+4Nv5wvHW2akz3HI9tskecyRFzS/rNxm6kjmNQoQrGVZnykuY6N O8KT6W+7wlvjNd5aVbK2xldUujJ4vGsYslQYw1J58/EMf0Kqvsb3bSJfpUjKOm4EG67FMmTJ fIaFNPNA7sXw6k405oxmXL6i9yuDx7uGIUuFMSyVNx/ijbhz705egQra3BThvWIdUzaPd92F mDJncOVeY3vjzl7c0sArg8e7hiFLhTEslTcf4i2jdSoNv2+S7ShD5EzMOtAnq8eDrKwDfCSF yfOrFvEC1WtmUr3+vdAl28LNbsAqb+lL3s3ANMWH5DowuQ/eB4ayDd5a5fFu5kKs3c7g4/Aa e2Ci5H1gOY8Lw4pXDUdchTO4yrsP8SbX/GSDdYmQbqV1rWfbjMOOr8d9HXBHql0BxuC/EK+x fynYbCv5Cr/qncHjXcMRV2EMS+XNhx40sC3kfwaiqt4MoVwma4aqW9xiv//5EDjCB3seE2NA 3vx6CLSGx5zR7GfnK3q9Mni8axiyVBjDUnnz8fwvwAD8eIw3DWVuZHN0cmVhbQ1lbmRvYmoN MzUgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBI ZWlnaHQgMCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDk2IA0vRm9udEJCb3ggWyAtNTYwIC0z NzYgMTE1NyAxMDMxIF0gDS9Gb250TmFtZSAvQXJpYWwsQm9sZEl0YWxpYyANL0l0YWxpY0Fu Z2xlIC0xNSANL1N0ZW1WIDEzMyANPj4gDWVuZG9iag0zNiAwIG9iag08PCANL1R5cGUgL0Zv bnQgDS9TdWJ0eXBlIC9UcnVlVHlwZSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDEyMSAN L1dpZHRocyBbIDI3OCAwIDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDAgMCAyNzggMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDMzMyAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCA3MjIgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgNTU2IDYx MSA1NTYgNjExIDU1NiAzMzMgNjExIDYxMSAyNzggMCAwIDI3OCA4ODkgNjExIA02MTEgMCAw IDM4OSA1NTYgMzMzIDAgNTU2IDAgMCA1NTYgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcgDS9CYXNlRm9udCAvQXJpYWwsQm9sZEl0YWxpYyANL0ZvbnREZXNjcmlwdG9yIDM1IDAg UiANPj4gDWVuZG9iag0zNyAwIG9iag04MTEgDWVuZG9iag0zOCAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM3IDAgUiA+PiANc3RyZWFtDQpIiXRVPa8cNwzs9Su2 9AtwikhRotQGdpPW2wWpDjCM4L0q/x8IyZF2zzZS3Ykihx9DzabvqU7KpdBRqWcZdHykqj3P fltqb7n5uQjs68yz5Ml0PNNlscjhEQuBzR4IK8c+P5OUlovcFrFcrwjX+cqxLbuKjXBV+VMf z/Q9SaeIFuLVm4gufFikwltKAeo619F33m1RRuRCqIYdkSvHPluEtjWn5TH0R4R9vnMsy1XF Qriq/KmPZ/o3/XGm38+TDzrOb6kcJDaN44GfYhEtdyn9YIPmYn/Oj/QoNqFSj/OZPn0db+c/ bpHZ9JA8pPNxfl4+DT5U3EkNkvV4SFbVcTstoOk+X87kKZsVyTSCqI/b0mZQ856+mm1GC9xG 1surxyr03Id7ebv9xec9ffstjME/6QW/LK3GdACPlG7r4wevxYbBN8364gN4VQR23asyEFCt iupkzAbia4uwVggRRkoLGlvRTL60Y0ZEsxsu6MNXtREQmceOoBKYNDGhVoYxYWebmBTPiWap thUhtjSegwzLpyYd2FNy9wCpETCuh8YlZrjftJU2zE8RtXvTGbdPm6CbfDpDwsPkoJXod5Q1 LfdgCUj/wfhkoDVryAu18VnJHBYJPGGCJtCMBoRQ6T0MW1dg2IvzsUlhLIa9OC+yTgzF14kY 1UqpccfdVhLqNUHgvU7ViXuhAQUT+HauFt+sKHBZYp0Yq8IDO4q2oqjL6/KZNcuGp18eA3Us MzPmQqYG3gVXbCEZsRFRdc2DC7TPhowezTPWSTq0s2Gz/R5ke89egmNELufMI7iiNVPTuKeW 65ogD0yFfY2jUp6Y3ObyPXlrZdzdRIsQIPkfAaI5lgBJMb5fBEhCNk5Z+jNJmoXZAhrfl7gw xOUkcjfrSkc//Eb7dCe74QDoUC7L2uatTRQC9pd51cdbz/qJ3v4+/0ycp30eHMcp/CUXSppA NLkTco3bkHCaD9l6p2vlVS7FwMBY8eZkMAbZoQsy1mfy/gza8IOQDgmTCS3xs9tdc3CW/Ujm WJYW1DZ7JLEcWiJHK+tZKeh0VRJsrEpoy+2BhXME9AFyn/8JMABdIJIdDWVuZHN0cmVhbQ1l bmRvYmoNMzkgMCBvYmoNNzY5IA1lbmRvYmoNNDAgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAzOSAwIFIgPj4gDXN0cmVhbQ0KSImMVjlyHDEMzOcVDG1XiSYB8Ep9 vGDnB1ulwLWKFPn3bgDk7GWVnWgECASB7gaoraQcC+VAPUXpOcgYkavaHFNSu8Vittj3vMmo kUQ9xU7KkNiT2u6XwTNDjV38BMdMV8+j/Xs7WYz+TiNZtrdNNL/l8QouN3m8tsv2+mX7tm8p ZIlJwot/UigpxdpTCSQporMa9rftJeEQcdjP26c9l8/7r+3nvvHIcSC7ZLL+3zZuLQ66erhW 7xNJNXLZjOo17rwdnkax64mZASh4hnnHsoFIqtbB8khudxkO+7hjeVYVK8NR5UMf5+1dofm6 7xRy2F+fQWLwVhOw4VbuQQJwCtIp5wmSFKeCc50gibTYzDOMEgHQScug7A0wxSpq18jeAOEW bZnT0SLpCW4um+zEszDKWiA1BUFcAJLQmkYUjqK5IdWk39KthrPKCDGWtSaLBZ3Wpnr8e4Gn OD3oSiW3ZASs5AOsBG1WhYhFRf43QdUlqDwHJ42JFY0+KXPPEjRjtMaNwBmydrIPTx2G1cqg nRrZ845lQ4LUDiwsgvtdhsM+7jg8s4qVYVX52Md/CCoXcG6Cog8ERRMk4uEzlrqpGiBBHiaL 6SFkdV03K+OwO1m5AGl5ardcKwMXn5R1x7JxAsJxGGdELfcZln29Y3lWFTPDUeVDHxOkJ2hI aOqnZcyDQwM8eInmZqcoKZAthJZvPBeIW31eTZqoKYm1e5R+L9cY9KDDY+K+KkwW3KDI5nV6 NL36bK56X8qtMstaUdeYNC/85+zoKLosKn+wjJvCgP01cgnQEFAN+w/9Q5/4IFpawC7PFT9r OH3HBvKaKPGETACGTUtyMITIaYWSfeMk20VEvkcwA6C1GY3Zp2eQP2XYXroZdHqyTig2RTZB sPijR1jxdT56tqNwt+JJkJJtm+I1qITmnoPorDpQbciXMU8UJxow+R2np3bfNc0c7EqzXapO wdIOyMHfMl2vMnK4zmd0LJz00bFnFA+5cSnDu008d8Vw1rP/S3D+I8AA7tWU5w1lbmRzdHJl YW0NZW5kb2JqDTQxIDAgb2JqDTg1OSANZW5kb2JqDTQyIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggNDEgMCBSID4+IA1zdHJlYW0NCkiJbFW5jh1HDMznKyaUDGyD V1+pbCdO92WGowUU7Ub6f0DFo58sYKOe5pBsslgkL5XdhPhWnnWOpgOnaOt+Ek7BqXm+XbKl bf9jHBoyZ977aLRwH6uxW4weHt+u10smN3Lv+Oc6H5cMacMlk+J8h6S3GXbSVFzy/Y/LdDdb HobF+QHJSENa8bwhsGUeOBziNJzxlFBb8bxuauI+ZKWmSqZmVinu/N+1ApY1KlwOC1mUoCB8 8/vEW26B09JipqZLZoBSCU/4DAsKTb+PJygS3hQAHlAKdEj8dFBW5g979xOg6Eqhcap/QKKR rEmlNnfUwJQz0DGieg6eWwIUJLtdgipGYADHU/T7WglnWJiUhewRvswSJsGbEQU0tFLOO0UM sOhZPNMVpRH7FYUzRlyzoiwL/JHIY4alaI+0TThg83vkxSkPGDUzcJkGGq4V79ITRk2Wu06y DTDyDUx53HS//nlZTzopr4gJRHM6BG1mEssyf7Vk7EFGbVVneJ6BJTrBC2uIwy21r6pGIuad kfl65la0WYEUJY1WVtbQndF9W44F6hSZEBf9D+2zbibp23gfC67KIo+IgpK0Xmn2jEH29HTy 8Gh4ZJ2ik7sFqU0KEW9Bf5OOxev/wPwBB2pVJg5FEFSr1JQQvEOy8xHq8SeZPSrfmjowHDV/ MAByysy6j8KWqm5PZqOtfX4okIgW1JkDAw96Fh5KWiZfPHoPWMs7ZcBVdZ9GIwOG5IyJdTj0 7XHRzQaj+yUPisYYRAMxEWDAx+PjIvybjpFApdl2mF7IA+z34+3698uD98vX0eYX/vrf45/f 8VxtT8MLoNEecPeX6wulvoT+y26Du91AabvL31TS5WchIEn0xu1dtaSsTiAWVn8/rsN03vs5 hDUKLEQ5RcTqLsFf77PoX5qnN1CvGKWYK7Fn3Jd3NB+GJ0FEZvFWV5LndLOPzpwJvyoT+6f3 w9vO6cM1KQd9dCx2W3QZosxdZocrUuyxHNve/V5/tVmWtQ3hmewzpsMBBSlynYE4XE2Ops9R 46M0nNuOBfccPl6GuYePn5Ok7FnEF1lFdM4NIjXKKdeqMNdmPMME0kwbEi8K+1Ko3elJ8Mz0 ZZ/RwBhE3oOyLSDlXkXZCQv3Xis+B/fbTwEGAMojklkNZW5kc3RyZWFtDWVuZG9iag00MyAw IG9iag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDM5IC9IZWln aHQgMzIgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMjMgMCBSIC9MZW5ndGgg MTA3MSAvRmlsdGVyIC9EQ1REZWNvZGUgPj4gDXN0cmVhbQ0K/9j/7gAOQWRvYmUAZIAAAAAB /9sAhAAOCgoKCwoOCwsOFQ0MDRUYEg4OEhgcFhYXFhYcGxUXFxcXFRsbICEjISAbKysuLisr Pj09PT5AQEBAQEBAQEBAAQ8NDQ8RDxMQEBMUDxEPFBcSFBQSFyIXFxkXFyIsHxsbGxsfLCYp IyMjKSYvLywsLy87Ozk7O0BAQEBAQEBAQED/wAARCAAgACcDASIAAhEBAxEB/90ABAAD/8QB PwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEBAQAAAAAAAAABAAIDBAUG BwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYUkaGxQiMkFVLBYjM0 coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5SkhbSVxNTk9KW1 xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQACEQMhMRIE QVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RFVTZ0 ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB AAIRAxEAPwDO6h9Y+uHOydudaxoseGsY4taAHEAABbND+u4nRH9bz+o3jc2MTHLydzn+1rnT 8d0Lk82Pt+RPHrPn/OK7T61ZlVtmFiVgPxMKj7Za2Ja4xtoYfidPmr+QAcEREUdTp0HT6tWB PqJJ02+rqN6XmX9MxH2dZvxsn0gHvFgLHPJLjPExMcrjuq5/1m6VluxcjqFxMB1djbCWvYeH NKFaW0004dkOdjUOt9E67sjKiAG/yGlp+Sv/AFtwqun9P6Lhf9qKqrDb4+4sd/1W6E3HGpAG pcd/o/W0yNgkenhrq3/q/wBV6nm9D6rZfl2usw6n2U2bvdPpv0LuSJEpKr9VP+Qev/8Ahd// AJ7eko6H3mqFXt9F9n2bvo//0M7qP1c62M/J24dj2mx5a9olpBcSCCul+ref17CqZgZ/TLbq GAiu7bDmNAnaZ+kPBdabr2uyT6Rc2oA0gaF/t3EA/HRCOZljA+0/Y3HIBLTihwnR+yQ4gafn fBTSzmUeGUYljjiETYJeX6ZZn9Mxrsm7pN2Z1DPsde6GgNZ7iGsJMkePC53qmB9Zuq5j8zKw rTY/QNDCGtaOGtHgF6ddk3V5ePjtx3WV3B5svH0a9okA6d0q8i92XbQ7HLKWD2Xzo8wwnSNP pRz2KUc5iTIRjZ6qOIEAEmg8d9W+kdSxuh9ZZfjvrsyaLGU1ke5x9N40HxKS7Gm7KdhG6ykM yNryKZMSCdomO+iSb7p9z3NLXcA4eHo//9kKZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iag03 NjcgDWVuZG9iag00NSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ0 IDAgUiA+PiANc3RyZWFtDQpIiXRVu24cMQzs9yu2tAOsID5ESW0eTVpfF6QykMpX+f8Bkxzt 5mIgMIw97XH4mBnqNmpUptHOJmUy7XHW4WeVMsbDmaWQf/+6vWy016L+36ft768baS+mCInQ +3aBqJXmyd/8TSv6EPO2/fmySZ2lcYT1BZR6hvUyKu1SqUh0JyOr82hAKBK/bmyzWJRqnP2y CDJYxZMUrRgl0tudDe0aF/MaNKiMOLeJc2cgPONCmCY3rFa6VyXPlWexxdlEbbbCujhqVuqa pC5SBjolPJ0U5zwrc8u8SYqOkaPJrFn+vuns6w3ns1VbZ82GG0lGyqiLlMY1RxCzohHBTl8g XNQQuwkig+6FEEYr1rPtJjPpowGJGqMH0nkiXNsYg1zEqKVzJAnOZpTUBqCdFdR7ih4ULIsX iEIKFE/I03RxzqqlepwBRYsDH5FTI8TNeUrUBNKQpXGogSvyMmGg+D7zhOiXRD3lOt/dM0t8 ol5PiXTxYLAXfDt0+RZSuW8Hw6dMCZTes08+ie6UT5a+GhYnBp7SS6okwpcpJJIGZPgYBIoo dqBLMidVs2bsSPq1LxsQXxwyuvGlSzLcWlEzMo0cCtskbKsGOYIyBwxDAtrZ50t6RdY2YUcc 4RMGibEbQNi6LxT2cAHSWIR7Jon3mNA23knyR0rYyQpmg3hZ2wLhkvivt626BX38/cCjLq2q 5d1A5h9u9+3X043pePZ1fZLn37ef249Axt/Lt006CJJ6yWcjVRZvKK8dW9RSw97YSe245Dup pZQtEDGmMAQWw5UmvnkgSrzPpJbnskRHTcbGSZ8Lca6ALLOf8p37LQzy45zdeg88QC2GfI9y Bh8xrWskwrNlOq/g8HG3vwn+y7F0v7LUqRWaPsTFMQk45uT408/CQUmFRrKu4pjvj7ooME60 79Ye2+ok/BuCtIfbe7a+H24I4fYphq7STIbR3dStmXfvwF6vpPXRD9UH6wHi6FgnGi7uzOG9 9N7HgtF8hB1BlLN5jMLe8KcYPq32IcAAjfhrKA1lbmRzdHJlYW0NZW5kb2JqDTQ2IDAgb2Jq DTw8IA0vVHlwZSAvRXh0R1N0YXRlIA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIgL0lkZW50 aXR5IA0+PiANZW5kb2JqDXhyZWYNMCA0OSANMDAwMDAwMDAxOCA2NTUzNSBmDQowMDAwMDAw MDE2IDAwMDAwIG4NCjAwMDAwMDAxNjggMDAwMDAgbg0KMDAwMDAwMDM1MCAwMDAwMCBuDQow MDAwMDAyMTE2IDAwMDAwIG4NCjAwMDAwMDIyNjggMDAwMDAgbg0KMDAwMDAwMjQ1MCAwMDAw MCBuDQowMDAwMDA1MDk1IDAwMDAwIG4NCjAwMDAwMDUyNDcgMDAwMDAgbg0KMDAwMDAwNTQy OSAwMDAwMCBuDQowMDAwMDA2ODU1IDAwMDAwIG4NCjAwMDAwMDcwMTAgMDAwMDAgbg0KMDAw MDAwNzIwNSAwMDAwMCBuDQowMDAwMDExMjc0IDAwMDAwIG4NCjAwMDAwMTE0MjkgMDAwMDAg bg0KMDAwMDAxMTYyNCAwMDAwMCBuDQowMDAwMDE0NjA0IDAwMDAwIG4NCjAwMDAwMTQ3MDIg MDAwMDAgbg0KMDAwMDAwMDA0NyAwMDAwMSBmDQowMDAwMDE0OTUzIDAwMDAwIG4NCjAwMDAw MTUwMDggMDAwMDAgbg0KMDAwMDAxNTIxNiAwMDAwMCBuDQowMDAwMDE1NDExIDAwMDAwIG4N CjAwMDAwMTU5NjIgMDAwMDAgbg0KMDAwMDAxNjE0MiAwMDAwMCBuDQowMDAwMDE2MzIxIDAw MDAwIG4NCjAwMDAwMTYzNDIgMDAwMDAgbg0KMDAwMDAxNzMzNiAwMDAwMCBuDQowMDAwMDE3 MzU3IDAwMDAwIG4NCjAwMDAwMTg0MDYgMDAwMDAgbg0KMDAwMDAxODQyNyAwMDAwMCBuDQow MDAwMDE5NDY5IDAwMDAwIG4NCjAwMDAwMTk5NDIgMDAwMDAgbg0KMDAwMDAyMDEyOCAwMDAw MCBuDQowMDAwMDIwMTQ5IDAwMDAwIG4NCjAwMDAwMjA4OTggMDAwMDAgbg0KMDAwMDAyMTA5 MiAwMDAwMCBuDQowMDAwMDIxNTA2IDAwMDAwIG4NCjAwMDAwMjE1MjcgMDAwMDAgbg0KMDAw MDAyMjQxNiAwMDAwMCBuDQowMDAwMDIyNDM3IDAwMDAwIG4NCjAwMDAwMjMyODQgMDAwMDAg bg0KMDAwMDAyMzMwNSAwMDAwMCBuDQowMDAwMDI0MjQyIDAwMDAwIG4NCjAwMDAwMjU0Nzgg MDAwMDAgbg0KMDAwMDAyNTQ5OSAwMDAwMCBuDQowMDAwMDI2MzQ0IDAwMDAwIG4NCjAwMDAw MDAwNDggMDAwMDEgZg0KMDAwMDAwMDAwMCAwMDAwMSBmDQp0cmFpbGVyDTw8DS9TaXplIDQ5 DS9JbmZvIDE3IDAgUiANL1Jvb3QgMTkgMCBSIA0vSURbPGVlZDMxNWUwZWFlZTVjZDkwZWE3 NmVkOTdhZWE5MjA2Pjw4OGQ4NWEyNjAyYmVmZDAzMDFhZGJlZTM2Yjg3YTQ3ZT5dDT4+DXN0 YXJ0eHJlZg0yNjQyMg0lJUVPRg0= --------------270D8844FEF77645E1AF6117-- From owner-ips@ece.cmu.edu Sat Jul 21 00:20:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03031 for ; Sat, 21 Jul 2001 00:20:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6L2xR928792 for ips-outgoing; Fri, 20 Jul 2001 22:59:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6L2xPg28788 for ; Fri, 20 Jul 2001 22:59:25 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 9F53D1577 for ; Fri, 20 Jul 2001 19:59:24 -0700 (PDT) Received: from rose.hp.com (sindhu.rose.hp.com [15.9.210.155]) by core.rose.hp.com with ESMTP (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id UAA01149 for ; Fri, 20 Jul 2001 20:00:37 -0700 (PDT) Message-ID: <3B58F051.1FEFDC31@rose.hp.com> Date: Fri, 20 Jul 2001 20:00:33 -0700 From: "Mallikarjun C." Reply-To: cbm@rose.hp.com Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI state transitions question [was: new iSCSI draft 07.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sanjay, You are right to the extent that S1 and S13 are similar since neither has a valid associated transport connection, but they differ in if active iSCSI tasks could possibly be associated with the state. S1 can not have any unfinished tasks, while S13 may. To quote 6.1 - The BUSY state (S13) implies that there are possibly iSCSI tasks that have not reached conclusion and are still considered busy. S13 is reached either through S19-* transitions, or S20-* transitions, both of which happen without a clean iSCSI Logout hence the possibility of unfinished iSCSI tasks. To quote 6.1 again - Whenever a connection state machine (say, CSM-R) enters the BUSY state (S13), it must go through the state transitions additionally described in the connection recovery state diagram. The above is to eventually get to S1. Please review the pdf file I posted to this list as well which additionally contains a graphical representation of standard connection state diagram. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard Roseville cbm@rose.hp.com Sanjay Goyal wrote: > > Hi > It is regarding Rev7.0, > 6.1 Standard connection state diagram > > The transition condition from S12 to S13 seems illogical to me. After both > sides close the connection, should not the state be S1. > to me either the condition T18 is not correct or the transition to S13 is > not correct. > Please clarify the issue. > > Regards > Sanjay Goyal > > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, July 20, 2001 4:38 AM > To: internet-drafts@ietf.org > Cc: bassoon@YOGI.PDL.CMU.EDU; ips@ece.cmu.edu > Subject: new iSCSI draft 07.txt > > On behalf of a group of authors from several organizations as part of the > IPS working group I submit a revision of an IETF-draft for immediate > publication. It specifies iSCSI - a SCSI Over TCP protocol and the file > name is "draft-ietf-ips-iSCSI-07.txt". It completely replaces > "draft-ietf-ips-iSCSI-06.txt". > > The draft can be found at: > > http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-07.txt > > Julian Satran - IBM Research Laboratory at Haifa From owner-ips@ece.cmu.edu Sat Jul 21 13:15:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01520 for ; Sat, 21 Jul 2001 13:15:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6LFnjx20453 for ips-outgoing; Sat, 21 Jul 2001 11:49:45 -0400 (EDT) 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 f6LFnhg20448 for ; Sat, 21 Jul 2001 11:49:43 -0400 (EDT) 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 RAA121956 for ; Sat, 21 Jul 2001 17:49:36 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6LFnWu229934 for ; Sat, 21 Jul 2001 17:49:36 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 21 Jul 2001 18:55:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 21/07/2001 18:49:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, All are correct. Julo Steve Senum on 20-07-2001 21:13:47 Please respond to Steve Senum To: ips@ece.cmu.edu cc: Subject: Re: iSCSI Login Questions Julian, Thanks for the reply. I have a few of more cases I would like to be sure of. Please comment on whether you think the given sequence is valid. Case 1: I-> Login AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes Case 2: I-> Login AuthMethod=none HeaderDigest=crc-32C,none DataDigest=crc-32C,none T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Case 3: I-> Login AuthMethod=none HeaderDigest=crc-32C,none DataDigest=crc-32C,none SecurityContextComplete=yes T-> Login-PR AuthMethod=none HeaderDigest=crc-32C DataDigest=crc-32C SecurityContextComplete=yes Thanks, Steve Senum From owner-ips@ece.cmu.edu Sat Jul 21 22:06:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19231 for ; Sat, 21 Jul 2001 22:06:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6M0QbF18980 for ips-outgoing; Sat, 21 Jul 2001 20:26:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6M0QMg18966 for ; Sat, 21 Jul 2001 20:26:22 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id B7478302 for ; Sat, 21 Jul 2001 17:26:21 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id RAA01066 for ips@ece.cmu.edu; Sat, 21 Jul 2001 17:27:34 -0700 (PDT) Message-Id: <200107220027.RAA01066@core.rose.hp.com> Subject: Re: iSCSI state transitions question To: ips@ece.cmu.edu Date: Sat, 21 Jul 2001 17:27:34 PDT In-Reply-To: <3B58F051.1FEFDC31@rose.hp.com>; from "Mallikarjun C." at Jul 20, 101 9:04 pm Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry, the sentence below: >S13 is reached either through S19-* transitions, or S20-*.... should have read: S13 is reached either through T19-* transitions, or T20-*.... BTW, the iSCSI state diagrams pdf file is now posted on Julian's website. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Sanjay, > >You are right to the extent that S1 and S13 are similar >since neither has a valid associated transport connection, >but they differ in if active iSCSI tasks could possibly be >associated with the state. S1 can not have any unfinished >tasks, while S13 may. >To quote 6.1 - > The BUSY state (S13) implies that there are possibly > iSCSI tasks that have not reached conclusion and are > still considered busy. > >S13 is reached either through S19-* transitions, or S20-* >transitions, both of which happen without a clean iSCSI Logout >hence the possibility of unfinished iSCSI tasks. > >To quote 6.1 again - > Whenever a connection state machine (say, CSM-R) enters > the BUSY state (S13), it must go through the state transitions > additionally described in the connection recovery state > diagram. > >The above is to eventually get to S1. > >Please review the pdf file I posted to this list as well >which additionally contains a graphical representation of standard >connection state diagram. > >Regards. >-- >Mallikarjun > > >Mallikarjun Chadalapaka >Networked Storage Architecture >Network Storage Solutions Organization >Hewlett-Packard Roseville >cbm@rose.hp.com > > >Sanjay Goyal wrote: >> >> Hi >> It is regarding Rev7.0, >> 6.1 Standard connection state diagram >> >> The transition condition from S12 to S13 seems illogical to me. After both >> sides close the connection, should not the state be S1. >> to me either the condition T18 is not correct or the transition to S13 is >> not correct. >> Please clarify the issue. >> >> Regards >> Sanjay Goyal >> >> >> -----Original Message----- >> From: Julian Satran [mailto:Julian_Satran@il.ibm.com] >> Sent: Friday, July 20, 2001 4:38 AM >> To: internet-drafts@ietf.org >> Cc: bassoon@YOGI.PDL.CMU.EDU; ips@ece.cmu.edu >> Subject: new iSCSI draft 07.txt >> >> On behalf of a group of authors from several organizations as part of the >> IPS working group I submit a revision of an IETF-draft for immediate >> publication. It specifies iSCSI - a SCSI Over TCP protocol and the file >> name is "draft-ietf-ips-iSCSI-07.txt". It completely replaces >> "draft-ietf-ips-iSCSI-06.txt". >> >> The draft can be found at: >> >> http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-07.txt >> >> Julian Satran - IBM Research Laboratory at Haifa > From owner-ips@ece.cmu.edu Sat Jul 21 22:36:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19311 for ; Sat, 21 Jul 2001 22:06:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6M15Ju21026 for ips-outgoing; Sat, 21 Jul 2001 21:05:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6M15Fg20996 for ; Sat, 21 Jul 2001 21:05:15 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Sat Jul 21 21:00:20 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Sat Jul 21 21:04:02 EDT 2001 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 VAA04670; Sat, 21 Jul 2001 21:03:32 -0400 (EDT) Message-ID: <3B5A2664.692BD175@research.bell-labs.com> Date: Sat, 21 Jul 2001 21:03:32 -0400 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: cbm@rose.hp.com CC: ips@ece.cmu.edu Subject: Re: iSCSI state transitions References: <3B58E738.E49B116A@rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mallikarjun, Just a few comments on this.. pages 5-6 look good but pages 1-4 have a high information density. (Uneasy rests the eye which traces the transitions..) I suspect the primary problem is that the initiator and target connection state diagrams have got combined into one diagram. As a result, most states as well as transitions have got special-cased as initiator-only or target-only. (For example, T1, T2, T3, T7, T15 are all initiator-only) Other points: a) State S13 should be called "suspended" or "to_be_recovered" The tasks are undoubtedly "busy" but the connection is certainly suspended. The state name must reflect the state of the connection, not the individual tasks. b) We seem to be tracking the TCP state (S2, S12 for SYN,FIN) It adds to the complexity and sidetracks one from the main purpose, which (i thought) was to document error recovery. If we remove the TCP state tracking, we may be be able to eliminate some states (S2, S12, etc) and keep the focus on iSCSI. Assume that connection establishment and destruction is an action on transition, not a whole new state to document. c) Transitions T7, T8 can be removed. How individual implementations behave on login errors (do a retry/bailout) need not be covered. On error, the connection will be closed and the state can be restored to S1 in one step. All in all, it should be possible to express the connection state for each end (with error recovery) in about 7-8 states. The following patterns would then be easy to spot: 1) There is one way to move from FREE to LOGGED_IN 2) There are four ways to move from LOGGED_IN to FREE a) by self-initiated logout -target sends Async -initiator sends Logout command b) by "other-end" requested logout -target receives a Logout command -initiator receives an Async message c) a transport failure followed by connection recovery failure which indicates a need to abort tasks. d) a transport failure followed by connection recovery success which indicates a clean shutdown. regards, -Sandeep "Mallikarjun C." wrote: > > All: > > Excuse my posting of the (relatively small sized, 27KB) > pdf file with the iSCSI state diagrams. I'll post a URL > shortly, but I wanted to get this out sooner to give > reviewers a graphical description of rev07, section 6. > > This was reviewed in the ERT forum, and the ASCII versions > of this slide set were incorporated into rev07. > > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard, Roseville > cbm@rose.hp.com > > ------------------------------------------------------------------------ > Name: iscsi_states.pdf > iscsi_states.pdf Type: Portable Document Format (application/pdf) > Encoding: base64 > Download Status: Not downloaded with message From owner-ips@ece.cmu.edu Mon Jul 23 00:09:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19238 for ; Mon, 23 Jul 2001 00:09:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6N2Z2k22547 for ips-outgoing; Sun, 22 Jul 2001 22:35:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from cs.unh.edu (cs.unh.edu [132.177.4.32]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6N2Z1g22543 for ; Sun, 22 Jul 2001 22:35:01 -0400 (EDT) Received: from lava.cs.unh.edu (lava.cs.unh.edu [132.177.4.30]) by cs.unh.edu (8.11.0/8.11.0) with ESMTP id f6N2YXc13151; Sun, 22 Jul 2001 22:34:33 -0400 (EDT) Date: Sun, 22 Jul 2001 22:34:33 -0400 (EDT) From: Qin Tao To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, Julian: I don't think "SecurityContextComplete=yes" should be used in the Login Command together with security parameters(as in Cases 1&3). Draft 07,Clause 4.1 says: "-Every party in the security negotiation indicates that it has completed building its security context (has all the required ^^^^^^^^^^^^^^^^^ information) by sending the key=value pair: ^^^^^^^^^^^ SecurityContextComplete=yes" When Login Command is sending out, the initiator has no idea how the target would response, how could it "has all the required information"? In Case 1, the initiator limits the response from target by providing only one option for each parameter, so that it has a good guess of the response. However, "a text response including only SecurityContextComplete=yes concludes the security sub-phase" (page 101 in draft 7). The initiator still needs to send SecurityContextComplete=yes in the next Text Command and wait for a Text Response with SecurityContextComplete=yes only to end the security sub-phase. It is meaningless to include the SecurityContextComplete=yes so early in the Login Command. If both Cases 2 and 3 are correct, sending "SecurityContextComplete=yes" becomes optional and loses its value to be used. I also checked the "Login Phase Examples" in Appendix A and I did not find any example with "SecurityContextComplete=yes" in Login Command. Could you please give more explanations on this issue? Thanks. Qin On Sat, 21 Jul 2001, Julian Satran wrote: > > Steve, > > All are correct. > > Julo > > Steve Senum on 20-07-2001 21:13:47 > > Please respond to Steve Senum > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI Login Questions > > > > > Julian, > > Thanks for the reply. > > I have a few of more cases I would like to be sure of. > Please comment on whether you think the given sequence > is valid. > > > Case 1: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > > > Case 2: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C,none > DataDigest=crc-32C,none > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > > Case 3: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C,none > DataDigest=crc-32C,none > SecurityContextComplete=yes > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > > > Thanks, > Steve Senum > > > > From owner-ips@ece.cmu.edu Mon Jul 23 04:56:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07671 for ; Mon, 23 Jul 2001 04:56:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6N7TQq08833 for ips-outgoing; Mon, 23 Jul 2001 03:29:26 -0400 (EDT) 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 f6N7TPg08828 for ; Mon, 23 Jul 2001 03:29:25 -0400 (EDT) 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 JAA187502 for ; Mon, 23 Jul 2001 09:29:18 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6N7TGn61410 for ; Mon, 23 Jul 2001 09:29:17 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Mon, 23 Jul 2001 08:50:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 23/07/2001 10:29:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Qin, The question Steve raised was if the example is correct and the example is correct. In the example the initiator clearly indicates that it is not offering any Authentication method ( "none") and it might as well conclude the security phase. It does not need any additional exchange. The target can reject the login. The fact that it is no such case included in examples does not make it incorrect. As for the SecurityContextComplete Steve has chose a strictly literal interpretation of the relevant paragraph from 4.2: The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item (even if it is not selected). Julo Qin Tao on 23-07-2001 05:34:33 Please respond to Qin Tao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions Hi, Julian: I don't think "SecurityContextComplete=yes" should be used in the Login Command together with security parameters(as in Cases 1&3). Draft 07,Clause 4.1 says: "-Every party in the security negotiation indicates that it has completed building its security context (has all the required ^^^^^^^^^^^^^^^^^ information) by sending the key=value pair: ^^^^^^^^^^^ SecurityContextComplete=yes" When Login Command is sending out, the initiator has no idea how the target would response, how could it "has all the required information"? In Case 1, the initiator limits the response from target by providing only one option for each parameter, so that it has a good guess of the response. However, "a text response including only SecurityContextComplete=yes concludes the security sub-phase" (page 101 in draft 7). The initiator still needs to send SecurityContextComplete=yes in the next Text Command and wait for a Text Response with SecurityContextComplete=yes only to end the security sub-phase. It is meaningless to include the SecurityContextComplete=yes so early in the Login Command. If both Cases 2 and 3 are correct, sending "SecurityContextComplete=yes" becomes optional and loses its value to be used. I also checked the "Login Phase Examples" in Appendix A and I did not find any example with "SecurityContextComplete=yes" in Login Command. Could you please give more explanations on this issue? Thanks. Qin On Sat, 21 Jul 2001, Julian Satran wrote: > > Steve, > > All are correct. > > Julo > > Steve Senum on 20-07-2001 21:13:47 > > Please respond to Steve Senum > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI Login Questions > > > > > Julian, > > Thanks for the reply. > > I have a few of more cases I would like to be sure of. > Please comment on whether you think the given sequence > is valid. > > > Case 1: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > > > Case 2: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C,none > DataDigest=crc-32C,none > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > > Case 3: > > I-> Login AuthMethod=none > HeaderDigest=crc-32C,none > DataDigest=crc-32C,none > SecurityContextComplete=yes > T-> Login-PR AuthMethod=none > HeaderDigest=crc-32C > DataDigest=crc-32C > SecurityContextComplete=yes > > > Thanks, > Steve Senum > > > > From owner-ips@ece.cmu.edu Mon Jul 23 08:57:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17001 for ; Mon, 23 Jul 2001 08:57:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NBTY401448 for ips-outgoing; Mon, 23 Jul 2001 07:29:34 -0400 (EDT) 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 f6NAtxg29569 for ; Mon, 23 Jul 2001 06:56:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09819; Mon, 23 Jul 2001 06:55:00 -0400 (EDT) Message-Id: <200107231055.GAA09819@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-gibbons-isnsmib-00.txt Date: Mon, 23 Jul 2001 06:55:00 -0400 Sender: owner-ips@ece.cmu.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, t.McSweeney Filename : draft-gibbons-isnsmib-00.txt Pages : 34 Date : 16-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based monitoring and management of an internet Storage Name Service (iSNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gibbons-isnsmib-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gibbons-isnsmib-00.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-gibbons-isnsmib-00.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: <20010720070049.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gibbons-isnsmib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gibbons-isnsmib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720070049.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Jul 23 15:15:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17283 for ; Mon, 23 Jul 2001 15:15:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NIjKS04164 for ips-outgoing; Mon, 23 Jul 2001 14:45:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe36.law11.hotmail.com [64.4.16.93]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NIjGg04125 for ; Mon, 23 Jul 2001 14:45:16 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Jul 2001 11:45:10 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: iSCSI Login Questions Date: Mon, 23 Jul 2001 14:44:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 23 Jul 2001 18:45:10.0476 (UTC) FILETIME=[99DA20C0:01C113A7] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit One other question that came up at UNH was the following: If an initiator says "AuthMethod=none<0> DataDigest=none<0> HeaderDigest=none" in the initial login, does that mean the parties have to use the SecurityContextComplete handshake? Does the scope of "even if it is not selected" below include the above? Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Monday, July 23, 2001 1:50 AM Subject: Re: iSCSI Login Questions > > Qin, > > The question Steve raised was if the example is correct and the example is > correct. > > In the example the initiator clearly indicates that it is not offering > any Authentication method ( "none") and it might as well conclude the > security phase. > It does not need any additional exchange. > > The target can reject the login. > > The fact that it is no such case included in examples does not make it > incorrect. > > As for the SecurityContextComplete Steve has chose a strictly literal > interpretation of the relevant paragraph from 4.2: > > The SecurityContextComplete handshake MUST be performed if any of > negotiating parties has offered a security/integrity item (even if it > is not selected). > > Julo > > > > > Qin Tao on 23-07-2001 05:34:33 > > Please respond to Qin Tao > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI Login Questions > > > > > Hi, Julian: > > I don't think "SecurityContextComplete=yes" should be used in the Login > Command together with security parameters(as in Cases 1&3). > > Draft 07,Clause 4.1 says: > > "-Every party in the security negotiation indicates that it has > completed building its security context (has all the required > ^^^^^^^^^^^^^^^^^ > information) by sending the key=value pair: > ^^^^^^^^^^^ > SecurityContextComplete=yes" > > When Login Command is sending out, the initiator has no idea how the > target would response, how could it "has all the required information"? > In Case 1, the initiator limits the response from target by providing only > one option for each parameter, so that it has a good guess of the > response. However, "a text response including only > SecurityContextComplete=yes concludes the security sub-phase" (page 101 in > draft 7). The initiator still needs to send SecurityContextComplete=yes > in the next Text Command and wait for a Text Response with > SecurityContextComplete=yes only to end the security sub-phase. It is > meaningless to include the SecurityContextComplete=yes so early in the > Login Command. > > If both Cases 2 and 3 are correct, sending "SecurityContextComplete=yes" > becomes optional and loses its value to be used. I also checked the "Login > Phase Examples" in Appendix A and I did not find any example with > "SecurityContextComplete=yes" in Login Command. Could you please give more > explanations on this issue? > > Thanks. > Qin > > > > > On Sat, 21 Jul 2001, Julian Satran wrote: > > > > > Steve, > > > > All are correct. > > > > Julo > > > > Steve Senum on 20-07-2001 21:13:47 > > > > Please respond to Steve Senum > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI Login Questions > > > > > > > > > > Julian, > > > > Thanks for the reply. > > > > I have a few of more cases I would like to be sure of. > > Please comment on whether you think the given sequence > > is valid. > > > > > > Case 1: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > > > > > Case 2: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C,none > > DataDigest=crc-32C,none > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > > > Case 3: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C,none > > DataDigest=crc-32C,none > > SecurityContextComplete=yes > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > > > > > Thanks, > > Steve Senum > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 23 15:18:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17429 for ; Mon, 23 Jul 2001 15:18:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NINi902371 for ips-outgoing; Mon, 23 Jul 2001 14:23:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NIM1g02205 for ; Mon, 23 Jul 2001 14:22:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by saturn.cs.uml.edu (8.11.0/8.11.2) with SMTP id f6NILxX223283; Mon, 23 Jul 2001 14:21:59 -0400 (EDT) Date: Mon, 23 Jul 2001 14:21:59 -0400 (EDT) From: Mike Brown To: rod.harrison@windriver.com cc: ips@ece.cmu.edu, sandeepj@research.bell-labs.com Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Rod, > > The initiator needs the initiator task tag in order to >associate inbound PDUs with the correct command. For >untagged commands the ATTR field of the SCSI Command PDU >should be set to 0, Untagged. The initiator associates inbound PDU's with the itt. I agree with Sandeep. If the SCSI Command is untagged, then the itt should be explicitly set to 0xffffffff in the iSCSI PDU since the initiator can still use the itt to associate inboud iSCSI PDU's with a current SCSI command because SAM-2 sec 4.9.1 states: "An untagged task does not include a tag in any of its component definitions, thus restricting the number of concurrent untagged tasks in a single task set to _ONE_ per initiator" If there are multiple outstanding tasks, (one untagged task and multiple tagged tasks), each task will still have a unique itt, and therefore the initiator can associate inbound iSCSI PDU's with a particular SCSI command. > > - Rod > >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On >Behalf Of >Sandeep Joshi >Sent: Monday, July 23, 2001 10:31 AM >To: ips@ece.cmu.edu >Subject: Re: iSCSI Plugfest at UNH (misc issues) > > > > >Hi Julian, > >Some additional items from the plugfest to resolve.. > >1) Sec 2.3.1 : Untagged tasks. > If the task attribute in the SCSI Command is "untagged" > then the initiator task tag should be ignored, correct ? > Can the draft explicitly state that the initiator must > set the Initiator Task Tag to 0x'ffffffff if its an > untagged task. > > Do we assume that the initiator ULP will not issue more >than > one untagged tasks simultaneously ? > >2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the >expCmdSN ? > Clearly, the target has received and executed the >commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which >response > is being received). > > This seems like a valid property which could be mandated > and checked, to allow efficient initiator >implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) > >3) Sending status in read PDU > Since quite a few initiators did not support this, > this feature had to be enabled or disabled frequently at > the target. > > Either we should make it mandatory to implement (at >initiator) > or we should add a key "SendStatusInReadPDU=yes/no". The >first > option seems simpler. > >thanks >-Sandeep > -Michael F. Brown, UMass Lowell Computer Science phone: (978) 934-5354 email: mbrown@cs.uml.edu "If a driver behaves incorrectly, the Driver Verifier will crash the system immediately. In this way, the Driver Verifier prevents the driver bug from being masked by further processing. The result is a faster, easier debugging process." -Windows 2000 Driver Development Kit Release Notes From owner-ips@ece.cmu.edu Mon Jul 23 15:18:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17464 for ; Mon, 23 Jul 2001 15:18:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NIfWY03894 for ips-outgoing; Mon, 23 Jul 2001 14:41:32 -0400 (EDT) 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 f6NIcWg03645 for ; Mon, 23 Jul 2001 14:38:32 -0400 (EDT) Received: from eddylaptop (h00e0987e14a3.ne.mediaone.net [66.31.75.202]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6NIcUc14982 for ; Mon, 23 Jul 2001 14:38:31 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: specific initiator Date: Mon, 23 Jul 2001 14:38:49 -0400 Message-ID: <000b01c113a6$b890a2b0$0100a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 4.2 says: -The target MUST reply with the first option in the list it supports and is allowed for the specific initiator. Can we also specify that the InitiatorName must be used before anything that requires "specific initiator" knowledge. That can simplify programming and is probably not a big restriction. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Jul 23 15:20:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17533 for ; Mon, 23 Jul 2001 15:20:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NHhns28733 for ips-outgoing; Mon, 23 Jul 2001 13:43:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NHhlg28729 for ; Mon, 23 Jul 2001 13:43:48 -0400 (EDT) Received: from london ([192.168.1.33]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id KAA24457; Mon, 23 Jul 2001 10:43:37 -0700 (PDT) From: "Rod Harrison" To: "Sandeep Joshi" , Subject: RE: iSCSI Plugfest at UNH (misc issues) Date: Mon, 23 Jul 2001 12:44:48 -0500 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.2314.1300 In-Reply-To: <3B5C431F.3B813A89@research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep, The initiator needs the initiator task tag in order to associate inbound PDUs with the correct command. For untagged commands the ATTR field of the SCSI Command PDU should be set to 0, Untagged. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Sandeep Joshi Sent: Monday, July 23, 2001 10:31 AM To: ips@ece.cmu.edu Subject: Re: iSCSI Plugfest at UNH (misc issues) Hi Julian, Some additional items from the plugfest to resolve.. 1) Sec 2.3.1 : Untagged tasks. If the task attribute in the SCSI Command is "untagged" then the initiator task tag should be ignored, correct ? Can the draft explicitly state that the initiator must set the Initiator Task Tag to 0x'ffffffff if its an untagged task. Do we assume that the initiator ULP will not issue more than one untagged tasks simultaneously ? 2) ExpCmdSN What are the semantics of something like this.. the target does not increase the expCmdSN but keeps sending the status (SCSI response) for commands after the expCmdSN ? Clearly, the target has received and executed the commands (in cmdSN order). Hence, the expCmdSN in a SCSI response must not be less than the cmdSN of the original command (for which response is being received). This seems like a valid property which could be mandated and checked, to allow efficient initiator implementations. The target eventually suffers but the standard could prevent such targets from being deployed :-) 3) Sending status in read PDU Since quite a few initiators did not support this, this feature had to be enabled or disabled frequently at the target. Either we should make it mandatory to implement (at initiator) or we should add a key "SendStatusInReadPDU=yes/no". The first option seems simpler. thanks -Sandeep From owner-ips@ece.cmu.edu Mon Jul 23 17:47:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26468 for ; Mon, 23 Jul 2001 17:47:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NK2V310913 for ips-outgoing; Mon, 23 Jul 2001 16:02:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f92.law11.hotmail.com [64.4.17.92]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NK2Tg10909 for ; Mon, 23 Jul 2001 16:02:29 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Jul 2001 13:02:24 -0700 Received: from 66.31.75.202 by lw11fd.law11.hotmail.msn.com with HTTP; Mon, 23 Jul 2001 20:02:23 GMT X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: mbrown@cs.uml.edu, rod.harrison@windriver.com Cc: ips@ece.cmu.edu, sandeepj@research.bell-labs.com Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) Date: Mon, 23 Jul 2001 16:02:23 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2001 20:02:24.0007 (UTC) FILETIME=[63A6D970:01C113B2] Sender: owner-ips@ece.cmu.edu Precedence: bulk For convience of programming at the initiator, it would be best to let the initiator decide if it wants to use the ITT or not. What is the problem from the target's standpoint if there is a value in the ITT for an untagged request? Eddy ----Original Message Follows---- From: Mike Brown To: rod.harrison@windriver.com CC: ips@ece.cmu.edu, sandeepj@research.bell-labs.com Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) Date: Mon, 23 Jul 2001 14:21:59 -0400 (EDT) Rod, > > The initiator needs the initiator task tag in order to >associate inbound PDUs with the correct command. For >untagged commands the ATTR field of the SCSI Command PDU >should be set to 0, Untagged. The initiator associates inbound PDU's with the itt. I agree with Sandeep. If the SCSI Command is untagged, then the itt should be explicitly set to 0xffffffff in the iSCSI PDU since the initiator can still use the itt to associate inboud iSCSI PDU's with a current SCSI command because SAM-2 sec 4.9.1 states: "An untagged task does not include a tag in any of its component definitions, thus restricting the number of concurrent untagged tasks in a single task set to _ONE_ per initiator" If there are multiple outstanding tasks, (one untagged task and multiple tagged tasks), each task will still have a unique itt, and therefore the initiator can associate inbound iSCSI PDU's with a particular SCSI command. > > - Rod > >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On >Behalf Of >Sandeep Joshi >Sent: Monday, July 23, 2001 10:31 AM >To: ips@ece.cmu.edu >Subject: Re: iSCSI Plugfest at UNH (misc issues) > > > > >Hi Julian, > >Some additional items from the plugfest to resolve.. > >1) Sec 2.3.1 : Untagged tasks. > If the task attribute in the SCSI Command is "untagged" > then the initiator task tag should be ignored, correct ? > Can the draft explicitly state that the initiator must > set the Initiator Task Tag to 0x'ffffffff if its an > untagged task. > > Do we assume that the initiator ULP will not issue more >than > one untagged tasks simultaneously ? > >2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the >expCmdSN ? > Clearly, the target has received and executed the >commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which >response > is being received). > > This seems like a valid property which could be mandated > and checked, to allow efficient initiator >implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) > >3) Sending status in read PDU > Since quite a few initiators did not support this, > this feature had to be enabled or disabled frequently at > the target. > > Either we should make it mandatory to implement (at >initiator) > or we should add a key "SendStatusInReadPDU=yes/no". The >first > option seems simpler. > >thanks >-Sandeep > -Michael F. Brown, UMass Lowell Computer Science phone: (978) 934-5354 email: mbrown@cs.uml.edu "If a driver behaves incorrectly, the Driver Verifier will crash the system immediately. In this way, the Driver Verifier prevents the driver bug from being masked by further processing. The result is a faster, easier debugging process." -Windows 2000 Driver Development Kit Release Notes _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Mon Jul 23 18:14:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27649 for ; Mon, 23 Jul 2001 18:14:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NFW4D18302 for ips-outgoing; Mon, 23 Jul 2001 11:32:04 -0400 (EDT) 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 f6NFW2g18296 for ; Mon, 23 Jul 2001 11:32:02 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Mon Jul 23 11:30:39 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Mon Jul 23 11:31:08 EDT 2001 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 LAA16287 for ; Mon, 23 Jul 2001 11:30:39 -0400 (EDT) Message-ID: <3B5C431F.3B813A89@research.bell-labs.com> Date: Mon, 23 Jul 2001 11:30:39 -0400 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 Plugfest at UNH (misc issues) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Julian, Some additional items from the plugfest to resolve.. 1) Sec 2.3.1 : Untagged tasks. If the task attribute in the SCSI Command is "untagged" then the initiator task tag should be ignored, correct ? Can the draft explicitly state that the initiator must set the Initiator Task Tag to 0x'ffffffff if its an untagged task. Do we assume that the initiator ULP will not issue more than one untagged tasks simultaneously ? 2) ExpCmdSN What are the semantics of something like this.. the target does not increase the expCmdSN but keeps sending the status (SCSI response) for commands after the expCmdSN ? Clearly, the target has received and executed the commands (in cmdSN order). Hence, the expCmdSN in a SCSI response must not be less than the cmdSN of the original command (for which response is being received). This seems like a valid property which could be mandated and checked, to allow efficient initiator implementations. The target eventually suffers but the standard could prevent such targets from being deployed :-) 3) Sending status in read PDU Since quite a few initiators did not support this, this feature had to be enabled or disabled frequently at the target. Either we should make it mandatory to implement (at initiator) or we should add a key "SendStatusInReadPDU=yes/no". The first option seems simpler. thanks -Sandeep From owner-ips@ece.cmu.edu Mon Jul 23 18:58:52 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29299 for ; Mon, 23 Jul 2001 18:58:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NKsOX15100 for ips-outgoing; Mon, 23 Jul 2001 16:54:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from saturn.cs.uml.edu (saturn.cs.uml.edu [129.63.8.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NKsLg15090 for ; Mon, 23 Jul 2001 16:54:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by saturn.cs.uml.edu (8.11.0/8.11.2) with SMTP id f6NKsGX257983; Mon, 23 Jul 2001 16:54:16 -0400 (EDT) Date: Mon, 23 Jul 2001 16:54:16 -0400 (EDT) From: Mike Brown To: Eddy Quicksall cc: rod.harrison@windriver.com, ips@ece.cmu.edu, sandeepj@research.bell-labs.com Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk >For convience of programming at the initiator, it would be best to let the >initiator decide if it wants to use the ITT or not. Actually, adding this check should be quite trivial for initiators. Something like: if (!ulp_scsi_command->is_tagged) { iscsi_scsi_cmd.itt = 0xffffffff; } else { iscsi_scsi_cmd.itt = iscsi_itt++; } Linux initiators could do something like: /* in queuecommand() */ if (!SCpnt->tag) { iscsi_scsi_cmd.itt = 0xffffffff; } else { iscsi_scsi_cmd.itt = iscsi_itt++; } This doesn't seem to be an unreasonable request if it significantly simplifies target code. >What is the problem from the target's standpoint if there is a value in the >ITT for an untagged request? > >Eddy > > >----Original Message Follows---- >From: Mike Brown >To: rod.harrison@windriver.com >CC: ips@ece.cmu.edu, sandeepj@research.bell-labs.com >Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) >Date: Mon, 23 Jul 2001 14:21:59 -0400 (EDT) > >Rod, > > > > > The initiator needs the initiator task tag in order to > >associate inbound PDUs with the correct command. For > >untagged commands the ATTR field of the SCSI Command PDU > >should be set to 0, Untagged. > >The initiator associates inbound PDU's with the itt. I agree with >Sandeep. If the SCSI Command is untagged, then the itt should >be explicitly set to 0xffffffff in the iSCSI PDU since the initiator can >still use the itt to associate inboud iSCSI PDU's with a current SCSI >command because SAM-2 sec 4.9.1 states: > >"An untagged task does not include a tag in any of its component >definitions, thus restricting the number of concurrent untagged tasks in a >single task set to _ONE_ per initiator" > >If there are multiple outstanding tasks, (one untagged task and multiple >tagged tasks), each task will still have a unique itt, and therefore the >initiator can associate inbound iSCSI PDU's with a particular SCSI >command. > > > > > - Rod > > > >-----Original Message----- > >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > >Behalf Of > >Sandeep Joshi > >Sent: Monday, July 23, 2001 10:31 AM > >To: ips@ece.cmu.edu > >Subject: Re: iSCSI Plugfest at UNH (misc issues) > > > > > > > > > >Hi Julian, > > > >Some additional items from the plugfest to resolve.. > > > >1) Sec 2.3.1 : Untagged tasks. > > If the task attribute in the SCSI Command is "untagged" > > then the initiator task tag should be ignored, correct ? > > Can the draft explicitly state that the initiator must > > set the Initiator Task Tag to 0x'ffffffff if its an > > untagged task. > > > > Do we assume that the initiator ULP will not issue more > >than > > one untagged tasks simultaneously ? > > > >2) ExpCmdSN > > What are the semantics of something like this.. the > > target does not increase the expCmdSN but keeps sending > > the status (SCSI response) for commands after the > >expCmdSN ? > > Clearly, the target has received and executed the > >commands > > (in cmdSN order). > > > > Hence, the expCmdSN in a SCSI response must not be less > > than the cmdSN of the original command (for which > >response > > is being received). > > > > This seems like a valid property which could be mandated > > and checked, to allow efficient initiator > >implementations. > > The target eventually suffers but the standard could > > prevent such targets from being deployed :-) > > > >3) Sending status in read PDU > > Since quite a few initiators did not support this, > > this feature had to be enabled or disabled frequently at > > the target. > > > > Either we should make it mandatory to implement (at > >initiator) > > or we should add a key "SendStatusInReadPDU=yes/no". The > >first > > option seems simpler. > > > >thanks > >-Sandeep > > > > >-Michael F. Brown, UMass Lowell Computer Science > >phone: (978) 934-5354 >email: mbrown@cs.uml.edu > >"If a driver behaves incorrectly, the Driver Verifier will crash the system > immediately. In this way, the Driver Verifier prevents the driver bug from > being masked by further processing. The result is a faster, easier >debugging > process." -Windows 2000 Driver Development Kit Release Notes > > >_________________________________________________________________ >Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > -Michael F. Brown, UMass Lowell Computer Science phone: (978) 934-5354 email: mbrown@cs.uml.edu "Black holes are where god divided by 0." From owner-ips@ece.cmu.edu Mon Jul 23 18:59:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29310 for ; Mon, 23 Jul 2001 18:59:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NLF4C16787 for ips-outgoing; Mon, 23 Jul 2001 17:15:04 -0400 (EDT) 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 f6NKMLg12580 for ; Mon, 23 Jul 2001 16:22:21 -0400 (EDT) Received: from eddylaptop (h00e0987e14a3.ne.mediaone.net [66.31.75.202]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6NKMKc10754 for ; Mon, 23 Jul 2001 16:22:20 -0400 (EDT) From: "Eddy Quicksall" To: Subject: mail archives Date: Mon, 23 Jul 2001 16:22:38 -0400 Message-ID: <001301c113b5$3a5e6e40$0100a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C11393.B34CCE40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C11393.B34CCE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Does anyone know the syntax for searching the mail archives? I want to search for subjects with a specific text string. I've tried quotes and + signs but it finds all sorts of unrelated mail. Eddy_Quicksall@iVivity.com ------=_NextPart_000_0014_01C11393.B34CCE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does = anyone know the=20 syntax for searching the mail archives? I want to search for subjects = with a=20 specific text string. I've tried quotes and + signs but it finds all = sorts of=20 unrelated mail.
 
Eddy_Quicksall@iVivity.com=
 
------=_NextPart_000_0014_01C11393.B34CCE40-- From owner-ips@ece.cmu.edu Mon Jul 23 19:02:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29427 for ; Mon, 23 Jul 2001 19:02:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NMFkn21203 for ips-outgoing; Mon, 23 Jul 2001 18:15:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe68.law11.hotmail.com [64.4.16.203]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NMFig21199 for ; Mon, 23 Jul 2001 18:15:44 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 23 Jul 2001 15:15:38 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: "Michael Schoberg" , References: <3C7122FAF06DD5118ED60050047336482630B0@esply01.cnt.com> Subject: Re: iSCSI draft-07 Padding Date: Mon, 23 Jul 2001 18:16:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 23 Jul 2001 22:15:38.0261 (UTC) FILETIME=[00993450:01C113C5] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit One problem I can see with pad in data is when receiving directly to the ULP buffers. Since you shouldn't trash the end of a ULP buffer, wouldn't it be better not to have the pad at all? I suppose the original idea was for a hardware reason but then the hardware has to finally deal with this "non-trashing" situation anyway and not store the pad into memory. Eddy ----- Original Message ----- From: "Michael Schoberg" To: Sent: Friday, July 20, 2001 4:27 PM Subject: iSCSI draft-07 Padding > I couldn't find anything in the latest iSCSI spec (draft-07) that prevents > someone from issuing multiple padded PDU's for iSCSI Data In/Out segments. > I guess I'm worried that someone could issue padded odd-length write/read > data when it wasn't necessary. Example: When moving a 512 byte disk sector > an initiator/target could legally issue 512 1-byte DataSegmentLength > messages (each padded up to a 32-bit boundary). This isn't the sort of data > stream one would expect, but it's allowed in the draft. > > This also leads into whether fixed or minimum length data segments (for all > but the last) would be nice to include as part of the spec. It may result > in a simpler software/hardware design. > From owner-ips@ece.cmu.edu Mon Jul 23 21:01:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05518 for ; Mon, 23 Jul 2001 21:01:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6NNJjF25306 for ips-outgoing; Mon, 23 Jul 2001 19:19:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas1t.cos.agilent.com (msgbas1tx.cos.agilent.com [192.6.9.34]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6NNJhg25302 for ; Mon, 23 Jul 2001 19:19:43 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas1t.cos.agilent.com (Postfix) with ESMTP id 0E88B8E0 for ; Mon, 23 Jul 2001 17:19:43 -0600 (MDT) Received: from rtl.rose.agilent.com (rtl.rose.agilent.com [130.30.179.189]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id C292E244 for ; Mon, 23 Jul 2001 17:19:42 -0600 (MDT) Received: from mail.rose.agilent.com (mailsrv@bellhop [130.30.179.19]) by rtl.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) with ESMTP id QAA22418 for ; Mon, 23 Jul 2001 16:19:41 -0700 (PDT) Received: from agilent.com (matt5670.rose.agilent.com [130.30.178.14]) by mail.rose.agilent.com (Netscape Messaging Server 3.6) with ESMTP id AAA5655 for ; Mon, 23 Jul 2001 16:19:39 -0700 Message-ID: <3B5CB140.7EB0BDBC@agilent.com> Date: Mon, 23 Jul 2001 16:20:32 -0700 From: "Matt Wakeley" Reply-To: Matt Wakeley Organization: Agilent Technologies X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iSCSI Plugfest at UNH (misc issues) References: <3B5C431F.3B813A89@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep Joshi wrote: > > Hi Julian, > > Some additional items from the plugfest to resolve.. > > 1) Sec 2.3.1 : Untagged tasks. > If the task attribute in the SCSI Command is "untagged" > then the initiator task tag should be ignored, correct ? > Can the draft explicitly state that the initiator must > set the Initiator Task Tag to 0x'ffffffff if its an > untagged task. What is so bad about an initiator assigned a task tag even if the command is flagged as "untagged"? In the FC world, initiators use the tag to route commands through the hardware. I don't want to restrict h/w implementations from using a task tag even if the command is marked untagged. > > Do we assume that the initiator ULP will not issue more than > one untagged tasks simultaneously ? > > 2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the expCmdSN ? > Clearly, the target has received and executed the commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which response > is being received). The iSCSI standard says that once SCSI commands get put into the task queue, the CmdSN no longer associated with the command. The initiator is NOT supposed to associate commands with responses based on the CmdSN or ExpCmdSN. But more importantly, what is the issue trying to be resolved here? > This seems like a valid property which could be mandated > and checked, to allow efficient initiator implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) Until you identify the problem, I don't want any more "tests" mandated. > 3) Sending status in read PDU > Since quite a few initiators did not support this, > this feature had to be enabled or disabled frequently at > the target. It is already mandatory to implement status in the read PDU. > > Either we should make it mandatory to implement (at initiator) > or we should add a key "SendStatusInReadPDU=yes/no". The first > option seems simpler. > > thanks > -Sandeep -Matt From owner-ips@ece.cmu.edu Mon Jul 23 22:17:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08368 for ; Mon, 23 Jul 2001 22:17:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O1GXH02340 for ips-outgoing; Mon, 23 Jul 2001 21:16:33 -0400 (EDT) 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 f6O1Fgg02259 for ; Mon, 23 Jul 2001 21:15:42 -0400 (EDT) Received: from eddylaptop (h00e0987e14a3.ne.mediaone.net [66.31.75.202]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6O1Fec25789; Mon, 23 Jul 2001 21:15:41 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: SendTargets in login or FFP? Date: Mon, 23 Jul 2001 21:15:56 -0400 Message-ID: <002b01c113de$33cffa20$0100a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The spec says: An initiator can log into this default target [iSCSI] name, and use a command called "SendTargets" to retrieve a list of iSCSI targets that exist at that address I assume this means the SendTargets would be used in Full Feature Phase ... the initiator would login using TargetName=iSCSI. That would get into FFP and then the initiator would use SendTargets= to get the list of targets. Then, login again with the appropriate target. The spec says: In full feature phase the initiator may send SCSI commands and data to the various LUs on the target by wrapping them in iSCSI PDUs that go over the established iSCSI session. That means the target has to do something if a CDB is received to the iSCSI canonical target. The spec doesn't give any suggestions here. I am assuming the target would give a reject PDU with a reason of "Protocol Error" (code 5). Do you agree that this is what should happen? We shouldn't require that the target enter FFP when it would not be valid to send a CDB. I think SendTargets should be done only at LO or IO time and that iSCSI should not get you into FFP. That would simplify coding. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Jul 23 22:19:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08402 for ; Mon, 23 Jul 2001 22:19:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O1GSQ02332 for ips-outgoing; Mon, 23 Jul 2001 21:16:28 -0400 (EDT) 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 f6O1FSg02240 for ; Mon, 23 Jul 2001 21:15:28 -0400 (EDT) Received: from eddylaptop (h00e0987e14a3.ne.mediaone.net [66.31.75.202]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6O1FPc25499; Mon, 23 Jul 2001 21:15:25 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: TargetAddress in the spec twice Date: Mon, 23 Jul 2001 21:15:43 -0400 Message-ID: <002901c113de$2b2fe0b0$0100a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit TargetAddress is in the spec twice and they both don't say the same thing. The question I'm trying to resolve is: If the targets are on the same address as the SendTargets command was sent on, does the TargetAddress need to be returned with the TargetName list? The 1st implies NO and the 2nd says YES. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Jul 23 22:20:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08426 for ; Mon, 23 Jul 2001 22:20:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O0tOZ01091 for ips-outgoing; Mon, 23 Jul 2001 20:55:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from spdmraac.compuserve.com (ds-img-rel-3.compuserve.com [149.174.206.154]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6O0tLg01079 for ; Mon, 23 Jul 2001 20:55:21 -0400 (EDT) Received: (from mailgate@localhost) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id UAA06945 for ips@ece.cmu.edu; Mon, 23 Jul 2001 20:55:10 -0400 (EDT) Received: from compuserve.com (dal-tgn-tka-vty51.as.wcom.net [206.175.230.51]) by spdmraac.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id UAA06921 for ; Mon, 23 Jul 2001 20:54:57 -0400 (EDT) Message-ID: <3B5CC86A.84064A3C@compuserve.com> Date: Mon, 23 Jul 2001 19:59:23 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.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: iSCSI: Concerns raised about ACA and denial of service conditions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The SCSI Commands, Architecture, and Protocols working group reviewed a proposal by Ed Gardner based on input from Julian Satran, the intent of which is to invoke ACA when a BUSY, TASK SET FULL, or RESERVATION CONFLICT status occurs. The CAP working group had several questions regarding the need for this proposal. Ed and I explained as best we could the iSCSI need for this capability to support high latency links. Generally, our explanations were deemed inadequate and several calls were heard along the lines of "if this is so important why isn't anybody here to defend it?" However, that was not the worst of the troubles visited on the proposal. Several people noted problems with using ACA to preserve synchronization following a rejected command, since ACA locks out all initiators, not just the one initiator whose command was rejected. For example, suppose one initiator holds a reservation. A second initiator sends a command and gets back RESERVATION CONFLICT, causing an ACA. The first initiator cannot access the device until the second initiator clears the ACA. If the second initiator simply does nothing (whether maliciously or due to crashing), the first initiator is permanently locked out from accessing the device it has reserved. Ed plans to be in London and will be happy to discuss this there. I will miss London due to the T11 meeting. The T10 CAP working group is seeking clarification from the iSCSI team regarding their desires in this matter. Is a feature that opens opportunities for denial of service attacks really the desired result? If not, it is the opinion of the CAP working group, that ACA is not the desired mechanism and further consideration of the real requirements is needed. All responses to this message will be collected in a T10 document for delivery to the CAP working group. It is advisable that someone who can defend the iSCSI requirements attend the next CAP working group meeting to be held Wednesday, September 12, 2001 from 9 a.m. to 7 p.m., continuing if necessary on Thursday, September 13, 2001 from 8:00 a.m. to 9:45 a.m. (or until all agenda items are completed). The meeting will be at the Hilton Waterfront Hotel (714-960-7873) in Huntington Beach, CA, hosted by QLogic. More information on the meeting can be obtained from the T10 web site www.t10.org. Thanks. Ralph... From owner-ips@ece.cmu.edu Tue Jul 24 00:41:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12314 for ; Tue, 24 Jul 2001 00:41:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O3QiT09983 for ips-outgoing; Mon, 23 Jul 2001 23:26:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6O3QBg09933 for ; Mon, 23 Jul 2001 23:26:35 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id B443DDD0 for ; Mon, 23 Jul 2001 20:26:10 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id UAA13165 for ips@ece.cmu.edu; Mon, 23 Jul 2001 20:27:24 -0700 (PDT) Message-Id: <200107240327.UAA13165@core.rose.hp.com> Subject: Re: iSCSI state transitions To: ips@ece.cmu.edu Date: Mon, 23 Jul 2001 20:27:24 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Thanks for the comments. >pages 5-6 look good >but pages 1-4 have a high information density. >(Uneasy rests the eye which traces the transitions..) Not sure what's implied above.... I was merely trying to keep the pdf file small. >I suspect the primary problem is that the initiator and >target connection state diagrams have got combined into >one diagram. Depends on the viewpoint. Out of 30 transitions, 7 are role-specific, rest are role-agnostic - that is 76.6% are the same. I consider duplicating >75% in two separate diagrams as unnecessary. Besides, 100% of the transitions are the same for both roles in both connection recovery and session state diagrams. While this hasn't been a "problem" for any of the reviewers so far, let us wait for more comments. >State S13 should be called "suspended" or "to_be_recovered" > The tasks are undoubtedly "busy" but the connection is > certainly suspended. I am not that certain. The connection state machine is simply entering into the recovery state diagram, S13 is _not_ a suspended dead end. When in S13, CSM-R is actively counting time to possibly take transition M1 to get to R3. Would RECOVERY_START be a better name than BUSY? > We seem to be tracking the TCP state (S2, S12 for SYN,FIN) > It adds to the complexity and sidetracks one > from the main purpose, which (i thought) was to document > error recovery. Sorry, not true - section 6 goes beyond error recovery(section 7). As stated in the preface, these document the entire life of the iSCSI connection and iSCSI session. At the iSCSI level, we have to clearly specify how iSCSI state machines react to transport connection events, since an implementation must deal with those. Section 1.2.6 clearly lays out how to deal with transport connection termination events for the same reason. >Assume that connection > establishment and destruction is an action on transition .. > On error, the connection will be closed and the state can be > restored to S1 in one step. These state diagrams are hoped to be implementable "as is". In reality, connection establishment is not atomic - an iSCSI driver/ASIC has to send a connect request and wait for the result, S2 represents the state of the iSCSI connection record during that time. Similar comments apply for connection termination. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Mallikarjun, > >Just a few comments on this.. pages 5-6 look good >but pages 1-4 have a high information density. >(Uneasy rests the eye which traces the transitions..) > >I suspect the primary problem is that the initiator and >target connection state diagrams have got combined into >one diagram. As a result, most states as well as transitions >have got special-cased as initiator-only or target-only. > >(For example, T1, T2, T3, T7, T15 are all initiator-only) > >Other points: >a) State S13 should be called "suspended" or "to_be_recovered" > The tasks are undoubtedly "busy" but the connection is > certainly suspended. The state name must reflect the state > of the connection, not the individual tasks. > >b) We seem to be tracking the TCP state (S2, S12 for SYN,FIN) > It adds to the complexity and sidetracks one > from the main purpose, which (i thought) was to document > error recovery. If we remove the TCP state tracking, we > may be be able to eliminate some states (S2, S12, etc) > and keep the focus on iSCSI. Assume that connection > establishment and destruction is an action on transition, > not a whole new state to document. > >c) Transitions T7, T8 can be removed. How individual implementations > behave on login errors (do a retry/bailout) need not be covered. > On error, the connection will be closed and the state can be > restored to S1 in one step. > >All in all, it should be possible to express the connection state >for each end (with error recovery) in about 7-8 states. > >The following patterns would then be easy to spot: >1) There is one way to move from FREE to LOGGED_IN >2) There are four ways to move from LOGGED_IN to FREE > a) by self-initiated logout > -target sends Async > -initiator sends Logout command > b) by "other-end" requested logout > -target receives a Logout command > -initiator receives an Async message > c) a transport failure followed by connection recovery failure > which indicates a need to abort tasks. > d) a transport failure followed by connection recovery success > which indicates a clean shutdown. > >regards, >-Sandeep > > >"Mallikarjun C." wrote: >> >> All: >> >> Excuse my posting of the (relatively small sized, 27KB) >> pdf file with the iSCSI state diagrams. I'll post a URL >> shortly, but I wanted to get this out sooner to give >> reviewers a graphical description of rev07, section 6. >> >> This was reviewed in the ERT forum, and the ASCII versions >> of this slide set were incorporated into rev07. >> >> Mallikarjun >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> Network Storage Solutions Organization >> Hewlett-Packard, Roseville >> cbm@rose.hp.com >> >> ------------------------------------------------------------------------ >> Name: iscsi_states.pdf >> iscsi_states.pdf Type: Portable Document Format (application/pdf) >> Encoding: base64 >> Download Status: Not downloaded with message > From owner-ips@ece.cmu.edu Tue Jul 24 04:38:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03974 for ; Tue, 24 Jul 2001 04:38:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O7JC822877 for ips-outgoing; Tue, 24 Jul 2001 03:19:12 -0400 (EDT) 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 f6O7JBg22873 for ; Tue, 24 Jul 2001 03:19:11 -0400 (EDT) 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 JAA232294 for ; Tue, 24 Jul 2001 09:19:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O7J3b68482 for ; Tue, 24 Jul 2001 09:19:03 +0200 Importance: Normal Subject: Re: iSCSI Plugfest at UNH (misc issues) To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 10:25:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 10:19:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments in text - Julo Sandeep Joshi on 23-07-2001 18:30:39 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: Re: iSCSI Plugfest at UNH (misc issues) Hi Julian, Some additional items from the plugfest to resolve.. 1) Sec 2.3.1 : Untagged tasks. If the task attribute in the SCSI Command is "untagged" then the initiator task tag should be ignored, correct ? Can the draft explicitly state that the initiator must set the Initiator Task Tag to 0x'ffffffff if its an untagged task. Do we assume that the initiator ULP will not issue more than one untagged tasks simultaneously ? +++ In fact iSCSI has no such thing as untagged tasks. It will always use a tag and it is up to SCSI to distinguish between them. This should not be aa practical issue since the task identifiers (tagged or not) have to unique only at the initiator (according to SAM2). The x'ffffffff" is a reserved value - not to be used by SCSI tasks. I will "expand" 2.2.2.8 to read: 1.1.1.1 Initiator Task Tag The initiator assigns a Task Tag to each iSCSI task that it issues. While a task exists, this tag MUST uniquely identify it session-wide. The initiator task tag may be used by SCSI too as part of the SCSI task identifier as the time span during which an iSCSI initiator task tag has to be unique extends over the time span during which a SCSI task tag has to be unique. However, the iSCSI Initiator Task Tag has to exist and be unique even for untagged SCSI commands. +++ 2) ExpCmdSN What are the semantics of something like this.. the target does not increase the expCmdSN but keeps sending the status (SCSI response) for commands after the expCmdSN ? Clearly, the target has received and executed the commands (in cmdSN order). Hence, the expCmdSN in a SCSI response must not be less than the cmdSN of the original command (for which response is being received). This seems like a valid property which could be mandated and checked, to allow efficient initiator implementations. The target eventually suffers but the standard could prevent such targets from being deployed :-) +++ Interesting proposal. Has some academic weaknesses however. We assume that CmdSN has no significance after delivery. Assume that you have a good target and a very long lived command - outlives a wrap around of CmdSN! How would you distinguish the status of this command carying a low ExpCmdSN from your case? I will change the following in 1.2.2.1 - CmdSN - the current command Sequence Number advanced by 1 on each command shipped except for commands marked for immediate delivery. - ExpCmdSN - the next expected command by the target. The target acknowledges all commands up to but not including this number and the initiator has to mark the acknowledged commands as such as soon as a PDU with the corresponding ExpCmdSN is received. The target iSCSI layer sets the ExpCmdSN to the largest non-immediate CmdSN that it is able to deliver for execution plus 1 (no holes in the CmdSN sequence). - MaxCmdSN - the maximum number to be shipped. The queuing capacity of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. And later - at the end of 1.2.2.1 A target MUST NOT issue a command response or DATA-In PDU with status before acknowledging the command. As with many other initiator deteced errors - the initiator has to decide what to do with such an error (logout, rest etc.) ++++ 3) Sending status in read PDU Since quite a few initiators did not support this, this feature had to be enabled or disabled frequently at the target. Either we should make it mandatory to implement (at initiator) or we should add a key "SendStatusInReadPDU=yes/no". The first option seems simpler. +++ Anything that is not optional is mandatory to implement to make it unequivocal I will add to 2.7: Status can accompany the last Data-in PDU if the command did not end with an exception. Presence of status (and of a residual count) is signaled though the S flag bit. Although targets may choose to send even non-exception status in separate responses initiators MUST support non-exception status in Data-In PDUs. +++ thanks -Sandeep From owner-ips@ece.cmu.edu Tue Jul 24 04:41:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04059 for ; Tue, 24 Jul 2001 04:41:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O7hd524198 for ips-outgoing; Tue, 24 Jul 2001 03:43:39 -0400 (EDT) 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 f6O7hcg24193 for ; Tue, 24 Jul 2001 03:43:38 -0400 (EDT) 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 JAA191014 for ; Tue, 24 Jul 2001 09:43:28 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O7hR210192 for ; Tue, 24 Jul 2001 09:43:27 +0200 Importance: Normal Subject: Re: iSCSI: specific initiator To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 10:49:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 10:43:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I will expand the relevant paragraph from 4.1 to read: If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used in determining the security mode or it is implicit part of authentication, then the iSCSI Target Name and/or iSCSI Initiator Name MUST be sent in the login command for the first connection of a session to identify the storage endpoint of the session. If sent on new connections within an existing session it MUST be the same as the one used for the leading connection. If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used only for access control, it can be sent after the Security Context Complete is achieved. An unknown target can be accessed by using "iSCSI" as a placeholder for the iSCSI Target Name or none if the session is a discovery session. Thanks, Julo "Eddy Quicksall" on 23-07-2001 21:38:49 Please respond to "Eddy Quicksall" To: ips@ece.cmu.edu cc: Subject: iSCSI: specific initiator Section 4.2 says: -The target MUST reply with the first option in the list it supports and is allowed for the specific initiator. Can we also specify that the InitiatorName must be used before anything that requires "specific initiator" knowledge. That can simplify programming and is probably not a big restriction. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 04:42:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04100 for ; Tue, 24 Jul 2001 04:42:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O7otB24623 for ips-outgoing; Tue, 24 Jul 2001 03:50:55 -0400 (EDT) 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 f6O7org24619 for ; Tue, 24 Jul 2001 03:50:53 -0400 (EDT) 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 JAA366350 for ; Tue, 24 Jul 2001 09:50:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O7okb48084 for ; Tue, 24 Jul 2001 09:50:46 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 10:56:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 10:50:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, This might make implementations independent of the value semantics (depend only on the option being offered) although none is special. But I am open to other opinions. In the meantime I'll make the text read: The SecurityContextComplete handshake MUST be performed if any of negotiating parties has offered a security/integrity item and regardless of the value or list offered (even if it is not selected). thanks, Julo "Eddy Quicksall" on 23-07-2001 21:44:04 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions One other question that came up at UNH was the following: If an initiator says "AuthMethod=none<0> DataDigest=none<0> HeaderDigest=none" in the initial login, does that mean the parties have to use the SecurityContextComplete handshake? Does the scope of "even if it is not selected" below include the above? Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Monday, July 23, 2001 1:50 AM Subject: Re: iSCSI Login Questions > > Qin, > > The question Steve raised was if the example is correct and the example is > correct. > > In the example the initiator clearly indicates that it is not offering > any Authentication method ( "none") and it might as well conclude the > security phase. > It does not need any additional exchange. > > The target can reject the login. > > The fact that it is no such case included in examples does not make it > incorrect. > > As for the SecurityContextComplete Steve has chose a strictly literal > interpretation of the relevant paragraph from 4.2: > > The SecurityContextComplete handshake MUST be performed if any of > negotiating parties has offered a security/integrity item (even if it > is not selected). > > Julo > > > > > Qin Tao on 23-07-2001 05:34:33 > > Please respond to Qin Tao > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI Login Questions > > > > > Hi, Julian: > > I don't think "SecurityContextComplete=yes" should be used in the Login > Command together with security parameters(as in Cases 1&3). > > Draft 07,Clause 4.1 says: > > "-Every party in the security negotiation indicates that it has > completed building its security context (has all the required > ^^^^^^^^^^^^^^^^^ > information) by sending the key=value pair: > ^^^^^^^^^^^ > SecurityContextComplete=yes" > > When Login Command is sending out, the initiator has no idea how the > target would response, how could it "has all the required information"? > In Case 1, the initiator limits the response from target by providing only > one option for each parameter, so that it has a good guess of the > response. However, "a text response including only > SecurityContextComplete=yes concludes the security sub-phase" (page 101 in > draft 7). The initiator still needs to send SecurityContextComplete=yes > in the next Text Command and wait for a Text Response with > SecurityContextComplete=yes only to end the security sub-phase. It is > meaningless to include the SecurityContextComplete=yes so early in the > Login Command. > > If both Cases 2 and 3 are correct, sending "SecurityContextComplete=yes" > becomes optional and loses its value to be used. I also checked the "Login > Phase Examples" in Appendix A and I did not find any example with > "SecurityContextComplete=yes" in Login Command. Could you please give more > explanations on this issue? > > Thanks. > Qin > > > > > On Sat, 21 Jul 2001, Julian Satran wrote: > > > > > Steve, > > > > All are correct. > > > > Julo > > > > Steve Senum on 20-07-2001 21:13:47 > > > > Please respond to Steve Senum > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI Login Questions > > > > > > > > > > Julian, > > > > Thanks for the reply. > > > > I have a few of more cases I would like to be sure of. > > Please comment on whether you think the given sequence > > is valid. > > > > > > Case 1: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > > > > > Case 2: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C,none > > DataDigest=crc-32C,none > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > > > Case 3: > > > > I-> Login AuthMethod=none > > HeaderDigest=crc-32C,none > > DataDigest=crc-32C,none > > SecurityContextComplete=yes > > T-> Login-PR AuthMethod=none > > HeaderDigest=crc-32C > > DataDigest=crc-32C > > SecurityContextComplete=yes > > > > > > Thanks, > > Steve Senum > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jul 24 06:11:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05426 for ; Tue, 24 Jul 2001 06:11:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O8t5q27982 for ips-outgoing; Tue, 24 Jul 2001 04:55:05 -0400 (EDT) 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 f6O8t3g27977 for ; Tue, 24 Jul 2001 04:55:03 -0400 (EDT) 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 KAA364090 for ; Tue, 24 Jul 2001 10:54:56 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O8su223434 for ; Tue, 24 Jul 2001 10:54:56 +0200 Importance: Normal Subject: Re: iSCSI: Concerns raised about ACA and denial of service conditions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 12:01:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 11:54:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, This is a request for clarification. Isn't the behavior you describe being controlled by the TST (and QErr) field from the Control Mode Page (SPC2) and the value of 001 insures that an ACA condition caused by one initiator does not cause tasks from another initiator be rejected? Regards, Julo Ralph Weber on 24-07-2001 03:59:23 Please respond to ENDL_TX@computer.org To: IPS Reflector cc: Subject: iSCSI: Concerns raised about ACA and denial of service conditions The SCSI Commands, Architecture, and Protocols working group reviewed a proposal by Ed Gardner based on input from Julian Satran, the intent of which is to invoke ACA when a BUSY, TASK SET FULL, or RESERVATION CONFLICT status occurs. The CAP working group had several questions regarding the need for this proposal. Ed and I explained as best we could the iSCSI need for this capability to support high latency links. Generally, our explanations were deemed inadequate and several calls were heard along the lines of "if this is so important why isn't anybody here to defend it?" However, that was not the worst of the troubles visited on the proposal. Several people noted problems with using ACA to preserve synchronization following a rejected command, since ACA locks out all initiators, not just the one initiator whose command was rejected. For example, suppose one initiator holds a reservation. A second initiator sends a command and gets back RESERVATION CONFLICT, causing an ACA. The first initiator cannot access the device until the second initiator clears the ACA. If the second initiator simply does nothing (whether maliciously or due to crashing), the first initiator is permanently locked out from accessing the device it has reserved. Ed plans to be in London and will be happy to discuss this there. I will miss London due to the T11 meeting. The T10 CAP working group is seeking clarification from the iSCSI team regarding their desires in this matter. Is a feature that opens opportunities for denial of service attacks really the desired result? If not, it is the opinion of the CAP working group, that ACA is not the desired mechanism and further consideration of the real requirements is needed. All responses to this message will be collected in a T10 document for delivery to the CAP working group. It is advisable that someone who can defend the iSCSI requirements attend the next CAP working group meeting to be held Wednesday, September 12, 2001 from 9 a.m. to 7 p.m., continuing if necessary on Thursday, September 13, 2001 from 8:00 a.m. to 9:45 a.m. (or until all agenda items are completed). The meeting will be at the Hilton Waterfront Hotel (714-960-7873) in Huntington Beach, CA, hosted by QLogic. More information on the meeting can be obtained from the T10 web site www.t10.org. Thanks. Ralph... From owner-ips@ece.cmu.edu Tue Jul 24 06:12:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05476 for ; Tue, 24 Jul 2001 06:12:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O9TZ129788 for ips-outgoing; Tue, 24 Jul 2001 05:29:35 -0400 (EDT) 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 f6O9TSg29782 for ; Tue, 24 Jul 2001 05:29:28 -0400 (EDT) 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 LAA315590 for ; Tue, 24 Jul 2001 11:29:19 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O9TIb35438 for ; Tue, 24 Jul 2001 11:29:18 +0200 Importance: Normal Subject: Re: iSCSI: TargetAddress in the spec twice To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 12:35:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 12:29:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OOps - 17 should have been deleted - Thanks, Julo "Eddy Quicksall" on 24-07-2001 04:15:43 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI: TargetAddress in the spec twice TargetAddress is in the spec twice and they both don't say the same thing. The question I'm trying to resolve is: If the targets are on the same address as the SendTargets command was sent on, does the TargetAddress need to be returned with the TargetName list? The 1st implies NO and the 2nd says YES. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 06:17:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05586 for ; Tue, 24 Jul 2001 06:17:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6O981k28678 for ips-outgoing; Tue, 24 Jul 2001 05:08:01 -0400 (EDT) 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 f6O97xg28674 for ; Tue, 24 Jul 2001 05:07:59 -0400 (EDT) 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 LAA115968 for ; Tue, 24 Jul 2001 11:07:52 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6O97qb39956 for ; Tue, 24 Jul 2001 11:07:52 +0200 Importance: Normal Subject: Re: iSCSI: SendTargets in login or FFP? To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 12:13:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 12:07:51 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, SendTargets can be used in both discovery session and normal session. Would you please clarify when you think this restriction should apply? Julo "Eddy Quicksall" on 24-07-2001 04:15:56 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI: SendTargets in login or FFP? The spec says: An initiator can log into this default target [iSCSI] name, and use a command called "SendTargets" to retrieve a list of iSCSI targets that exist at that address I assume this means the SendTargets would be used in Full Feature Phase ... the initiator would login using TargetName=iSCSI. That would get into FFP and then the initiator would use SendTargets= to get the list of targets. Then, login again with the appropriate target. The spec says: In full feature phase the initiator may send SCSI commands and data to the various LUs on the target by wrapping them in iSCSI PDUs that go over the established iSCSI session. That means the target has to do something if a CDB is received to the iSCSI canonical target. The spec doesn't give any suggestions here. I am assuming the target would give a reject PDU with a reason of "Protocol Error" (code 5). Do you agree that this is what should happen? We shouldn't require that the target enter FFP when it would not be valid to send a CDB. I think SendTargets should be done only at LO or IO time and that iSCSI should not get you into FFP. That would simplify coding. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 09:21:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16177 for ; Tue, 24 Jul 2001 09:21:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OBwFI19797 for ips-outgoing; Tue, 24 Jul 2001 07:58:15 -0400 (EDT) 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 f6OAUBg15079 for ; Tue, 24 Jul 2001 06:30:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05842; Tue, 24 Jul 2001 06:29:13 -0400 (EDT) Message-Id: <200107241029.GAA05842@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-iscsi-07.txt Date: Tue, 24 Jul 2001 06:29:13 -0400 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 : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-07.txt Pages : 187 Date : 23-Jul-01 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This memo describes a transport protocol for SCSI that operates on top of TCP. The iSCSI protocol aims to be fully compliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-07.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-iscsi-07.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: <20010723140355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140355.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jul 24 10:12:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19127 for ; Tue, 24 Jul 2001 10:11:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OCu0n23360 for ips-outgoing; Tue, 24 Jul 2001 08:56:00 -0400 (EDT) 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 f6OCtEg23282 for ; Tue, 24 Jul 2001 08:55:14 -0400 (EDT) Received: from eddylaptop (h00e0987e14a3.ne.mediaone.net [66.31.75.202]) by chmls20.mediaone.net (8.11.1/8.11.1) with SMTP id f6OCsnc17315; Tue, 24 Jul 2001 08:54:50 -0400 (EDT) From: "Eddy Quicksall" To: Cc: Subject: iSCSI: SecurityContextComplete without operational parameters Date: Tue, 24 Jul 2001 08:55:05 -0400 Message-ID: <002f01c1143f$dfe66cc0$0100a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In section "4.2 iSCSI Security and Integrity Negotiation", it would be best if the target is required to send SecurityContextComplete=yes without any new operational parameters within the same PDU. It makes coding cleaner because the initiator can have a simple send/receive loop that pops out when security is complete. If operational parameters are allowed with SecurityContextComplete=yes, the initiator's security module must also have operational parameter code or it must set flags, leave information in buffers, etc that all create messy code. The spec says: If the initiator has been the last to complete the handshake it MUST NOT start sending operational parameters within the same text command. How about if we say the same thing for the target? There shouldn't be any harm because I suspect everyone is doing that anyway. Comments? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 10:13:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19253 for ; Tue, 24 Jul 2001 10:13:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ODgO526561 for ips-outgoing; Tue, 24 Jul 2001 09:42:24 -0400 (EDT) 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 f6ODgLg26530 for ; Tue, 24 Jul 2001 09:42:21 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id JAA16183 for ips@ece.cmu.edu; Tue, 24 Jul 2001 09:42:16 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkm-vty13.as.wcom.net [216.192.225.13]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id JAA16092 for ; Tue, 24 Jul 2001 09:42:09 -0400 (EDT) Message-ID: <3B5D7C33.BE04B314@compuserve.com> Date: Tue, 24 Jul 2001 08:46:27 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI: Concerns raised about ACA and denial of service conditions 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, > Isn't the behavior you describe being controlled by the > TST (and QErr) field from the Control Mode Page (SPC2) > and the value of 001 insures that an ACA condition caused > by one initiator does not cause tasks from another > initiator be rejected? The behavior I described assumes TST=000, which I consider to be the default case. QErr affects whether pending tasks are terminated when an error occurs, so I do not think QErr applies here. Note that TST=001 affects more than just the error behavior. If TST=001, then ORDERED tasks from one initiator are not coordinated with ORDERED tasks from other initiators. ABORT TASK SET only the tasks from one initiator making it the same as CLEAR TASK SET. These behaviors could be viewed as undesirable. Thanks. Ralph... From owner-ips@ece.cmu.edu Tue Jul 24 10:16:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19413 for ; Tue, 24 Jul 2001 10:16:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OD4kC23859 for ips-outgoing; Tue, 24 Jul 2001 09:04:46 -0400 (EDT) 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 f6OD4jg23855 for ; Tue, 24 Jul 2001 09:04:45 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA18731; Tue, 24 Jul 2001 09:04:32 -0400 (EDT) Message-ID: <3B5D710F.B8B4CCD0@cisco.com> Date: Tue, 24 Jul 2001 07:58:55 -0500 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: Eddy Quicksall CC: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: TargetAddress in the spec twice References: <002901c113de$2b2fe0b0$0100a8c0@eddylaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy- The second TargetAddress (17) should be deleted. 12 is correct; the TargetAddress does not include the target name. If a target receives a SendTargets command, and returns targets that are accessible ONLY at the same IP address and TCP port on which the SendTargets was received, the TargetAddress key may be omitted from the response. Appendix F says the above, but perhaps I should have used the wording above. Does this help? -- Mark Eddy Quicksall wrote: > > TargetAddress is in the spec twice and they both don't say the same thing. > > The question I'm trying to resolve is: If the targets are on the same > address as the SendTargets command was sent on, does the TargetAddress need > to be returned with the TargetName list? > > The 1st implies NO and the 2nd says YES. > > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 10:17:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19500 for ; Tue, 24 Jul 2001 10:17:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ODaBk26070 for ips-outgoing; Tue, 24 Jul 2001 09:36:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe38.law11.hotmail.com [64.4.16.95]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6ODaAg26066 for ; Tue, 24 Jul 2001 09:36:10 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Jul 2001 06:36:04 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: iSCSI: SendTargets in login or FFP? Date: Tue, 24 Jul 2001 09:36:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 24 Jul 2001 13:36:04.0226 (UTC) FILETIME=[95D6B620:01C11445] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I missed the new "iSCSI session types" in the new spec. Nauty me ... :>) I'll study that. Thanks, Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, July 24, 2001 5:13 AM Subject: Re: iSCSI: SendTargets in login or FFP? > Eddy, > > SendTargets can be used in both discovery session and normal session. > Would you please clarify when you think this restriction should apply? > > Julo > > "Eddy Quicksall" on 24-07-2001 04:15:56 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: iSCSI: SendTargets in login or FFP? > > > > > The spec says: > > An initiator can log into this default target [iSCSI] > name, and use a command called "SendTargets" to retrieve a list of > iSCSI targets that exist at that address > > I assume this means the SendTargets would be used in Full Feature Phase ... > the initiator would login using TargetName=iSCSI. That would get into FFP > and then the initiator would use SendTargets= to get the list of targets. > Then, login again with the appropriate target. > > The spec says: > > In full feature phase the initiator may send SCSI > commands and data to the various LUs on the target by wrapping them > in iSCSI PDUs that go over the established iSCSI session. > > That means the target has to do something if a CDB is received to the iSCSI > canonical target. The spec doesn't give any suggestions here. I am assuming > the target would give a reject PDU with a reason of "Protocol Error" (code > 5). > > Do you agree that this is what should happen? > > We shouldn't require that the target enter FFP when it would not be valid > to > send a CDB. I think SendTargets should be done only at LO or IO time and > that iSCSI should not get you into FFP. That would simplify coding. > > > Eddy_Quicksall@iVivity.com > > > > > From owner-ips@ece.cmu.edu Tue Jul 24 10:17:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19518 for ; Tue, 24 Jul 2001 10:17:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ODnYC27046 for ips-outgoing; Tue, 24 Jul 2001 09:49:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6ODYFg25911 for ; Tue, 24 Jul 2001 09:34:15 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id GAA28799 for ; Tue, 24 Jul 2001 06:34:09 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 06:34:08 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu Subject: RE: iSCSI draft-07 Padding Date: Tue, 24 Jul 2001 06:34:07 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Fibre Channel's approach to this problem is to prohibit padding for all transfers except the transfer that moves the last bytes in the last (or highest pointer value) burst of data. Intermediate bursts are required to end on 4-byte boundaries, regardless of tranfer order as allowed by EMDP. Bob ----- Original Message ----- From: "Michael Schoberg" To: Sent: Friday, July 20, 2001 4:27 PM Subject: iSCSI draft-07 Padding > I couldn't find anything in the latest iSCSI spec (draft-07) that prevents > someone from issuing multiple padded PDU's for iSCSI Data In/Out segments. > I guess I'm worried that someone could issue padded odd-length write/read > data when it wasn't necessary. Example: When moving a 512 byte disk sector > an initiator/target could legally issue 512 1-byte DataSegmentLength > messages (each padded up to a 32-bit boundary). This isn't the sort of data > stream one would expect, but it's allowed in the draft. > > This also leads into whether fixed or minimum length data segments (for all > but the last) would be nice to include as part of the spec. It may result > in a simpler software/hardware design. > From owner-ips@ece.cmu.edu Tue Jul 24 10:18:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19602 for ; Tue, 24 Jul 2001 10:18:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ODHR624778 for ips-outgoing; Tue, 24 Jul 2001 09:17:27 -0400 (EDT) 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 f6ODHQg24773 for ; Tue, 24 Jul 2001 09:17:26 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA02388; Tue, 24 Jul 2001 09:17:17 -0400 (EDT) Message-ID: <3B5D740B.EB1B928B@cisco.com> Date: Tue, 24 Jul 2001 08:11:39 -0500 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: Eddy Quicksall CC: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: SendTargets in login or FFP? References: <002b01c113de$33cffa20$0100a8c0@eddylaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy- Thanks for bringing this one up. One of the changes we have made to the way SendTargets works is that rather than logging into the default target "iSCSI", the initiator simply supplies the key SessionType=Discovery in the initial Login Command PDU and no longer specifies the TargetName at all. Unfortunately, we didn't catch all of the places where default/canonical targets were discussed. Please consider the default target "iSCSI" as simply "reserved for a future use". Anyway, SendTargets is always done in full feature phase, and never during the login phase. Eddy Quicksall wrote: > > The spec says: > > An initiator can log into this default target [iSCSI] > name, and use a command called "SendTargets" to retrieve a list of > iSCSI targets that exist at that address > > I assume this means the SendTargets would be used in Full Feature Phase ... Correct. > the initiator would login using TargetName=iSCSI. That would get into FFP The login now uses SessionType=Discovery instead. > and then the initiator would use SendTargets= to get the list of targets. Yes. > Then, login again with the appropriate target. Yes, but on a new connection. > > The spec says: > > In full feature phase the initiator may send SCSI > commands and data to the various LUs on the target by wrapping them > in iSCSI PDUs that go over the established iSCSI session. > > That means the target has to do something if a CDB is received to the iSCSI > canonical target. The spec doesn't give any suggestions here. I am assuming > the target would give a reject PDU with a reason of "Protocol Error" (code > 5). That makes sense to me. Since a discovery session does not terminate at an actual target, anything addressed to a target must fail. 5 seems like the best fit. > Do you agree that this is what should happen? > > We shouldn't require that the target enter FFP when it would not be valid to > send a CDB. I think SendTargets should be done only at LO or IO time and > that iSCSI should not get you into FFP. That would simplify coding. No. The point of doing SendTarget in full feature phase is that the initiators must first go through their normal authentication; SendTargets responses will often be based on the initiator's identity. Having SendTargets as a one-shot at the end of login, without going into full feature phase was another option, but this would effectively kill the discovery session after the first SendTargets. Some implementations may keep this session around for further SendTargets requests. > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 10:19:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19752 for ; Tue, 24 Jul 2001 10:19:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6ODjII26728 for ips-outgoing; Tue, 24 Jul 2001 09:45:18 -0400 (EDT) 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 f6ODjFg26711 for ; Tue, 24 Jul 2001 09:45:16 -0400 (EDT) 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 PAA309656 for ; Tue, 24 Jul 2001 15:45:08 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6ODj8270074 for ; Tue, 24 Jul 2001 15:45:08 +0200 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 16:51:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 16:45:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk OK Julo "Eddy Quicksall" on 24-07-2001 15:55:05 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: SecurityContextComplete without operational parameters In section "4.2 iSCSI Security and Integrity Negotiation", it would be best if the target is required to send SecurityContextComplete=yes without any new operational parameters within the same PDU. It makes coding cleaner because the initiator can have a simple send/receive loop that pops out when security is complete. If operational parameters are allowed with SecurityContextComplete=yes, the initiator's security module must also have operational parameter code or it must set flags, leave information in buffers, etc that all create messy code. The spec says: If the initiator has been the last to complete the handshake it MUST NOT start sending operational parameters within the same text command. How about if we say the same thing for the target? There shouldn't be any harm because I suspect everyone is doing that anyway. Comments? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 10:33:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20830 for ; Tue, 24 Jul 2001 10:33:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OBwBl19788 for ips-outgoing; Tue, 24 Jul 2001 07:58:11 -0400 (EDT) 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 f6OAU5g15058 for ; Tue, 24 Jul 2001 06:30:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05829; Tue, 24 Jul 2001 06:29:06 -0400 (EDT) Message-Id: <200107241029.GAA05829@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-iscsi-mib-02.txt Date: Tue, 24 Jul 2001 06:29:06 -0400 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 : Definitions of Managed Objects for iSCSI Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-mib-02.txt Pages : 54 Date : 23-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-mib-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-mib-02.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-iscsi-mib-02.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: <20010723140346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140346.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Jul 24 10:38:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21160 for ; Tue, 24 Jul 2001 10:38:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OE2XN28055 for ips-outgoing; Tue, 24 Jul 2001 10:02:33 -0400 (EDT) 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 f6OE2Vg28043 for ; Tue, 24 Jul 2001 10:02:31 -0400 (EDT) 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 QAA215838 for ; Tue, 24 Jul 2001 16:02:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6OE2Lb31200 for ; Tue, 24 Jul 2001 16:02:21 +0200 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 17:08:27 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 17:02:20 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk the new text will read: If the initiator has been the last to complete the handshake it MUST NOT start sending operational parameters that need to be protected within the same text command; a text response including only SecurityContextComplete=yes concludes the security sub-phase. Only the following PDU exchange is protected by digests (if any). If the target has been the last to complete the handshake, the initiator can start the operational parameter negotiation with the next text command; the security negotiation sub-phase ends with the target text response. However, the target handshake concluding response MUST NOT include operational parameters that need to be protected. Only the following PDU exchange is protected by digests (if any). Julo "Eddy Quicksall" on 24-07-2001 15:55:05 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: SecurityContextComplete without operational parameters In section "4.2 iSCSI Security and Integrity Negotiation", it would be best if the target is required to send SecurityContextComplete=yes without any new operational parameters within the same PDU. It makes coding cleaner because the initiator can have a simple send/receive loop that pops out when security is complete. If operational parameters are allowed with SecurityContextComplete=yes, the initiator's security module must also have operational parameter code or it must set flags, leave information in buffers, etc that all create messy code. The spec says: If the initiator has been the last to complete the handshake it MUST NOT start sending operational parameters within the same text command. How about if we say the same thing for the target? There shouldn't be any harm because I suspect everyone is doing that anyway. Comments? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Jul 24 11:51:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26454 for ; Tue, 24 Jul 2001 11:51:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OEVe700342 for ips-outgoing; Tue, 24 Jul 2001 10:31:40 -0400 (EDT) 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 f6OEVcg00338 for ; Tue, 24 Jul 2001 10:31:38 -0400 (EDT) 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 QAA182490 for ; Tue, 24 Jul 2001 16:31:31 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6OEVVb58216 for ; Tue, 24 Jul 2001 16:31:31 +0200 Importance: Normal Subject: Re: iSCSI: Concerns raised about ACA and denial of service conditions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 17:37:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 17:31:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, I need some more clarifications. If ordered tasks between initiators have to be coordinated then what you view as a DOS attack is perhaps desirable behavior (everything goes down the drain because we want coordination); the only open issue is why can't any initiator - in this case - clear the ACA? If they don't have to be coordinated then we don't have a problem - right? Can I call you somewhere? Today after 12 AM CDT or tomorrow after 10 AM CDT ? Thanks, Julo Ralph Weber on 24-07-2001 16:46:27 Please respond to ENDL_TX@computer.org To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Concerns raised about ACA and denial of service conditions Julian, > Isn't the behavior you describe being controlled by the > TST (and QErr) field from the Control Mode Page (SPC2) > and the value of 001 insures that an ACA condition caused > by one initiator does not cause tasks from another > initiator be rejected? The behavior I described assumes TST=000, which I consider to be the default case. QErr affects whether pending tasks are terminated when an error occurs, so I do not think QErr applies here. Note that TST=001 affects more than just the error behavior. If TST=001, then ORDERED tasks from one initiator are not coordinated with ORDERED tasks from other initiators. ABORT TASK SET only the tasks from one initiator making it the same as CLEAR TASK SET. These behaviors could be viewed as undesirable. Thanks. Ralph... From owner-ips@ece.cmu.edu Tue Jul 24 12:44:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00674 for ; Tue, 24 Jul 2001 12:44:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OFGAi03869 for ips-outgoing; Tue, 24 Jul 2001 11:16:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OFG9g03865 for ; Tue, 24 Jul 2001 11:16:09 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 10:16:03 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482630B6@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" Subject: RE: iSCSI draft-07 Padding Date: Tue, 24 Jul 2001 10:13:14 -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, at the very least the spec should not allow padding on intermediate ReadData/WriteData bursts. I can't think of a reason why one would want to use odd length intermediate bursts, so hopefully it's safe to restrict it. Padding the last burst still seems reasonable for easy CRC calculation. Setting a fixed size is optional. A minimum would avoid memory fragmentation when working with memory descriptors. : -----Original Message----- : From: Robert Snively [mailto:rsnively@Brocade.COM] : Sent: Tuesday, July 24, 2001 8:34 AM : To: ips@ece.cmu.edu : Subject: RE: iSCSI draft-07 Padding : : : Fibre Channel's approach to this problem is to prohibit padding : for all transfers except the transfer that moves the last bytes : in the last (or highest pointer value) burst of data. Intermediate : bursts are required to end on 4-byte boundaries, regardless of : tranfer order as allowed by EMDP. : : Bob : : ----- Original Message ----- : From: "Michael Schoberg" : To: : Sent: Friday, July 20, 2001 4:27 PM : Subject: iSCSI draft-07 Padding : : : > I couldn't find anything in the latest iSCSI spec : (draft-07) that prevents : > someone from issuing multiple padded PDU's for iSCSI Data : In/Out segments. : > I guess I'm worried that someone could issue padded : odd-length write/read : > data when it wasn't necessary. Example: When moving a 512 byte disk : sector : > an initiator/target could legally issue 512 1-byte DataSegmentLength : > messages (each padded up to a 32-bit boundary). This isn't : the sort of : data : > stream one would expect, but it's allowed in the draft. : > : > This also leads into whether fixed or minimum length data : segments (for : all : > but the last) would be nice to include as part of the spec. : It may result : > in a simpler software/hardware design. : > : From owner-ips@ece.cmu.edu Tue Jul 24 13:30:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04510 for ; Tue, 24 Jul 2001 13:30:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OFsDA06951 for ips-outgoing; Tue, 24 Jul 2001 11:54:13 -0400 (EDT) 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 f6OFsBg06946 for ; Tue, 24 Jul 2001 11:54:11 -0400 (EDT) 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 RAA27576 for ; Tue, 24 Jul 2001 17:54:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6OFs4b24956 for ; Tue, 24 Jul 2001 17:54:04 +0200 Importance: Normal Subject: RE: iSCSI draft-07 Padding To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 19:00:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 18:54:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I'll add to 2.7.6: The Data Segments of Data-in and Data-out PDUs SHOULD be filled to integer number of 4 byte words (real payload) unless the F bit is set to 1. Julo Michael Schoberg on 24-07-2001 18:13:14 Please respond to Michael Schoberg To: "'ips@ece.cmu.edu'" cc: Subject: RE: iSCSI draft-07 Padding Yes, at the very least the spec should not allow padding on intermediate ReadData/WriteData bursts. I can't think of a reason why one would want to use odd length intermediate bursts, so hopefully it's safe to restrict it. Padding the last burst still seems reasonable for easy CRC calculation. Setting a fixed size is optional. A minimum would avoid memory fragmentation when working with memory descriptors. : -----Original Message----- : From: Robert Snively [mailto:rsnively@Brocade.COM] : Sent: Tuesday, July 24, 2001 8:34 AM : To: ips@ece.cmu.edu : Subject: RE: iSCSI draft-07 Padding : : : Fibre Channel's approach to this problem is to prohibit padding : for all transfers except the transfer that moves the last bytes : in the last (or highest pointer value) burst of data. Intermediate : bursts are required to end on 4-byte boundaries, regardless of : tranfer order as allowed by EMDP. : : Bob : : ----- Original Message ----- : From: "Michael Schoberg" : To: : Sent: Friday, July 20, 2001 4:27 PM : Subject: iSCSI draft-07 Padding : : : > I couldn't find anything in the latest iSCSI spec : (draft-07) that prevents : > someone from issuing multiple padded PDU's for iSCSI Data : In/Out segments. : > I guess I'm worried that someone could issue padded : odd-length write/read : > data when it wasn't necessary. Example: When moving a 512 byte disk : sector : > an initiator/target could legally issue 512 1-byte DataSegmentLength : > messages (each padded up to a 32-bit boundary). This isn't : the sort of : data : > stream one would expect, but it's allowed in the draft. : > : > This also leads into whether fixed or minimum length data : segments (for : all : > but the last) would be nice to include as part of the spec. : It may result : > in a simpler software/hardware design. : > : From owner-ips@ece.cmu.edu Tue Jul 24 13:57:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06793 for ; Tue, 24 Jul 2001 13:57:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OGjVq10851 for ips-outgoing; Tue, 24 Jul 2001 12:45:31 -0400 (EDT) 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 f6OGjUg10843 for ; Tue, 24 Jul 2001 12:45:30 -0400 (EDT) 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 MAA12788 for ; Tue, 24 Jul 2001 12:37:24 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OGjRI87040 for ; Tue, 24 Jul 2001 10:45:27 -0600 Importance: Normal Subject: iSCSI: Draft-07, URL and names/addresses To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 09:45:25 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 09:45:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, The current draft (07) specifies different ways that iSCSI names and addresses are to be used: a) Within the protocol useage itself is the InitiatorName (or TargeName) keys used in Login and in the context of SendTargets along with TargetAddress. b) Section 1.2.7 describes formatting of these names and addresses as URLs. These URLs are never used within the context of the protocol. Such a format *might* be used in a GUI or some other application but specifying how is beyond the scope of this standard. Consequently, to avoid confusion with name/address formats, I suggest that the text that begins in 1.2.7 paragraph 6 with "The iSCSI Name is incorporated as part of the address. An iSCSI address is specified as a URL, such as:... and up to but not including the paragraph that starts: "To assist..." be deleted. It might be replaced with a reference to the SendTargets Appendix where names and addresses are formatted within the protocol. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 14:07:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07628 for ; Tue, 24 Jul 2001 14:07:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OGgms10634 for ips-outgoing; Tue, 24 Jul 2001 12:42:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OGgkg10628 for ; Tue, 24 Jul 2001 12:42:47 -0400 (EDT) Received: from london ([192.168.1.21]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id JAA07256; Tue, 24 Jul 2001 09:42:21 -0700 (PDT) From: "Rod Harrison" To: "Mike Brown" Cc: , Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) Date: Tue, 24 Jul 2001 11:43:34 -0500 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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit A couple of points. The initiator task tag is not a SCSI object, it is an iSCSI object. The iSCSI spec makes no correlation between the ITT and SCSI task tags. The ITT is the only routing object available to the initiator and should be opaque to the target, as should the target task tag to the initiator. I am of the opinion that the Attribute field of the iSCSI Command PDU tells the target which type of tag it should generate for the SCSI operation. Since command sequence numbers are session wide and there are likely to be multiple LUNs in the session, forcing the initiator to use a constant ITT for untagged commands will be problematic. What exactly is the difficulty at the target side with preserving the ITT irregardless of the attribute setting? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Mike Brown Sent: Monday, July 23, 2001 1:22 PM To: rod.harrison@windriver.com Cc: ips@ece.cmu.edu; sandeepj@research.bell-labs.com Subject: RE: iSCSI Plugfest at UNH (misc issues) (fwd) Rod, > > The initiator needs the initiator task tag in order to >associate inbound PDUs with the correct command. For >untagged commands the ATTR field of the SCSI Command PDU >should be set to 0, Untagged. The initiator associates inbound PDU's with the itt. I agree with Sandeep. If the SCSI Command is untagged, then the itt should be explicitly set to 0xffffffff in the iSCSI PDU since the initiator can still use the itt to associate inboud iSCSI PDU's with a current SCSI command because SAM-2 sec 4.9.1 states: "An untagged task does not include a tag in any of its component definitions, thus restricting the number of concurrent untagged tasks in a single task set to _ONE_ per initiator" If there are multiple outstanding tasks, (one untagged task and multiple tagged tasks), each task will still have a unique itt, and therefore the initiator can associate inbound iSCSI PDU's with a particular SCSI command. > > - Rod > >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On >Behalf Of >Sandeep Joshi >Sent: Monday, July 23, 2001 10:31 AM >To: ips@ece.cmu.edu >Subject: Re: iSCSI Plugfest at UNH (misc issues) > > > > >Hi Julian, > >Some additional items from the plugfest to resolve.. > >1) Sec 2.3.1 : Untagged tasks. > If the task attribute in the SCSI Command is "untagged" > then the initiator task tag should be ignored, correct ? > Can the draft explicitly state that the initiator must > set the Initiator Task Tag to 0x'ffffffff if its an > untagged task. > > Do we assume that the initiator ULP will not issue more >than > one untagged tasks simultaneously ? > >2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the >expCmdSN ? > Clearly, the target has received and executed the >commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which >response > is being received). > > This seems like a valid property which could be mandated > and checked, to allow efficient initiator >implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) > >3) Sending status in read PDU > Since quite a few initiators did not support this, > this feature had to be enabled or disabled frequently at > the target. > > Either we should make it mandatory to implement (at >initiator) > or we should add a key "SendStatusInReadPDU=yes/no". The >first > option seems simpler. > >thanks >-Sandeep > -Michael F. Brown, UMass Lowell Computer Science phone: (978) 934-5354 email: mbrown@cs.uml.edu "If a driver behaves incorrectly, the Driver Verifier will crash the system immediately. In this way, the Driver Verifier prevents the driver bug from being masked by further processing. The result is a faster, easier debugging process." -Windows 2000 Driver Development Kit Release Notes From owner-ips@ece.cmu.edu Tue Jul 24 14:09:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07769 for ; Tue, 24 Jul 2001 14:09:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OH8pw14601 for ips-outgoing; Tue, 24 Jul 2001 13:08:51 -0400 (EDT) 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 f6OH72g12557 for ; Tue, 24 Jul 2001 13:07:03 -0400 (EDT) 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 MAA10342 for ; Tue, 24 Jul 2001 12:58:58 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OH71I42114 for ; Tue, 24 Jul 2001 11:07:01 -0600 Importance: Normal Subject: iSCSI: SessionTypes To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 10:07:01 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 10:07:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, As was noted in another thread, the recent drafts (07 included) introduced a new mechanism for avoiding the issue of login to the "default target" for SendTargets only function. It did this with the "SessionType" key. I like this idea a lot. However, the draft proposes two additional session types besides "Discovery" (for SendTargets only) and "Normal" (for SCSI to a real live target). The two additional ones are "Boot" and "CopyManager" and in both of these additional cases, it is suggested that the target might limit what SCSI commands are allowed. I have very strong feelings that these are (a) both unnecessary, (b) strongly violate layering AND (c) are incompletely specified, in any case. It's unnecessary because in both cases, the intent seems to be to limit what SCSI commands might be allowed within the given session, but if an initiator voluntarily requests such limiting behavior, then it can voluntarily limit what SCSI commands it sends. For the initiator to ask for a filter from the target when it can filter itself is silly. With respect to layering, this would be the first protocol that *might* restricts the set of SCSI commands allowed. In affect, it allows the iSCSI layer to filter the SCSI layer by changing the set of commands supported by a particular device type. That could get very confusing for the SCSI layer in the initiator (it sends a command and the iSCSI target layer rejects it, even though the device should support the command). It is also well beyond what a protocol spec should do. The proposal does not say what error conditions are reported if a command is rejected. By saying it's "vendor-dependent", it leaves the door open for massive interoperability problems (one target doesn't filter, another filters most everything). I can possibly foresee iSCSI specific reasons for such things (e.g., to request different authentication methods or security context, in analogy with Discovery session type), but until those are defined in detail, I see no reason to keep these things in. At best they might be reintroduced in the second generation of the standard. Consequently, I would *strongly* suggest that these two be removed from the draft. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 14:09:20 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07786 for ; Tue, 24 Jul 2001 14:09:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OH75212590 for ips-outgoing; Tue, 24 Jul 2001 13:07:05 -0400 (EDT) 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 f6OH72g12557 for ; Tue, 24 Jul 2001 13:07:03 -0400 (EDT) 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 MAA10342 for ; Tue, 24 Jul 2001 12:58:58 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OH71I42114 for ; Tue, 24 Jul 2001 11:07:01 -0600 Importance: Normal Subject: iSCSI: SessionTypes To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 10:07:01 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 10:07:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, As was noted in another thread, the recent drafts (07 included) introduced a new mechanism for avoiding the issue of login to the "default target" for SendTargets only function. It did this with the "SessionType" key. I like this idea a lot. However, the draft proposes two additional session types besides "Discovery" (for SendTargets only) and "Normal" (for SCSI to a real live target). The two additional ones are "Boot" and "CopyManager" and in both of these additional cases, it is suggested that the target might limit what SCSI commands are allowed. I have very strong feelings that these are (a) both unnecessary, (b) strongly violate layering AND (c) are incompletely specified, in any case. It's unnecessary because in both cases, the intent seems to be to limit what SCSI commands might be allowed within the given session, but if an initiator voluntarily requests such limiting behavior, then it can voluntarily limit what SCSI commands it sends. For the initiator to ask for a filter from the target when it can filter itself is silly. With respect to layering, this would be the first protocol that *might* restricts the set of SCSI commands allowed. In affect, it allows the iSCSI layer to filter the SCSI layer by changing the set of commands supported by a particular device type. That could get very confusing for the SCSI layer in the initiator (it sends a command and the iSCSI target layer rejects it, even though the device should support the command). It is also well beyond what a protocol spec should do. The proposal does not say what error conditions are reported if a command is rejected. By saying it's "vendor-dependent", it leaves the door open for massive interoperability problems (one target doesn't filter, another filters most everything). I can possibly foresee iSCSI specific reasons for such things (e.g., to request different authentication methods or security context, in analogy with Discovery session type), but until those are defined in detail, I see no reason to keep these things in. At best they might be reintroduced in the second generation of the standard. Consequently, I would *strongly* suggest that these two be removed from the draft. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 14:11:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08018 for ; Tue, 24 Jul 2001 14:11:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHZ3W16615 for ips-outgoing; Tue, 24 Jul 2001 13:35:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe38.law11.hotmail.com [64.4.16.95]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OHZ1216604 for ; Tue, 24 Jul 2001 13:35:01 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Jul 2001 10:34:55 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: iSCSI: SecurityContextComplete without operational parameters Date: Tue, 24 Jul 2001 13:35:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 24 Jul 2001 17:34:55.0300 (UTC) FILETIME=[F3D31040:01C11466] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit What I was actually asking for is that the target would not send any operational parameters in the same PDU as the SecurityContextComplete. Rationalization given below. Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, July 24, 2001 10:08 AM Subject: Re: iSCSI: SecurityContextComplete without operational parameters > the new text will read: > > If the initiator has been the last to complete the handshake it MUST > NOT start sending operational parameters that need to be protected > within the same text command; a text response including only > SecurityContextComplete=yes concludes the security sub-phase. Only > the following PDU exchange is protected by digests (if any). > > If the target has been the last to complete the handshake, the initiator > can start the operational parameter negotiation with the next text command; > the security negotiation sub-phase ends with the target text response. > However, the target handshake concluding response MUST NOT include > operational parameters that need to be protected. Only the following PDU > exchange is protected by digests (if any). > > Julo > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be best > if the target is required to send SecurityContextComplete=yes without any > new operational parameters within the same PDU. > > It makes coding cleaner because the initiator can have a simple > send/receive > loop that pops out when security is complete. If operational parameters are > allowed with SecurityContextComplete=yes, the initiator's security module > must also have operational parameter code or it must set flags, leave > information in buffers, etc that all create messy code. > > The spec says: > > If the initiator has been the last to complete the handshake it > MUST NOT start sending operational parameters within the same > text command. > > How about if we say the same thing for the target? There shouldn't be any > harm because I suspect everyone is doing that anyway. > > Comments? > > > Eddy_Quicksall@iVivity.com > > > > > From owner-ips@ece.cmu.edu Tue Jul 24 14:11:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08051 for ; Tue, 24 Jul 2001 14:11:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHTVD16179 for ips-outgoing; Tue, 24 Jul 2001 13:29:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe25.law11.hotmail.com [64.4.16.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OHTU216175 for ; Tue, 24 Jul 2001 13:29:30 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Jul 2001 10:29:24 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: "Michael Schoberg" , References: <3C7122FAF06DD5118ED60050047336482630B6@esply01.cnt.com> Subject: Re: iSCSI draft-07 Padding Date: Tue, 24 Jul 2001 13:29:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 24 Jul 2001 17:29:24.0138 (UTC) FILETIME=[2E6FC0A0:01C11466] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit What does a Fibre Channel driver do when the ULP wants to receive data into memory which is not a multiple of 4 bytes long? Eddy ----- Original Message ----- From: "Michael Schoberg" To: Sent: Tuesday, July 24, 2001 11:13 AM Subject: RE: iSCSI draft-07 Padding > Yes, at the very least the spec should not allow padding on intermediate > ReadData/WriteData bursts. I can't think of a reason why one would want to > use odd length intermediate bursts, so hopefully it's safe to restrict it. > Padding the last burst still seems reasonable for easy CRC calculation. > > Setting a fixed size is optional. A minimum would avoid memory > fragmentation when working with memory descriptors. > > : -----Original Message----- > : From: Robert Snively [mailto:rsnively@Brocade.COM] > : Sent: Tuesday, July 24, 2001 8:34 AM > : To: ips@ece.cmu.edu > : Subject: RE: iSCSI draft-07 Padding > : > : > : Fibre Channel's approach to this problem is to prohibit padding > : for all transfers except the transfer that moves the last bytes > : in the last (or highest pointer value) burst of data. Intermediate > : bursts are required to end on 4-byte boundaries, regardless of > : tranfer order as allowed by EMDP. > : > : Bob > : > : ----- Original Message ----- > : From: "Michael Schoberg" > : To: > : Sent: Friday, July 20, 2001 4:27 PM > : Subject: iSCSI draft-07 Padding > : > : > : > I couldn't find anything in the latest iSCSI spec > : (draft-07) that prevents > : > someone from issuing multiple padded PDU's for iSCSI Data > : In/Out segments. > : > I guess I'm worried that someone could issue padded > : odd-length write/read > : > data when it wasn't necessary. Example: When moving a 512 byte disk > : sector > : > an initiator/target could legally issue 512 1-byte DataSegmentLength > : > messages (each padded up to a 32-bit boundary). This isn't > : the sort of > : data > : > stream one would expect, but it's allowed in the draft. > : > > : > This also leads into whether fixed or minimum length data > : segments (for > : all > : > but the last) would be nice to include as part of the spec. > : It may result > : > in a simpler software/hardware design. > : > > : > From owner-ips@ece.cmu.edu Tue Jul 24 14:13:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08172 for ; Tue, 24 Jul 2001 14:12:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OGYYt10030 for ips-outgoing; Tue, 24 Jul 2001 12:34:34 -0400 (EDT) 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 f6OGYWg10024 for ; Tue, 24 Jul 2001 12:34:32 -0400 (EDT) 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 MAA41040 for ; Tue, 24 Jul 2001 12:26:26 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OGYJI290760 for ; Tue, 24 Jul 2001 10:34:19 -0600 Importance: Normal Subject: Re: iSCSI: Iterating long text responses To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 09:34:16 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 09:34:18 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark et al, I may be wrong here, but I read the general feeling of the group that option #5 (simple request length from the initiator and total available response length from the target) was the best option. I would like someone (David?) to call for concensus on this issue. I do not like the bookmark proposal. It needlessly requires: 1) the target to create and maintain this bookmark between Text commands 2) requires a whole new error state when the bookmark is invalid 3) doesn't spell out how long the target has to maintain the bookmark 4) requires the initiator to track the bookmark between Text commands etc. In other words, it's a lot more work for no real gain. Can we get closure on this issue, please? Jim Hafner Mark Bakke @ece.cmu.edu on 07-18-2001 12:32:44 PM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: "IPS Subject: Re: iSCSI: Iterating long text responses The "bookmark" solution that Julian had mentioned is currently in the -98 version of the iSCSI draft at: http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-06-98.txt This solution is more akin to #3, since the target does need to keep track of bookmarks, and the initiator requests each piece. This doesn't seem quite as simple as #5, but it will work. Simple targets that will not return enough addresses to fill a 4k text response PDU would not have to implement the bookmarks at all. Anyway, this is a change from what we had been discussing on the list, so it's worth looking at, and would perhaps be a good thing to do a consensus call on so we can put this thing to rest either way. -- Mark Julian Satran wrote: > > I think that both 4 and 5 involve in fact some state to be kept at the > target between PDUs sent in something related to > to a "task control block" if we assume that all the text commands carry the > same ITT. > 4 enables the initiator to reuse its parse buffer while 5 requires the > initiator to allocate a buffer for all the text responses (or keep the pipe > closed). > 4 is simpler than 5. If you add to 4 a handle that the initiator has to > give back the target next time (the bookmark) > then the target does not have to keep state. > A 0 bookmark says start from the top. It is very much like an offset (that > was mentioned) but it is generic and opaque. > > Regards, > Julo > > Mark Bakke on 29-06-2001 23:18:20 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: Iterating long text responses > > Initiator developers- > > Please respond to the questions at the end. > > Thanks, > > Mark > > The current iSCSI draft allows text command and response > PDUs of up to 4096 bytes. While we don't see any real > problems for the command PDU size, commands such as SendTargets > can easily exceed the response size. > > There are several ways we can fix this. The first two solutions > require no differences in the current iSCSI text command and > response; the latter three involve the use of the F bit. > > 1. Assume that such commands are done on a "special" connection > or are handled completely in software, and allow its response > PDU to be as large as it needs to be. > > This one appears too restrictive to be a solid solution. It > will also weaken any data digests done on the longer PDU. > > 2. Create an iterative SendTargets key (and do the same for any > other text commands that need this), that would allow the > initiator to request the "next target" or "next address". > > This would work, but would require any new command that needed > a large response to implement an iterator. It also means that > each part of the response from the iterator would have to fit > in the 4k PDU. > > The remainder of these require that only one text command sequence > be outstanding on a connection at a given time. They use the F > bit to indicate the last PDU of the sequence. Note that connection > allegiance is assumed for the entire sequence, and text commands > are never retried on another connection; a new command is issued > instead. > > 3. Do a text-response R2T, where the initiator controls when the > next partial response is sent. This would be more generic: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > I->T Text Command (with some indicator that we want more) > T->I Text Response (next PDU, F bit cleared) > > ... > > I->T Text Command (with indicator that we want more) > T->I Text Response (last PDU, F bit set) > > The main problem with this is that the target must keep track > of the state of its responses; if the initiator just stops asking, > it may have to keep a buffered response around until it times out, > the connection is dropped, or another text command comes along. > > 4. Allow multiple response PDUs to a single text command: > > I->T Text Command (F bit set) > T->I Text Response (first PDU, F bit cleared) > T->I Text Response (next PDU, F bit cleared) > > ... > > T->I Text Response (last PDU, F bit set) > > Basically, we are doing (3) without the R2T. The initiator, > upon sending the text command, must be prepared either to > accept as many PDUs as come back, or throw them away if it > can't handle them. This solution is a lot like #1, but with > the response spread across 4k PDUs. > > Also note that this (and the following scheme) avoid the problem > of the target keeping state; it sends ALL of the response PDUs > without the initiator asking for them. > > 5. Do #4, but allow the initiator to specify the amount of data > it is willing to accept: > > I->T Text Command (F bit set, AcceptResponseLength=4096) > T->I Text Response (first PDU, F bit set, TotalResponseLength=12288) > > In the above example, we have created a new text command field: > > AcceptResponseLength > > And in the text response PDU: > > TotalResponseLength > > The initiator indicated it was willing to accept a 4k response. > The target returned the first 4k in the text response, but set > the F bit since it was at its limit. It also returned a > TotalResponseLength field. Since this was greater than the > AcceptResponseLength, the initiator knows the amount of buffer > space it will need to get the full response. It can then choose > whether it will re-send the command, and if so, can give it a > large enough response length: > > I->T Text Command (F bit set, AcceptResponseLength=12288) > T->I Text Response (first PDU, F bit clear) > T->I Text Response (next PDU, F bit clear) > T->I Text Response (last PDU, F bit set, TotalResponseLength=12288) > > Note that most initiators will probably send an AcceptResponseLength > of the largest response they would normally accept, and that most > target responses will fit in one or a few PDUs anyway. > > #5 is really a compromise between #3 and #4; the target has the > benefit of being less statefull, and the initiator has the benefit > of controlling the amount of data it receives. > > I would like to recommend either #4 or #5. I think that #5 is > probably the safest solution, but #4 may not be a problem for anyone. > > Assuming that none of the implementors of initiators have a problem > with #4, I would pick that. > > If they do have a problem with it, we should go with #5. > > Targets probably don't care much whether we do #4 or #5. > > Initiator developers- > > Please indicate which solution (#4 or #5) appeals to you. > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 14:13:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08200 for ; Tue, 24 Jul 2001 14:13:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHQHC15945 for ips-outgoing; Tue, 24 Jul 2001 13:26:17 -0400 (EDT) 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 [192.151.27.9]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OHQF215941 for ; Tue, 24 Jul 2001 13:26:16 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 8C4231F795 for ; Tue, 24 Jul 2001 13:25:26 -0400 (EDT) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 0B2791F556 for ; Tue, 24 Jul 2001 13:26:10 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <36RH7WM0>; Tue, 24 Jul 2001 13:26:09 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A091E5@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: SessionTypes Date: Tue, 24 Jul 2001 13:26:02 -0400 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 agree completely with Jim's comments, and would add that any "vendor specific" behavior should stay in the vendor specific arena, and not be specified in any manner in the protocol spec. It seems to me that a copymanager implementation could have different authentication methods on a target (based on initiator name) without any special treatment in the iSCSI protocol. In addition, I am seriously dismayed to see more "new features" creeping into the protocol via draft 07 that haven't been discussed on the IPS list, and seem in no way to represent any group concensis. At this rate the draft will *never* reach RFC status. 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: Jim Hafner [mailto:hafner@almaden.ibm.com] > Sent: Tuesday, July 24, 2001 10:07 AM > To: ips@ece.cmu.edu > Subject: iSCSI: SessionTypes > > > Folks, > > As was noted in another thread, the recent drafts (07 > included) introduced > a new mechanism for avoiding the issue of login to the > "default target" for > SendTargets only function. It did this with the > "SessionType" key. I > like this idea a lot. > > However, the draft proposes two additional session types besides > "Discovery" (for SendTargets only) and "Normal" (for SCSI to > a real live > target). The two additional ones are "Boot" and > "CopyManager" and in both > of these additional cases, it is suggested that the target > might limit what > SCSI commands are allowed. > > I have very strong feelings that these are (a) both unnecessary, (b) > strongly violate layering AND (c) are incompletely specified, > in any case. > > It's unnecessary because in both cases, the intent seems to > be to limit > what SCSI commands might be allowed within the given session, > but if an > initiator voluntarily requests such limiting behavior, then it can > voluntarily limit what SCSI commands it sends. For the > initiator to ask > for a filter from the target when it can filter itself is silly. > > With respect to layering, this would be the first protocol > that *might* > restricts the set of SCSI commands allowed. In affect, it > allows the iSCSI > layer to filter the SCSI layer by changing the set of > commands supported by > a particular device type. That could get very confusing for > the SCSI layer > in the initiator (it sends a command and the iSCSI target > layer rejects it, > even though the device should support the command). It is > also well beyond > what a protocol spec should do. > > The proposal does not say what error conditions are reported > if a command > is rejected. By saying it's "vendor-dependent", it leaves > the door open > for massive interoperability problems (one target doesn't > filter, another > filters most everything). > > I can possibly foresee iSCSI specific reasons for such things > (e.g., to > request different authentication methods or security context, > in analogy > with Discovery session type), but until those are defined in > detail, I see > no reason to keep these things in. At best they might be > reintroduced in > the second generation of the standard. > > Consequently, I would *strongly* suggest that these two be > removed from the > draft. > > Comments? > Jim Hafner > From owner-ips@ece.cmu.edu Tue Jul 24 14:15:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08295 for ; Tue, 24 Jul 2001 14:15:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHfBr17147 for ips-outgoing; Tue, 24 Jul 2001 13:41:11 -0400 (EDT) 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 f6OHfA217143 for ; Tue, 24 Jul 2001 13:41:10 -0400 (EDT) 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 NAA47656 for ; Tue, 24 Jul 2001 13:33:05 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OHf9I61650 for ; Tue, 24 Jul 2001 11:41:09 -0600 Importance: Normal Subject: iSCSI: "when a target acts as an initiator..." To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 10:41:07 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 10:41:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, Draft 07 contains, in clause 1.2.7, the following paragraph concerning copy manager type functions: "When a target has to act as an initiator for a third party command, it MAY use the iSCSI Initiator Name it learned during login as required by the authentication mechanism to the third party." I believe this paragraph should be deleted for the following reasons: 1) by saying 'MAY' it doesn't define the behavior well-enough 2) without careful review, this could open gapping security holes (e.g., under what conditions can I pretend to be someone else?) 3) generally speaking, a "target acting as an initiator" (aka copy manager) is just another initiator in the world. The fact that it's acting on someone else's behalf is pretty much lost (particularly at the SCSI layer). 4) copy managers usually have more rights than the requesting initiator, consequently, this may be a bad thing. 5) copy managers may be acting more on behalf of an enterprise level backup operation and not specifically on behalf of the requesting initiator through which the SCSI command is sent (e.g., the backup app could use InitiatorA as the "conduit" for delivering an Extended Copy command that moves InitiatorB's data around in the SAN - in this case, pretending to be 'A' wouldn't do the copy manager any good). As seen from this post and the previous one on Copy Manager session type, there is a lot of ill-defined stuff in the document about third party issues. I would suggest that this is a complex issue and that it needs to be addressed in its entirety. To facilitate this, I would recommend that we avoid this topic for the first version of the iSCSI standard (it's not a critical component at all), remove all specific behavior specifications (required or otherwise) concerning third party/copy manager/etc. and save this for a more detailed review in a second generation of the standard (if a need arises). Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 14:15:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08390 for ; Tue, 24 Jul 2001 14:15:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHmCC17783 for ips-outgoing; Tue, 24 Jul 2001 13:48:12 -0400 (EDT) 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 f6OHmA217775 for ; Tue, 24 Jul 2001 13:48:10 -0400 (EDT) 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 NAA23258 for ; Tue, 24 Jul 2001 13:40:05 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OHm9I286184 for ; Tue, 24 Jul 2001 11:48:09 -0600 Importance: Normal Subject: iSCSI: AccessID text key To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 10:48:07 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 10:48:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I would like to ask that the AccessID text key be deleted from the list of supported/required keys. My reasons are: 1) it violates layering (this is a SCSI level construct) 2) the spec is not complete in how this is formatted. At the SCSI layer, it is a 16 byte value with no other syntactic meaning. How is that formatted in a text value. 3) it really isn't needed for two reasons: (a) SCSI Access Controls will (when I get the proposal approved, probably in Sept) define iSCSI TransportID to be the iSCSI Initiator Name; this name lives above the SCSI port level (i.e., at the SCSI device level) and so the additional value of the AccessID (a device level construct) is mitigated and (b) the SCSI layer can deliver this as needed. 4) it's not clear how the iSCSI layer (in the initiator) gets its hands on this value, in any case. I'll admit that early on I was encouraged by the idea that this AccessID could be sent in login/text, but I've since backed off and changed my mind, for the reasons stated above. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 15:02:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11745 for ; Tue, 24 Jul 2001 15:02:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OI7Zi19392 for ips-outgoing; Tue, 24 Jul 2001 14:07:35 -0400 (EDT) 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 f6OI7X219386 for ; Tue, 24 Jul 2001 14:07:33 -0400 (EDT) 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 NAA55192 for ; Tue, 24 Jul 2001 13:59:28 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OI7VI84824 for ; Tue, 24 Jul 2001 12:07:31 -0600 Importance: Normal Subject: iSCSI: Status'es (clause 2.11.6) To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 11:07:30 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 11:07:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I have some questions, recommendations and editorial comments about the status codes for iSCSI in clause 2.11.6. Proxy Required is defined as the response when "the initiator must use an ISCSI proxy for this target". But that isn't defined anywhere in the document, so I recommend deleting this status code. What's the functional difference between the following: "Security negotiation failed" and "Forbidden Target"? In both cases, the initiator doesn't get to use what it thinks is there. I would think that "Forbidden Target" might be a security leak as it admits the fact that the target is there, whereas if the initiator only got back failed security, that admission wouldn't be made. "Target Conflict" and "Service Unavailable" both look more like "insufficient resources". In particular, "Target Conflict" should not be limited to a response in the 1->2 or more initiators case but in the n->n+1 initiators case. That is, if the target has resources for 'n' logins, it can reject another login with "insufficient resources", whether n=1 or n=10. So, I'd suggest that "insufficient resources" is a better catch-all for both of these cases. We need to clarify the "Session already open" to include language that says "with this initiator to this target portal group". The sentence immediately after the table says that "accept" means the initiator may proceed to issue SCSI commands. This is only true in a Normal session type and is not true for the Discovery session type. This should be clarified. Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 16:36:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20061 for ; Tue, 24 Jul 2001 16:36:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OJX2d26306 for ips-outgoing; Tue, 24 Jul 2001 15:33:02 -0400 (EDT) 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 f6OJX0226299 for ; Tue, 24 Jul 2001 15:33:00 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA06925; Tue, 24 Jul 2001 15:32:53 -0400 (EDT) Message-ID: <3B5DCC14.4561254A@cisco.com> Date: Tue, 24 Jul 2001 14:27:16 -0500 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: Robert Snively CC: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob- Very useful comments. I had not seen the idn-nameprep draft, and am somewhat surprised that I missed it when I was looking for this stuff before. I just read through nameprep-05, and it looks like the sort of thing that I had in mind by recommending that names be generated in lower case of whatever character set was being used. Anyway, if this is to be used for domain names, we ought to use it, too. Any idea when it will be an RFC? More comments below. -- Mark Robert Snively wrote: > > I am concerned about this approach for two reasons. > > 1) Name server programs do not allow case insensitivity. > > If I understand correctly from my admittedly incomplete experience > in this area, the names must be entered through an appropriate > application. Different systems and applications allowed to enter > such names may actually create different encodings for each character > that is represented. As one example, three separate encodings are > identified in draft-duerst-i18n-norm-04.txt for the character > LATIN CAPITAL LETTER A WITH RING ABOVE. Thus, what you typed > into the system would not be able to be found in a "case-sensitive" > international environment unless the original name happened to be > made by a program that used the same encoding, even though the > characters look identical. The solution being proposed is that > all names go through a "NAMEPREP" process described in > draft-ietf-idn-nameprep-05.txt. That process maps all > permitted code points to a normalized code point, including > forcing the names to be case insensitive. That is (again if > I understand it correctly), the character "B" will be mapped to > the character "b" before it is ever used by a name service program. > Thus, we are fooling ourselves if we expect a B to be differentiated > from a b by any compliant name server. I was hoping that nobody would generate both "B" and "b" anyway, but the definition in NAMEPREP is much better. > 2) Name registration will become painful (and perhaps expensive) > > If I understand correctly how domain names are registered, they > are presently registered by the case-insensitive character > string. If I make the name of a SCSI device case sensitive, it > implies that a name must now be registered in all its case sensitive > variations. Thus a company like Cisco must register a minimum > of three variations of the name, Cisco, CISCO, and cisco to be > reasonably assured of correct resolution to the domain. This > strikes me as a significant complication of the registration > process. OK > Assuming I have understood this environment correctly, I see two > possible solutions to these problems. > > 1) My original thought was to make the names using manufacturer > established invariant binary values, using an appropriate > World-Wide-Name like the EUI-64. Those have the benefit > of being internationalized to all countries that use > binary or hexadecimal numbers. They have the inconvenience > of requiring an installation process that maps them to > a locally assigned user-friendly name, but those installation > processes would normally be automated anyway. The user-friendly > name would probably be the domain name of the local network > modified by appropriate locally assigned variables. > > This is in some sense like the Ethernet MAC names which are > world-wide unique invariant formats that are mapped to > convenient IP addresses and domain names. This is allowed in iSCSI names by using the "eui" format, for those who can use EUI-64. > 2) Since my original thought has long ago been discarded by This wasn't thrown out; it is still there, and fully supported. It just didn't meet everyone's requirements. I would expect different types of products to use EUI-64 than the other mechanisms. > the naming committee, then I think we must at least require > that the names be unique within the context of the NAMEPREP > character mappings, which include not only case insensitivity, > but the mapping of many specialized characters to normalized > characters. This context also requires the prohibition of > certain characters. > > This is equivalent to rewording Mark's stated rule: > > - iSCSI names SHOULD be generated in a > case-insensitive manner. > > to say instead: > > - iSCSI names SHALL be generated using the normalized characters > that would be generated by processing through NAMEPREP. I really like this; it is a much stronger statement, and NAMEPREP can remove some of the ambiguity of "case-insensitive manner". > This has the advantage of allowing direct comparison, > but requires some thought during the generation of the names. > > It seems to me that these are the only two approaches that do not > require the installation of the NAMEPREP pre-processing in the > compare function. The thing I really like about this is that anyone comparing iSCSI names does not have to worry about any of this stuff; a byte-compare is all that's needed. Anyone generating the names only needs to put in NAMEPREP if the names are based on a source that might need to be mapped. Anyone building user interfaces for this stuff has the option to put in NAMEPREP to make things easier for their users, but can decide this on their own. > References that I found useful in this include: > > draft-duerst-i18n-norm-04.txt > draft-ietf-idn-idne-02.txt > draft-ietf-idn-nameprep-05.txt > draft-skwan-utf8-dns-06.txt Anyway, thanks for the reference. -- Mark > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, July 17, 2001 1:29 PM > To: IPS > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 16:36:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20121 for ; Tue, 24 Jul 2001 16:36:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OJFcw24913 for ips-outgoing; Tue, 24 Jul 2001 15:15:38 -0400 (EDT) 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 f6OJFb224908 for ; Tue, 24 Jul 2001 15:15:37 -0400 (EDT) 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 PAA10226; Tue, 24 Jul 2001 15:07:31 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OJFWI294334; Tue, 24 Jul 2001 13:15:32 -0600 Importance: Normal Subject: RE: iSCSI: "when a target acts as an initiator..." To: "Nate Lawson" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 12:15:29 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 12:15:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Nate, I agree with you. If the document defines what a well-behaved target is and defines what a well-behaved initiator is, then your copy manager should be able to function correctly, as you suggest. Now, whether the document does those two things well is ..... :-{) Jim Hafner "Nate Lawson" on 07-24-2001 12:04:38 PM To: Jim Hafner/Almaden/IBM@IBMUS cc: Subject: RE: iSCSI: "when a target acts as an initiator..." I agree that the standard should not specifically try to address copy manager behavior, however, the standard should do nothing to prevent it. A well-behaved copy manager is simply a well-behaved target + well-behaved initiator. I certainly hope nothing in the the standard disallows this! -Nate > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Jim Hafner > Sent: Tuesday, July 24, 2001 10:41 AM > To: ips@ece.cmu.edu > Subject: iSCSI: "when a target acts as an initiator..." > > > Folks, > > Draft 07 contains, in clause 1.2.7, the following paragraph > concerning copy > manager type functions: > > "When a target has to act as an initiator for a third party > command, it MAY > use the iSCSI Initiator Name it learned during login as required by the > authentication mechanism to the third party." > > I believe this paragraph should be deleted for the following reasons: > 1) by saying 'MAY' it doesn't define the behavior well-enough > 2) without careful review, this could open gapping security holes (e.g., > under what conditions can I pretend to be someone else?) > 3) generally speaking, a "target acting as an initiator" (aka > copy manager) > is just another initiator in the world. The fact that it's acting on > someone else's behalf is pretty much lost (particularly at the > SCSI layer). > 4) copy managers usually have more rights than the requesting initiator, > consequently, this may be a bad thing. > 5) copy managers may be acting more on behalf of an enterprise > level backup > operation and not specifically on behalf of the requesting initiator > through which the SCSI command is sent (e.g., the backup app could use > InitiatorA as the "conduit" for delivering an Extended Copy command that > moves InitiatorB's data around in the SAN - in this case, pretending to be > 'A' wouldn't do the copy manager any good). > > As seen from this post and the previous one on Copy Manager session type, > there is a lot of ill-defined stuff in the document about third party > issues. I would suggest that this is a complex issue and that > it needs to > be addressed in its entirety. To facilitate this, I would recommend that > we avoid this topic for the first version of the iSCSI standard > (it's not a > critical component at all), remove all specific behavior specifications > (required or otherwise) concerning third party/copy manager/etc. and save > this for a more detailed review in a second generation of the standard (if > a need arises). > > Comments? > Jim Hafner > > From owner-ips@ece.cmu.edu Tue Jul 24 17:43:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26052 for ; Tue, 24 Jul 2001 17:43:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OL3fJ03244 for ips-outgoing; Tue, 24 Jul 2001 17:03:41 -0400 (EDT) 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 f6OL3e203240 for ; Tue, 24 Jul 2001 17:03:40 -0400 (EDT) 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 QAA16550 for ; Tue, 24 Jul 2001 16:55:34 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OL3aI147340 for ; Tue, 24 Jul 2001 15:03:36 -0600 Importance: Normal Subject: Re: TargetAlias/InitiatorAlias text commands To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 14:03:35 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 02:03:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Marj, I concur. I don't see any value in these keys either, at least within the protocol. Jim Hafner "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 07-24-2001 01:38:35 PM Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: TargetAlias/InitiatorAlias text commands As outlined in David Black's consensus statement on the SendTargets command (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target records returned in response to a SendTargets request will not include TargetAlias, in response to the expressed desire to limit the SendTargets functionality to the basic description of the target iSCSI device. There are references to "aliases" sprinkled throughout the iSCSI protocol document, but this construct doesn't add any value to the iSCSI protocol model or functionality. Since the TargetAlias and InitiatorAlias text commands do not contribute any functionality to the iSCSI protocol, are not used in any iSCSI-related logic within an implementation, and are basicly a "label" more appropriately administered by a management tool, I propose they be removed from the iSCSI protocol spec. Comments? 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 Tue Jul 24 17:48:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26484 for ; Tue, 24 Jul 2001 17:48:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OKW1100810 for ips-outgoing; Tue, 24 Jul 2001 16:32:01 -0400 (EDT) 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 f6OKVx200806 for ; Tue, 24 Jul 2001 16:31:59 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Tue Jul 24 16:30:33 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Tue Jul 24 16:30:55 EDT 2001 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 QAA08923; Tue, 24 Jul 2001 16:30:30 -0400 (EDT) Message-ID: <3B5DDAE6.5EDD39B5@research.bell-labs.com> Date: Tue, 24 Jul 2001 16:30:30 -0400 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: cbm@rose.hp.com CC: ips@ece.cmu.edu Subject: Re: iSCSI state transitions References: <200107240327.UAA13165@core.rose.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok.. here is what I had in mind before I saw the new state diagram. See http://www.bell-labs.com/user/sandeepj/conn.pdf This is probably not detailing all the events/actions but I sincerely think the current 14-state machine probably wont make it as-is into most implementations (i.e. it will get ignored by the silent majority - overspecification creates the same result as underspecification) To respond to all the comments below : 1) You are right, the states for target & initiator may be the same but the transitions events are different. Separating the diagrams will make it *much* easier to read. See Barry's (Reinhold) login phase diagrams for a good example. 2) State S13-BUSY can get confused with full-feature phase. RECOVERY_START sounds like a better name. 3) As regards TCP-related state, I think we are talking of nested state machines. From my limited knowledge of VHDL, I think these would become nested entities in a design hierarchy with their own state machines - the iSCSI state machine would be blocked until the TCP state machine comes back with a new connection and then enable the READY/GRANT signal or whatever. I still dont think the TCP state needs to show up in iSCSI connection state - it may be correct but it does not seem necessary. regards, -Sandeep "Mallikarjun C." wrote: > > Sandeep, > > Thanks for the comments. > > >pages 5-6 look good > >but pages 1-4 have a high information density. > >(Uneasy rests the eye which traces the transitions..) > > Not sure what's implied above.... > > I was merely trying to keep the pdf file small. > > >I suspect the primary problem is that the initiator and > >target connection state diagrams have got combined into > >one diagram. > > Depends on the viewpoint. Out of 30 transitions, 7 are > role-specific, rest are role-agnostic - that is 76.6% are > the same. I consider duplicating >75% in two separate diagrams > as unnecessary. Besides, 100% of the transitions are the same > for both roles in both connection recovery and session state > diagrams. While this hasn't been a "problem" for any of the > reviewers so far, let us wait for more comments. > > >State S13 should be called "suspended" or "to_be_recovered" > > The tasks are undoubtedly "busy" but the connection is > > certainly suspended. > > I am not that certain. The connection state machine is simply > entering into the recovery state diagram, S13 is _not_ a suspended > dead end. When in S13, CSM-R is actively counting time to > possibly take transition M1 to get to R3. > > Would RECOVERY_START be a better name than BUSY? > > > We seem to be tracking the TCP state (S2, S12 for SYN,FIN) > > It adds to the complexity and sidetracks one > > from the main purpose, which (i thought) was to document > > error recovery. > > Sorry, not true - section 6 goes beyond error recovery(section 7). > As stated in the preface, these document the entire life of the > iSCSI connection and iSCSI session. > > At the iSCSI level, we have to clearly specify how iSCSI state > machines react to transport connection events, since an implementation > must deal with those. Section 1.2.6 clearly lays out how to deal with > transport connection termination events for the same reason. > > >Assume that connection > > establishment and destruction is an action on transition > .. > > On error, the connection will be closed and the state can be > > restored to S1 in one step. > > These state diagrams are hoped to be implementable "as is". > In reality, connection establishment is not atomic - an iSCSI > driver/ASIC has to send a connect request and wait for the > result, S2 represents the state of the iSCSI connection record > during that time. Similar comments apply for connection > termination. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > >Mallikarjun, > > > >Just a few comments on this.. pages 5-6 look good > >but pages 1-4 have a high information density. > >(Uneasy rests the eye which traces the transitions..) > > > >I suspect the primary problem is that the initiator and > >target connection state diagrams have got combined into > >one diagram. As a result, most states as well as transitions > >have got special-cased as initiator-only or target-only. > > > >(For example, T1, T2, T3, T7, T15 are all initiator-only) > > > >Other points: > >a) State S13 should be called "suspended" or "to_be_recovered" > > The tasks are undoubtedly "busy" but the connection is > > certainly suspended. The state name must reflect the state > > of the connection, not the individual tasks. > > > >b) We seem to be tracking the TCP state (S2, S12 for SYN,FIN) > > It adds to the complexity and sidetracks one > > from the main purpose, which (i thought) was to document > > error recovery. If we remove the TCP state tracking, we > > may be be able to eliminate some states (S2, S12, etc) > > and keep the focus on iSCSI. Assume that connection > > establishment and destruction is an action on transition, > > not a whole new state to document. > > > >c) Transitions T7, T8 can be removed. How individual implementations > > behave on login errors (do a retry/bailout) need not be covered. > > On error, the connection will be closed and the state can be > > restored to S1 in one step. > > > >All in all, it should be possible to express the connection state > >for each end (with error recovery) in about 7-8 states. > > > >The following patterns would then be easy to spot: > >1) There is one way to move from FREE to LOGGED_IN > >2) There are four ways to move from LOGGED_IN to FREE > > a) by self-initiated logout > > -target sends Async > > -initiator sends Logout command > > b) by "other-end" requested logout > > -target receives a Logout command > > -initiator receives an Async message > > c) a transport failure followed by connection recovery failure > > which indicates a need to abort tasks. > > d) a transport failure followed by connection recovery success > > which indicates a clean shutdown. > > > >regards, > >-Sandeep > > > > > >"Mallikarjun C." wrote: > >> > >> All: > >> > >> Excuse my posting of the (relatively small sized, 27KB) > >> pdf file with the iSCSI state diagrams. I'll post a URL > >> shortly, but I wanted to get this out sooner to give > >> reviewers a graphical description of rev07, section 6. > >> > >> This was reviewed in the ERT forum, and the ASCII versions > >> of this slide set were incorporated into rev07. > >> > >> Mallikarjun > >> > >> Mallikarjun Chadalapaka > >> Networked Storage Architecture > >> Network Storage Solutions Organization > >> Hewlett-Packard, Roseville > >> cbm@rose.hp.com > >> > >> ------------------------------------------------------------------------ > >> Name: iscsi_states.pdf > >> iscsi_states.pdf Type: Portable Document Format (application/pdf) > >> Encoding: base64 > >> Download Status: Not downloaded with message > > From owner-ips@ece.cmu.edu Tue Jul 24 17:51:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26729 for ; Tue, 24 Jul 2001 17:51:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OKcji01319 for ips-outgoing; Tue, 24 Jul 2001 16:38:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OKci201313 for ; Tue, 24 Jul 2001 16:38:44 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id 6C64D15EE for ; Tue, 24 Jul 2001 13:38:43 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id B3D3A1F556 for ; Tue, 24 Jul 2001 13:38:42 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id <3PL0TTMA>; Tue, 24 Jul 2001 13:38:41 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A091E7@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" Subject: TargetAlias/InitiatorAlias text commands Date: Tue, 24 Jul 2001 13:38:35 -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 As outlined in David Black's consensus statement on the SendTargets command (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target records returned in response to a SendTargets request will not include TargetAlias, in response to the expressed desire to limit the SendTargets functionality to the basic description of the target iSCSI device. There are references to "aliases" sprinkled throughout the iSCSI protocol document, but this construct doesn't add any value to the iSCSI protocol model or functionality. Since the TargetAlias and InitiatorAlias text commands do not contribute any functionality to the iSCSI protocol, are not used in any iSCSI-related logic within an implementation, and are basicly a "label" more appropriately administered by a management tool, I propose they be removed from the iSCSI protocol spec. Comments? 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 Tue Jul 24 17:56:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26985 for ; Tue, 24 Jul 2001 17:56:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OHtIa18350 for ips-outgoing; Tue, 24 Jul 2001 13:55:18 -0400 (EDT) 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 f6OHtE218322 for ; Tue, 24 Jul 2001 13:55:14 -0400 (EDT) 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 TAA50490 for ; Tue, 24 Jul 2001 19:55:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6OHt6b65526 for ; Tue, 24 Jul 2001 19:55:07 +0200 Importance: Normal Subject: Re: iSCSI: SessionTypes To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Tue, 24 Jul 2001 21:01:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 24/07/2001 20:55:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim, Layering between SCSI and iSCSI is a question of implementation and not protocol. A boot device may do filtering and authentication - but my assumption was that i will do some more and here are but a few examples: on boot it can load a specific CD/DVD if it is a changer and do not give you access to any other device - or not accept you at all for an all-purpose session on copy manager it may allow you access to part of a robot library but not another and get the credentials from the "original initiator" Even if loosely specified now they have a "framework value" and will help implementers craft APIs to surface hose type to operational (SCSI) or management layers. If we don't introduce them now there will be no such "hooks" and we stand no chance to introduce them later as a refinement Marjorie, There where no new features introduced in 07 - and if it seems so to will have to be more specific. The session type (in another form) was there for a long time. Regards, Julo "Jim Hafner" on 24-07-2001 20:07:01 Please respond to "Jim Hafner" To: ips@ece.cmu.edu cc: Subject: iSCSI: SessionTypes Folks, As was noted in another thread, the recent drafts (07 included) introduced a new mechanism for avoiding the issue of login to the "default target" for SendTargets only function. It did this with the "SessionType" key. I like this idea a lot. However, the draft proposes two additional session types besides "Discovery" (for SendTargets only) and "Normal" (for SCSI to a real live target). The two additional ones are "Boot" and "CopyManager" and in both of these additional cases, it is suggested that the target might limit what SCSI commands are allowed. I have very strong feelings that these are (a) both unnecessary, (b) strongly violate layering AND (c) are incompletely specified, in any case. It's unnecessary because in both cases, the intent seems to be to limit what SCSI commands might be allowed within the given session, but if an initiator voluntarily requests such limiting behavior, then it can voluntarily limit what SCSI commands it sends. For the initiator to ask for a filter from the target when it can filter itself is silly. With respect to layering, this would be the first protocol that *might* restricts the set of SCSI commands allowed. In affect, it allows the iSCSI layer to filter the SCSI layer by changing the set of commands supported by a particular device type. That could get very confusing for the SCSI layer in the initiator (it sends a command and the iSCSI target layer rejects it, even though the device should support the command). It is also well beyond what a protocol spec should do. The proposal does not say what error conditions are reported if a command is rejected. By saying it's "vendor-dependent", it leaves the door open for massive interoperability problems (one target doesn't filter, another filters most everything). I can possibly foresee iSCSI specific reasons for such things (e.g., to request different authentication methods or security context, in analogy with Discovery session type), but until those are defined in detail, I see no reason to keep these things in. At best they might be reintroduced in the second generation of the standard. Consequently, I would *strongly* suggest that these two be removed from the draft. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 18:43:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29145 for ; Tue, 24 Jul 2001 18:43:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OMM6q08923 for ips-outgoing; Tue, 24 Jul 2001 18:22:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6OMM5208918 for ; Tue, 24 Jul 2001 18:22:05 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id F124A602 for ; Tue, 24 Jul 2001 18:22:03 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id PAA00271 for ips@ece.cmu.edu; Tue, 24 Jul 2001 15:23:16 -0700 (PDT) Message-Id: <200107242223.PAA00271@core.rose.hp.com> Subject: iSCSI: ImmediateData To: ips@ece.cmu.edu Date: Tue, 24 Jul 2001 15:23:16 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk [ Attached is an exchange with Julian mid-last week. ] Julian, I once again recommend that the default for ImmediateData be "no". I would argue that the most simple case should be enabled by default - just what we did for InitialR2T - not the one that demands more memory for unsolicited immediate data. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com - I realized (during plugfest) that ImmdiateData's default is "yes". I recommend making it "no", keeping simple-minded targets in view. This issue is more serious if those simple targets do not do a lot of text negotiation, when they will be stuck with having to support a DataPDULength worth of immediate data. This is also in contrary to the conservative spirit of the default for InitialR2T (whose default is "yes"). Please feel free to take it to ips if you think it's a change that warrants comments from a wider audience. +++ I did not hear any comment from the plugfest on this. The rational behind it is that simple software implementions benefit the most out of it and the default buffer is small ++ From owner-ips@ece.cmu.edu Tue Jul 24 18:45:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29251 for ; Tue, 24 Jul 2001 18:45:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OLQOx05007 for ips-outgoing; Tue, 24 Jul 2001 17:26:24 -0400 (EDT) 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 f6OLQM205003 for ; Tue, 24 Jul 2001 17:26:22 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA15642; Tue, 24 Jul 2001 17:26:15 -0400 (EDT) Message-ID: <3B5DE6A5.C9884CB7@cisco.com> Date: Tue, 24 Jul 2001 16:20:37 -0500 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: Jim Hafner CC: ips@ece.cmu.edu Subject: Re: TargetAlias/InitiatorAlias text commands References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't agree. Although TargetAlias and InitiatorAlias are not used within the SendTargets response, they ARE specified as being sent during the login phase. Basically, the initiator would send its InitiatorAlias whenever it sends InitiatorName, and the target would send back TargetAlias within the login response. This enables initiators and targets to have non-unique, user-friendly names apart from their iSCSI names, and a way to communicate them. These can then be used within a user interface as specified in the NDT document's alias section. I really do think that these add value; gateways such as ours provide access to multiple targets, which the user is allowed to name. These names are not necessarily globally-unique, but they are meaningful to the user. A method to communicate these names provides a method to give a user that warm, fuzzy feeling that he or she has found the right drive. Keep in mind that some target and initiator names may be based on EUI-64, and will basically be a bunch of hex digits. This was not very friendly or usable with Fibre Channel; why should we make the same mistake? -- Mark Jim Hafner wrote: > > Marj, > > I concur. I don't see any value in these keys either, at least within the > protocol. > > Jim Hafner > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu > on 07-24-2001 01:38:35 PM > > Sent by: owner-ips@ece.cmu.edu > > To: "Ips Reflector (E-mail)" > cc: > Subject: TargetAlias/InitiatorAlias text commands > > As outlined in David Black's consensus statement on the SendTargets command > (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target > records returned in response to a SendTargets request will not include > TargetAlias, in response to the expressed desire to limit the SendTargets > functionality to the basic description of the target iSCSI device. > > There are references to "aliases" sprinkled throughout the iSCSI protocol > document, but this construct doesn't add any value to the iSCSI protocol > model or functionality. > > Since the TargetAlias and InitiatorAlias text commands do not contribute > any > functionality to the iSCSI protocol, are not used in any iSCSI-related > logic > within an implementation, and are basicly a "label" more appropriately > administered by a management tool, I propose they be removed from the iSCSI > protocol spec. > > Comments? > > 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 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 18:46:18 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29326 for ; Tue, 24 Jul 2001 18:46:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OM8uo08058 for ips-outgoing; Tue, 24 Jul 2001 18:08:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e33.bld.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 f6OM8s208053 for ; Tue, 24 Jul 2001 18:08:55 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA25212 for ; Tue, 24 Jul 2001 17:03:35 -0500 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OM8rI33012 for ; Tue, 24 Jul 2001 16:08:53 -0600 Subject: Re: iSCSI: SessionTypes To: "Julian Satran" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Prasenjit Sarkar" Date: Tue, 24 Jul 2001 15:08:52 -0700 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 03:08:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, There are existing mechnaisms to deal with the DVD/CD/robot example you came up with, so adding another mechanism (to a complex spec) is probably not desirable. The second and more important issue is how you came up with the desired behavior on "SessionType=BootSession". From a survey of exisitng booting protocols (SCSI and non-SCSI), I could not find anything remotely like it because such issues are dealt with in a different layer. Finally, the oft-repeated reason that "if we dont introduce them now, we will never have them" is very specious and is contrary to the history of protocol development. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose Julian Satran/Haifa/I To: ips@ece.cmu.edu BM@IBMIL cc: Sent by: Subject: Re: iSCSI: SessionTypes owner-ips@ece. cmu.edu 07/24/2001 11:01 AM Jim, Layering between SCSI and iSCSI is a question of implementation and not protocol. A boot device may do filtering and authentication - but my assumption was that i will do some more and here are but a few examples: on boot it can load a specific CD/DVD if it is a changer and do not give you access to any other device - or not accept you at all for an all-purpose session on copy manager it may allow you access to part of a robot library but not another and get the credentials from the "original initiator" Even if loosely specified now they have a "framework value" and will help implementers craft APIs to surface hose type to operational (SCSI) or management layers. If we don't introduce them now there will be no such "hooks" and we stand no chance to introduce them later as a refinement Marjorie, There where no new features introduced in 07 - and if it seems so to will have to be more specific. The session type (in another form) was there for a long time. Regards, Julo "Jim Hafner" on 24-07-2001 20:07:01 Please respond to "Jim Hafner" To: ips@ece.cmu.edu cc: Subject: iSCSI: SessionTypes Folks, As was noted in another thread, the recent drafts (07 included) introduced a new mechanism for avoiding the issue of login to the "default target" for SendTargets only function. It did this with the "SessionType" key. I like this idea a lot. However, the draft proposes two additional session types besides "Discovery" (for SendTargets only) and "Normal" (for SCSI to a real live target). The two additional ones are "Boot" and "CopyManager" and in both of these additional cases, it is suggested that the target might limit what SCSI commands are allowed. I have very strong feelings that these are (a) both unnecessary, (b) strongly violate layering AND (c) are incompletely specified, in any case. It's unnecessary because in both cases, the intent seems to be to limit what SCSI commands might be allowed within the given session, but if an initiator voluntarily requests such limiting behavior, then it can voluntarily limit what SCSI commands it sends. For the initiator to ask for a filter from the target when it can filter itself is silly. With respect to layering, this would be the first protocol that *might* restricts the set of SCSI commands allowed. In affect, it allows the iSCSI layer to filter the SCSI layer by changing the set of commands supported by a particular device type. That could get very confusing for the SCSI layer in the initiator (it sends a command and the iSCSI target layer rejects it, even though the device should support the command). It is also well beyond what a protocol spec should do. The proposal does not say what error conditions are reported if a command is rejected. By saying it's "vendor-dependent", it leaves the door open for massive interoperability problems (one target doesn't filter, another filters most everything). I can possibly foresee iSCSI specific reasons for such things (e.g., to request different authentication methods or security context, in analogy with Discovery session type), but until those are defined in detail, I see no reason to keep these things in. At best they might be reintroduced in the second generation of the standard. Consequently, I would *strongly* suggest that these two be removed from the draft. Comments? Jim Hafner From owner-ips@ece.cmu.edu Tue Jul 24 18:46:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29349 for ; Tue, 24 Jul 2001 18:46:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OM3MC07697 for ips-outgoing; Tue, 24 Jul 2001 18:03:22 -0400 (EDT) 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 f6OM3K207693 for ; Tue, 24 Jul 2001 18:03:21 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel2.hp.com (Postfix) with ESMTP id 54B82CB5; Tue, 24 Jul 2001 18:03:20 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 1EE531F55F; Tue, 24 Jul 2001 18:03:18 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 18:03:18 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87802A091E9@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Mark Bakke'" Cc: ips@ece.cmu.edu Subject: RE: TargetAlias/InitiatorAlias text commands Date: Tue, 24 Jul 2001 18:03:09 -0400 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 You are describing something that is exposed to the user via a management interface to your implementation. There is no value of these constructs *to the iSCSI protocol operation*. I don't deny the value to a user, but a management interface provides the iSCSI contact point to a user, and can provide the association of iSCSI names to an "alias string" within an implementation environment. There is nothing similar contained in any transport protocol specification that I'm aware of, and I don't think that's "a mistake", but a design of specifying only what's necessary to protocol operation. Alias names are appropriate to the MIB, or some other management definition, not the iSCSI protocol. Marj > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, July 24, 2001 2:21 PM > To: Jim Hafner > Cc: ips@ece.cmu.edu > Subject: Re: TargetAlias/InitiatorAlias text commands > > > > I don't agree. Although TargetAlias and InitiatorAlias are not > used within the SendTargets response, they ARE specified as being > sent during the login phase. Basically, the initiator would send > its InitiatorAlias whenever it sends InitiatorName, and the target > would send back TargetAlias within the login response. This enables > initiators and targets to have non-unique, user-friendly names > apart from their iSCSI names, and a way to communicate them. These > can then be used within a user interface as specified in the > NDT document's alias section. > > I really do think that these add value; gateways such as ours > provide access to multiple targets, which the user is allowed to > name. These names are not necessarily globally-unique, but they > are meaningful to the user. A method to communicate these names > provides a method to give a user that warm, fuzzy feeling that > he or she has found the right drive. > > Keep in mind that some target and initiator names may be based > on EUI-64, and will basically be a bunch of hex digits. This > was not very friendly or usable with Fibre Channel; why should > we make the same mistake? > > -- > Mark > > Jim Hafner wrote: > > > > Marj, > > > > I concur. I don't see any value in these keys either, at > least within the > > protocol. > > > > Jim Hafner > > > > "KRUEGER,MARJORIE (HP-Roseville,ex1)" > @ece.cmu.edu > > on 07-24-2001 01:38:35 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: "Ips Reflector (E-mail)" > > cc: > > Subject: TargetAlias/InitiatorAlias text commands > > > > As outlined in David Black's consensus statement on the > SendTargets command > > (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target > records returned in response to a SendTargets request will not include > TargetAlias, in response to the expressed desire to limit the SendTargets > functionality to the basic description of the target iSCSI device. > > There are references to "aliases" sprinkled throughout the iSCSI protocol > document, but this construct doesn't add any value to the iSCSI protocol > model or functionality. > > Since the TargetAlias and InitiatorAlias text commands do not contribute > any > functionality to the iSCSI protocol, are not used in any iSCSI-related > logic > within an implementation, and are basicly a "label" more appropriately > administered by a management tool, I propose they be removed from the iSCSI > protocol spec. > > Comments? > > 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 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 18:56:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29825 for ; Tue, 24 Jul 2001 18:56:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OLOC804799 for ips-outgoing; Tue, 24 Jul 2001 17:24:12 -0400 (EDT) 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 f6OLOA204794 for ; Tue, 24 Jul 2001 17:24:10 -0400 (EDT) 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 RAA21446 for ; Tue, 24 Jul 2001 17:16:05 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OLO9I216296 for ; Tue, 24 Jul 2001 15:24:09 -0600 Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 24 Jul 2001 14:24:06 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 02:24:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark and Bob, This looks like exactly what we want. In short, whatever rules should be applied to domain names should be applied to iSCSI names. This seems to be a very clean way to express that principle. Thanks Bob! Jim Hafner Mark Bakke @ece.cmu.edu on 07-24-2001 12:27:16 PM Sent by: owner-ips@ece.cmu.edu To: Robert Snively cc: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names Bob- Very useful comments. I had not seen the idn-nameprep draft, and am somewhat surprised that I missed it when I was looking for this stuff before. I just read through nameprep-05, and it looks like the sort of thing that I had in mind by recommending that names be generated in lower case of whatever character set was being used. Anyway, if this is to be used for domain names, we ought to use it, too. Any idea when it will be an RFC? More comments below. -- Mark Robert Snively wrote: > > I am concerned about this approach for two reasons. > > 1) Name server programs do not allow case insensitivity. > > If I understand correctly from my admittedly incomplete experience > in this area, the names must be entered through an appropriate > application. Different systems and applications allowed to enter > such names may actually create different encodings for each character > that is represented. As one example, three separate encodings are > identified in draft-duerst-i18n-norm-04.txt for the character > LATIN CAPITAL LETTER A WITH RING ABOVE. Thus, what you typed > into the system would not be able to be found in a "case-sensitive" > international environment unless the original name happened to be > made by a program that used the same encoding, even though the > characters look identical. The solution being proposed is that > all names go through a "NAMEPREP" process described in > draft-ietf-idn-nameprep-05.txt. That process maps all > permitted code points to a normalized code point, including > forcing the names to be case insensitive. That is (again if > I understand it correctly), the character "B" will be mapped to > the character "b" before it is ever used by a name service program. > Thus, we are fooling ourselves if we expect a B to be differentiated > from a b by any compliant name server. I was hoping that nobody would generate both "B" and "b" anyway, but the definition in NAMEPREP is much better. > 2) Name registration will become painful (and perhaps expensive) > > If I understand correctly how domain names are registered, they > are presently registered by the case-insensitive character > string. If I make the name of a SCSI device case sensitive, it > implies that a name must now be registered in all its case sensitive > variations. Thus a company like Cisco must register a minimum > of three variations of the name, Cisco, CISCO, and cisco to be > reasonably assured of correct resolution to the domain. This > strikes me as a significant complication of the registration > process. OK > Assuming I have understood this environment correctly, I see two > possible solutions to these problems. > > 1) My original thought was to make the names using manufacturer > established invariant binary values, using an appropriate > World-Wide-Name like the EUI-64. Those have the benefit > of being internationalized to all countries that use > binary or hexadecimal numbers. They have the inconvenience > of requiring an installation process that maps them to > a locally assigned user-friendly name, but those installation > processes would normally be automated anyway. The user-friendly > name would probably be the domain name of the local network > modified by appropriate locally assigned variables. > > This is in some sense like the Ethernet MAC names which are > world-wide unique invariant formats that are mapped to > convenient IP addresses and domain names. This is allowed in iSCSI names by using the "eui" format, for those who can use EUI-64. > 2) Since my original thought has long ago been discarded by This wasn't thrown out; it is still there, and fully supported. It just didn't meet everyone's requirements. I would expect different types of products to use EUI-64 than the other mechanisms. > the naming committee, then I think we must at least require > that the names be unique within the context of the NAMEPREP > character mappings, which include not only case insensitivity, > but the mapping of many specialized characters to normalized > characters. This context also requires the prohibition of > certain characters. > > This is equivalent to rewording Mark's stated rule: > > - iSCSI names SHOULD be generated in a > case-insensitive manner. > > to say instead: > > - iSCSI names SHALL be generated using the normalized characters > that would be generated by processing through NAMEPREP. I really like this; it is a much stronger statement, and NAMEPREP can remove some of the ambiguity of "case-insensitive manner". > This has the advantage of allowing direct comparison, > but requires some thought during the generation of the names. > > It seems to me that these are the only two approaches that do not > require the installation of the NAMEPREP pre-processing in the > compare function. The thing I really like about this is that anyone comparing iSCSI names does not have to worry about any of this stuff; a byte-compare is all that's needed. Anyone generating the names only needs to put in NAMEPREP if the names are based on a source that might need to be mapped. Anyone building user interfaces for this stuff has the option to put in NAMEPREP to make things easier for their users, but can decide this on their own. > References that I found useful in this include: > > draft-duerst-i18n-norm-04.txt > draft-ietf-idn-idne-02.txt > draft-ietf-idn-nameprep-05.txt > draft-skwan-utf8-dns-06.txt Anyway, thanks for the reference. -- Mark > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, July 17, 2001 1:29 PM > To: IPS > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Jul 24 19:37:57 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01317 for ; Tue, 24 Jul 2001 19:37:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6OMYSS09806 for ips-outgoing; Tue, 24 Jul 2001 18:34:28 -0400 (EDT) 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 f6OMYQ209801 for ; Tue, 24 Jul 2001 18:34:26 -0400 (EDT) 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 SAA51512 for ; Tue, 24 Jul 2001 18:26:21 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6OMYOI53788 for ; Tue, 24 Jul 2001 16:34:25 -0600 Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names 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: Tue, 24 Jul 2001 15:34:08 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 04:34:24 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I want to jump on this bandwagon too. This seems to be exactly the right approach. . . . 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 Internet address: hufferd@us.ibm.com Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 07/24/2001 02:24:06 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Case-sensitivity in iSCSI names Mark and Bob, This looks like exactly what we want. In short, whatever rules should be applied to domain names should be applied to iSCSI names. This seems to be a very clean way to express that principle. Thanks Bob! Jim Hafner Mark Bakke @ece.cmu.edu on 07-24-2001 12:27:16 PM Sent by: owner-ips@ece.cmu.edu To: Robert Snively cc: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names Bob- Very useful comments. I had not seen the idn-nameprep draft, and am somewhat surprised that I missed it when I was looking for this stuff before. I just read through nameprep-05, and it looks like the sort of thing that I had in mind by recommending that names be generated in lower case of whatever character set was being used. Anyway, if this is to be used for domain names, we ought to use it, too. Any idea when it will be an RFC? More comments below. -- Mark Robert Snively wrote: > > I am concerned about this approach for two reasons. > > 1) Name server programs do not allow case insensitivity. > > If I understand correctly from my admittedly incomplete experience > in this area, the names must be entered through an appropriate > application. Different systems and applications allowed to enter > such names may actually create different encodings for each character > that is represented. As one example, three separate encodings are > identified in draft-duerst-i18n-norm-04.txt for the character > LATIN CAPITAL LETTER A WITH RING ABOVE. Thus, what you typed > into the system would not be able to be found in a "case-sensitive" > international environment unless the original name happened to be > made by a program that used the same encoding, even though the > characters look identical. The solution being proposed is that > all names go through a "NAMEPREP" process described in > draft-ietf-idn-nameprep-05.txt. That process maps all > permitted code points to a normalized code point, including > forcing the names to be case insensitive. That is (again if > I understand it correctly), the character "B" will be mapped to > the character "b" before it is ever used by a name service program. > Thus, we are fooling ourselves if we expect a B to be differentiated > from a b by any compliant name server. I was hoping that nobody would generate both "B" and "b" anyway, but the definition in NAMEPREP is much better. > 2) Name registration will become painful (and perhaps expensive) > > If I understand correctly how domain names are registered, they > are presently registered by the case-insensitive character > string. If I make the name of a SCSI device case sensitive, it > implies that a name must now be registered in all its case sensitive > variations. Thus a company like Cisco must register a minimum > of three variations of the name, Cisco, CISCO, and cisco to be > reasonably assured of correct resolution to the domain. This > strikes me as a significant complication of the registration > process. OK > Assuming I have understood this environment correctly, I see two > possible solutions to these problems. > > 1) My original thought was to make the names using manufacturer > established invariant binary values, using an appropriate > World-Wide-Name like the EUI-64. Those have the benefit > of being internationalized to all countries that use > binary or hexadecimal numbers. They have the inconvenience > of requiring an installation process that maps them to > a locally assigned user-friendly name, but those installation > processes would normally be automated anyway. The user-friendly > name would probably be the domain name of the local network > modified by appropriate locally assigned variables. > > This is in some sense like the Ethernet MAC names which are > world-wide unique invariant formats that are mapped to > convenient IP addresses and domain names. This is allowed in iSCSI names by using the "eui" format, for those who can use EUI-64. > 2) Since my original thought has long ago been discarded by This wasn't thrown out; it is still there, and fully supported. It just didn't meet everyone's requirements. I would expect different types of products to use EUI-64 than the other mechanisms. > the naming committee, then I think we must at least require > that the names be unique within the context of the NAMEPREP > character mappings, which include not only case insensitivity, > but the mapping of many specialized characters to normalized > characters. This context also requires the prohibition of > certain characters. > > This is equivalent to rewording Mark's stated rule: > > - iSCSI names SHOULD be generated in a > case-insensitive manner. > > to say instead: > > - iSCSI names SHALL be generated using the normalized characters > that would be generated by processing through NAMEPREP. I really like this; it is a much stronger statement, and NAMEPREP can remove some of the ambiguity of "case-insensitive manner". > This has the advantage of allowing direct comparison, > but requires some thought during the generation of the names. > > It seems to me that these are the only two approaches that do not > require the installation of the NAMEPREP pre-processing in the > compare function. The thing I really like about this is that anyone comparing iSCSI names does not have to worry about any of this stuff; a byte-compare is all that's needed. Anyone generating the names only needs to put in NAMEPREP if the names are based on a source that might need to be mapped. Anyone building user interfaces for this stuff has the option to put in NAMEPREP to make things easier for their users, but can decide this on their own. > References that I found useful in this include: > > draft-duerst-i18n-norm-04.txt > draft-ietf-idn-idne-02.txt > draft-ietf-idn-nameprep-05.txt > draft-skwan-utf8-dns-06.txt Anyway, thanks for the reference. -- Mark > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Tuesday, July 17, 2001 1:29 PM > To: IPS > Subject: iSCSI: Case-sensitivity in iSCSI names > > We are attempting to wrap up all of the issues surrounding > the creation and comparison of iSCSI initiator and target > names. One of these is whether the names are case-sensitive. > > The last naming & discovery draft stated that the names are > case-insensitive; this was to allow better transcribability > in cases where names were communicated outside the automated > discovery processes. > > This comes at some expense, particularly since these names > are defined to allow UTF-8 encoding of international character > sets. Initiators and targets would have to include code to > compare these sets. > > To simplify implementation and interoperability, it has been > recommended that we make iSCSI names case-sensitive instead. > > I am fine with doing this, and I think that we could even > get some of the usability back by adding these rules: > > - iSCSI names MUST be case-sensitive, and compared strictly > byte-for-byte. > > - iSCSI names SHOULD be generated in a case-insensitive > manner. > > I'm not sure how to properly word the latter, but the intent > is that someone generating the names would not produce both: > > iqn.9.com.cisco.myiscsithing > > and > > iqn.9.com.cisco.MyIscsiThing > > since a user would be likely to confuse these. Again, it doesn't > affect the protocol itself, just its usability. > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > case-sensitive? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 25 00:19:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12069 for ; Wed, 25 Jul 2001 00:19:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P326G23891 for ips-outgoing; Tue, 24 Jul 2001 23:02:06 -0400 (EDT) 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 f6P325223886 for ; Tue, 24 Jul 2001 23:02:05 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 22:17:56 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AA3@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Security Gateways Date: Tue, 24 Jul 2001 22:11:27 -0400 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 following issue was hidden in my long set of comments on the -03 version of FCIP: > > Delete 12 b). If an FCIP entity is operating with an external > > security gateway, only the interface on the public side of the > > gateway is compliant with this specification. The interface > > between the FCIP entity and the gateway is not compliant because > > it is lacking required security features - the FCIP entity > > *includes* the security gateway in this structure. > > Please post this as a separate issue because several of the > FCIP Authors believe it is appropriate for FCIP and I cannot > represent their opinions. The issue is not whether it's "appropriate". The issue is that if an implementation uses an FCIP Entity plus an external security gateway, the only interface that conforms to the forthcoming RFC is the public/external interface on the security gateway. The interface between the FCIP Entity and the security gateway is private and fails to conform to the security that will be required of all FCIP implementations. The above paragraph also applies to iSCSI (substitute iSCSI for FCIP in all instances). Let me also note that iSCSI's ability to use a security gateway is not final at this juncture. The spectrum of security possibilities includes things like SRP keying of ESP and IPsec transport mode that would make external gateways difficult or impossible to use. Those who care about being able to use security gateways (or think that there's no need to support their use) should speak up on the list, in London, and/or in Orange County (I would expect the decision not to be made prior to Orange County) and *EXPLAIN WHY* [technical rationale]. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 25 00:19:38 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12083 for ; Wed, 25 Jul 2001 00:19:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P30u523796 for ips-outgoing; Tue, 24 Jul 2001 23:00:56 -0400 (EDT) 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 f6P30t223790 for ; Tue, 24 Jul 2001 23:00:55 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0TDD14>; Tue, 24 Jul 2001 22:44:43 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AA5@CORPMX14> From: Black_David@emc.com To: ENDL_TX@computer.org, ips@ece.cmu.edu Subject: RE: FCIP -03 comments (part 2) Date: Tue, 24 Jul 2001 22:40:13 -0400 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 Three open issues, two of which are figure/diagram related. > > -- Figures 4-6 > > > > Should probably have an additional figure that shows > > at least one FCIP Entity, FC_LEP, and FC_DE in a single > > diagram. > > I don't know how to use stick figures to communicate the > concept that there can be multiple FCIP_LEPs in which there > are multiple FCIP_DEs in the confined line widths of an > Internet Draft. I believe that any figure that fails to > communicate that point is a disservice to the reader. In other words, too complex to do in ASCII graphics. If that's the case, so be it. I'll take another look at this in a future version, but it is definitely not a requirement for approval. > > -- Section 6.6.1 > > > > Please add a diagram of the whole header in addition to the > > protocol-specific fields. > > I will do this in rev 05 provided it it confirmed that the IETF > practice is to replicate requirements in multiple RFCs so that > a change in one RFC requires several others to be revised > concurrently. It's not necessary to show all the fields from the common encapsulation header, but at least show their size and reference the common encap draft/RFC for details, so that the reader understands the overall structure. This is common practice in IETF RFCs (e.g., you'll find lots of discussion of IP headers in the IPsec documents), and is similar to an issue that turned up in an earlier version of the iSCSI draft where it was difficult to determine field offset from the start of the iSCSI PDU due to nested diagrams. > There is an open issue among the FCIP Authors regarding the > need for specificity about what constitutes a loss of > synchronization. This probably will result in additional > changes in rev 05 (since the Internet Drafts deadline looms > too close for resolution in 04). > > Examples of conditions that may be declared to be indicators > of loss of synchronization are: > > a) failure of the comparison between length and -length > b) two consecutive header errors in other fields > > There is a reluctance to standardize on one minimum > list of validation criteria because several equally > valid lists have been proposed. It is the determination > of the FCIP Authors that choices of validation criteria > have no effect on product interoperability and thus > are not an absolute necessity in FCIP. Clearly some sort of hurdle is needed here to make sure that sufficient checks are made to avoid sending bad data to the FC Entity. There are clearly insufficient lists of validation criteria (e.g., checking only that the timestamp is reasonable is not enough), and hence I think some words are needed about what makes a set of validation criteria a "valid list". 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 25 00:19:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12101 for ; Wed, 25 Jul 2001 00:19:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P2QpZ22385 for ips-outgoing; Tue, 24 Jul 2001 22:26:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6P2Qo222380 for ; Tue, 24 Jul 2001 22:26:50 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 5B66313D4 for ; Tue, 24 Jul 2001 19:26:49 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 095441F511 for ; Tue, 24 Jul 2001 19:26:49 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 19:26:48 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6503F00E30@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: Case-sensitivity in iSCSI names Date: Tue, 24 Jul 2001 19:26:47 -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 Have room for one more on that wagon..? Sounds like a good way to go. ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Tuesday, July 24, 2001 3:34 PM > To: Jim Hafner > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > > > I want to jump on this bandwagon too. This seems to be > exactly the right > approach. > > . > . > . > 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 > Internet address: hufferd@us.ibm.com > > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 07/24/2001 02:24:06 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > > > > Mark and Bob, > > This looks like exactly what we want. In short, whatever > rules should be > applied to domain names should be applied to iSCSI names. > This seems to be > a very clean way to express that principle. > > Thanks Bob! > > Jim Hafner > > > Mark Bakke @ece.cmu.edu on 07-24-2001 12:27:16 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: Robert Snively > cc: IPS > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > > > > Bob- > > Very useful comments. I had not seen the idn-nameprep draft, and > am somewhat surprised that I missed it when I was looking for this > stuff before. I just read through nameprep-05, and it looks like > the sort of thing that I had in mind by recommending that names > be generated in lower case of whatever character set was being used. > > Anyway, if this is to be used for domain names, we ought to use it, > too. Any idea when it will be an RFC? > > More comments below. > > -- > Mark > > Robert Snively wrote: > > > > I am concerned about this approach for two reasons. > > > > 1) Name server programs do not allow case insensitivity. > > > > If I understand correctly from my admittedly incomplete experience > > in this area, the names must be entered through an appropriate > > application. Different systems and applications allowed to enter > > such names may actually create different encodings for each > character > > that is represented. As one example, three separate encodings are > > identified in draft-duerst-i18n-norm-04.txt for the character > > LATIN CAPITAL LETTER A WITH RING ABOVE. Thus, what you typed > > into the system would not be able to be found in a "case-sensitive" > > international environment unless the original name happened to be > > made by a program that used the same encoding, even though the > > characters look identical. The solution being proposed is that > > all names go through a "NAMEPREP" process described in > > draft-ietf-idn-nameprep-05.txt. That process maps all > > permitted code points to a normalized code point, including > > forcing the names to be case insensitive. That is (again if > > I understand it correctly), the character "B" will be mapped to > > the character "b" before it is ever used by a name service program. > > Thus, we are fooling ourselves if we expect a B to be differentiated > > from a b by any compliant name server. > > I was hoping that nobody would generate both "B" and "b" anyway, but > the definition in NAMEPREP is much better. > > > 2) Name registration will become painful (and perhaps expensive) > > > > If I understand correctly how domain names are registered, they > > are presently registered by the case-insensitive character > > string. If I make the name of a SCSI device case sensitive, it > > implies that a name must now be registered in all its case sensitive > > variations. Thus a company like Cisco must register a minimum > > of three variations of the name, Cisco, CISCO, and cisco to be > > reasonably assured of correct resolution to the domain. This > > strikes me as a significant complication of the registration > > process. > > OK > > > Assuming I have understood this environment correctly, I see two > > possible solutions to these problems. > > > > 1) My original thought was to make the names using manufacturer > > established invariant binary values, using an appropriate > > World-Wide-Name like the EUI-64. Those have the benefit > > of being internationalized to all countries that use > > binary or hexadecimal numbers. They have the inconvenience > > of requiring an installation process that maps them to > > a locally assigned user-friendly name, but those installation > > processes would normally be automated anyway. The user-friendly > > name would probably be the domain name of the local network > > modified by appropriate locally assigned variables. > > > > This is in some sense like the Ethernet MAC names which are > > world-wide unique invariant formats that are mapped to > > convenient IP addresses and domain names. > > This is allowed in iSCSI names by using the "eui" format, for > those who can use EUI-64. > > > 2) Since my original thought has long ago been discarded by > > This wasn't thrown out; it is still there, and fully supported. It > just didn't meet everyone's requirements. I would expect different > types of products to use EUI-64 than the other mechanisms. > > > the naming committee, then I think we must at least require > > that the names be unique within the context of the NAMEPREP > > character mappings, which include not only case insensitivity, > > but the mapping of many specialized characters to normalized > > characters. This context also requires the prohibition of > > certain characters. > > > > This is equivalent to rewording Mark's stated rule: > > > > - iSCSI names SHOULD be generated in a > > case-insensitive manner. > > > > to say instead: > > > > - iSCSI names SHALL be generated using the > normalized characters > > that would be generated by processing through NAMEPREP. > > I really like this; it is a much stronger statement, and NAMEPREP can > remove some of the ambiguity of "case-insensitive manner". > > > This has the advantage of allowing direct comparison, > > but requires some thought during the generation of the names. > > > > It seems to me that these are the only two approaches that do not > > require the installation of the NAMEPREP pre-processing in the > > compare function. > > The thing I really like about this is that anyone comparing iSCSI > names does not have to worry about any of this stuff; a byte-compare > is all that's needed. Anyone generating the names only needs to > put in NAMEPREP if the names are based on a source that might need > to be mapped. Anyone building user interfaces for this stuff has > the option to put in NAMEPREP to make things easier for their users, > but can decide this on their own. > > > References that I found useful in this include: > > > > draft-duerst-i18n-norm-04.txt > > draft-ietf-idn-idne-02.txt > > draft-ietf-idn-nameprep-05.txt > > draft-skwan-utf8-dns-06.txt > > Anyway, thanks for the reference. > > -- > Mark > > > Bob Snively e-mail: rsnively@brocade.com > > Brocade Communications Systems phone: 408 487 8135 > > 1745 Technology Drive > > San Jose, CA 95110 > > > > > > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Tuesday, July 17, 2001 1:29 PM > > To: IPS > > Subject: iSCSI: Case-sensitivity in iSCSI names > > > > We are attempting to wrap up all of the issues surrounding > > the creation and comparison of iSCSI initiator and target > > names. One of these is whether the names are case-sensitive. > > > > The last naming & discovery draft stated that the names are > > case-insensitive; this was to allow better transcribability > > in cases where names were communicated outside the automated > > discovery processes. > > > > This comes at some expense, particularly since these names > > are defined to allow UTF-8 encoding of international character > > sets. Initiators and targets would have to include code to > > compare these sets. > > > > To simplify implementation and interoperability, it has been > > recommended that we make iSCSI names case-sensitive instead. > > > > I am fine with doing this, and I think that we could even > > get some of the usability back by adding these rules: > > > > - iSCSI names MUST be case-sensitive, and compared strictly > > byte-for-byte. > > > > - iSCSI names SHOULD be generated in a case-insensitive > > manner. > > > > I'm not sure how to properly word the latter, but the intent > > is that someone generating the names would not produce both: > > > > iqn.9.com.cisco.myiscsithing > > > > and > > > > iqn.9.com.cisco.MyIscsiThing > > > > since a user would be likely to confuse these. Again, it doesn't > > affect the protocol itself, just its usability. > > > > Any thoughts? Will it hurt anyone's plans if iSCSI names were > > case-sensitive? > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 00:19:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12103 for ; Wed, 25 Jul 2001 00:19:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P32Cq23898 for ips-outgoing; Tue, 24 Jul 2001 23:02:12 -0400 (EDT) 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 f6P32B223893 for ; Tue, 24 Jul 2001 23:02:11 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 22:26:54 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AA4@CORPMX14> From: Black_David@emc.com To: ENDL_TX@computer.org, ips@ece.cmu.edu Subject: RE: FCIP -03 comments and Annex E Date: Tue, 24 Jul 2001 22:20:27 -0400 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 Three remaining things, although this is after the -04 deadline and hence these'll have to go in -05. > > Add at least FC-PH to the list of referenced documents > > T11 adamantly holds the opinion that the combination of > FC-PI and FC-FS replaces FC-PH. Ok. We'll deal with what versions of those documents to reference when we get to/through WG Last Call. > > I agree that detailed specification > > of Fibre Channel aspects (e.g., DLY_LIM calculation) > > belongs in FC-BB-2, but (non-normative) explanations > > of the purpose and rationale for inclusion of functionality > > in FCIP is in order for the FCIP spec, and such > > explanations will have to touch on FC concepts > > (e.g., an explanation of DLY_LIM is much clearer > > if it explains what R_A_TOV is and why violating it > > is a *really bad thing* in a Fibre Channel fabric). > > It seems to me that the simpler rational to explain > is that the Fibre Channel routing and error recovery > protocols require FC Frames to exit a receiving FCIP > Entity within in a fixed interval from the time they > entered a sending FCIP Entity, IP Network transit > time included, or never exit the FCIP Entity. Yes, that's good. > Mentioning the Fibre Channel specifics both obscures the > matter of concern and obliges Fibre Channel to either > forever maintain R_A_TOV as the one and only issue of > merit in this matter or bother the IESG with a new > revision of FCIP when it does. The cross-dependence of the standards does not occur if R_A_TOV is mentioned as a non-normative example and cited to the section of the document that currently defines it. I think specific examples are useful in helping people navigate back and forth between the two sets of specs. R_A_TOV is also fairly well embedded into fabric operation; I don't think there's much of a risk of it going away. > > > > E-5.4.1 Determining loss of connectivity {partial} > > > > > > > > Somewhere, possibly in Annex D, making the FC entity > > > > responsible for checking for loss of TCP connectivity > > > > ought to be enhanced by giving the HLO SW_ILS as an > > > > example of how this could be done without requiring it > > > > to be used. > > > > > > No changes have been made in FCIP in response to this comment. > > > > > > This is 100% a Fibre Channel issue. If Fibre Channel does > > > not want to test connectivity, that is Fibre Channel's business. > > > If Fibre Channel wants to invent a replacement for the HLO > > > SW_ILS (perhaps even one suited specifically to FCIP) why > > > should it be the place of FCIP to mandate use of HLO? > > > > I didn't say "mandate", I said "as an example". The general > > point is that FC may have a keep-alive mechanism such as HLO > > that would obviate the need for any such mechanism at this > > level, and it should be made in the FCIP spec. Referencing > > HLO and the version of FC-SW that defines it *as an example* > > would help get the point across, without requiring any use > > of HLO (that sort of requirement is FC's business). > > If it is expected that all IETF standards track RFCs must > discuss how they implement a keep-alive mechanism, then > most certainly FCIP needs to explain why it does not > need one. It's not "expected". IMHO, this is analogous to the previous issue - FC has a requirement to detect loss of connectivity for correct operation of the fabric, and has mechanisms to do so, such as HLO. I'm not sure that the HLO example is as important as the R_A_TOV one above. --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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 25 00:20:51 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12171 for ; Wed, 25 Jul 2001 00:20:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P2xvL23712 for ips-outgoing; Tue, 24 Jul 2001 22:59:57 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6ONc0213919 for ; Tue, 24 Jul 2001 19:38:00 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id QAA19264; Tue, 24 Jul 2001 16:37:46 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 16:37:45 -0700 Message-ID: From: Robert Snively To: "'Eddy Quicksall'" , Michael Schoberg , ips@ece.cmu.edu Subject: RE: iSCSI draft-07 Padding Date: Tue, 24 Jul 2001 16:37:44 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk The burst of data (sequence in FCP-2, I assume a PDU in iSCSI) carrying the last byte (as defined by the highest displacement of the SCSI data pointer) may be padded by 0,1,2,or 3 bytes to bring the last PDU to a 4-byte transfer boundary. The number of bytes padded is included in the last transfer header, so they can be ignored and not passed to memory in an automated manner. Bob -----Original Message----- From: Eddy Quicksall [mailto:ESQuicksall@hotmail.com] Sent: Tuesday, July 24, 2001 10:30 AM To: Michael Schoberg; ips@ece.cmu.edu Subject: Re: iSCSI draft-07 Padding What does a Fibre Channel driver do when the ULP wants to receive data into memory which is not a multiple of 4 bytes long? Eddy ----- Original Message ----- From: "Michael Schoberg" To: Sent: Tuesday, July 24, 2001 11:13 AM Subject: RE: iSCSI draft-07 Padding > Yes, at the very least the spec should not allow padding on intermediate > ReadData/WriteData bursts. I can't think of a reason why one would want to > use odd length intermediate bursts, so hopefully it's safe to restrict it. > Padding the last burst still seems reasonable for easy CRC calculation. > > Setting a fixed size is optional. A minimum would avoid memory > fragmentation when working with memory descriptors. > > : -----Original Message----- > : From: Robert Snively [mailto:rsnively@Brocade.COM] > : Sent: Tuesday, July 24, 2001 8:34 AM > : To: ips@ece.cmu.edu > : Subject: RE: iSCSI draft-07 Padding > : > : > : Fibre Channel's approach to this problem is to prohibit padding > : for all transfers except the transfer that moves the last bytes > : in the last (or highest pointer value) burst of data. Intermediate > : bursts are required to end on 4-byte boundaries, regardless of > : tranfer order as allowed by EMDP. > : > : Bob > : > : ----- Original Message ----- > : From: "Michael Schoberg" > : To: > : Sent: Friday, July 20, 2001 4:27 PM > : Subject: iSCSI draft-07 Padding > : > : > : > I couldn't find anything in the latest iSCSI spec > : (draft-07) that prevents > : > someone from issuing multiple padded PDU's for iSCSI Data > : In/Out segments. > : > I guess I'm worried that someone could issue padded > : odd-length write/read > : > data when it wasn't necessary. Example: When moving a 512 byte disk > : sector > : > an initiator/target could legally issue 512 1-byte DataSegmentLength > : > messages (each padded up to a 32-bit boundary). This isn't > : the sort of > : data > : > stream one would expect, but it's allowed in the draft. > : > > : > This also leads into whether fixed or minimum length data > : segments (for > : all > : > but the last) would be nice to include as part of the spec. > : It may result > : > in a simpler software/hardware design. > : > > : > From owner-ips@ece.cmu.edu Wed Jul 25 04:17:21 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04277 for ; Wed, 25 Jul 2001 04:17:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P6hDm22114 for ips-outgoing; Wed, 25 Jul 2001 02:43:13 -0400 (EDT) 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 f6P6hB222109 for ; Wed, 25 Jul 2001 02:43:11 -0400 (EDT) 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 IAA218384 for ; Wed, 25 Jul 2001 08:43:04 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6P6h3B75842 for ; Wed, 25 Jul 2001 08:43:03 +0200 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 25 Jul 2001 09:49:10 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 25/07/2001 09:43:03 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I understood what you are asking but I don't necessarily agree. Operational parameters are problematic if you want them exchanged in a secure environment. If not you should be able to handle them as you should be able to handle any set of parameters on the same PDU. The need to keep them and perhaps reset them is part of the negotiation process. Julo "Eddy Quicksall" on 24-07-2001 20:35:18 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters What I was actually asking for is that the target would not send any operational parameters in the same PDU as the SecurityContextComplete. Rationalization given below. Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Tuesday, July 24, 2001 10:08 AM Subject: Re: iSCSI: SecurityContextComplete without operational parameters > the new text will read: > > If the initiator has been the last to complete the handshake it MUST > NOT start sending operational parameters that need to be protected > within the same text command; a text response including only > SecurityContextComplete=yes concludes the security sub-phase. Only > the following PDU exchange is protected by digests (if any). > > If the target has been the last to complete the handshake, the initiator > can start the operational parameter negotiation with the next text command; > the security negotiation sub-phase ends with the target text response. > However, the target handshake concluding response MUST NOT include > operational parameters that need to be protected. Only the following PDU > exchange is protected by digests (if any). > > Julo > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be best > if the target is required to send SecurityContextComplete=yes without any > new operational parameters within the same PDU. > > It makes coding cleaner because the initiator can have a simple > send/receive > loop that pops out when security is complete. If operational parameters are > allowed with SecurityContextComplete=yes, the initiator's security module > must also have operational parameter code or it must set flags, leave > information in buffers, etc that all create messy code. > > The spec says: > > If the initiator has been the last to complete the handshake it > MUST NOT start sending operational parameters within the same > text command. > > How about if we say the same thing for the target? There shouldn't be any > harm because I suspect everyone is doing that anyway. > > Comments? > > > Eddy_Quicksall@iVivity.com > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 04:17:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04294 for ; Wed, 25 Jul 2001 04:17:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6P6wvi22749 for ips-outgoing; Wed, 25 Jul 2001 02:58:57 -0400 (EDT) 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 f6P6wu222744 for ; Wed, 25 Jul 2001 02:58:56 -0400 (EDT) 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 IAA258244 for ; Wed, 25 Jul 2001 08:58:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6P6win218862 for ; Wed, 25 Jul 2001 08:58:45 +0200 Importance: Normal Subject: iSCSI session types To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 25 Jul 2001 10:04:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 25/07/2001 09:58:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim Hafner convinced me that - except for Discovery all the other session-types can be implemented by just using different target (and initiator) names. If there is no strong objection I will take out the boot & copymanager session types. Julo From owner-ips@ece.cmu.edu Wed Jul 25 09:23:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20093 for ; Wed, 25 Jul 2001 09:23:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PBvwU16163 for ips-outgoing; Wed, 25 Jul 2001 07:57:58 -0400 (EDT) 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 f6PBvu216158 for ; Wed, 25 Jul 2001 07:57:56 -0400 (EDT) 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 NAA163470 for ; Wed, 25 Jul 2001 13:57:46 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6PBvjB52778 for ; Wed, 25 Jul 2001 13:57:45 +0200 Importance: Normal Subject: Re: TargetAlias/InitiatorAlias text commands To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Wed, 25 Jul 2001 15:03:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 25/07/2001 14:57:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie & Jim, This artifact (the Alias keys) where introduced at the express request of the NDT. Why don't you come (came) with a similar consensus recommendation to remove them and resort to the IPS list at large? Is this the NDT consensus and you have just forgot to mention it? Julo ---------------------- Forwarded by Julian Satran/Haifa/IBM on 25-07-2001 14:59 --------------------------- "Jim Hafner" on 25-07-2001 00:03:35 Please respond to "Jim Hafner" To: ips@ece.cmu.edu cc: Subject: Re: TargetAlias/InitiatorAlias text commands Marj, I concur. I don't see any value in these keys either, at least within the protocol. Jim Hafner "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 07-24-2001 01:38:35 PM Sent by: owner-ips@ece.cmu.edu To: "Ips Reflector (E-mail)" cc: Subject: TargetAlias/InitiatorAlias text commands As outlined in David Black's consensus statement on the SendTargets command (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target records returned in response to a SendTargets request will not include TargetAlias, in response to the expressed desire to limit the SendTargets functionality to the basic description of the target iSCSI device. There are references to "aliases" sprinkled throughout the iSCSI protocol document, but this construct doesn't add any value to the iSCSI protocol model or functionality. Since the TargetAlias and InitiatorAlias text commands do not contribute any functionality to the iSCSI protocol, are not used in any iSCSI-related logic within an implementation, and are basicly a "label" more appropriately administered by a management tool, I propose they be removed from the iSCSI protocol spec. Comments? 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 "KRUEGER,MARJORIE (HP-Roseville,ex1)" on 24-07-2001 23:38:35 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "Ips Reflector (E-mail)" cc: Subject: TargetAlias/InitiatorAlias text commands As outlined in David Black's consensus statement on the SendTargets command (http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05119.html), the target records returned in response to a SendTargets request will not include TargetAlias, in response to the expressed desire to limit the SendTargets functionality to the basic description of the target iSCSI device. There are references to "aliases" sprinkled throughout the iSCSI protocol document, but this construct doesn't add any value to the iSCSI protocol model or functionality. Since the TargetAlias and InitiatorAlias text commands do not contribute any functionality to the iSCSI protocol, are not used in any iSCSI-related logic within an implementation, and are basicly a "label" more appropriately administered by a management tool, I propose they be removed from the iSCSI protocol spec. Comments? 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 Wed Jul 25 13:54:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16754 for ; Wed, 25 Jul 2001 13:54:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PGS9G00846 for ips-outgoing; Wed, 25 Jul 2001 12:28:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PGS7200842 for ; Wed, 25 Jul 2001 12:28:07 -0400 (EDT) Received: from cs.uchicago.edu (h005018030f43.ne.mediaone.net [24.91.87.148]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f6PGAZZ11496; Wed, 25 Jul 2001 12:10:36 -0400 (EDT) Message-Id: <200107251610.f6PGAZZ11496@chmls06.mediaone.net> To: "Jim Hafner" cc: ips@ece.cmu.edu Subject: Re: iSCSI: AccessID text key In-Reply-To: Message from "Jim Hafner" of "Tue, 24 Jul 2001 10:48:07 PDT." References: Date: Wed, 25 Jul 2001 12:09:50 -0400 From: Stephen Bailey Sender: owner-ips@ece.cmu.edu Precedence: bulk > I would like to ask that the AccessID text key be deleted from the list of > supported/required keys. > > Comments? Works for me. I'd had my doubts about it too. Steph From owner-ips@ece.cmu.edu Wed Jul 25 14:01:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17469 for ; Wed, 25 Jul 2001 14:01:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PGhLA01880 for ips-outgoing; Wed, 25 Jul 2001 12:43:21 -0400 (EDT) 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 f6PGhJ201866 for ; Wed, 25 Jul 2001 12:43:20 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA09824; Wed, 25 Jul 2001 11:59:03 -0400 (EDT) Message-ID: <3B5EEB73.3F7878A@cisco.com> Date: Wed, 25 Jul 2001 10:53:23 -0500 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: Jim Hafner CC: ips@ece.cmu.edu Subject: Re: iSCSI: Status'es (clause 2.11.6) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim- Comments are below. -- Mark Jim Hafner wrote: > > Folks, > > I have some questions, recommendations and editorial comments about the > status codes for iSCSI in clause 2.11.6. > > Proxy Required is defined as the response when "the initiator must use an > ISCSI proxy for this target". But that isn't defined anywhere in the > document, so I recommend deleting this status code. We should define this, then. If a target is accessible only through an iSCSI proxy, perhaps for security purposes, an initiator attempting to log in to it directly should get an error. If the target is aware of the proxy, it can return the proxy's address in this type of redirect response. This is similar to what was done in HTTP/1.1. Although this status code likely won't be used right away, it does have utility long-term when we start building larger storage networks with this stuff. I still don't believe that all iSCSI devices will provide all of their own security code; other devices may have to provide this on their behalf, which was why we had added iSCSI proxy capabilities in the first place. > What's the functional difference between the following: "Security > negotiation failed" and "Forbidden Target"? In both cases, the initiator > doesn't get to use what it thinks is there. I would think that "Forbidden > Target" might be a security leak as it admits the fact that the target is > there, whereas if the initiator only got back failed security, that > admission wouldn't be made. Security Negotiation Failed means that the initiator could not be successfully authenticated. Forbidden Target means that the initiator was authenticated, but is not authorized to access the target. These are two different reasons for an initiator not to be able to get to a target, and would more useful to someone configuring an initiator than simply returning "not found". Keep in mind that when returning Forbidden Target, the initiator has been authenticated, so it's likely to be somewhere within the realm of things that the target trusts. If the target wants to be more tight-lipped about this one, it could certainly return "Not Found" instead. This adds a bit more security at the expense of making it easier to troubleshoot a mis-configured initiator. The names for these two status codes are perhaps a bit clumsy; perhaps renaming them will help. How about: Authentication Failure instead of Security Negotiation Failed and Authorization Failure instead of Forbidden Target? > "Target Conflict" and "Service Unavailable" both look more like > "insufficient resources". In particular, "Target Conflict" should not be > limited to a response in the 1->2 or more initiators case but in the n->n+1 > initiators case. That is, if the target has resources for 'n' logins, it > can reject another login with "insufficient resources", whether n=1 or > n=10. So, I'd suggest that "insufficient resources" is a better catch-all > for both of these cases. We had this discussion on the list a long time ago. Target Conflict is the initiator's problem; it should not be asking to connect to a target that someone else is using (assuming it supports only one initiator at a time). Service Unavailable is the target's problem; it is used when the target is not working at all. > We need to clarify the "Session already open" to include language that says > "with this initiator to this target portal group". Agree. > The sentence immediately after the table says that "accept" means the > initiator may proceed to issue SCSI commands. This is only true in a > Normal session type and is not true for the Discovery session type. This > should be clarified. Agree here, too. > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 25 14:42:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21784 for ; Wed, 25 Jul 2001 14:42:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PHkHu05857 for ips-outgoing; Wed, 25 Jul 2001 13:46:17 -0400 (EDT) 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 f6PHkF205847 for ; Wed, 25 Jul 2001 13:46:15 -0400 (EDT) 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 TAA328620 for ; Wed, 25 Jul 2001 19:46:09 +0200 Received: from d12hubm3.de.ibm.com (d12hubm3_tr0 [9.165.255.246]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6PHk8n172494 for ; Wed, 25 Jul 2001 19:46:09 +0200 Importance: Normal Subject: Re: iSCSI Plugfest at UNH (misc issues) To: Sandeep Joshi Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Julian_Satran/Haifa/IBM%IBMIL Date: Wed, 25 Jul 2001 20:51:05 +0300 X-MIMETrack: Serialize by Router on D12HUBM3/12/H/IBM(Release 5.0.6 |December 14, 2000) at 25/07/2001 19:50:08 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The case arises with a well behaved target and the question was meant to show only that the test is not trivial and can't be based on numbers alone - although I assumed that any good initiator will mark acked commands and might show its displeasure receiving status from an unacked command (it MUST be acked at least with the status). I think that the clarification I sent out will solve your problem. Julo Sandeep Joshi on 25-07-2001 18:07:52 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: Re: iSCSI Plugfest at UNH (misc issues) thanks to all for the clarifications on ITT usage. Matt & Julian, to answer your comments on expCmdSN.. > Until you identify the problem, I don't want any more "tests" mandated. The initiator balked somewhere in retry/timeout processing or garbage collection or some state assertion. I'll have to tinker under the hood to find more, but it did not seem correct to get status for something which had not been acknowledged as delivered. > The iSCSI standard says that once SCSI commands get put into the task queue, > the CmdSN no longer associated with the command. The initiator is NOT > supposed to associate commands with responses based on the CmdSN or ExpCmdSN. Enlighten me here....to retry a command, doesnt one need to know the original cmdSN of a command (Sec 7.1) ? The initiator is not associating responses with cmdSN but it does know the original cmdSN for each task. > +++ > > Interesting proposal. Has some academic weaknesses however. We assume that > CmdSN has no significance after delivery. > Assume that you have a good target and a very long lived command - outlives > a wrap around of CmdSN! > How would you distinguish the status of this command carying a low ExpCmdSN > from your case? I did not understand how this case could arise, assuming that comparisons occur in the sequence space (RFC1982) and (maxCmdSN-expCmdSN < 2^31) -Sandeep > 2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the expCmdSN ? > Clearly, the target has received and executed the commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which response > is being received). > > This seems like a valid property which could be mandated > and checked, to allow efficient initiator implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) > > +++ > > Interesting proposal. Has some academic weaknesses however. We assume that > CmdSN has no significance after delivery. > Assume that you have a good target and a very long lived command - outlives > a wrap around of CmdSN! > > How would you distinguish the status of this command carying a low ExpCmdSN > from your case? > > I will change the following in 1.2.2.1 > > - CmdSN - the current command Sequence Number advanced by 1 on each > command shipped except for commands marked for immediate delivery. > - ExpCmdSN - the next expected command by the target. The target > acknowledges all commands up to but not including this number and the > initiator has to mark the acknowledged commands as such as soon as a > PDU with the corresponding ExpCmdSN is received. The target iSCSI > layer sets the ExpCmdSN to the largest non-immediate CmdSN that it is > able to deliver for execution plus 1 (no holes in the CmdSN > sequence). > - MaxCmdSN - the maximum number to be shipped. The queuing capacity > of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. > > And later - at the end of 1.2.2.1 > > A target MUST NOT issue a command response or DATA-In PDU with status > before acknowledging the command. > > As with many other initiator deteced errors - the initiator has to decide > what to do with such an error (logout, rest etc.) > > ++++ > From owner-ips@ece.cmu.edu Wed Jul 25 14:46:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22110 for ; Wed, 25 Jul 2001 14:46:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PHWvG05006 for ips-outgoing; Wed, 25 Jul 2001 13:32:57 -0400 (EDT) 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 f6PHWu205002 for ; Wed, 25 Jul 2001 13:32:56 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA10093; Wed, 25 Jul 2001 13:32:47 -0400 (EDT) Message-ID: <3B5F016B.5D92777E@cisco.com> Date: Wed, 25 Jul 2001 12:27:07 -0500 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: Jim Hafner CC: ips@ece.cmu.edu Subject: Re: iSCSI: Draft-07, URL and names/addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim- You're right; I don't think we need the URL stuff anymore, and we don't specify iSCSI names and addresses in the same string in iSCSI anymore. If there are no strong objections, I'll remove the section you mentioned. The iSCSI name examples in the section still apply. Should we keep them, throw them, or move them to an appendix with the other examples? -- Mark Jim Hafner wrote: > > Folks, > > The current draft (07) specifies different ways that iSCSI names and > addresses are to be used: > > a) Within the protocol useage itself is the InitiatorName (or TargeName) > keys used in Login and in the context of SendTargets along with > TargetAddress. > > b) Section 1.2.7 describes formatting of these names and addresses as URLs. > These URLs are never used within the context of the protocol. Such a > format *might* be used in a GUI or some other application but specifying > how is beyond the scope of this standard. > > Consequently, to avoid confusion with name/address formats, I suggest that > the text that begins in 1.2.7 paragraph 6 with > "The iSCSI Name is incorporated as part of the address. An iSCSI > address is specified as a URL, such as:... > and up to but not including the paragraph that starts: > "To assist..." > be deleted. It might be replaced with a reference to the SendTargets > Appendix where names and addresses are formatted within the protocol. > > Comments? > > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 25 14:47:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22191 for ; Wed, 25 Jul 2001 14:47:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PI7fZ07293 for ips-outgoing; Wed, 25 Jul 2001 14:07:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PI7d207289 for ; Wed, 25 Jul 2001 14:07:39 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id OAA22765; Wed, 25 Jul 2001 14:07:26 -0400 (EDT) Date: Wed, 25 Jul 2001 14:07:26 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: I think this exchange between you and Eddy illustrates the fundamental problem with login that everyone at the plugfest realized: the login process is too complex, we need to simplify it. Eddy was asking for a simplification -- that operational parameters NOT be sent with SCC=yes. The change you made does not do that, and the response you gave below "If not you should be able to handle them as you should be able to handle any set of parameters on the same PDU." illustrates to me that you do not understand the problem, which is that login is too complex "to handle any set of parameters on the same PDU". The combinations and misinterpretations of these combinations are horrendous. It needs to be simplified, and that is what Eddy is asking -- do NOT allow these arbitrary combinations. In the rewording you added the phrase "that need to be protected" in two places. Please remove that phrase from both places, because it defeats the whole purpose of the change and introduces more ambiguity -- who decides what needs to be protected and what doesn't? Suppose the target decides one thing and the initiator the other? Where is the defined list of parameters that "need" to be protected and those that do not "need" to be protected. etc. A big simplification is one requested a long time back by Barry Reinhold and recently reiterated in a new request by Rod Harrison of Wind River, which I strongly support, to mandate that the login PDU MUST only contain security parameters -- no operational parameters. Then the login MUST ALWAYS start with the security subphase, and MUST end with a handshake of messages that contained ONLY SecurityContextComplete from both target and initiator. Only then would the operational parameter negotiation start. I would also add to this recommendation that for normal logins (as opposed to discovery logins) the login MUST ALWAYS contain the TargetName and InitiatorName keys too. Furthermore, if the SessionType parameter is offered, it MUST be offered on the login. These changes would also clean up the wording in the standard, because: 1. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the new OpParmReset key (there is no way they could have changed). 2. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the wording in 4.3 that talks about "Operational parameters negotiated inadvertently before the security/integrity negotiation" (a standard really shouldn't be allowing "inadvertent" things to happen). 3. The discussion in 4.1 about the TargetName and InitiatorName would be considerably simplified, since there would be no need for phrases like "If the iSCSI Target Name is going to be used in determining the security mode or it is implicit part of authentication," because it should just ALWAYS be sent. Phrases like the one just quoted cause enormous interoperability problems, because they introduce ambiguity that different implementers can resolve in different ways (who determines if the TargetName is going to be used? How? Who determines if it is implicit? How? etc.) I believe these suggestions, most of which have been made before, would simplify the login process. This is done by placing restrictions on what can be done when. It may involve the exchange of a few extra PDUs (ie. the text commands containing only SecurityContectComplete=yes), but logins are not part of the critical fast path and are not under tight time constraints -- it is more important that they be correct, unambiguous and easily interoperable than that they be superfast. Thank you, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 25 Jul 2001, Julian Satran wrote: > Eddy, > > I understood what you are asking but I don't necessarily agree. Operational > parameters are problematic if you want them exchanged in a secure > environment. If not you should be able to handle them as you should be able > to handle > any set of parameters on the same PDU. The need to keep them and perhaps > reset them is part of the negotiation process. > > Julo > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > What I was actually asking for is that the target would not send any > operational parameters in the same PDU as the SecurityContextComplete. > Rationalization given below. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, July 24, 2001 10:08 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > the new text will read: > > > > If the initiator has been the last to complete the handshake it > MUST > > NOT start sending operational parameters that need to be protected > > within the same text command; a text response including only > > SecurityContextComplete=yes concludes the security sub-phase. Only > > the following PDU exchange is protected by digests (if any). > > > > If the target has been the last to complete the handshake, the initiator > > can start the operational parameter negotiation with the next text > command; > > the security negotiation sub-phase ends with the target text response. > > However, the target handshake concluding response MUST NOT include > > operational parameters that need to be protected. Only the following PDU > > exchange is protected by digests (if any). > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > best > > if the target is required to send SecurityContextComplete=yes without any > > new operational parameters within the same PDU. > > > > It makes coding cleaner because the initiator can have a simple > > send/receive > > loop that pops out when security is complete. If operational parameters > are > > allowed with SecurityContextComplete=yes, the initiator's security module > > must also have operational parameter code or it must set flags, leave > > information in buffers, etc that all create messy code. > > > > The spec says: > > > > If the initiator has been the last to complete the handshake > it > > MUST NOT start sending operational parameters within the same > > text command. > > > > How about if we say the same thing for the target? There shouldn't be any > > harm because I suspect everyone is doing that anyway. > > > > Comments? > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 14:47:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22188 for ; Wed, 25 Jul 2001 14:47:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PIIbt07954 for ips-outgoing; Wed, 25 Jul 2001 14:18:37 -0400 (EDT) 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 f6PIIZ207948 for ; Wed, 25 Jul 2001 14:18:35 -0400 (EDT) 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 OAA16776 for ; Wed, 25 Jul 2001 14:10:29 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6PIIXB180730 for ; Wed, 25 Jul 2001 12:18:33 -0600 Importance: Normal Subject: Re: iSCSI: Status'es (clause 2.11.6) To: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 25 Jul 2001 11:18:30 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/25/2001 11:18:33 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Comments in line. But for closure on some things and to tagged the still open issues, I'll summarize my comments. There are three independent issues (and a few minor ones I'll skip): 1) Proxy Required - I think this is just a placeholder and need not be there -- save it for generation 2 (still open). 2) Security Negotiation Failed and Forbidden Target - thanks for the clarification, I think I like the name changes (closed) 3) Target Conflict - what about "n->n+1" -- we have no status code for that. I suggest alternate names for this and that it cover not just the 1->2 problem but the n->n+1 (still open). All other issues are agreed. Jim Hafner Mark Bakke @ece.cmu.edu on 07-25-2001 08:53:23 AM Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: Status'es (clause 2.11.6) Jim- Comments are below. -- Mark Jim Hafner wrote: > > Folks, > > I have some questions, recommendations and editorial comments about the > status codes for iSCSI in clause 2.11.6. > > Proxy Required is defined as the response when "the initiator must use an > ISCSI proxy for this target". But that isn't defined anywhere in the > document, so I recommend deleting this status code. We should define this, then. If a target is accessible only through an iSCSI proxy, perhaps for security purposes, an initiator attempting to log in to it directly should get an error. If the target is aware of the proxy, it can return the proxy's address in this type of redirect response. This is similar to what was done in HTTP/1.1. If the target is aware of this (undefined) thing, then a simple redirect would suffice and we don't need the status code. If the target is not aware, then how can it know to return this status code? Does it just know that there should be one but doesn't know the address? How can it know whether to accept the login from any old initiator vs the initiator that lives in the proxy? It will be configured (I assume) to allow login by the proxy and reject all other logins. It doesn't really help the initiator to get back "can't login in here, use a proxy but it's up to you (the initiator) to find the right address". Until we define this, I strongly suggest we take it out the status code -- it adds no value to the protocol. We can't have placeholders for things that are undefined (except perhaps reserved values or keywords). You clearly have an idea in your mind of what an iSCSI Proxy is, but I searched for "proxy" in the document and the ONLY occurrances are in this clause. My suggestion then is (a) take it out for now (and reserve the code value) and (b) table the whole definition/description/model, etc for an iSCSI proxy is to "iSCSI-the sequel". I expect that this will be a complex issue (as I've hinted at above), and I don't want it to delay this draft. Although this status code likely won't be used right away, it does have utility long-term when we start building larger storage networks with this stuff. I still don't believe that all iSCSI devices will provide all of their own security code; other devices may have to provide this on their behalf, which was why we had added iSCSI proxy capabilities in the first place. This is yet to be proven and in the meantime, we don't need the placeholder. > What's the functional difference between the following: "Security > negotiation failed" and "Forbidden Target"? In both cases, the initiator > doesn't get to use what it thinks is there. I would think that "Forbidden > Target" might be a security leak as it admits the fact that the target is > there, whereas if the initiator only got back failed security, that > admission wouldn't be made. Security Negotiation Failed means that the initiator could not be successfully authenticated. Forbidden Target means that the initiator was authenticated, but is not authorized to access the target. These are two different reasons for an initiator not to be able to get to a target, and would more useful to someone configuring an initiator than simply returning "not found". Keep in mind that when returning Forbidden Target, the initiator has been authenticated, so it's likely to be somewhere within the realm of things that the target trusts. If the target wants to be more tight-lipped about this one, it could certainly return "Not Found" instead. This adds a bit more security at the expense of making it easier to troubleshoot a mis-configured initiator. The names for these two status codes are perhaps a bit clumsy; perhaps renaming them will help. How about: Authentication Failure instead of Security Negotiation Failed and Authorization Failure instead of Forbidden Target? Thanks for the explanation. I can live with this; the alternative wording might be more clear. > "Target Conflict" and "Service Unavailable" both look more like > "insufficient resources". In particular, "Target Conflict" should not be > limited to a response in the 1->2 or more initiators case but in the n->n+1 > initiators case. That is, if the target has resources for 'n' logins, it > can reject another login with "insufficient resources", whether n=1 or > n=10. So, I'd suggest that "insufficient resources" is a better catch-all > for both of these cases. We had this discussion on the list a long time ago. Target Conflict is the initiator's problem; it should not be asking to connect to a target that someone else is using (assuming it supports only one initiator at a time). Service Unavailable is the target's problem; it is used when the target is not working at all. Apologies if I didn't follow or absorb all of that previous thread. I can see the subtle difference between Target Conflict and Service Unavailable. But what do we do if the target supports "n" logins (only) and an "n+1" guy tries to login? We have no status code for that. I also don't see how the name "Target Conflict" carries the meaning you want. I would suggest "Insufficient Login Resources" or "Target In Use" and use this for anytime the target can't support an additional login (either from 1 to 2 or from n to n+1). > We need to clarify the "Session already open" to include language that says > "with this initiator to this target portal group". Agree. > The sentence immediately after the table says that "accept" means the > initiator may proceed to issue SCSI commands. This is only true in a > Normal session type and is not true for the Discovery session type. This > should be clarified. Agree here, too. > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Jul 25 14:48:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22399 for ; Wed, 25 Jul 2001 14:48:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PIMf808219 for ips-outgoing; Wed, 25 Jul 2001 14:22:41 -0400 (EDT) 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 f6PIMc208214 for ; Wed, 25 Jul 2001 14:22:38 -0400 (EDT) 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 OAA28924; Wed, 25 Jul 2001 14:14:28 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6PIMBB224472; Wed, 25 Jul 2001 12:22:11 -0600 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: "Robert D. Russell" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 25 Jul 2001 11:22:09 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/25/2001 11:22:10 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rob, It sounds to me like another way to interpret what you're suggesting is to have two classes of Keys: Login keys (security + names, etc) and Text message keys (operational). Is that a valid separation? Jim Hafner "Robert D. Russell" @ece.cmu.edu on 07-25-2001 11:07:26 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters Julian: I think this exchange between you and Eddy illustrates the fundamental problem with login that everyone at the plugfest realized: the login process is too complex, we need to simplify it. Eddy was asking for a simplification -- that operational parameters NOT be sent with SCC=yes. The change you made does not do that, and the response you gave below "If not you should be able to handle them as you should be able to handle any set of parameters on the same PDU." illustrates to me that you do not understand the problem, which is that login is too complex "to handle any set of parameters on the same PDU". The combinations and misinterpretations of these combinations are horrendous. It needs to be simplified, and that is what Eddy is asking -- do NOT allow these arbitrary combinations. In the rewording you added the phrase "that need to be protected" in two places. Please remove that phrase from both places, because it defeats the whole purpose of the change and introduces more ambiguity -- who decides what needs to be protected and what doesn't? Suppose the target decides one thing and the initiator the other? Where is the defined list of parameters that "need" to be protected and those that do not "need" to be protected. etc. A big simplification is one requested a long time back by Barry Reinhold and recently reiterated in a new request by Rod Harrison of Wind River, which I strongly support, to mandate that the login PDU MUST only contain security parameters -- no operational parameters. Then the login MUST ALWAYS start with the security subphase, and MUST end with a handshake of messages that contained ONLY SecurityContextComplete from both target and initiator. Only then would the operational parameter negotiation start. I would also add to this recommendation that for normal logins (as opposed to discovery logins) the login MUST ALWAYS contain the TargetName and InitiatorName keys too. Furthermore, if the SessionType parameter is offered, it MUST be offered on the login. These changes would also clean up the wording in the standard, because: 1. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the new OpParmReset key (there is no way they could have changed). 2. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the wording in 4.3 that talks about "Operational parameters negotiated inadvertently before the security/integrity negotiation" (a standard really shouldn't be allowing "inadvertent" things to happen). 3. The discussion in 4.1 about the TargetName and InitiatorName would be considerably simplified, since there would be no need for phrases like "If the iSCSI Target Name is going to be used in determining the security mode or it is implicit part of authentication," because it should just ALWAYS be sent. Phrases like the one just quoted cause enormous interoperability problems, because they introduce ambiguity that different implementers can resolve in different ways (who determines if the TargetName is going to be used? How? Who determines if it is implicit? How? etc.) I believe these suggestions, most of which have been made before, would simplify the login process. This is done by placing restrictions on what can be done when. It may involve the exchange of a few extra PDUs (ie. the text commands containing only SecurityContectComplete=yes), but logins are not part of the critical fast path and are not under tight time constraints -- it is more important that they be correct, unambiguous and easily interoperable than that they be superfast. Thank you, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 25 Jul 2001, Julian Satran wrote: > Eddy, > > I understood what you are asking but I don't necessarily agree. Operational > parameters are problematic if you want them exchanged in a secure > environment. If not you should be able to handle them as you should be able > to handle > any set of parameters on the same PDU. The need to keep them and perhaps > reset them is part of the negotiation process. > > Julo > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > What I was actually asking for is that the target would not send any > operational parameters in the same PDU as the SecurityContextComplete. > Rationalization given below. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, July 24, 2001 10:08 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > the new text will read: > > > > If the initiator has been the last to complete the handshake it > MUST > > NOT start sending operational parameters that need to be protected > > within the same text command; a text response including only > > SecurityContextComplete=yes concludes the security sub-phase. Only > > the following PDU exchange is protected by digests (if any). > > > > If the target has been the last to complete the handshake, the initiator > > can start the operational parameter negotiation with the next text > command; > > the security negotiation sub-phase ends with the target text response. > > However, the target handshake concluding response MUST NOT include > > operational parameters that need to be protected. Only the following PDU > > exchange is protected by digests (if any). > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > best > > if the target is required to send SecurityContextComplete=yes without any > > new operational parameters within the same PDU. > > > > It makes coding cleaner because the initiator can have a simple > > send/receive > > loop that pops out when security is complete. If operational parameters > are > > allowed with SecurityContextComplete=yes, the initiator's security module > > must also have operational parameter code or it must set flags, leave > > information in buffers, etc that all create messy code. > > > > The spec says: > > > > If the initiator has been the last to complete the handshake > it > > MUST NOT start sending operational parameters within the same > > text command. > > > > How about if we say the same thing for the target? There shouldn't be any > > harm because I suspect everyone is doing that anyway. > > > > Comments? > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 14:48:14 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22419 for ; Wed, 25 Jul 2001 14:48:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PHM1u04381 for ips-outgoing; Wed, 25 Jul 2001 13:22:01 -0400 (EDT) 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 f6PHM0204377 for ; Wed, 25 Jul 2001 13:22:00 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Wed Jul 25 11:07:55 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Jul 25 11:08:17 EDT 2001 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 LAA13821 for ; Wed, 25 Jul 2001 11:07:52 -0400 (EDT) Message-ID: <3B5EE0C8.630BB644@research.bell-labs.com> Date: Wed, 25 Jul 2001 11:07:52 -0400 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 Plugfest at UNH (misc issues) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit thanks to all for the clarifications on ITT usage. Matt & Julian, to answer your comments on expCmdSN.. > Until you identify the problem, I don't want any more "tests" mandated. The initiator balked somewhere in retry/timeout processing or garbage collection or some state assertion. I'll have to tinker under the hood to find more, but it did not seem correct to get status for something which had not been acknowledged as delivered. > The iSCSI standard says that once SCSI commands get put into the task queue, > the CmdSN no longer associated with the command. The initiator is NOT > supposed to associate commands with responses based on the CmdSN or ExpCmdSN. Enlighten me here....to retry a command, doesnt one need to know the original cmdSN of a command (Sec 7.1) ? The initiator is not associating responses with cmdSN but it does know the original cmdSN for each task. > +++ > > Interesting proposal. Has some academic weaknesses however. We assume that > CmdSN has no significance after delivery. > Assume that you have a good target and a very long lived command - outlives > a wrap around of CmdSN! > How would you distinguish the status of this command carying a low ExpCmdSN > from your case? I did not understand how this case could arise, assuming that comparisons occur in the sequence space (RFC1982) and (maxCmdSN-expCmdSN < 2^31) -Sandeep > 2) ExpCmdSN > What are the semantics of something like this.. the > target does not increase the expCmdSN but keeps sending > the status (SCSI response) for commands after the expCmdSN ? > Clearly, the target has received and executed the commands > (in cmdSN order). > > Hence, the expCmdSN in a SCSI response must not be less > than the cmdSN of the original command (for which response > is being received). > > This seems like a valid property which could be mandated > and checked, to allow efficient initiator implementations. > The target eventually suffers but the standard could > prevent such targets from being deployed :-) > > +++ > > Interesting proposal. Has some academic weaknesses however. We assume that > CmdSN has no significance after delivery. > Assume that you have a good target and a very long lived command - outlives > a wrap around of CmdSN! > > How would you distinguish the status of this command carying a low ExpCmdSN > from your case? > > I will change the following in 1.2.2.1 > > - CmdSN - the current command Sequence Number advanced by 1 on each > command shipped except for commands marked for immediate delivery. > - ExpCmdSN - the next expected command by the target. The target > acknowledges all commands up to but not including this number and the > initiator has to mark the acknowledged commands as such as soon as a > PDU with the corresponding ExpCmdSN is received. The target iSCSI > layer sets the ExpCmdSN to the largest non-immediate CmdSN that it is > able to deliver for execution plus 1 (no holes in the CmdSN > sequence). > - MaxCmdSN - the maximum number to be shipped. The queuing capacity > of the receiving iSCSI layer is MaxCmdSN - ExpCmdSN + 1. > > And later - at the end of 1.2.2.1 > > A target MUST NOT issue a command response or DATA-In PDU with status > before acknowledging the command. > > As with many other initiator deteced errors - the initiator has to decide > what to do with such an error (logout, rest etc.) > > ++++ > From owner-ips@ece.cmu.edu Wed Jul 25 14:48:24 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22463 for ; Wed, 25 Jul 2001 14:48:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PIK2308028 for ips-outgoing; Wed, 25 Jul 2001 14:20:02 -0400 (EDT) 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 f6PIK1208022 for ; Wed, 25 Jul 2001 14:20:01 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Jul 25 14:19:38 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Wed Jul 25 14:20:06 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id OAA25967 for ips@ece.cmu.edu; Wed, 25 Jul 2001 14:19:35 -0400 (EDT) Date: Wed, 25 Jul 2001 14:19:35 -0400 (EDT) Message-Id: <200107251819.OAA25967@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: Re: iSCSI: ImmediateData Sender: owner-ips@ece.cmu.edu Precedence: bulk One could tweak the advertised queue size (max-expCmdSN) if the target does not have enuf memory. It would avoid the R2T delay on every command. -Sandeep > [ Attached is an exchange with Julian mid-last week. ] > > Julian, > > I once again recommend that the default for ImmediateData > be "no". I would argue that the most simple case should be > enabled by default - just what we did for InitialR2T - > not the one that demands more memory for unsolicited > immediate data. > > Comments? > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > - I realized (during plugfest) that ImmdiateData's default is > "yes". I recommend making it "no", keeping simple-minded targets > in view. This issue is more serious if those simple targets > do not do a lot of text negotiation, when they will be stuck > with having to support a DataPDULength worth of immediate data. > This is also in contrary to the conservative spirit of the default > for InitialR2T (whose default is "yes"). > > Please feel free to take it to ips if you think it's a change that > warrants comments from a wider audience. > > +++ I did not hear any comment from the plugfest on this. > The rational behind it is that simple software implementions benefit the > most out of it > and the default buffer is small ++ > From owner-ips@ece.cmu.edu Wed Jul 25 17:03:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07887 for ; Wed, 25 Jul 2001 17:03:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PJmHA15612 for ips-outgoing; Wed, 25 Jul 2001 15:48:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PJmF215606 for ; Wed, 25 Jul 2001 15:48:15 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA25913; Wed, 25 Jul 2001 15:47:32 -0400 (EDT) Date: Wed, 25 Jul 2001 15:47:32 -0400 From: "Robert D. Russell" To: Jim Hafner cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Jim: We already have the classification of keys into security (given in Appendix A) and operational (given in Appendix D), although a few of the keys in Appendix D (TargetAddress, TargetName, TargetAlias, InitiatorName, InitiatorAlias) are really informational parameters (a third category) since they cannot be negotiated. The problem is the way these are negotiated during login. The simplification most people want is to ALWAYS start a login with a security negotiation subphase that involves NO operational parameter negotiation (the informational parameters are ok). This phase ALWAYS ends with an exchange of messages (a "handshake") containing the key SecurityContextComplete=yes and no other security keys and no operational keys. Only after this exchange should any operational parameters be negotiated in additional messages. If no security is wanted, a login command with F=0 can start the handshake by offering SecurityContextComplete=yes (along with the TargetName= and InitiatorName= keys, which should ALWAYS be required on the login command), and the target can respond with a login response with F=0 and containing only SecurityContextComplete=yes. Then and only then can operational parameters be negotiated. If neither security nor operational parameters need to be negotiated, the login command is as above but with F=1, and the target response as above but with F=1. At that point, both sides are in full feature phase. It is simple and unambiguous. Bob On Wed, 25 Jul 2001, Jim Hafner wrote: > > Rob, > > It sounds to me like another way to interpret what you're suggesting is to > have two classes of Keys: Login keys (security + names, etc) and Text > message keys (operational). > > Is that a valid separation? > > Jim Hafner > > > "Robert D. Russell" @ece.cmu.edu on 07-25-2001 > 11:07:26 AM > > Sent by: owner-ips@ece.cmu.edu > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > Julian: > > I think this exchange between you and Eddy illustrates the fundamental > problem with login that everyone at the plugfest realized: > the login process is too complex, we need to simplify it. > > Eddy was asking for a simplification -- that operational parameters > NOT be sent with SCC=yes. The change you made does not do that, > and the response you gave below "If not you should be able to > handle them as you should be able to handle any set of parameters > on the same PDU." illustrates to me that you do not understand the > problem, which is that login is too complex "to handle any set of > parameters on the same PDU". The combinations and misinterpretations > of these combinations are horrendous. It needs to be simplified, > and that is what Eddy is asking -- do NOT allow these arbitrary > combinations. > > In the rewording you added the phrase "that need to be protected" in > two places. Please remove that phrase from both places, > because it defeats the whole purpose of the change and introduces more > ambiguity -- who decides what needs to be protected and what > doesn't? Suppose the target decides one thing and the initiator the > other? Where is the defined list of parameters that "need" to be > protected and those that do not "need" to be protected. etc. > > A big simplification is one requested a long time back by > Barry Reinhold and recently reiterated in a new request by > Rod Harrison of Wind River, which I strongly support, to mandate > that the login PDU MUST only contain security parameters -- no > operational parameters. Then the login MUST ALWAYS start with > the security subphase, and MUST end with a handshake of messages > that contained ONLY SecurityContextComplete from both target and > initiator. Only then would the operational parameter negotiation > start. I would also add to this recommendation that for normal > logins (as opposed to discovery logins) the login MUST ALWAYS > contain the TargetName and InitiatorName keys too. Furthermore, > if the SessionType parameter is offered, it MUST be offered on > the login. > > These changes would also clean up the wording in the standard, because: > > 1. By prohibiting any operational parameter negotiation before the > security subphase was completed, there would be no need for the > new OpParmReset key (there is no way they could have changed). > > 2. By prohibiting any operational parameter negotiation before the > security subphase was completed, there would be no need for the > wording in 4.3 that talks about "Operational parameters negotiated > inadvertently before the security/integrity negotiation" > (a standard really shouldn't be allowing "inadvertent" things to > happen). > > 3. The discussion in 4.1 about the TargetName and InitiatorName would > be considerably simplified, since there would be no need for > phrases like "If the iSCSI Target Name is going to be used in > determining the security mode or it is implicit part of > authentication," because it should just ALWAYS be sent. > Phrases like the one just quoted cause enormous interoperability > problems, because they introduce ambiguity that different > implementers can resolve in different ways (who determines if > the TargetName is going to be used? How? Who determines if it is > implicit? How? etc.) > > I believe these suggestions, most of which have been made before, > would simplify the login process. This is done by placing restrictions > on what can be done when. It may involve the exchange of a few > extra PDUs (ie. the text commands containing only > SecurityContectComplete=yes), but logins are not part of the critical > fast path and are not under tight time constraints -- it is more > important that they be correct, unambiguous and easily interoperable > than that they be superfast. > > Thank you, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > > On Wed, 25 Jul 2001, Julian Satran wrote: > > > Eddy, > > > > I understood what you are asking but I don't necessarily agree. > Operational > > parameters are problematic if you want them exchanged in a secure > > environment. If not you should be able to handle them as you should be > able > > to handle > > any set of parameters on the same PDU. The need to keep them and perhaps > > reset them is part of the negotiation process. > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > > > > What I was actually asking for is that the target would not send any > > operational parameters in the same PDU as the SecurityContextComplete. > > Rationalization given below. > > > > Eddy > > > > ----- Original Message ----- > > From: "Julian Satran" > > To: > > Sent: Tuesday, July 24, 2001 10:08 AM > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > the new text will read: > > > > > > If the initiator has been the last to complete the handshake it > > MUST > > > NOT start sending operational parameters that need to be > protected > > > within the same text command; a text response including only > > > SecurityContextComplete=yes concludes the security sub-phase. > Only > > > the following PDU exchange is protected by digests (if any). > > > > > > If the target has been the last to complete the handshake, the > initiator > > > can start the operational parameter negotiation with the next text > > command; > > > the security negotiation sub-phase ends with the target text response. > > > However, the target handshake concluding response MUST NOT include > > > operational parameters that need to be protected. Only the following > PDU > > > exchange is protected by digests (if any). > > > > > > Julo > > > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > > > Please respond to "Eddy Quicksall" > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > > best > > > if the target is required to send SecurityContextComplete=yes without > any > > > new operational parameters within the same PDU. > > > > > > It makes coding cleaner because the initiator can have a simple > > > send/receive > > > loop that pops out when security is complete. If operational parameters > > are > > > allowed with SecurityContextComplete=yes, the initiator's security > module > > > must also have operational parameter code or it must set flags, leave > > > information in buffers, etc that all create messy code. > > > > > > The spec says: > > > > > > If the initiator has been the last to complete the handshake > > it > > > MUST NOT start sending operational parameters within the > same > > > text command. > > > > > > How about if we say the same thing for the target? There shouldn't be > any > > > harm because I suspect everyone is doing that anyway. > > > > > > Comments? > > > > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 17:04:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08076 for ; Wed, 25 Jul 2001 17:04:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PK1G016451 for ips-outgoing; Wed, 25 Jul 2001 16:01:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PK1E216446 for ; Wed, 25 Jul 2001 16:01:14 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id 9C9D71793 for ; Wed, 25 Jul 2001 13:01:13 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id NAA00237 for ips@ece.cmu.edu; Wed, 25 Jul 2001 13:02:27 -0700 (PDT) Message-Id: <200107252002.NAA00237@core.rose.hp.com> Subject: Re: iSCSI state transitions To: ips@ece.cmu.edu Date: Wed, 25 Jul 2001 13:02:27 PDT In-Reply-To: <3B5DDAE6.5EDD39B5@research.bell-labs.com>; from "Sandeep Joshi" at Jul 24, 101 2:28 pm Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, I think #2 below is closed. I have an open mind on #1, since it is rather subjective. My only observation was that none of the reviewers including the ERT (and several other colleagues) - found it an issue so far. If more reviewers think it needs to be separated - I can split it (I will try it anyway to see how it shapes up, but probably not before London). #3 is where I have a problem. IMHO, a seemingly simple solution of dropping XPT_* states is a bad idea since presence/absence of a valid transport connection is obviously, inherently part of the "state" of the iSCSI connection record! I strongly believe that, contrary to your opinion, having these states increases the ease of understanding of the iSCSI state diagrams, NOT decrease it. It is easier to assume that transport connections get created "on the fly"/"on the transition", but that's only good for explaining, not for implementation - as I clearly explained below in my response. Ofcourse, comments from others are also appreciated. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Ok.. here is what I had in mind before I saw the new state diagram. > >This is probably not detailing all the events/actions but I sincerely >think the current 14-state machine probably wont make it as-is >into most implementations (i.e. it will get ignored by the >silent majority - overspecification creates the same result as >underspecification) > >To respond to all the comments below : > >1) You are right, the states for target & initiator may be > the same but the transitions events are different. > Separating the diagrams will make it *much* easier to read. > See Barry's (Reinhold) login phase diagrams for a good example. > >2) State S13-BUSY can get confused with full-feature phase. > RECOVERY_START sounds like a better name. > >3) As regards TCP-related state, I think we are talking of nested > state machines. From my limited knowledge of VHDL, I think > these would become nested entities in a design hierarchy with > their own state machines - the iSCSI state machine would be > blocked until the TCP state machine comes back with a new > connection and then enable the READY/GRANT signal or whatever. > I still dont think the TCP state needs to show up in iSCSI > connection state - it may be correct but it does not seem necessary. > >regards, >-Sandeep > >"Mallikarjun C." wrote: >> >> Sandeep, >> >> Thanks for the comments. >> >> >pages 5-6 look good >> >but pages 1-4 have a high information density. >> >(Uneasy rests the eye which traces the transitions..) >> >> Not sure what's implied above.... >> >> I was merely trying to keep the pdf file small. >> >> >I suspect the primary problem is that the initiator and >> >target connection state diagrams have got combined into >> >one diagram. >> >> Depends on the viewpoint. Out of 30 transitions, 7 are >> role-specific, rest are role-agnostic - that is 76.6% are >> the same. I consider duplicating >75% in two separate diagrams >> as unnecessary. Besides, 100% of the transitions are the same >> for both roles in both connection recovery and session state >> diagrams. While this hasn't been a "problem" for any of the >> reviewers so far, let us wait for more comments. >> >> >State S13 should be called "suspended" or "to_be_recovered" >> > The tasks are undoubtedly "busy" but the connection is >> > certainly suspended. >> >> I am not that certain. The connection state machine is simply >> entering into the recovery state diagram, S13 is _not_ a suspended >> dead end. When in S13, CSM-R is actively counting time to >> possibly take transition M1 to get to R3. >> >> Would RECOVERY_START be a better name than BUSY? >> >> > We seem to be tracking the TCP state (S2, S12 for SYN,FIN) >> > It adds to the complexity and sidetracks one >> > from the main purpose, which (i thought) was to document >> > error recovery. >> >> Sorry, not true - section 6 goes beyond error recovery(section 7). >> As stated in the preface, these document the entire life of the >> iSCSI connection and iSCSI session. >> >> At the iSCSI level, we have to clearly specify how iSCSI state >> machines react to transport connection events, since an implementation >> must deal with those. Section 1.2.6 clearly lays out how to deal with >> transport connection termination events for the same reason. >> >> >Assume that connection >> > establishment and destruction is an action on transition >> .. >> > On error, the connection will be closed and the state can be >> > restored to S1 in one step. >> >> These state diagrams are hoped to be implementable "as is". >> In reality, connection establishment is not atomic - an iSCSI >> driver/ASIC has to send a connect request and wait for the >> result, S2 represents the state of the iSCSI connection record >> during that time. Similar comments apply for connection >> termination. >> >> Regards. >> -- >> Mallikarjun >> >> Mallikarjun Chadalapaka >> Networked Storage Architecture >> Network Storage Solutions Organization >> MS 5668 Hewlett-Packard, Roseville. >> cbm@rose.hp.com >> >> >Mallikarjun, >> > >> >Just a few comments on this.. pages 5-6 look good >> >but pages 1-4 have a high information density. >> >(Uneasy rests the eye which traces the transitions..) >> > >> >I suspect the primary problem is that the initiator and >> >target connection state diagrams have got combined into >> >one diagram. As a result, most states as well as transitions >> >have got special-cased as initiator-only or target-only. >> > >> >(For example, T1, T2, T3, T7, T15 are all initiator-only) >> > >> >Other points: >> >a) State S13 should be called "suspended" or "to_be_recovered" >> > The tasks are undoubtedly "busy" but the connection is >> > certainly suspended. The state name must reflect the state >> > of the connection, not the individual tasks. >> > >> >b) We seem to be tracking the TCP state (S2, S12 for SYN,FIN) >> > It adds to the complexity and sidetracks one >> > from the main purpose, which (i thought) was to document >> > error recovery. If we remove the TCP state tracking, we >> > may be be able to eliminate some states (S2, S12, etc) >> > and keep the focus on iSCSI. Assume that connection >> > establishment and destruction is an action on transition, >> > not a whole new state to document. >> > >> >c) Transitions T7, T8 can be removed. How individual implementations >> > behave on login errors (do a retry/bailout) need not be covered. >> > On error, the connection will be closed and the state can be >> > restored to S1 in one step. >> > >> >All in all, it should be possible to express the connection state >> >for each end (with error recovery) in about 7-8 states. >> > >> >The following patterns would then be easy to spot: >> >1) There is one way to move from FREE to LOGGED_IN >> >2) There are four ways to move from LOGGED_IN to FREE >> > a) by self-initiated logout >> > -target sends Async >> > -initiator sends Logout command >> > b) by "other-end" requested logout >> > -target receives a Logout command >> > -initiator receives an Async message >> > c) a transport failure followed by connection recovery failure >> > which indicates a need to abort tasks. >> > d) a transport failure followed by connection recovery success >> > which indicates a clean shutdown. >> > >> >regards, >> >-Sandeep >> > >> > >> >"Mallikarjun C." wrote: >> >> >> >> All: >> >> >> >> Excuse my posting of the (relatively small sized, 27KB) >> >> pdf file with the iSCSI state diagrams. I'll post a URL >> >> shortly, but I wanted to get this out sooner to give >> >> reviewers a graphical description of rev07, section 6. >> >> >> >> This was reviewed in the ERT forum, and the ASCII versions >> >> of this slide set were incorporated into rev07. >> >> >> >> Mallikarjun >> >> >> >> Mallikarjun Chadalapaka >> >> Networked Storage Architecture >> >> Network Storage Solutions Organization >> >> Hewlett-Packard, Roseville >> >> cbm@rose.hp.com >> >> >> >> ------------------------------------------------------------------------ >> >> Name: iscsi_states.pdf >> >> iscsi_states.pdf Type: Portable Document Format (application/pdf) >> >> Encoding: base64 >> >> Download Status: Not downloaded with message >> > > From owner-ips@ece.cmu.edu Wed Jul 25 17:17:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09435 for ; Wed, 25 Jul 2001 17:17:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PKaiM18715 for ips-outgoing; Wed, 25 Jul 2001 16:36:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe70.law11.hotmail.com [64.4.16.205]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PKah218711 for ; Wed, 25 Jul 2001 16:36:43 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 25 Jul 2001 13:36:37 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: iSCSI: SecurityContextComplete without operational parameters Date: Wed, 25 Jul 2001 16:23:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 25 Jul 2001 20:36:37.0011 (UTC) FILETIME=[8029E630:01C11549] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure we are talking the same thing. What I'm asking is that the target and initiator both have the same rule regarding the fact that "it MUST NOT start sending operational parameters within the same text command" when SecurityContextComplete=yes. If the initiator has been the last to complete the handshake it MUST NOT start sending operational parameters within the same text command. Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Wednesday, July 25, 2001 2:49 AM Subject: Re: iSCSI: SecurityContextComplete without operational parameters > Eddy, > > I understood what you are asking but I don't necessarily agree. Operational > parameters are problematic if you want them exchanged in a secure > environment. If not you should be able to handle them as you should be able > to handle > any set of parameters on the same PDU. The need to keep them and perhaps > reset them is part of the negotiation process. > > Julo > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > What I was actually asking for is that the target would not send any > operational parameters in the same PDU as the SecurityContextComplete. > Rationalization given below. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, July 24, 2001 10:08 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > the new text will read: > > > > If the initiator has been the last to complete the handshake it > MUST > > NOT start sending operational parameters that need to be protected > > within the same text command; a text response including only > > SecurityContextComplete=yes concludes the security sub-phase. Only > > the following PDU exchange is protected by digests (if any). > > > > If the target has been the last to complete the handshake, the initiator > > can start the operational parameter negotiation with the next text > command; > > the security negotiation sub-phase ends with the target text response. > > However, the target handshake concluding response MUST NOT include > > operational parameters that need to be protected. Only the following PDU > > exchange is protected by digests (if any). > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > best > > if the target is required to send SecurityContextComplete=yes without any > > new operational parameters within the same PDU. > > > > It makes coding cleaner because the initiator can have a simple > > send/receive > > loop that pops out when security is complete. If operational parameters > are > > allowed with SecurityContextComplete=yes, the initiator's security module > > must also have operational parameter code or it must set flags, leave > > information in buffers, etc that all create messy code. > > > > The spec says: > > > > If the initiator has been the last to complete the handshake > it > > MUST NOT start sending operational parameters within the same > > text command. > > > > How about if we say the same thing for the target? There shouldn't be any > > harm because I suspect everyone is doing that anyway. > > > > Comments? > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Wed Jul 25 18:07:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14113 for ; Wed, 25 Jul 2001 18:07:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PKqin19737 for ips-outgoing; Wed, 25 Jul 2001 16:52:44 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PKqg219733 for ; Wed, 25 Jul 2001 16:52:43 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id H0725-1652-734e12; Wed, 25 Jul 2001 20:52:37 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 25 Jul 2001 15:41:37 -0500 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: RE: iSCSI draft-07 Padding Date: Wed, 25 Jul 2001 15:38:26 -0500 Message-ID: Thread-Topic: iSCSI draft-07 Padding Thread-Index: AcEUXYdZLmWEGTflRvWdXY4mCCvo5wA5VIJQ From: "Robert Griswold" To: X-OriginalArrivalTime: 25 Jul 2001 20:41:37.0963 (UTC) FILETIME=[338B87B0:01C1154A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f6PKqh219734 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit I am generally in agreement with those discussing the 'bad iSCSI' behavior on this thread, but am reluctant to spend too many words defining implementation guidelines in the body of the specification. By Julian using 'should' we allow the bad to take place, but do not lock out the unknown legitimate use of such a transfer. I would like to think that if the I_T nexus can operate on a set of parameters governing communication, and within the bounds of the transport and protocol, that the communication would be allowed to take place. A simple annex or white paper would be good to explain why not to do something bad. Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 24, 2001 11:00 AM To: ips@ece.cmu.edu Subject: RE: iSCSI draft-07 Padding I'll add to 2.7.6: The Data Segments of Data-in and Data-out PDUs SHOULD be filled to integer number of 4 byte words (real payload) unless the F bit is set to 1. Julo Michael Schoberg on 24-07-2001 18:13:14 Please respond to Michael Schoberg To: "'ips@ece.cmu.edu'" cc: Subject: RE: iSCSI draft-07 Padding Yes, at the very least the spec should not allow padding on intermediate ReadData/WriteData bursts. I can't think of a reason why one would want to use odd length intermediate bursts, so hopefully it's safe to restrict it. Padding the last burst still seems reasonable for easy CRC calculation. Setting a fixed size is optional. A minimum would avoid memory fragmentation when working with memory descriptors. : -----Original Message----- : From: Robert Snively [mailto:rsnively@Brocade.COM] : Sent: Tuesday, July 24, 2001 8:34 AM : To: ips@ece.cmu.edu : Subject: RE: iSCSI draft-07 Padding : : : Fibre Channel's approach to this problem is to prohibit padding : for all transfers except the transfer that moves the last bytes : in the last (or highest pointer value) burst of data. Intermediate : bursts are required to end on 4-byte boundaries, regardless of : tranfer order as allowed by EMDP. : : Bob : : ----- Original Message ----- : From: "Michael Schoberg" : To: : Sent: Friday, July 20, 2001 4:27 PM : Subject: iSCSI draft-07 Padding : : : > I couldn't find anything in the latest iSCSI spec : (draft-07) that prevents : > someone from issuing multiple padded PDU's for iSCSI Data : In/Out segments. : > I guess I'm worried that someone could issue padded : odd-length write/read : > data when it wasn't necessary. Example: When moving a 512 byte disk : sector : > an initiator/target could legally issue 512 1-byte DataSegmentLength : > messages (each padded up to a 32-bit boundary). This isn't : the sort of : data : > stream one would expect, but it's allowed in the draft. : > : > This also leads into whether fixed or minimum length data : segments (for : all : > but the last) would be nice to include as part of the spec. : It may result : > in a simpler software/hardware design. : > : From owner-ips@ece.cmu.edu Wed Jul 25 18:32:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16333 for ; Wed, 25 Jul 2001 18:32:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PLPht21653 for ips-outgoing; Wed, 25 Jul 2001 17:25:43 -0400 (EDT) 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 f6PLPg221649 for ; Wed, 25 Jul 2001 17:25:42 -0400 (EDT) Received: from breinhold ([140.186.66.73]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f6PLPWq28794; Wed, 25 Jul 2001 17:25:32 -0400 (EDT) From: "Barry Reinhold" To: "Robert D. Russell" , "Jim Hafner" Cc: Subject: RE: iSCSI: SecurityContextComplete without operational parameters Date: Wed, 25 Jul 2001 17:27:42 -0400 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am in favor if this, and a new crack at the documentation of it. The current text is getting overloaded - this does not need to be a complex process given what we are trying to accomplish. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Robert D. Russell >Sent: Wednesday, July 25, 2001 3:48 PM >To: Jim Hafner >Cc: ips@ece.cmu.edu >Subject: Re: iSCSI: SecurityContextComplete without operational >parameters > > >Jim: > >We already have the classification of keys into security >(given in Appendix A) and operational (given in Appendix D), >although a few of the keys in Appendix D (TargetAddress, TargetName, >TargetAlias, InitiatorName, InitiatorAlias) are really >informational parameters (a third category) since they cannot >be negotiated. > >The problem is the way these are negotiated during login. >The simplification most people want is to ALWAYS start a login >with a security negotiation subphase that involves NO operational >parameter negotiation (the informational parameters are ok). >This phase ALWAYS ends with an exchange >of messages (a "handshake") containing the key >SecurityContextComplete=yes and no other security keys and no >operational keys. >Only after this exchange should any operational parameters be >negotiated in additional messages. > >If no security is wanted, a login command with F=0 can start the >handshake by offering SecurityContextComplete=yes (along with >the TargetName= and InitiatorName= keys, which should ALWAYS be >required on the login command), and the target can respond >with a login response with F=0 and containing only >SecurityContextComplete=yes. >Then and only then can operational parameters be negotiated. > >If neither security nor operational parameters need to be negotiated, >the login command is as above but with F=1, and the target response >as above but with F=1. At that point, both sides are in full feature >phase. > >It is simple and unambiguous. > >Bob > > > >On Wed, 25 Jul 2001, Jim Hafner wrote: > >> >> Rob, >> >> It sounds to me like another way to interpret what you're >suggesting is to >> have two classes of Keys: Login keys (security + names, etc) and Text >> message keys (operational). >> >> Is that a valid separation? >> >> Jim Hafner >> >> >> "Robert D. Russell" @ece.cmu.edu on 07-25-2001 >> 11:07:26 AM >> >> Sent by: owner-ips@ece.cmu.edu >> >> >> To: Julian Satran/Haifa/IBM@IBMIL >> cc: ips@ece.cmu.edu >> Subject: Re: iSCSI: SecurityContextComplete without operational >parameters >> >> >> >> Julian: >> >> I think this exchange between you and Eddy illustrates the fundamental >> problem with login that everyone at the plugfest realized: >> the login process is too complex, we need to simplify it. >> >> Eddy was asking for a simplification -- that operational parameters >> NOT be sent with SCC=yes. The change you made does not do that, >> and the response you gave below "If not you should be able to >> handle them as you should be able to handle any set of parameters >> on the same PDU." illustrates to me that you do not understand the >> problem, which is that login is too complex "to handle any set of >> parameters on the same PDU". The combinations and misinterpretations >> of these combinations are horrendous. It needs to be simplified, >> and that is what Eddy is asking -- do NOT allow these arbitrary >> combinations. >> >> In the rewording you added the phrase "that need to be protected" in >> two places. Please remove that phrase from both places, >> because it defeats the whole purpose of the change and introduces more >> ambiguity -- who decides what needs to be protected and what >> doesn't? Suppose the target decides one thing and the initiator the >> other? Where is the defined list of parameters that "need" to be >> protected and those that do not "need" to be protected. etc. >> >> A big simplification is one requested a long time back by >> Barry Reinhold and recently reiterated in a new request by >> Rod Harrison of Wind River, which I strongly support, to mandate >> that the login PDU MUST only contain security parameters -- no >> operational parameters. Then the login MUST ALWAYS start with >> the security subphase, and MUST end with a handshake of messages >> that contained ONLY SecurityContextComplete from both target and >> initiator. Only then would the operational parameter negotiation >> start. I would also add to this recommendation that for normal >> logins (as opposed to discovery logins) the login MUST ALWAYS >> contain the TargetName and InitiatorName keys too. Furthermore, >> if the SessionType parameter is offered, it MUST be offered on >> the login. >> >> These changes would also clean up the wording in the standard, because: >> >> 1. By prohibiting any operational parameter negotiation before the >> security subphase was completed, there would be no need for the >> new OpParmReset key (there is no way they could have changed). >> >> 2. By prohibiting any operational parameter negotiation before the >> security subphase was completed, there would be no need for the >> wording in 4.3 that talks about "Operational parameters negotiated >> inadvertently before the security/integrity negotiation" >> (a standard really shouldn't be allowing "inadvertent" things to >> happen). >> >> 3. The discussion in 4.1 about the TargetName and InitiatorName would >> be considerably simplified, since there would be no need for >> phrases like "If the iSCSI Target Name is going to be used in >> determining the security mode or it is implicit part of >> authentication," because it should just ALWAYS be sent. >> Phrases like the one just quoted cause enormous interoperability >> problems, because they introduce ambiguity that different >> implementers can resolve in different ways (who determines if >> the TargetName is going to be used? How? Who determines if it is >> implicit? How? etc.) >> >> I believe these suggestions, most of which have been made before, >> would simplify the login process. This is done by placing restrictions >> on what can be done when. It may involve the exchange of a few >> extra PDUs (ie. the text commands containing only >> SecurityContectComplete=yes), but logins are not part of the critical >> fast path and are not under tight time constraints -- it is more >> important that they be correct, unambiguous and easily interoperable >> than that they be superfast. >> >> Thank you, >> >> Bob Russell >> InterOperability Lab >> University of New Hampshire >> rdr@iol.unh.edu >> 603-862-3774 >> >> >> On Wed, 25 Jul 2001, Julian Satran wrote: >> >> > Eddy, >> > >> > I understood what you are asking but I don't necessarily agree. >> Operational >> > parameters are problematic if you want them exchanged in a secure >> > environment. If not you should be able to handle them as you should be >> able >> > to handle >> > any set of parameters on the same PDU. The need to keep them >and perhaps >> > reset them is part of the negotiation process. >> > >> > Julo >> > >> > "Eddy Quicksall" on 24-07-2001 20:35:18 >> > >> > Please respond to "Eddy Quicksall" >> > >> > To: Julian Satran/Haifa/IBM@IBMIL >> > cc: ips@ece.cmu.edu >> > Subject: Re: iSCSI: SecurityContextComplete without operational >> parameters >> > >> > >> > >> > >> > What I was actually asking for is that the target would not send any >> > operational parameters in the same PDU as the SecurityContextComplete. >> > Rationalization given below. >> > >> > Eddy >> > >> > ----- Original Message ----- >> > From: "Julian Satran" >> > To: >> > Sent: Tuesday, July 24, 2001 10:08 AM >> > Subject: Re: iSCSI: SecurityContextComplete without operational >> parameters >> > >> > >> > > the new text will read: >> > > >> > > If the initiator has been the last to complete the handshake it >> > MUST >> > > NOT start sending operational parameters that need to be >> protected >> > > within the same text command; a text response including only >> > > SecurityContextComplete=yes concludes the security sub-phase. >> Only >> > > the following PDU exchange is protected by digests (if any). >> > > >> > > If the target has been the last to complete the handshake, the >> initiator >> > > can start the operational parameter negotiation with the next text >> > command; >> > > the security negotiation sub-phase ends with the target text >response. >> > > However, the target handshake concluding response MUST NOT include >> > > operational parameters that need to be protected. Only the following >> PDU >> > > exchange is protected by digests (if any). >> > > >> > > Julo >> > > >> > > "Eddy Quicksall" on 24-07-2001 15:55:05 >> > > >> > > Please respond to "Eddy Quicksall" >> > > >> > > To: Julian Satran/Haifa/IBM@IBMIL >> > > cc: ips@ece.cmu.edu >> > > Subject: iSCSI: SecurityContextComplete without operational >parameters >> > > >> > > >> > > >> > > >> > > In section "4.2 iSCSI Security and Integrity Negotiation", >it would be >> > best >> > > if the target is required to send SecurityContextComplete=yes without >> any >> > > new operational parameters within the same PDU. >> > > >> > > It makes coding cleaner because the initiator can have a simple >> > > send/receive >> > > loop that pops out when security is complete. If operational >parameters >> > are >> > > allowed with SecurityContextComplete=yes, the initiator's security >> module >> > > must also have operational parameter code or it must set flags, leave >> > > information in buffers, etc that all create messy code. >> > > >> > > The spec says: >> > > >> > > If the initiator has been the last to complete >the handshake >> > it >> > > MUST NOT start sending operational parameters within the >> same >> > > text command. >> > > >> > > How about if we say the same thing for the target? There shouldn't be >> any >> > > harm because I suspect everyone is doing that anyway. >> > > >> > > Comments? >> > > >> > > >> > > Eddy_Quicksall@iVivity.com >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> >> >> >> >> > From owner-ips@ece.cmu.edu Wed Jul 25 18:35:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16751 for ; Wed, 25 Jul 2001 18:35:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PLS4n21770 for ips-outgoing; Wed, 25 Jul 2001 17:28:04 -0400 (EDT) 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 f6PLS3221765 for ; Wed, 25 Jul 2001 17:28:03 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA07182 for ; Wed, 25 Jul 2001 17:27:56 -0400 (EDT) Message-ID: <3B5F393F.59E6988F@cisco.com> Date: Wed, 25 Jul 2001 16:25:19 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI Login Questions 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, Is it valid (under draft -07) to offer the SecurityContextComplete key without the AuthMethod, HeaderDigest or DataDigest keys having been offered? In other words, are the following sequences valid? Sequence 1: I-> Login SecurityContextComplete=yes T-> Login-PR SecurityContextComplete=yes Sequence 2: I-> Login T-> Login-PR SecurityContextComplete=yes I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Sequence 3: I-> Login I-> Login-PR I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Thanks, Steve Senum From owner-ips@ece.cmu.edu Wed Jul 25 19:49:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22384 for ; Wed, 25 Jul 2001 19:49:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6PMWle25959 for ips-outgoing; Wed, 25 Jul 2001 18:32:47 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail1.tor.primus.ca (mail.tor.primus.ca [216.254.136.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PMWj225955 for ; Wed, 25 Jul 2001 18:32:45 -0400 (EDT) Received: from dsl-216-254-190-113.tor.primus.ca ([216.254.190.113] helo=perfisan4) by mail1.tor.primus.ca with smtp (Exim 2.11 #1) id 15PXCf-0005ww-05 for ips@ece.cmu.edu; Wed, 25 Jul 2001 18:32:29 -0400 Reply-To: From: "Trang Nguyen" To: "IPS" Subject: SCSI CDB bytes Date: Wed, 25 Jul 2001 18:35:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I have some questions about the SCSI CDB. From the draft-ietf-ips-iscsi-07.txt: "2.3.6 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the commonly used CDB. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST is used to contain the CDB spillover. " 1. The SCSI CDB field in the SCSI Command PDU is 16 bytes long. Does it mean that iSCSI supports SCSI-3? I thought that iSCSI supports only SCSI-2 commands, and doesn't support SCSI-3 commands. 2. If iSCSI supports SCSI-2 commands, then in which case the CDB is larger 16 bytes? Thanks a lot, ********************************* Trang Nguyen tnguyen@perfisans.com ********************************* From owner-ips@ece.cmu.edu Wed Jul 25 21:38:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00604 for ; Wed, 25 Jul 2001 21:38:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q0bBt02535 for ips-outgoing; Wed, 25 Jul 2001 20:37:11 -0400 (EDT) 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 f6Q0bA202531 for ; Wed, 25 Jul 2001 20:37:10 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 20:35:27 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AB5@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Feature Discussion Date: Wed, 25 Jul 2001 20:32:33 -0400 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've seen a couple of comments whose form I need to discourage: (1) On the boot and copy manager sessions, saying that something's been in there for a long time is a rather weak reason for keeping it. Technical rationale is needed, and it's ok to question things that may have seemed like a good idea way back when. These session types have turned out to be a worked example, as I strongly support the direction of removing these session types. I would ask everyone to please focus on technical rationale, not how long something's been in the draft without attracting attention. (2) The attempt to refer the Alias issue to the naming and discovery team is misplaced. Design teams are a vehicle for making progress, not a tool for squelching discussion. Yes, the design team put the Alias in, but requiring someone who objects to it to get their permission to object is backwards - objecting on the mailing list is fine, and should lead to explanations from those who think the feature is a good idea. 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 25 21:39:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00796 for ; Wed, 25 Jul 2001 21:39:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q0qG103296 for ips-outgoing; Wed, 25 Jul 2001 20:52:16 -0400 (EDT) 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 f6Q0qE203289 for ; Wed, 25 Jul 2001 20:52:15 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0T16JN>; Wed, 25 Jul 2001 20:52:09 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AB7@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: Procedural Matters Date: Wed, 25 Jul 2001 20:47:38 -0400 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 Time to break a few more eggs ... (1) Iterating Long Responses. While I've been inundated by email lately, I don't think I've seen consensus on the list. Since this is in the context of the Naming draft, whoever's going to lead the discussion of this draft in London (Mark?) should prepare a slide on this issue so that we can attempt to resolve it there. (2) Login Text. To borrow a line from the late Admiral Hopper, "It's better to apologize than ask permission". This discussion about whether the WG approves of rewriting the login text is misdirected. I strongly encourage the core set of people involved in the bakeoff who are familiar with the login difficulties to write an iSCSI login draft containing a clear self-contained description of login, and recommend login simplifications as part of the draft. Once we have that text in front of us, we can figure out what to do with it - nobody's permission (mine, Julian's, etc.) is needed to write that draft, and the plugfest turned up what looks to me like a clear need to do something about this. (3) Version number. The word from above is that the version number should remain at 0 in the draft versions of iSCSI. It could be advanced to 1 for the approved RFC (i.e., the version of the draft prepared after the successful WG Last Call would set the version number to 1). As noted previously, discussions of interoperability of products implemented to Internet-Drafts should be sent directly to the bit bucket ;-). 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Wed Jul 25 21:42:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00953 for ; Wed, 25 Jul 2001 21:42:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q0CS001374 for ips-outgoing; Wed, 25 Jul 2001 20:12:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6Q0CR201370 for ; Wed, 25 Jul 2001 20:12:27 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6Q0CKg22724; Wed, 25 Jul 2001 17:12:20 -0700 (PDT) Received: from DAPW2K (sjc-vpn1-8.cisco.com [10.21.96.8]) by sponge.cisco.com (Mirapoint) with SMTP id AAG09500; Wed, 25 Jul 2001 19:10:56 -0500 (CDT) From: "Dave Peterson" To: , "IPS" Subject: RE: SCSI CDB bytes Date: Wed, 25 Jul 2001 19:12:48 -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.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Not sure where you came up with SCSI-2. Currently iSCSI refers to the SAM-2 architecture which implies support for SCSI-3 command set. New XOR commands defined in SBC-2 use 32 byte CDBs. Most OSD commnds (Object Based Storage Device) are also > 16 bytes. Dave -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Trang Nguyen Sent: Wednesday, July 25, 2001 5:35 PM To: IPS Subject: SCSI CDB bytes Hello, I have some questions about the SCSI CDB. From the draft-ietf-ips-iscsi-07.txt: "2.3.6 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the commonly used CDB. Whenever the CDB is larger than 16 bytes, an Extended CDB AHS MUST is used to contain the CDB spillover. " 1. The SCSI CDB field in the SCSI Command PDU is 16 bytes long. Does it mean that iSCSI supports SCSI-3? I thought that iSCSI supports only SCSI-2 commands, and doesn't support SCSI-3 commands. 2. If iSCSI supports SCSI-2 commands, then in which case the CDB is larger 16 bytes? Thanks a lot, ********************************* Trang Nguyen tnguyen@perfisans.com ********************************* From owner-ips@ece.cmu.edu Wed Jul 25 22:08:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02580 for ; Wed, 25 Jul 2001 22:08:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q16Jb04012 for ips-outgoing; Wed, 25 Jul 2001 21:06:19 -0400 (EDT) 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 f6Q16I204007 for ; Wed, 25 Jul 2001 21:06:18 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0T16R2>; Wed, 25 Jul 2001 21:06:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AB8@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI Simplification: Something Radical Date: Wed, 25 Jul 2001 21:01:41 -0400 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 We need to revive this topic, so I'm going to do something radical. Would everyone who cares about simplifying iSCSI please send me a brief email with a list of the most important areas in which you think iSCSI needs to be simplified. So that I can do something useful with the resulting email tidal wave, please follow these guidelines: - 3-5 items, no more. - 1 line name of each item. A section reference to the -07 draft may be included, but is not required. - Maximum of 2 sentences, 4 lines explaining WHAT should be done. - Maximum of 2 sentences, 4 lines explaining WHY it should be done. Emails not following these guidelines (especially any email with more than 5 items) will be ignored. Please keep in mind that brevity is a virtue. Deadline is end of the day, Tuesday, July 31st. The most common items and the best WHAT/WHY explanations will go on slides for London, and there will be time on the agenda set aside for this ... yes, I know I need to get the London agenda done ... 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Thu Jul 26 00:23:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10269 for ; Thu, 26 Jul 2001 00:23:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q3TZd11053 for ips-outgoing; Wed, 25 Jul 2001 23:29:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6PK5G216721 for ; Wed, 25 Jul 2001 16:05:16 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 020646426; Wed, 25 Jul 2001 16:03:48 -0400 (EDT) From: "Dev - Platys" To: "Robert D. Russell" , "Julian Satran" Cc: Subject: RE: iSCSI: SecurityContextComplete without operational parameters Date: Wed, 25 Jul 2001 13:07:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Robert, >A big simplification is one requested a long time back by >Barry Reinhold and recently reiterated in a new request by >Rod Harrison of Wind River, which I strongly support, to mandate >that the login PDU MUST only contain security parameters -- no >operational parameters. Then the login MUST ALWAYS start with >the security subphase, and MUST end with a handshake of messages >that contained ONLY SecurityContextComplete from both target and >initiator. Only then would the operational parameter negotiation >start. I would also add to this recommendation that for normal >logins (as opposed to discovery logins) the login MUST ALWAYS >contain the TargetName and InitiatorName keys too. Furthermore, >if the SessionType parameter is offered, it MUST be offered on >the login. I agree that this makes the login process less complex and less ambiguous. Thanks Deva Platys Communications -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Robert D. Russell Sent: Wednesday, July 25, 2001 11:07 AM To: Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters Julian: I think this exchange between you and Eddy illustrates the fundamental problem with login that everyone at the plugfest realized: the login process is too complex, we need to simplify it. Eddy was asking for a simplification -- that operational parameters NOT be sent with SCC=yes. The change you made does not do that, and the response you gave below "If not you should be able to handle them as you should be able to handle any set of parameters on the same PDU." illustrates to me that you do not understand the problem, which is that login is too complex "to handle any set of parameters on the same PDU". The combinations and misinterpretations of these combinations are horrendous. It needs to be simplified, and that is what Eddy is asking -- do NOT allow these arbitrary combinations. In the rewording you added the phrase "that need to be protected" in two places. Please remove that phrase from both places, because it defeats the whole purpose of the change and introduces more ambiguity -- who decides what needs to be protected and what doesn't? Suppose the target decides one thing and the initiator the other? Where is the defined list of parameters that "need" to be protected and those that do not "need" to be protected. etc. A big simplification is one requested a long time back by Barry Reinhold and recently reiterated in a new request by Rod Harrison of Wind River, which I strongly support, to mandate that the login PDU MUST only contain security parameters -- no operational parameters. Then the login MUST ALWAYS start with the security subphase, and MUST end with a handshake of messages that contained ONLY SecurityContextComplete from both target and initiator. Only then would the operational parameter negotiation start. I would also add to this recommendation that for normal logins (as opposed to discovery logins) the login MUST ALWAYS contain the TargetName and InitiatorName keys too. Furthermore, if the SessionType parameter is offered, it MUST be offered on the login. These changes would also clean up the wording in the standard, because: 1. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the new OpParmReset key (there is no way they could have changed). 2. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the wording in 4.3 that talks about "Operational parameters negotiated inadvertently before the security/integrity negotiation" (a standard really shouldn't be allowing "inadvertent" things to happen). 3. The discussion in 4.1 about the TargetName and InitiatorName would be considerably simplified, since there would be no need for phrases like "If the iSCSI Target Name is going to be used in determining the security mode or it is implicit part of authentication," because it should just ALWAYS be sent. Phrases like the one just quoted cause enormous interoperability problems, because they introduce ambiguity that different implementers can resolve in different ways (who determines if the TargetName is going to be used? How? Who determines if it is implicit? How? etc.) I believe these suggestions, most of which have been made before, would simplify the login process. This is done by placing restrictions on what can be done when. It may involve the exchange of a few extra PDUs (ie. the text commands containing only SecurityContectComplete=yes), but logins are not part of the critical fast path and are not under tight time constraints -- it is more important that they be correct, unambiguous and easily interoperable than that they be superfast. Thank you, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 25 Jul 2001, Julian Satran wrote: > Eddy, > > I understood what you are asking but I don't necessarily agree. Operational > parameters are problematic if you want them exchanged in a secure > environment. If not you should be able to handle them as you should be able > to handle > any set of parameters on the same PDU. The need to keep them and perhaps > reset them is part of the negotiation process. > > Julo > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > What I was actually asking for is that the target would not send any > operational parameters in the same PDU as the SecurityContextComplete. > Rationalization given below. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, July 24, 2001 10:08 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > the new text will read: > > > > If the initiator has been the last to complete the handshake it > MUST > > NOT start sending operational parameters that need to be protected > > within the same text command; a text response including only > > SecurityContextComplete=yes concludes the security sub-phase. Only > > the following PDU exchange is protected by digests (if any). > > > > If the target has been the last to complete the handshake, the initiator > > can start the operational parameter negotiation with the next text > command; > > the security negotiation sub-phase ends with the target text response. > > However, the target handshake concluding response MUST NOT include > > operational parameters that need to be protected. Only the following PDU > > exchange is protected by digests (if any). > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > best > > if the target is required to send SecurityContextComplete=yes without any > > new operational parameters within the same PDU. > > > > It makes coding cleaner because the initiator can have a simple > > send/receive > > loop that pops out when security is complete. If operational parameters > are > > allowed with SecurityContextComplete=yes, the initiator's security module > > must also have operational parameter code or it must set flags, leave > > information in buffers, etc that all create messy code. > > > > The spec says: > > > > If the initiator has been the last to complete the handshake > it > > MUST NOT start sending operational parameters within the same > > text command. > > > > How about if we say the same thing for the target? There shouldn't be any > > harm because I suspect everyone is doing that anyway. > > > > Comments? > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 26 00:24:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10344 for ; Thu, 26 Jul 2001 00:24:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q3Sx611009 for ips-outgoing; Wed, 25 Jul 2001 23:28:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.brocade.com (asbestos.brocade.com [63.121.140.244]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6PJJv211630 for ; Wed, 25 Jul 2001 15:19:57 -0400 (EDT) Received: from hq-ex-c2.brocade.com (hq-ex-c2 [192.168.126.35]) by mail.brocade.com (8.8.8+Sun/8.8.8) with ESMTP id MAA06464 for ; Wed, 25 Jul 2001 12:19:50 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 12:19:49 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu Subject: RE: iSCSI: Case-sensitivity in iSCSI names Date: Wed, 25 Jul 2001 12:19:40 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I did want to point out one characteristic of this. Whatever mechanism you use to assign the names SHALL cross check each name you assign for compliance with NAMEPREP normalization. This gets especially sticky as the folded cases and the multi-character cases are resolved. Basically, I would expect that the name would get run through NAMEPREP's latest revision. If it came out unchanged, you have selected a valid name. If it came out changed, you have to either use a different name or use the normalized changed name. In either of the mismatch cases, you must be careful to avoid duplications. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 From owner-ips@ece.cmu.edu Thu Jul 26 00:26:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10512 for ; Thu, 26 Jul 2001 00:26:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q3XOI11348 for ips-outgoing; Wed, 25 Jul 2001 23:33:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tiny-teddy.aarnet.edu.au (IDENT:root@tiny-teddy.aarnet.edu.au [203.21.37.30]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6P83q225522 for ; Wed, 25 Jul 2001 04:03:53 -0400 (EDT) Received: from aarnet.edu.au (bush.aarnet.adelaide.edu.au [129.127.180.236]) by tiny-teddy.aarnet.edu.au (8.11.0/8.11.0) with ESMTP id f6P83jD16241; Wed, 25 Jul 2001 17:33:46 +0930 Message-ID: <3B5E7D5C.3D3B3170@aarnet.edu.au> Date: Wed, 25 Jul 2001 17:33:40 +0930 From: Glen Turner Organization: Australian Academic and Research Network X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-ac19 i686) X-Accept-Language: en MIME-Version: 1.0 To: John Hufferd CC: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Hufferd wrote: > > I want to jump on this bandwagon too. This seems to be exactly the right > approach. I'm showing some caution. It seems that NAMEPREP still requires casing tables. Where and how are these maintained? Does the proposal lead to language-based variants of iSCSI products. At the moment I can safely buy a hard disk drive from the USA and use it anywhere in the world: IDE, FC or SCSI. That should be so for iSCSI. Mark wrote: > Anyway, if this is to be used for domain names, we ought to use it, > too. Except that no-one is suggesting embedding DNS in a platform that won't be maintained after sale. Before support one way or the other I'd like to be clearer about the boundaries of iSCSI naming. Regards, Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Thu Jul 26 00:27:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10558 for ; Thu, 26 Jul 2001 00:27:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q3Nqt10708 for ips-outgoing; Wed, 25 Jul 2001 23:23:52 -0400 (EDT) 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 f6PAWp212415 for ; Wed, 25 Jul 2001 06:32:51 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07322; Wed, 25 Jul 2001 06:31:52 -0400 (EDT) Message-Id: <200107251031.GAA07322@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-iscsi-slp-01.txt Date: Wed, 25 Jul 2001 06:31:51 -0400 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 iSCSI Targets and Name Servers Using SLP Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-slp-01.txt Pages : 17 Date : 24-Jul-01 The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and name services, along with the SLP service type templates that describe the services they provide. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-slp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-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-iscsi-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: <20010724132056.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-slp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-slp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132056.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jul 26 00:28:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10612 for ; Thu, 26 Jul 2001 00:28:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q3MiW10656 for ips-outgoing; Wed, 25 Jul 2001 23:22:44 -0400 (EDT) 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 f6PAWi212406 for ; Wed, 25 Jul 2001 06:32:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07301; Wed, 25 Jul 2001 06:31:45 -0400 (EDT) Message-Id: <200107251031.GAA07301@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-fcovertcpip-04.txt Date: Wed, 25 Jul 2001 06:31:44 -0400 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 : Fibre Channel Over TCP/IP (FCIP) Author(s) : M. Rajagopal, R. Bhagwat et al. Filename : draft-ietf-ips-fcovertcpip-04.txt Pages : 42 Date : 24-Jul-01 Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcovertcpip-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcovertcpip-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010724132046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcovertcpip-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcovertcpip-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132046.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Jul 26 13:38:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24563 for ; Thu, 26 Jul 2001 13:38:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QGTxv29066 for ips-outgoing; Thu, 26 Jul 2001 12:29:59 -0400 (EDT) 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 f6QGTv229061 for ; Thu, 26 Jul 2001 12:29:57 -0400 (EDT) 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 SAA284988 for ; Thu, 26 Jul 2001 18:29:51 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6QGToZ149154 for ; Thu, 26 Jul 2001 18:29:50 +0200 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 26 Jul 2001 19:35:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 19:29:50 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I am working on it. Thanks for your patience, Julo "Eddy Quicksall" on 26-07-2001 19:17:58 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters Julian, This thread seems to have gone a bit further than my original request. I don't see an answer to the below. Can you please let me know? Again, all I am asking is that both initiator and target have the same rule. It seems simple and constructive to do so. I can rationalize it again if you like. Eddy ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Wednesday, July 25, 2001 4:23 PM Subject: Re: iSCSI: SecurityContextComplete without operational parameters > I'm not sure we are talking the same thing. What I'm asking is that the > target and initiator both have the same rule regarding the fact that "it > MUST NOT start sending operational parameters within the same text command" > when SecurityContextComplete=yes. > > If the initiator has been the last to complete the handshake it > MUST NOT start sending operational parameters within the same > text command. > > Eddy > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Wednesday, July 25, 2001 2:49 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > Eddy, > > > > I understood what you are asking but I don't necessarily agree. > Operational > > parameters are problematic if you want them exchanged in a secure > > environment. If not you should be able to handle them as you should be > able > > to handle > > any set of parameters on the same PDU. The need to keep them and perhaps > > reset them is part of the negotiation process. > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > > > > What I was actually asking for is that the target would not send any > > operational parameters in the same PDU as the SecurityContextComplete. > > Rationalization given below. > > > > Eddy > > > > ----- Original Message ----- > > From: "Julian Satran" > > To: > > Sent: Tuesday, July 24, 2001 10:08 AM > > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > > > the new text will read: > > > > > > If the initiator has been the last to complete the handshake it > > MUST > > > NOT start sending operational parameters that need to be protected > > > within the same text command; a text response including only > > > SecurityContextComplete=yes concludes the security sub-phase. Only > > > the following PDU exchange is protected by digests (if any). > > > > > > If the target has been the last to complete the handshake, the initiator > > > can start the operational parameter negotiation with the next text > > command; > > > the security negotiation sub-phase ends with the target text response. > > > However, the target handshake concluding response MUST NOT include > > > operational parameters that need to be protected. Only the following PDU > > > exchange is protected by digests (if any). > > > > > > Julo > > > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > > > Please respond to "Eddy Quicksall" > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > > best > > > if the target is required to send SecurityContextComplete=yes without > any > > > new operational parameters within the same PDU. > > > > > > It makes coding cleaner because the initiator can have a simple > > > send/receive > > > loop that pops out when security is complete. If operational parameters > > are > > > allowed with SecurityContextComplete=yes, the initiator's security > module > > > must also have operational parameter code or it must set flags, leave > > > information in buffers, etc that all create messy code. > > > > > > The spec says: > > > > > > If the initiator has been the last to complete the handshake > > it > > > MUST NOT start sending operational parameters within the same > > > text command. > > > > > > How about if we say the same thing for the target? There shouldn't be > any > > > harm because I suspect everyone is doing that anyway. > > > > > > Comments? > > > > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 26 13:39:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24630 for ; Thu, 26 Jul 2001 13:39:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QDT5X19479 for ips-outgoing; Thu, 26 Jul 2001 09:29:05 -0400 (EDT) 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 f6QDT4219475 for ; Thu, 26 Jul 2001 09:29:04 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA18518; Thu, 26 Jul 2001 09:28:57 -0400 (EDT) Message-ID: <3B6019C3.F9AAA229@cisco.com> Date: Thu, 26 Jul 2001 08:23:15 -0500 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: Robert Snively CC: ips@ece.cmu.edu Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Snively wrote: > > I did want to point out one characteristic of this. > > Whatever mechanism you use to assign the names SHALL > cross check each name you assign for compliance with > NAMEPREP normalization. True, however most of use will likely just assign names using digits and lower-case ASCII. Since those are already normalized, anything that generates based on this is OK. Even if I allow a user to enter part of the name, I can still just do tolower() and use isalnum() to check that no other characters have been added. The place where one would have to run NAMEPREP is wherever names are generated using characters outside ASCII. At that point, your procedure below must be used. > This gets especially sticky as > the folded cases and the multi-character cases are > resolved. Basically, I would expect that the name would > get run through NAMEPREP's latest revision. If it came > out unchanged, you have selected a valid name. If it > came out changed, you have to either use a different name > or use the normalized changed name. In either of the > mismatch cases, you must be careful to avoid duplications. > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 26 13:39:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24700 for ; Thu, 26 Jul 2001 13:39:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QDcEL20079 for ips-outgoing; Thu, 26 Jul 2001 09:38:14 -0400 (EDT) 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 f6QDcD220074 for ; Thu, 26 Jul 2001 09:38:13 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA25246; Thu, 26 Jul 2001 09:37:58 -0400 (EDT) Message-ID: <3B601BE0.8B27B394@cisco.com> Date: Thu, 26 Jul 2001 08:32:16 -0500 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: Glen Turner CC: John Hufferd , IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: <3B5E7D5C.3D3B3170@aarnet.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Turner wrote: > > John Hufferd wrote: > > > > I want to jump on this bandwagon too. This seems to be exactly the right > > approach. > > I'm showing some caution. > > It seems that NAMEPREP still requires casing tables. Where > and how are these maintained? NAMEPREP casing only needs to be done when the iSCSI name is assigned, and it can be simplified in some cases, such as when names are generated using only ASCII. Since the assignor of the names completely controls which character sets are used, it can include the appropriate normalization code: - If the names are just generated using lower-case (in any character set) plus digits, no normalization is required. - If the names are generated from some other all-ASCII string, tolower() normalizes and isalnum() verifies. - If the names are generated from more general, internationalized text, either the equivalent of tolower() and isalnum() appropriate to the character set may be used, or the NAMEPREP procedure that Bob sent in his last email can be used. In any case, it is at the complete discretion of the naming authority that generates the name whether to use one of the above methods. It can be kept very simple (first or second method), or include case tables to make it more user-friendly. User-friendly naming conventions are an option, and they always cost something. > Does the proposal lead to language-based variants of > iSCSI products. At the moment I can safely buy a > hard disk drive from the USA and use it anywhere in > the world: IDE, FC or SCSI. That should be so for > iSCSI. That's still the case. An iSCSI name that is not in the NAMEPREP-normalized form MUST NOT be used within the iSCSI protocol. Therefore, all compares on iSCSI names are opaque and byte-for-byte, so it doesn't matter where the device is manufactured, or in what locale it is used. -- Mark7 > Mark wrote: > > Anyway, if this is to be used for domain names, we ought to use it, > > too. > > Except that no-one is suggesting embedding DNS in a platform > that won't be maintained after sale. > > Before support one way or the other I'd like to be > clearer about the boundaries of iSCSI naming. Hopefully, the above helps. > Regards, > Glen > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 26 13:39:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24720 for ; Thu, 26 Jul 2001 13:39:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QDf0420264 for ips-outgoing; Thu, 26 Jul 2001 09:41:00 -0400 (EDT) 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 f6QDex220260 for ; Thu, 26 Jul 2001 09:40:59 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA27653; Thu, 26 Jul 2001 09:40:44 -0400 (EDT) Message-ID: <3B601C86.8D7C5551@cisco.com> Date: Thu, 26 Jul 2001 08:35:02 -0500 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: John Hufferd CC: Glen Turner , IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Hufferd wrote: > > Glen, > Perhaps I have this wrong, but I think what we are talking about is a Name > that gets Generated via some sort of Management Tool. Then the iSCSI > Initiator, or the iSCSI Target saves the string that the Management or > Discovery process gives to them. Correct. > This String is then suppose to be able to be use in simple comparisons. > That is it is the TargetID or InitiatorID, may save the string to be used > during negations. I think you meant negotiations (finger ck :-)). > If the manufacture assigns the name, it will also be inserted into the unit > via some kind of interactive Tool. > > I do not understand why the Target or Initiator needs to have the purifying > function called "NAMEPREP". This function should be done on the > interactive Tool/Management routine, on which the Administrator, (or > Manufacture) uses to enter the name. And most of the time, the name is automatically generated, and not entered by a human at all, so not even all management routines will need NAMEPREP. > So I can not see that this causes us any significant problems, and it helps > the Admin ease of use, and a help in reducing finger ck errors. > > Please set me straight if I have this wrong. > > . > 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 > Internet address: hufferd@us.ibm.com > > Glen Turner @ece.cmu.edu on 07/25/2001 01:03:40 > AM > > Sent by: owner-ips@ece.cmu.edu > > To: John Hufferd/San Jose/IBM@IBMUS > cc: IPS > Subject: Re: iSCSI: Case-sensitivity in iSCSI names > > John Hufferd wrote: > > > > I want to jump on this bandwagon too. This seems to be exactly the right > > approach. > > I'm showing some caution. > > It seems that NAMEPREP still requires casing tables. Where > and how are these maintained? > > Does the proposal lead to language-based variants of > iSCSI products. At the moment I can safely buy a > hard disk drive from the USA and use it anywhere in > the world: IDE, FC or SCSI. That should be so for > iSCSI. > > Mark wrote: > > Anyway, if this is to be used for domain names, we ought to use it, > > too. > > Except that no-one is suggesting embedding DNS in a platform > that won't be maintained after sale. > > Before support one way or the other I'd like to be > clearer about the boundaries of iSCSI naming. > > Regards, > Glen > > -- > Glen Turner Network Engineer > (08) 8303 3936 Australian Academic and Research Network > glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ > -- > The revolution will not be televised, it will be digitised -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 26 13:42:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25110 for ; Thu, 26 Jul 2001 13:42:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QGIGf28539 for ips-outgoing; Thu, 26 Jul 2001 12:18:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe73.law11.hotmail.com [64.4.16.208]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6QGIF228534 for ; Thu, 26 Jul 2001 12:18:15 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 26 Jul 2001 09:18:09 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: iSCSI: SecurityContextComplete without operational parameters Date: Thu, 26 Jul 2001 12:17:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 26 Jul 2001 16:18:09.0380 (UTC) FILETIME=[8F4EF240:01C115EE] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, This thread seems to have gone a bit further than my original request. I don't see an answer to the below. Can you please let me know? Again, all I am asking is that both initiator and target have the same rule. It seems simple and constructive to do so. I can rationalize it again if you like. Eddy ----- Original Message ----- From: "Eddy Quicksall" To: "Julian Satran" Cc: Sent: Wednesday, July 25, 2001 4:23 PM Subject: Re: iSCSI: SecurityContextComplete without operational parameters > I'm not sure we are talking the same thing. What I'm asking is that the > target and initiator both have the same rule regarding the fact that "it > MUST NOT start sending operational parameters within the same text command" > when SecurityContextComplete=yes. > > If the initiator has been the last to complete the handshake it > MUST NOT start sending operational parameters within the same > text command. > > Eddy > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Wednesday, July 25, 2001 2:49 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > Eddy, > > > > I understood what you are asking but I don't necessarily agree. > Operational > > parameters are problematic if you want them exchanged in a secure > > environment. If not you should be able to handle them as you should be > able > > to handle > > any set of parameters on the same PDU. The need to keep them and perhaps > > reset them is part of the negotiation process. > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > > > > What I was actually asking for is that the target would not send any > > operational parameters in the same PDU as the SecurityContextComplete. > > Rationalization given below. > > > > Eddy > > > > ----- Original Message ----- > > From: "Julian Satran" > > To: > > Sent: Tuesday, July 24, 2001 10:08 AM > > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > > > the new text will read: > > > > > > If the initiator has been the last to complete the handshake it > > MUST > > > NOT start sending operational parameters that need to be protected > > > within the same text command; a text response including only > > > SecurityContextComplete=yes concludes the security sub-phase. Only > > > the following PDU exchange is protected by digests (if any). > > > > > > If the target has been the last to complete the handshake, the initiator > > > can start the operational parameter negotiation with the next text > > command; > > > the security negotiation sub-phase ends with the target text response. > > > However, the target handshake concluding response MUST NOT include > > > operational parameters that need to be protected. Only the following PDU > > > exchange is protected by digests (if any). > > > > > > Julo > > > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > > > Please respond to "Eddy Quicksall" > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > > best > > > if the target is required to send SecurityContextComplete=yes without > any > > > new operational parameters within the same PDU. > > > > > > It makes coding cleaner because the initiator can have a simple > > > send/receive > > > loop that pops out when security is complete. If operational parameters > > are > > > allowed with SecurityContextComplete=yes, the initiator's security > module > > > must also have operational parameter code or it must set flags, leave > > > information in buffers, etc that all create messy code. > > > > > > The spec says: > > > > > > If the initiator has been the last to complete the handshake > > it > > > MUST NOT start sending operational parameters within the same > > > text command. > > > > > > How about if we say the same thing for the target? There shouldn't be > any > > > harm because I suspect everyone is doing that anyway. > > > > > > Comments? > > > > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 26 13:55:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26695 for ; Thu, 26 Jul 2001 13:55:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q5A3F15772 for ips-outgoing; Thu, 26 Jul 2001 01:10:03 -0400 (EDT) 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 f6Q5A1215768 for ; Thu, 26 Jul 2001 01:10:01 -0400 (EDT) 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 HAA347442 for ; Thu, 26 Jul 2001 07:09:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6Q59s265432 for ; Thu, 26 Jul 2001 07:09:54 +0200 Importance: Normal Subject: Re: iSCSI: Draft-07, URL and names/addresses To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 26 Jul 2001 08:16:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 08:09:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think you will want to leave the examples. Julo Mark Bakke on 25-07-2001 20:27:07 Please respond to Mark Bakke To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: Draft-07, URL and names/addresses Jim- You're right; I don't think we need the URL stuff anymore, and we don't specify iSCSI names and addresses in the same string in iSCSI anymore. If there are no strong objections, I'll remove the section you mentioned. The iSCSI name examples in the section still apply. Should we keep them, throw them, or move them to an appendix with the other examples? -- Mark Jim Hafner wrote: > > Folks, > > The current draft (07) specifies different ways that iSCSI names and > addresses are to be used: > > a) Within the protocol useage itself is the InitiatorName (or TargeName) > keys used in Login and in the context of SendTargets along with > TargetAddress. > > b) Section 1.2.7 describes formatting of these names and addresses as URLs. > These URLs are never used within the context of the protocol. Such a > format *might* be used in a GUI or some other application but specifying > how is beyond the scope of this standard. > > Consequently, to avoid confusion with name/address formats, I suggest that > the text that begins in 1.2.7 paragraph 6 with > "The iSCSI Name is incorporated as part of the address. An iSCSI > address is specified as a URL, such as:... > and up to but not including the paragraph that starts: > "To assist..." > be deleted. It might be replaced with a reference to the SendTargets > Appendix where names and addresses are formatted within the protocol. > > Comments? > > Jim Hafner -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Thu Jul 26 14:28:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01395 for ; Thu, 26 Jul 2001 14:28:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q7uQ623153 for ips-outgoing; Thu, 26 Jul 2001 03:56:26 -0400 (EDT) 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 f6Q7uO223148 for ; Thu, 26 Jul 2001 03:56:24 -0400 (EDT) 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 JAA288394 for ; Thu, 26 Jul 2001 09:56:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6Q7uE258534 for ; Thu, 26 Jul 2001 09:56:14 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 26 Jul 2001 11:02:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 10:56:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Yes that is (in 07) a legitmate sequence. Julo Steve Senum on 26-07-2001 00:25:19 Please respond to Steve Senum To: ietf-ips cc: Subject: Re: iSCSI Login Questions Julian, Is it valid (under draft -07) to offer the SecurityContextComplete key without the AuthMethod, HeaderDigest or DataDigest keys having been offered? In other words, are the following sequences valid? Sequence 1: I-> Login SecurityContextComplete=yes T-> Login-PR SecurityContextComplete=yes Sequence 2: I-> Login T-> Login-PR SecurityContextComplete=yes I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Sequence 3: I-> Login I-> Login-PR I-> Text SecurityContextComplete=yes T-> Text SecurityContextComplete=yes Thanks, Steve Senum From owner-ips@ece.cmu.edu Thu Jul 26 14:28:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01401 for ; Thu, 26 Jul 2001 14:28:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q7ZYk22246 for ips-outgoing; Thu, 26 Jul 2001 03:35:34 -0400 (EDT) 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 f6Q7ZX222242 for ; Thu, 26 Jul 2001 03:35:33 -0400 (EDT) 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 DAA64052; Thu, 26 Jul 2001 03:33:32 -0400 Received: from d03nm065.boulder.ibm.com (d03nm065.boulder.ibm.com [9.99.140.49]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6Q7ZVB247234; Thu, 26 Jul 2001 01:35:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Case-sensitivity in iSCSI names To: Glen Turner Cc: IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 26 Jul 2001 00:35:02 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.6 |December 14, 2000) at 07/26/2001 01:35:31 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Glen, Perhaps I have this wrong, but I think what we are talking about is a Name that gets Generated via some sort of Management Tool. Then the iSCSI Initiator, or the iSCSI Target saves the string that the Management or Discovery process gives to them. This String is then suppose to be able to be use in simple comparisons. That is it is the TargetID or InitiatorID, may save the string to be used during negations. If the manufacture assigns the name, it will also be inserted into the unit via some kind of interactive Tool. I do not understand why the Target or Initiator needs to have the purifying function called "NAMEPREP". This function should be done on the interactive Tool/Management routine, on which the Administrator, (or Manufacture) uses to enter the name. So I can not see that this causes us any significant problems, and it helps the Admin ease of use, and a help in reducing finger ck errors. Please set me straight if I have this wrong. . 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 Internet address: hufferd@us.ibm.com Glen Turner @ece.cmu.edu on 07/25/2001 01:03:40 AM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: IPS Subject: Re: iSCSI: Case-sensitivity in iSCSI names John Hufferd wrote: > > I want to jump on this bandwagon too. This seems to be exactly the right > approach. I'm showing some caution. It seems that NAMEPREP still requires casing tables. Where and how are these maintained? Does the proposal lead to language-based variants of iSCSI products. At the moment I can safely buy a hard disk drive from the USA and use it anywhere in the world: IDE, FC or SCSI. That should be so for iSCSI. Mark wrote: > Anyway, if this is to be used for domain names, we ought to use it, > too. Except that no-one is suggesting embedding DNS in a platform that won't be maintained after sale. Before support one way or the other I'd like to be clearer about the boundaries of iSCSI naming. Regards, Glen -- Glen Turner Network Engineer (08) 8303 3936 Australian Academic and Research Network glen.turner@aarnet.edu.au http://www.aarnet.edu.au/ -- The revolution will not be televised, it will be digitised From owner-ips@ece.cmu.edu Thu Jul 26 15:16:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04921 for ; Thu, 26 Jul 2001 15:16:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q6v9O20514 for ips-outgoing; Thu, 26 Jul 2001 02:57:09 -0400 (EDT) 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 f6Q6v8220509 for ; Thu, 26 Jul 2001 02:57:08 -0400 (EDT) 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 IAA19982 for ; Thu, 26 Jul 2001 08:57:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6Q6v0220798 for ; Thu, 26 Jul 2001 08:57:00 +0200 Importance: Normal Subject: Re: iSCSI: minor editorial request To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 26 Jul 2001 10:03:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 09:57:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, OK for the description. The name change involves perhaps some other changes and It is consistent with the field usage in other PDUs (with a similar treatement) and I would suggest is stays as is. Julo sandeepj@research.bell-labs.com (Sandeep Joshi) on 25-07-2001 21:08:10 Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: minor editorial request Julian, Minor request.. The text for expDataSN/expR2TSN fields in SCSI response. (Sec 2.4.7 and Sec 2.4.8) could be reworded to avoid confusion (this happened at the plugfest) The description currently states "One past the largest DataSN in an input data PDU..." Could be restated as "The number of read PDUs which were sent.." I wonder if the field name in SCSI response could also be changed to "numDataSN" (old=expDataSN) and "numR2TSN" (old=expR2TSN) to signify this. thanks, -Sandeep From owner-ips@ece.cmu.edu Thu Jul 26 15:39:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06445 for ; Thu, 26 Jul 2001 15:39:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6Q6STR19272 for ips-outgoing; Thu, 26 Jul 2001 02:28:29 -0400 (EDT) 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 f6Q6SS219268 for ; Thu, 26 Jul 2001 02:28:28 -0400 (EDT) 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 IAA38342 for ; Thu, 26 Jul 2001 08:28:21 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6Q6SK248524 for ; Thu, 26 Jul 2001 08:28:21 +0200 Importance: Normal Subject: Re: iSCSI: SecurityContextComplete without operational parameters To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Thu, 26 Jul 2001 09:34:27 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 26/07/2001 09:28:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, I DO UNDERSTAND both the complexity of writing and implementing a protocol. I do also understand that as long as we require negotiations to be atomic with regard to a complete sequence buffering and keeping temporary values must be implemented anyhow and adding restrictions does not simplify the task - as any restriction in the protocol adds a test. What I really do not understand is your apparent belief that by making the language of your statements "stronger" your will make your arguments more convincing. Julo "Robert D. Russell" on 25-07-2001 21:07:26 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters Julian: I think this exchange between you and Eddy illustrates the fundamental problem with login that everyone at the plugfest realized: the login process is too complex, we need to simplify it. Eddy was asking for a simplification -- that operational parameters NOT be sent with SCC=yes. The change you made does not do that, and the response you gave below "If not you should be able to handle them as you should be able to handle any set of parameters on the same PDU." illustrates to me that you do not understand the problem, which is that login is too complex "to handle any set of parameters on the same PDU". The combinations and misinterpretations of these combinations are horrendous. It needs to be simplified, and that is what Eddy is asking -- do NOT allow these arbitrary combinations. In the rewording you added the phrase "that need to be protected" in two places. Please remove that phrase from both places, because it defeats the whole purpose of the change and introduces more ambiguity -- who decides what needs to be protected and what doesn't? Suppose the target decides one thing and the initiator the other? Where is the defined list of parameters that "need" to be protected and those that do not "need" to be protected. etc. A big simplification is one requested a long time back by Barry Reinhold and recently reiterated in a new request by Rod Harrison of Wind River, which I strongly support, to mandate that the login PDU MUST only contain security parameters -- no operational parameters. Then the login MUST ALWAYS start with the security subphase, and MUST end with a handshake of messages that contained ONLY SecurityContextComplete from both target and initiator. Only then would the operational parameter negotiation start. I would also add to this recommendation that for normal logins (as opposed to discovery logins) the login MUST ALWAYS contain the TargetName and InitiatorName keys too. Furthermore, if the SessionType parameter is offered, it MUST be offered on the login. These changes would also clean up the wording in the standard, because: 1. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the new OpParmReset key (there is no way they could have changed). 2. By prohibiting any operational parameter negotiation before the security subphase was completed, there would be no need for the wording in 4.3 that talks about "Operational parameters negotiated inadvertently before the security/integrity negotiation" (a standard really shouldn't be allowing "inadvertent" things to happen). 3. The discussion in 4.1 about the TargetName and InitiatorName would be considerably simplified, since there would be no need for phrases like "If the iSCSI Target Name is going to be used in determining the security mode or it is implicit part of authentication," because it should just ALWAYS be sent. Phrases like the one just quoted cause enormous interoperability problems, because they introduce ambiguity that different implementers can resolve in different ways (who determines if the TargetName is going to be used? How? Who determines if it is implicit? How? etc.) I believe these suggestions, most of which have been made before, would simplify the login process. This is done by placing restrictions on what can be done when. It may involve the exchange of a few extra PDUs (ie. the text commands containing only SecurityContectComplete=yes), but logins are not part of the critical fast path and are not under tight time constraints -- it is more important that they be correct, unambiguous and easily interoperable than that they be superfast. Thank you, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Wed, 25 Jul 2001, Julian Satran wrote: > Eddy, > > I understood what you are asking but I don't necessarily agree. Operational > parameters are problematic if you want them exchanged in a secure > environment. If not you should be able to handle them as you should be able > to handle > any set of parameters on the same PDU. The need to keep them and perhaps > reset them is part of the negotiation process. > > Julo > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > What I was actually asking for is that the target would not send any > operational parameters in the same PDU as the SecurityContextComplete. > Rationalization given below. > > Eddy > > ----- Original Message ----- > From: "Julian Satran" > To: > Sent: Tuesday, July 24, 2001 10:08 AM > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > the new text will read: > > > > If the initiator has been the last to complete the handshake it > MUST > > NOT start sending operational parameters that need to be protected > > within the same text command; a text response including only > > SecurityContextComplete=yes concludes the security sub-phase. Only > > the following PDU exchange is protected by digests (if any). > > > > If the target has been the last to complete the handshake, the initiator > > can start the operational parameter negotiation with the next text > command; > > the security negotiation sub-phase ends with the target text response. > > However, the target handshake concluding response MUST NOT include > > operational parameters that need to be protected. Only the following PDU > > exchange is protected by digests (if any). > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > best > > if the target is required to send SecurityContextComplete=yes without any > > new operational parameters within the same PDU. > > > > It makes coding cleaner because the initiator can have a simple > > send/receive > > loop that pops out when security is complete. If operational parameters > are > > allowed with SecurityContextComplete=yes, the initiator's security module > > must also have operational parameter code or it must set flags, leave > > information in buffers, etc that all create messy code. > > > > The spec says: > > > > If the initiator has been the last to complete the handshake > it > > MUST NOT start sending operational parameters within the same > > text command. > > > > How about if we say the same thing for the target? There shouldn't be any > > harm because I suspect everyone is doing that anyway. > > > > Comments? > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 26 18:15:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17315 for ; Thu, 26 Jul 2001 18:15:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QKvaC13032 for ips-outgoing; Thu, 26 Jul 2001 16:57:36 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6QKvZ213027 for ; Thu, 26 Jul 2001 16:57:35 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id QAA29294; Thu, 26 Jul 2001 16:57:32 -0400 (EDT) Date: Thu, 26 Jul 2001 16:57:32 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: As a further simplification to the login process, I believe the InitiatorName and TargetName keys should both be required in the login command sent by the initiator. According to draft 7 page 158 and 159, these keys already "MUST be provided by the initiator of the TCP connection to the remote endpoint before the end of the login phase", and given that there is now a separate session type for discovery, I don't see any benefit in allowing the initiator to postpone sending these keys beyond the login command itself, and I do see lots of simplification possible if they are required on the login. (Could you please give me a situation for "normal" logins where there is a benefit to not having these keys in the login? Does that benefit outweigh the simplifications I am suggesting here?) This change simplifies the wording just quoted, which becomes "MUST be provided on the login command". It also eliminates the phrase "Some targets MAY require this key before authenticating." that is currently in the description of the 13 TargetName key on page 158 of draft 7. It also eliminates the phrase "the iSCSI Initiator Name MUST be sent before the target is required to disclose its LUs." in section 4.1 on page 99 of draft 7. It also eliminates the phrase "If the iSCSI Target Name is going to be used in determining the security mode or it is implicit part of authentication, then the iSCSI Target Name MUST be sent in the login command for the first connection of a session to identify the storage endpoint of the session." in section 4.1 on page 99 of draft 7. It also eliminates the phrase "If the iSCSI Target Name is going to be used only for access control, it can be sent after the Security Context Complete is achieved." in section 4.1 on page 99 of draft 7. It also eliminates the need for status code 0x0002 in the login response (page 73 of draft 7). It is also my belief that coding for the login phase is simplified by this requirement, due to the following: In draft 7 a target MAY need to check the login to see if it contains the TargetName in order to set the status code in the login response, and if it is missing, may need to go into a "wait for TargetName" state before proceeding with security checking. In the new version a target MUST check the login to see if it contains the TargetName (and InitiatorName) keys and can immediately reject the connection if they are missing -- no new target state is needed. The wording quoted above from section 4.1 talks about how these keys "may" be used by the target. The problems that I see with this current wording is there is no way for the initiator to know in advance how the target will use the information (so it doesn't know exactly when in the login sequence to send them), and there is no way for the target to inform the initiator about this in advance -- the initiator must simply try something and hope it works. If it doesn't, in most cases the connection will be rejected with "parameters missing". Of course, in the case when the TargetName is missing on the login, the partial login response has a special code to inform the initiator of the problem -- but suppose the target also needs the InitiatorName? How does the target inform the initiator of that? There currently does not seem to be a way, so after responding to the login partial response with the TargetName the initiator will still find the connection dropped anyway. I believe as a result of this complexity, most initiators will simply send both the TargetName and InitiatorName keys on the login command anyway (is there a good reason not to?), and so requiring that they MUST be on the login is not a hardship and will bring about the simplifications I just mentioned. Thanks for your consideration, Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 From owner-ips@ece.cmu.edu Thu Jul 26 19:53:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24053 for ; Thu, 26 Jul 2001 19:53:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QMSSs17786 for ips-outgoing; Thu, 26 Jul 2001 18:28:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com ([216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6QMSQ217781 for ; Thu, 26 Jul 2001 18:28:27 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters In-Reply-To: Message from "Robert D. Russell" of "Thu, 26 Jul 2001 16:56:23 EDT." References: Date: Thu, 26 Jul 2001 18:27:38 -0400 From: Stephen Bailey Message-Id: <20010726222825.9C7A34E8E@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > I believe the login process would be considerably simplified if it > were cleanly separated into two distinct subphases: the security > negotiation subphase, and the operational parameter subphase, with > a REQUIRED demarcation line (i.e., the SecurityContextComplete=yes > handshake) between them. I strongly agree with the thrust of Bob's suggestion here, but maybe not the details. Personally, I find the `SecurityContextComplete=' thing a bit of an irritant. It doesn't not add any additional information to either end, it only reconfirms that both ends are in sync. Every security handshake has an architected protocol where the completion is unambiguous to both ends, assuming the handshake has been properly implemented. As such, the context complete message is something that the endpoints must check, but it's a really odd condition if you receive it when you're not expecting it. The exception cases are either not getting the `ContextComplete' when you expect it, or getting `ContextComplete' prematurely. Either alternative indicates an implementation bug. Getting it prematurely is somewhat terrifying to contemplate :^) That said I think the login process should have little or NO branching complexity to it. Put another way, a state machine processing login would be a single spine, with the only branching being for failure. The FCP `negotiation' (AKA PRLI) is the right way to go. That is, EVERY parameter included in the request, and in the response. I also agree that having a strong demarcation between security exchange and operational parameter exchange is the right thing to do. To be fair, I believe that this demarcation is the intent of the spec even if it might not be well explained. If you wanted to apply the single spine principle to security and operational phases, you could stipulate that EVERY login have a security exchange, even if it leads to no security. Personally, having a single branch in the login state machine (security -> operational or just operational) probably wouldn't make a big difference one way or the other. A key question here is what's our target round trip time? I think a 70 MS RTT is a generous target, in which case, I don't see a really compelling reason to try an optimize for a single round-trip exchange in the no security case. However, maybe y'all think 1 S RTT is the target, in which case having the possibility of one round-trip login is a big improvement over a two-round trip login. Of course, that one round-trip wouldn't get you security. Steph From owner-ips@ece.cmu.edu Thu Jul 26 20:58:04 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26791 for ; Thu, 26 Jul 2001 20:58:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QNcdj20806 for ips-outgoing; Thu, 26 Jul 2001 19:38:39 -0400 (EDT) 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 f6QNcb220796 for ; Thu, 26 Jul 2001 19:38:37 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA10816 for ; Thu, 26 Jul 2001 19:38:20 -0400 (EDT) Message-ID: <3B60A94D.31E900F9@cisco.com> Date: Thu, 26 Jul 2001 18:35:41 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions 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: If the sequences mentioned below are all valid, plus the trivial sequence: I-> Login I-> Login-PR where these are all followed by Operational Parameter negotiation, I have a concern. Since either side is allowed to initiate the SecurityContextComplete=yes handshake, I would think that either Initiator or Target would transition to the next phase too soon if one side thought the handshake was needed, and the other side didn't. The only way I see to keep this from happening is either: 1. Don't allow the SecurityContextComplete=yes handshake unless AuthMethod, HeaderDigest, or DataDigest keys have been offered. 2. Always require the SecurityContextComplete=yes handshake. Regards, Steve Senum Julian Satran wrote: > > Yes that is (in 07) a legitmate sequence. Julo > > Steve Senum on 26-07-2001 00:25:19 > > Please respond to Steve Senum > > To: ietf-ips > cc: > Subject: Re: iSCSI Login Questions > > Julian, > > Is it valid (under draft -07) to offer the > SecurityContextComplete key without the AuthMethod, > HeaderDigest or DataDigest keys having been offered? > > In other words, are the following sequences valid? > > Sequence 1: > > I-> Login SecurityContextComplete=yes > T-> Login-PR SecurityContextComplete=yes > > Sequence 2: > > I-> Login > T-> Login-PR SecurityContextComplete=yes > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Sequence 3: > > I-> Login > I-> Login-PR > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Thanks, > Steve Senum From owner-ips@ece.cmu.edu Thu Jul 26 21:01:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26959 for ; Thu, 26 Jul 2001 21:01:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6QKuSB12980 for ips-outgoing; Thu, 26 Jul 2001 16:56:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6QKuP212967 for ; Thu, 26 Jul 2001 16:56:25 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id QAA29266; Thu, 26 Jul 2001 16:56:23 -0400 (EDT) Date: Thu, 26 Jul 2001 16:56:23 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI: SecurityContextComplete without operational parameters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian: > I DO UNDERSTAND both the complexity of writing and implementing a protocol. I do not doubt this, and apologize for anything I said that would lead you, or anyone else, to infer otherwise. Let me make my request again in different words: I believe the login process would be considerably simplified if it were cleanly separated into two distinct subphases: the security negotiation subphase, and the operational parameter subphase, with a REQUIRED demarcation line (i.e., the SecurityContextComplete=yes handshake) between them. I also believe the following will simplify the login process further (I hasten to add that these are not all my ideas -- most if not all have been mentioned by several other people in e-mails posted over the past several months -- I am attempting here to simply bring them all together and to supply additional justification for them): - if every login for a "normal" session (as opposed to discovery, etc.) must always start in the security subphase, - if before or during the security subphase operational parameters MUST NOT be offered or negotiated, - if this subphase MUST be terminate with an exchange of messages each containing only the key SecurityContextComplete=yes (plus perhaps informational keys, such as TargetName=, InitiatorName=, etc., but no other security keys and no operational keys). This exchange can be initiated by either the target or the initiator, and is completed by the response from the other party, at which time both parties put the negotiated security measures into effect. Only after this can operational parameters be sent by either side. If this is done: - we can eliminate the sentence in section 4.2 page 101 of draft 7 "When establishing the security context, any operational parameters sent before establishing a secure context MUST be discarded by both the target and the initiator." - The beginning of section 4.3 page 102 of draft 7 can be simplified by eliminating the phrase: "- starting with the Login command if the initiator does not offer any security/integrity option" - The beginning of section 4.3 page 102 of draft 7 can be simplified by replacing the whole paragraph: "An operational parameter negotiation on a connection SHOULD not start before the security/integrity negotiation if such a negotiation exists. Operational parameters negotiated inadvertently before the security/integrity negotiation MAY be reset after the security/ integrity negotiation at the explicit request of the initiator or target" with the simpler: "Operational parameter negotiation on a connection MUST not start start before the security/integrity negotiation has completed successfully." - the newly added key 35 OpParmReset on page 167 and 168 of draft 7 is entirely eliminated. I also strongly support: - the suggestion from Steve Senum that the initiator be required to send the AuthMethod, HeaderDigest and DataDigest keys on every login for a "normal" (as opposed to "discovery", etc.) session. - with the simplification suggested by Rod Harrison that if the initiator supports no security then the login command should contain only SecurityContextComplete=yes. Together these would ensure my first point above, namely that every login always starts in the security subphase. I would ask if there is any justification for NOT doing what Steve and Rod are suggesting? I will also suggest a further simplification in a follow up e-mail, but this one is already long enough. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Thu, 26 Jul 2001, Julian Satran wrote: > Robert, > > I DO UNDERSTAND both the complexity of writing and implementing a protocol. > I do also understand that as long as we require negotiations to be atomic > with regard to a complete sequence > buffering and keeping temporary values must be implemented anyhow and > adding restrictions does not simplify the task - as any restriction in the > protocol adds a test. > > What I really do not understand is your apparent belief that by making the > language of your statements "stronger" your will make your arguments more > convincing. > > Julo > > "Robert D. Russell" on 25-07-2001 21:07:26 > > Please respond to "Robert D. Russell" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SecurityContextComplete without operational parameters > > > > > Julian: > > I think this exchange between you and Eddy illustrates the fundamental > problem with login that everyone at the plugfest realized: > the login process is too complex, we need to simplify it. > > Eddy was asking for a simplification -- that operational parameters > NOT be sent with SCC=yes. The change you made does not do that, > and the response you gave below "If not you should be able to > handle them as you should be able to handle any set of parameters > on the same PDU." illustrates to me that you do not understand the > problem, which is that login is too complex "to handle any set of > parameters on the same PDU". The combinations and misinterpretations > of these combinations are horrendous. It needs to be simplified, > and that is what Eddy is asking -- do NOT allow these arbitrary > combinations. > > In the rewording you added the phrase "that need to be protected" in > two places. Please remove that phrase from both places, > because it defeats the whole purpose of the change and introduces more > ambiguity -- who decides what needs to be protected and what > doesn't? Suppose the target decides one thing and the initiator the > other? Where is the defined list of parameters that "need" to be > protected and those that do not "need" to be protected. etc. > > A big simplification is one requested a long time back by > Barry Reinhold and recently reiterated in a new request by > Rod Harrison of Wind River, which I strongly support, to mandate > that the login PDU MUST only contain security parameters -- no > operational parameters. Then the login MUST ALWAYS start with > the security subphase, and MUST end with a handshake of messages > that contained ONLY SecurityContextComplete from both target and > initiator. Only then would the operational parameter negotiation > start. I would also add to this recommendation that for normal > logins (as opposed to discovery logins) the login MUST ALWAYS > contain the TargetName and InitiatorName keys too. Furthermore, > if the SessionType parameter is offered, it MUST be offered on > the login. > > These changes would also clean up the wording in the standard, because: > > 1. By prohibiting any operational parameter negotiation before the > security subphase was completed, there would be no need for the > new OpParmReset key (there is no way they could have changed). > > 2. By prohibiting any operational parameter negotiation before the > security subphase was completed, there would be no need for the > wording in 4.3 that talks about "Operational parameters negotiated > inadvertently before the security/integrity negotiation" > (a standard really shouldn't be allowing "inadvertent" things to > happen). > > 3. The discussion in 4.1 about the TargetName and InitiatorName would > be considerably simplified, since there would be no need for > phrases like "If the iSCSI Target Name is going to be used in > determining the security mode or it is implicit part of > authentication," because it should just ALWAYS be sent. > Phrases like the one just quoted cause enormous interoperability > problems, because they introduce ambiguity that different > implementers can resolve in different ways (who determines if > the TargetName is going to be used? How? Who determines if it is > implicit? How? etc.) > > I believe these suggestions, most of which have been made before, > would simplify the login process. This is done by placing restrictions > on what can be done when. It may involve the exchange of a few > extra PDUs (ie. the text commands containing only > SecurityContectComplete=yes), but logins are not part of the critical > fast path and are not under tight time constraints -- it is more > important that they be correct, unambiguous and easily interoperable > than that they be superfast. > > Thank you, > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > > On Wed, 25 Jul 2001, Julian Satran wrote: > > > Eddy, > > > > I understood what you are asking but I don't necessarily agree. > Operational > > parameters are problematic if you want them exchanged in a secure > > environment. If not you should be able to handle them as you should be > able > > to handle > > any set of parameters on the same PDU. The need to keep them and perhaps > > reset them is part of the negotiation process. > > > > Julo > > > > "Eddy Quicksall" on 24-07-2001 20:35:18 > > > > Please respond to "Eddy Quicksall" > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > > > > What I was actually asking for is that the target would not send any > > operational parameters in the same PDU as the SecurityContextComplete. > > Rationalization given below. > > > > Eddy > > > > ----- Original Message ----- > > From: "Julian Satran" > > To: > > Sent: Tuesday, July 24, 2001 10:08 AM > > Subject: Re: iSCSI: SecurityContextComplete without operational > parameters > > > > > > > the new text will read: > > > > > > If the initiator has been the last to complete the handshake it > > MUST > > > NOT start sending operational parameters that need to be > protected > > > within the same text command; a text response including only > > > SecurityContextComplete=yes concludes the security sub-phase. > Only > > > the following PDU exchange is protected by digests (if any). > > > > > > If the target has been the last to complete the handshake, the > initiator > > > can start the operational parameter negotiation with the next text > > command; > > > the security negotiation sub-phase ends with the target text response. > > > However, the target handshake concluding response MUST NOT include > > > operational parameters that need to be protected. Only the following > PDU > > > exchange is protected by digests (if any). > > > > > > Julo > > > > > > "Eddy Quicksall" on 24-07-2001 15:55:05 > > > > > > Please respond to "Eddy Quicksall" > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: iSCSI: SecurityContextComplete without operational parameters > > > > > > > > > > > > > > > In section "4.2 iSCSI Security and Integrity Negotiation", it would be > > best > > > if the target is required to send SecurityContextComplete=yes without > any > > > new operational parameters within the same PDU. > > > > > > It makes coding cleaner because the initiator can have a simple > > > send/receive > > > loop that pops out when security is complete. If operational parameters > > are > > > allowed with SecurityContextComplete=yes, the initiator's security > module > > > must also have operational parameter code or it must set flags, leave > > > information in buffers, etc that all create messy code. > > > > > > The spec says: > > > > > > If the initiator has been the last to complete the handshake > > it > > > MUST NOT start sending operational parameters within the > same > > > text command. > > > > > > How about if we say the same thing for the target? There shouldn't be > any > > > harm because I suspect everyone is doing that anyway. > > > > > > Comments? > > > > > > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Thu Jul 26 21:59:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29889 for ; Thu, 26 Jul 2001 21:59:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6R0XE223318 for ips-outgoing; Thu, 26 Jul 2001 20:33:14 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-m05.mx.aol.com (imo-m05.mx.aol.com [64.12.136.8]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6R0XC223314 for ; Thu, 26 Jul 2001 20:33:12 -0400 (EDT) Received: from KA5VBS@aol.com by imo-m05.mx.aol.com (mail_out_v31.9.) id 3.a2.1769050f (4411) for ; Thu, 26 Jul 2001 20:33:03 -0400 (EDT) From: KA5VBS@aol.com Message-ID: Date: Thu, 26 Jul 2001 20:33:03 EDT Subject: iSCSI: Draft-07, Response Code conflict (2.4.3) To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_a2.1769050f.289210bf_boundary" X-Mailer: AOL 6.0 for Windows US sub 10532 Sender: owner-ips@ece.cmu.edu Precedence: bulk --part1_a2.1769050f.289210bf_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks, While looking through section 2.4.3, I noticed the following: First mention of response code 0x05 is described as "Command in progress" In the table that follows (about two paragraphs later) 0x05 is "SNACK rejected" Help me out and tell me which is correct! Thanks, Greg A. --part1_a2.1769050f.289210bf_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks,

While looking through section 2.4.3, I noticed the following:

First mention of response code 0x05 is described as "Command in progress"

In the table that follows (about two paragraphs later) 0x05 is "SNACK
rejected"

Help me out and tell me which is correct!

Thanks,

Greg A.
--part1_a2.1769050f.289210bf_boundary-- From owner-ips@ece.cmu.edu Thu Jul 26 22:57:43 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03110 for ; Thu, 26 Jul 2001 22:57:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6R1qIg26785 for ips-outgoing; Thu, 26 Jul 2001 21:52:18 -0400 (EDT) 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 f6R1qH226780 for ; Thu, 26 Jul 2001 21:52:17 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 128A32EE for ; Thu, 26 Jul 2001 21:52:17 -0400 (EDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id SAA27995 for ips@ece.cmu.edu; Thu, 26 Jul 2001 18:53:30 -0700 (PDT) Message-Id: <200107270153.SAA27995@core.rose.hp.com> Subject: Re: iSCSI: Draft-07, Response Code conflict (2.4.3) To: ips@ece.cmu.edu Date: Thu, 26 Jul 2001 18:53:30 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Greg, It is the latter - "SNACK rejected". Julian, may be we should remove the first listing, except stating the vendor-unique response codes. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >Folks, > >While looking through section 2.4.3, I noticed the following: > >First mention of response code 0x05 is described as "Command in progress" > >In the table that follows (about two paragraphs later) 0x05 is "SNACK >rejected" > >Help me out and tell me which is correct! > >Thanks, > >Greg A. > From owner-ips@ece.cmu.edu Thu Jul 26 22:59:45 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA03179 for ; Thu, 26 Jul 2001 22:59:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6R2O4I28254 for ips-outgoing; Thu, 26 Jul 2001 22:24:04 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07b.vwh1.net (mail07b.vwh1.net [209.238.9.59]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6R1tB226917 for ; Thu, 26 Jul 2001 21:55:11 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail07b.vwh1.net (RS ver 1.0.60s) with SMTP id 022244449; Thu, 26 Jul 2001 21:54:57 -0400 (EDT) From: "Dev - Platys" To: "Steve Senum" , Subject: RE: iSCSI Login Questions Date: Thu, 26 Jul 2001 18:58:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3B60A94D.31E900F9@cisco.com> X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve, I've closely following the thread and after going through the interactions, I think I've to clear my doubts and present my opinion. If I am NOT on right track, please set me straight. I agree that the current login sequence is highly flexible and compliance testing between initiator and targets will become a real issue. As said else where in this discussion we should give thoughts to reducing the number of handshakes for a login with and without authentication. I would also think that the initiator has implied that authmethod is none by not including it. Hence the following sequence is OK. I think if the order of the key=value pair of authentication namely authmethod (if not present assumed no authentication), SecurityCompleteContext=Yes be specified to be ahead of the other parameters. It will be helpful but not a necessity though. I-> Login SecurityContextComplete=yes + additional parameters. T-> Login-FR SecurityContextComplete=yes + additional parameters I think the side that requires authentication will give an error. If it is a target then login response will be an error code of authentication failure and if it is the initiator it can decide not to connect to the target by logging off the connection. BTW, Which one of the sequences are you suggesting? I guess you are for sequence 2) below. 1) I -> Login - AuthMethod=None T -> Login PR - SecurityContextComplete = Yes (May send a final response with error if the target requires authentication) I -> Text FR - SecurityContextComplete = Yes + additional parameters T -> Target Final Response - SecurityContextComplete = Yes + additional parameters 2) I -> Login - AuthMethod=None T -> Login PR - SecurityContextComplete = Yes (May send a final response with error if the target requires authentication) I -> Text PR - SecurityContextComplete = Yes T -> Text PR - SecurityContextComplete = Yes I -> Text FR - Parameters for negotiation T -> Target Final Response - Negotiated parameters thanks & regards Deva If the sequences mentioned below are all valid, plus the trivial sequence: I-> Login I-> Login-PR where these are all followed by Operational Parameter negotiation, I have a concern. Since either side is allowed to initiate the SecurityContextComplete=yes handshake, I would think that either Initiator or Target would transition to the next phase too soon if one side thought the handshake was needed, and the other side didn't. The only way I see to keep this from happening is either: 1. Don't allow the SecurityContextComplete=yes handshake unless AuthMethod, HeaderDigest, or DataDigest keys have been offered. 2. Always require the SecurityContextComplete=yes handshake. Regards, Steve Senum Julian Satran wrote: > > Yes that is (in 07) a legitmate sequence. Julo > > Steve Senum on 26-07-2001 00:25:19 > > Please respond to Steve Senum > > To: ietf-ips > cc: > Subject: Re: iSCSI Login Questions > > Julian, > > Is it valid (under draft -07) to offer the > SecurityContextComplete key without the AuthMethod, > HeaderDigest or DataDigest keys having been offered? > > In other words, are the following sequences valid? > > Sequence 1: > > I-> Login SecurityContextComplete=yes > T-> Login-PR SecurityContextComplete=yes > > Sequence 2: > > I-> Login > T-> Login-PR SecurityContextComplete=yes > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Sequence 3: > > I-> Login > I-> Login-PR > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Thanks, > Steve Senum From owner-ips@ece.cmu.edu Fri Jul 27 03:37:03 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28620 for ; Fri, 27 Jul 2001 03:37:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6R6Lkh07755 for ips-outgoing; Fri, 27 Jul 2001 02:21:46 -0400 (EDT) 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 f6R6Li207751 for ; Fri, 27 Jul 2001 02:21:44 -0400 (EDT) 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 IAA149766 for ; Fri, 27 Jul 2001 08:21:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6R6LaL123342 for ; Fri, 27 Jul 2001 08:21:37 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 09:27:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 09:21:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve, The sequence was meant to end always with an I,T handshake. If T starts it then we have a T,I,T exchange This is what I suggest for the my new proposal too. Phase transition starts always after a complete "instruction" (request response). Julo Steve Senum on 27-07-2001 02:35:41 Please respond to Steve Senum To: ips@ece.cmu.edu cc: Subject: Re: iSCSI Login Questions Julian: If the sequences mentioned below are all valid, plus the trivial sequence: I-> Login I-> Login-PR where these are all followed by Operational Parameter negotiation, I have a concern. Since either side is allowed to initiate the SecurityContextComplete=yes handshake, I would think that either Initiator or Target would transition to the next phase too soon if one side thought the handshake was needed, and the other side didn't. The only way I see to keep this from happening is either: 1. Don't allow the SecurityContextComplete=yes handshake unless AuthMethod, HeaderDigest, or DataDigest keys have been offered. 2. Always require the SecurityContextComplete=yes handshake. Regards, Steve Senum Julian Satran wrote: > > Yes that is (in 07) a legitmate sequence. Julo > > Steve Senum on 26-07-2001 00:25:19 > > Please respond to Steve Senum > > To: ietf-ips > cc: > Subject: Re: iSCSI Login Questions > > Julian, > > Is it valid (under draft -07) to offer the > SecurityContextComplete key without the AuthMethod, > HeaderDigest or DataDigest keys having been offered? > > In other words, are the following sequences valid? > > Sequence 1: > > I-> Login SecurityContextComplete=yes > T-> Login-PR SecurityContextComplete=yes > > Sequence 2: > > I-> Login > T-> Login-PR SecurityContextComplete=yes > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Sequence 3: > > I-> Login > I-> Login-PR > I-> Text SecurityContextComplete=yes > T-> Text SecurityContextComplete=yes > > Thanks, > Steve Senum From owner-ips@ece.cmu.edu Fri Jul 27 06:12:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05035 for ; Fri, 27 Jul 2001 06:12:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6R67Zg07242 for ips-outgoing; Fri, 27 Jul 2001 02:07:35 -0400 (EDT) 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 f6R67X207237 for ; Fri, 27 Jul 2001 02:07:33 -0400 (EDT) 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 IAA42744 for ; Fri, 27 Jul 2001 08:07:27 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6R67Qt42576 for ; Fri, 27 Jul 2001 08:07:26 +0200 Importance: Normal Subject: iSCSI login phasing To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 09:13:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 09:07:26 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, As some of you have complained about difficulty in implementing the login phase I thought it might be worthwhile to consider a slight departure from the current description. The current text assumes that negotiations are forming one tree and the "login machine" has to parse the tree. A leaf node will completely define a state and some pathes may get you to error. I was driven to this design by the need to keep the parsing tree minimal (under the assumption that any split in subtrees will result is some parameters needing to appear in several subtrees). However - after the noisy (mostly UPPERCASE) debate - I came to realize that few if any have done the generalized mapping I started with, and implemented a parser, and ad-hoc, man-glued, engines have to have smaller trees for the next plugfest (although by then some bright undergraduate student may take onto himself to give us an open-source yacc definition of the login phase!). I looked at the 2 phases and the number of key=values that they share are probably limited today at initiator and target names (some organizations/configurations want them for authentication while some others will object to them being revealed in the "open phase") and as such we may want to slit the login in 2, completely bracketed, phases each of them optional but not both: a security phase that if present must start with the login command and is bracketed by the pairs SecurityPhase=start and ended by SecurityPhase=end (on both initiator and target) an operational-parameter-negotiation phase that must follow security phase (if there is a security phase) and is bracketed by the pairs OperationalPhase=start and OperationalPhase=end (on both initiator and target) Some additional rules will apply: No request/response will span phases The phase closing handshake can start on both sides but if started at target will be followed by an "full initiator target handshake" - i.e a new phase or the "curtain close" end always with the target having the last word. keys will be clearly segregated and only a few (like names) should be allowed in both. Comments? Julo From owner-ips@ece.cmu.edu Fri Jul 27 09:00:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14475 for ; Fri, 27 Jul 2001 09:00:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RBUhQ00332 for ips-outgoing; Fri, 27 Jul 2001 07:30:43 -0400 (EDT) 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 f6RB90229499 for ; Fri, 27 Jul 2001 07:09:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06726; Fri, 27 Jul 2001 07:08:01 -0400 (EDT) Message-Id: <200107271108.HAA06726@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-iscsi-name-disc-02.txt Date: Fri, 27 Jul 2001 07:08:00 -0400 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 : iSCSI Naming and Discovery Requirements Author(s) : M. Bakke et al. Filename : draft-ietf-ips-iscsi-name-disc-02.txt Pages : 22 Date : 26-Jul-01 This document describes iSCSI [7] naming and discovery details. This document complements the iSCSI Protocol draft. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-iscsi-name-disc-02.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-iscsi-name-disc-02.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: <20010726170641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-name-disc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-name-disc-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Fri Jul 27 10:54:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24082 for ; Fri, 27 Jul 2001 10:54:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6REGZn07782 for ips-outgoing; Fri, 27 Jul 2001 10:16:35 -0400 (EDT) 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 f6RDcO205592 for ; Fri, 27 Jul 2001 09:38:24 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.171]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PV5XL1P9; Fri, 27 Jul 2001 09:38:17 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: iSCSI "bad practice" Date: Fri, 27 Jul 2001 09:37:27 -0400 Message-ID: <000501c116a1$605f2b40$ab01a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I don't think statements like "However not responding is considered bad practice and is discouraged." should be in a spec. The problem with this kind of statement is "well, what do I do if someone does that?". There can be all sorts of interpretations. If "not responding" is allowed, then so be it. If you don't want someone to "not respond", then say so. Can we please remove all of those ambiguous statements from the spec? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 10:56:25 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24261 for ; Fri, 27 Jul 2001 10:56:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RDl7V06103 for ips-outgoing; Fri, 27 Jul 2001 09:47:07 -0400 (EDT) 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 f6RDl6206099 for ; Fri, 27 Jul 2001 09:47:06 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA16058; Fri, 27 Jul 2001 09:47:00 -0400 (EDT) Message-ID: <3B616F7B.B5F42A73@cisco.com> Date: Fri, 27 Jul 2001 08:41:15 -0500 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: iSCSI: Reject, CmdSN, and DataSN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit When a PDU is rejected, I assume that the CmdSN is still updated, as well as the DataSN where applicable. That is, a rejected command still uses up a SN. It probably wouldn't hurt to state this in the reject section. Since the Reject response does not contain ExpCmdSN, if the last command before the window is closed is rejected, the initiator has to rely on prior commands completing to re-open the window. This will usually work, but what if the window size is reduced to one outstanding command for some reason? Any command that is rejected will close the window for good. A sequence of rejected commands equal to the window size will do the same. Any thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 10:56:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24273 for ; Fri, 27 Jul 2001 10:56:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RDqpY06383 for ips-outgoing; Fri, 27 Jul 2001 09:52:51 -0400 (EDT) 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 f6RDqo206379 for ; Fri, 27 Jul 2001 09:52:50 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Jul 2001 09:52:44 -0400 Message-ID: <25369470B6F0D41194820002B328BDD20266DB@ATLOPS> From: Sanjay Goyal To: ips@ece.cmu.edu Cc: Sanjay Goyal Subject: Crc-32c example in iSCSI spec Date: Fri, 27 Jul 2001 09:52:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi I tried matching the crc32c example results with mine for all ZEROs and all ONEs the result for Zeros matches whereas it does not match for all Ones. My result instead of 21 44 df 1c is 62 a8 ab 43 Can somebody clarify me on the issue. Regards Sanjay Goyal From owner-ips@ece.cmu.edu Fri Jul 27 10:57:01 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24372 for ; Fri, 27 Jul 2001 10:57:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RDVCN05240 for ips-outgoing; Fri, 27 Jul 2001 09:31:12 -0400 (EDT) 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 f6RDVB205236 for ; Fri, 27 Jul 2001 09:31:11 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA01856; Fri, 27 Jul 2001 09:31:05 -0400 (EDT) Message-ID: <3B616BC0.498A994A@cisco.com> Date: Fri, 27 Jul 2001 08:25:20 -0500 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: iSCSI: NOP-Out closing the command window Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit When sending a NOP-Out without the P bit set, there's no response to update ExpCmdSN to keep the window open. On an otherwise idle session, sending a long enough sequence of these NOP-Outs can close the command window permanently. In case of a stuck command window, please break glass... The easy solution is to turn on the P bit, and get the responses to update the window, but that defaults the purpose of allowing the P bit to not be set in the first place. Another easy solution (but I almost hate to mention it) is not to have NOP-Out update the CmdSN. This seems to have the possibility of breaking other things. I suppose we could come up with a more complicated rule, like "if the NOP-Out's CmdSN would be the last (or perhaps penultimate) CmdSN allowed by the current window, it MUST set the P bit." Or something like that. Anyway, I see three possible solutions. Any thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 12:26:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03316 for ; Fri, 27 Jul 2001 12:26:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFY1S12216 for ips-outgoing; Fri, 27 Jul 2001 11:34:01 -0400 (EDT) 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 f6RFY0212211 for ; Fri, 27 Jul 2001 11:34:00 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jul 27 11:33:05 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jul 27 11:33:36 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id LAA04588 for ips@ece.cmu.edu; Fri, 27 Jul 2001 11:33:03 -0400 (EDT) Date: Fri, 27 Jul 2001 11:33:03 -0400 (EDT) Message-Id: <200107271533.LAA04588@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: iSCSI-07: recovery Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments/questions on new Appendix F and related Section 7.x These are arranged sequentially down the appendix. -Sandeep 1) Page 173: What is the usage of nextCmdSN in the Connection structure ? If it is being used to check gaps, something like this seems more appropriate to the Session and not Connection. 2) Page 174: Within-command recovery Initiator algo for Recover-Data-If-Possible The step of sending an abort here could be skipped if the initiator knew that task has already completed at the target. This avoids an extra task cmd & response (Function-complete) The initiator knows the task has completed if this routine is invoked on an expDataSN mismatch in a SCSI Response (middle of page 175) 3) Top of Page 175: Within-command recovery Initiator algo for Receive-a-In-PDU When SoFarInOrder is False, and current DataSN is expected (its the next) then the action seems to be "discard; return". Is this correct ? So when does one *accept* the next DataSN (say 9) in the presence of outstanding missing data PDUs (say 4-6) 4) Page 175-176: Within-command recovery Initiator algo for Receive-a-In-PDU The psuedo-code under "Connection.SoFarInOrder is TRUE" could be moved to Within-Connection recovery since the logic applies to all other PDUs (not just SCSI response) sent from target bearing statSNs. 5) Page 177 : Within-command recovery Target algo for Receive-a-In-PDU Please confirm, can the target use R2T for digest errors on unsolicited bursts ? If yes, can we add an explicit statement to this effect. Neither Section 7.4.(a) nor this section seem to imply otherwise but just want to confirm. 6) Page 177 : Within-command recovery Target algo for Receive-a-In-PDU Bottom of the case for "if (CurrentPDU.type=DATA)" we have "if (TCB.activeR2Ts=0) Build-and-send-Status()" This needs an extra predicate as follows.. "If TCB.Response=DeliveryFailure && TCB.ActiveR2Ts=0" This is correct in Transfer-Context-Timeout-Handler. 7) Page 179 : Within-connection recovery Initiator algo for Recover-Status-If-Possible Typo error.. "note the missing statSNs in TCB" should be "note the missing statSNs in Connection" statSN list is per-connection state. 8) Page 180: Within-Connection recovery Initiator algo for Command-Acknowledge-Timeout-Handler This function seems like a better fit for the previous section on "within-command-recovery" and could be moved over there. 9) Page 184 : Within-Session recovery Target algo for Receive-A-In-PDU It does not cover the case of receiving a login-restart (implicit logout). This would have the same action as "logout.reason=recoveryRemove" From owner-ips@ece.cmu.edu Fri Jul 27 12:26:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03373 for ; Fri, 27 Jul 2001 12:26:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFhOG12743 for ips-outgoing; Fri, 27 Jul 2001 11:43:24 -0400 (EDT) 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 f6RFhM212738 for ; Fri, 27 Jul 2001 11:43:22 -0400 (EDT) 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 RAA33860 for ; Fri, 27 Jul 2001 17:43:16 +0200 Received: from d12hubm3.de.ibm.com (d12hubm3_tr0 [9.165.255.246]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RFhGt42808 for ; Fri, 27 Jul 2001 17:43:16 +0200 Importance: Normal Subject: Re: iSCSI padding should be 0 To: eddy_quicksall@ivivity.com Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Julian_Satran/Haifa/IBM%IBMIL Date: Fri, 27 Jul 2001 18:45:59 +0300 X-MIMETrack: Serialize by Router on D12HUBM3/12/H/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 17:47:18 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 12:28:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03546 for ; Fri, 27 Jul 2001 12:28:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6REtk509944 for ips-outgoing; Fri, 27 Jul 2001 10:55:46 -0400 (EDT) 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 f6REti209939 for ; Fri, 27 Jul 2001 10:55:45 -0400 (EDT) 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 QAA16708 for ; Fri, 27 Jul 2001 16:55:37 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6REtbL208624 for ; Fri, 27 Jul 2001 16:55:37 +0200 Importance: Normal Subject: Re: iSCSI: NOP-Out closing the command window To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 18:01:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 17:55:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, Definitely a problem . How about stating (the obvious) that NOP as any thing carying an ITT expectes an answer wheter it carries an echo (P=1) or not (P=0). If it does not carry an ITT it does not. We can have the following sequences all valid: I->T NOP +P=1 +I=x+ Data T->I NOP +P=0 + Data I->T NOP +P=0 +I=x+ Data T->I NOP +P=0 +I=x T->I NOP +P=1 +TTT I->T NOP +P=0 I=1 + TTT (no ITT) All would be permitted today if we remove the tie between ITT and P say that NOP must have an ITT if issued at initiators initiative. We might add as valid (today it is not, it is explicitly forbidden): T->I NOP +P=1 +TTT I->T NOP +P=1+ I= 1 TTT + ITT + Data T->I NOP +P=0 +ITT + Data The last requires us to "tweak" the termination rule (a target is forbiden to answer a P=1 with a P=1 comments? Julo Mark Bakke on 27-07-2001 16:25:20 Please respond to Mark Bakke To: IPS cc: Subject: iSCSI: NOP-Out closing the command window When sending a NOP-Out without the P bit set, there's no response to update ExpCmdSN to keep the window open. On an otherwise idle session, sending a long enough sequence of these NOP-Outs can close the command window permanently. In case of a stuck command window, please break glass... The easy solution is to turn on the P bit, and get the responses to update the window, but that defaults the purpose of allowing the P bit to not be set in the first place. Another easy solution (but I almost hate to mention it) is not to have NOP-Out update the CmdSN. This seems to have the possibility of breaking other things. I suppose we could come up with a more complicated rule, like "if the NOP-Out's CmdSN would be the last (or perhaps penultimate) CmdSN allowed by the current window, it MUST set the P bit." Or something like that. Anyway, I see three possible solutions. Any thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 12:30:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03891 for ; Fri, 27 Jul 2001 12:30:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFkLP12979 for ips-outgoing; Fri, 27 Jul 2001 11:46:21 -0400 (EDT) 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 f6RFkI212972 for ; Fri, 27 Jul 2001 11:46:19 -0400 (EDT) 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 RAA352924 for ; Fri, 27 Jul 2001 17:46:11 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RFkBL213678 for ; Fri, 27 Jul 2001 17:46:11 +0200 Importance: Normal Subject: Re: iSCSI Login Questions To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 18:52:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 18:46:11 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve - please refer to my proposal for a 2 phase login? If that fails the we can go back to the current discussion. Thanks, Julo Steve Senum on 27-07-2001 18:23:03 Please respond to Steve Senum To: ips@ece.cmu.edu cc: Subject: Re: iSCSI Login Questions Julian, I don't think I was clear in my last message. My concern is not with the details of the handshake. I think those are clearly specified in the current draft. My concern is under what conditions the handshake is done. By my current (perhaps wrong) understanding of draft -07, if AuthMethod, HeaderDigest, or DataDigest is offered in the opening login cmd/login rsp, then the handshake is a MUST. If AuthMethod, HeaderDigest and DataDigest are all not offered, then the handshake is a MAY. It is the second part (the MAY) of this I am having trouble with. I believe it needs to be either a MUST (handshake all the time), or a MUST NOT (handshake not allowed if AuthMethod, HeaderDigest or DataDigest all not offered). Regards, Steve Senum Julian Satran wrote: > > Steve, > > The sequence was meant to end always with an I,T handshake. If T starts it > then we have a T,I,T exchange > This is what I suggest for the my new proposal too. Phase transition starts > always after a complete "instruction" (request response). > > Julo > > Steve Senum on 27-07-2001 02:35:41 > > Please respond to Steve Senum > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI Login Questions > > Julian: > > If the sequences mentioned below are all valid, > plus the trivial sequence: > > I-> Login > I-> Login-PR > > where these are all followed by Operational > Parameter negotiation, I have a concern. > > Since either side is allowed to initiate > the SecurityContextComplete=yes handshake, > I would think that either Initiator or Target > would transition to the next phase too soon > if one side thought the handshake was needed, > and the other side didn't. > > The only way I see to keep this from happening > is either: > > 1. Don't allow the SecurityContextComplete=yes handshake > unless AuthMethod, HeaderDigest, or DataDigest keys > have been offered. > > 2. Always require the SecurityContextComplete=yes handshake. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > Yes that is (in 07) a legitmate sequence. Julo > > > > Steve Senum on 26-07-2001 00:25:19 > > > > Please respond to Steve Senum > > > > To: ietf-ips > > cc: > > Subject: Re: iSCSI Login Questions > > > > Julian, > > > > Is it valid (under draft -07) to offer the > > SecurityContextComplete key without the AuthMethod, > > HeaderDigest or DataDigest keys having been offered? > > > > In other words, are the following sequences valid? > > > > Sequence 1: > > > > I-> Login SecurityContextComplete=yes > > T-> Login-PR SecurityContextComplete=yes > > > > Sequence 2: > > > > I-> Login > > T-> Login-PR SecurityContextComplete=yes > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > Sequence 3: > > > > I-> Login > > I-> Login-PR > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > Thanks, > > Steve Senum From owner-ips@ece.cmu.edu Fri Jul 27 12:31:02 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03922 for ; Fri, 27 Jul 2001 12:31:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFpNJ13307 for ips-outgoing; Fri, 27 Jul 2001 11:51:23 -0400 (EDT) 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 f6RFIo211287 for ; Fri, 27 Jul 2001 11:18:51 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.171]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PV5XL1RQ; Fri, 27 Jul 2001 11:18:42 -0400 Reply-To: From: "Eddy Quicksall" To: , Subject: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 11:18:33 -0400 Message-ID: <000201c116af$67b00000$ab01a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 12:31:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03939 for ; Fri, 27 Jul 2001 12:31:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RF9Ab10695 for ips-outgoing; Fri, 27 Jul 2001 11:09:10 -0400 (EDT) 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 f6RF98210688 for ; Fri, 27 Jul 2001 11:09:08 -0400 (EDT) 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 RAA301270 for ; Fri, 27 Jul 2001 17:09:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RF91L177230 for ; Fri, 27 Jul 2001 17:09:01 +0200 Importance: Normal Subject: Re: iSCSI: Reject, CmdSN, and DataSN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 18:15:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 18:09:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk How about haing all the regular counts back in Reject (including StatSN for good measure)? Someting like: 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|1|1| 0x3f |1| Reserved (0) | +---------------+---------------+---------------+---------------+ 4| Reserved (0) | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8/ Reserved (0) / +/ / +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 26| Reserved (0) | +---------------+---------------+---------------+---------------+ 40| Reason | Reserved (0) | First Bad Byte or Rsvd(0) | +---------------+---------------+---------------+---------------+ 44| Reserved (0) | +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ xx/ Complete Header of Bad PDU / +/ / +---------------+---------------+---------------+---------------+ yy Julo Mark Bakke on 27-07-2001 16:41:15 Please respond to Mark Bakke To: IPS cc: Subject: iSCSI: Reject, CmdSN, and DataSN When a PDU is rejected, I assume that the CmdSN is still updated, as well as the DataSN where applicable. That is, a rejected command still uses up a SN. It probably wouldn't hurt to state this in the reject section. Since the Reject response does not contain ExpCmdSN, if the last command before the window is closed is rejected, the initiator has to rely on prior commands completing to re-open the window. This will usually work, but what if the window size is reduced to one outstanding command for some reason? Any command that is rejected will close the window for good. A sequence of rejected commands equal to the window size will do the same. Any thoughts? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 12:31:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03970 for ; Fri, 27 Jul 2001 12:31:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFwOg13805 for ips-outgoing; Fri, 27 Jul 2001 11:58:24 -0400 (EDT) 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 f6RFwN213801 for ; Fri, 27 Jul 2001 11:58:23 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA03321 for ; Fri, 27 Jul 2001 11:58:17 -0400 (EDT) Message-ID: <3B618EF9.308E8841@cisco.com> Date: Fri, 27 Jul 2001 10:55:37 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Deva, I think I might have lead you down the wrong track, at least with respect to what problem I was trying to discuss in my last message to Julian. See my reply to Julian on this thread. BTW, I would prefer to keep Operational Parameters Negotiation start after the final handshake message (sequence 2 below). Steve Senum Dev - Platys wrote: > > Steve, > > I've closely following the thread and after going through the interactions, > I think I've to clear my doubts and present my opinion. If I am NOT on right > track, please set me straight. > > I agree that the current login sequence is highly flexible and compliance > testing between initiator and targets will become a real issue. > As said else where in this discussion we should give thoughts to reducing > the number of handshakes for a login with and without authentication. > > I would also think that the initiator has implied that authmethod is none by > not including it. Hence the following sequence is OK. I think if the order > of the key=value pair of authentication namely authmethod (if not present > assumed no authentication), SecurityCompleteContext=Yes be specified to be > ahead of the other parameters. It will be helpful but not a necessity > though. > > I-> Login SecurityContextComplete=yes + additional parameters. > T-> Login-FR SecurityContextComplete=yes + additional parameters > > I think the side that requires authentication will give an error. If it is a > target then login response will be an error code > of authentication failure and if it is the initiator it can decide not to > connect to the target by logging off the connection. > > BTW, Which one of the sequences are you suggesting? I guess you are for > sequence 2) below. > > 1) I -> Login - AuthMethod=None > T -> Login PR - SecurityContextComplete = Yes (May send a final response > with error if the target requires authentication) > I -> Text FR - SecurityContextComplete = Yes + additional parameters > T -> Target Final Response - SecurityContextComplete = Yes + additional > parameters > > 2) I -> Login - AuthMethod=None > T -> Login PR - SecurityContextComplete = Yes (May send a final response > with error if the target requires authentication) > I -> Text PR - SecurityContextComplete = Yes > T -> Text PR - SecurityContextComplete = Yes > I -> Text FR - Parameters for negotiation > T -> Target Final Response - Negotiated parameters > > thanks & regards > > Deva From owner-ips@ece.cmu.edu Fri Jul 27 12:31:19 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03984 for ; Fri, 27 Jul 2001 12:31:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFpdP13326 for ips-outgoing; Fri, 27 Jul 2001 11:51:39 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6RFQU211783 for ; Fri, 27 Jul 2001 11:26:30 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail07a.vwh1.net (RS ver 1.0.60s) with SMTP id 027337327; Fri, 27 Jul 2001 11:26:14 -0400 (EDT) From: "Dev - Platys" To: "Julian Satran" , Subject: RE: iSCSI login phasing Date: Fri, 27 Jul 2001 08:30:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, So this proposal allows the operational parameters to be issued during login request itself if it there is no authentication ? i.e. I ->FR Login -> Operational Parameters = Start key1=x, key2 =x, Operational Parameters = End T ->FR Login -> Operation Parameters = Start key=x, key2=x, key3=x In the above case, since no authentication is involved thre is no security phase start end. Also the keywords SecurityPhase=Start and SecurityPhase=end mandatory so to be used even during non authentication phases. Thanks Deva -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Thursday, July 26, 2001 11:14 PM To: ips@ece.cmu.edu Subject: iSCSI login phasing Dear colleagues, As some of you have complained about difficulty in implementing the login phase I thought it might be worthwhile to consider a slight departure from the current description. The current text assumes that negotiations are forming one tree and the "login machine" has to parse the tree. A leaf node will completely define a state and some pathes may get you to error. I was driven to this design by the need to keep the parsing tree minimal (under the assumption that any split in subtrees will result is some parameters needing to appear in several subtrees). However - after the noisy (mostly UPPERCASE) debate - I came to realize that few if any have done the generalized mapping I started with, and implemented a parser, and ad-hoc, man-glued, engines have to have smaller trees for the next plugfest (although by then some bright undergraduate student may take onto himself to give us an open-source yacc definition of the login phase!). I looked at the 2 phases and the number of key=values that they share are probably limited today at initiator and target names (some organizations/configurations want them for authentication while some others will object to them being revealed in the "open phase") and as such we may want to slit the login in 2, completely bracketed, phases each of them optional but not both: a security phase that if present must start with the login command and is bracketed by the pairs SecurityPhase=start and ended by SecurityPhase=end (on both initiator and target) an operational-parameter-negotiation phase that must follow security phase (if there is a security phase) and is bracketed by the pairs OperationalPhase=start and OperationalPhase=end (on both initiator and target) Some additional rules will apply: No request/response will span phases The phase closing handshake can start on both sides but if started at target will be followed by an "full initiator target handshake" - i.e a new phase or the "curtain close" end always with the target having the last word. keys will be clearly segregated and only a few (like names) should be allowed in both. Comments? Julo From owner-ips@ece.cmu.edu Fri Jul 27 12:33:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04207 for ; Fri, 27 Jul 2001 12:33:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFKum11472 for ips-outgoing; Fri, 27 Jul 2001 11:20:56 -0400 (EDT) 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 f6RFKs211467 for ; Fri, 27 Jul 2001 11:20:55 -0400 (EDT) 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 RAA11452; Fri, 27 Jul 2001 17:20:48 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RFKlt63146; Fri, 27 Jul 2001 17:20:47 +0200 Importance: Normal Subject: Re: iSCSI "bad practice" To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 18:26:52 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 18:20:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sure I can - I wanted to point out that such an answer will be harder to read (infer) on a trace and I can change it to: For numerical (and binary) negotiations, the responding party SHOULD respond with the required key but the offering party MUST accept no answer as equivalent to answering with the default value. Thanks, Julo "Eddy Quicksall" on 27-07-2001 16:37:27 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI "bad practice" I don't think statements like "However not responding is considered bad practice and is discouraged." should be in a spec. The problem with this kind of statement is "well, what do I do if someone does that?". There can be all sorts of interpretations. If "not responding" is allowed, then so be it. If you don't want someone to "not respond", then say so. Can we please remove all of those ambiguous statements from the spec? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 12:33:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04239 for ; Fri, 27 Jul 2001 12:33:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFeNN12554 for ips-outgoing; Fri, 27 Jul 2001 11:40:23 -0400 (EDT) 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 f6RFeM212549 for ; Fri, 27 Jul 2001 11:40:22 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA15824; Fri, 27 Jul 2001 11:40:14 -0400 (EDT) Message-ID: <3B618A05.FC706EDD@cisco.com> Date: Fri, 27 Jul 2001 10:34:29 -0500 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: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: Reject, CmdSN, and DataSN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit That should work just fine, and will make more of the commands work the same. I'll have to think about StatSN; if a Reject command has a StatSN, it will have to be saved for possible recovery later, possibly by re-sending the rejected command? I think it would be better to not include StatSN in Reject for that reason, although I'm not sure my thoughts are fully baked on this one. -- Mark Julian Satran wrote: > > How about haing all the regular counts back in Reject (including StatSN for > good measure)? > > Someting like: > > 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|1|1| 0x3f |1| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 4| Reserved (0) | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8/ Reserved (0) / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 26| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 40| Reason | Reserved (0) | First Bad Byte or Rsvd(0) | > +---------------+---------------+---------------+---------------+ > 44| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > xx/ Complete Header of Bad PDU / > +/ / > +---------------+---------------+---------------+---------------+ > yy > > Julo > > Mark Bakke on 27-07-2001 16:41:15 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: Reject, CmdSN, and DataSN > > When a PDU is rejected, I assume that the CmdSN is still > updated, as well as the DataSN where applicable. That is, > a rejected command still uses up a SN. It probably wouldn't > hurt to state this in the reject section. > > Since the Reject response does not contain ExpCmdSN, if the > last command before the window is closed is rejected, the > initiator has to rely on prior commands completing to re-open > the window. This will usually work, but what if the window > size is reduced to one outstanding command for some reason? > Any command that is rejected will close the window for good. > A sequence of rejected commands equal to the window size will > do the same. > > Any thoughts? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 12:33:42 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04278 for ; Fri, 27 Jul 2001 12:33:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFs3m13510 for ips-outgoing; Fri, 27 Jul 2001 11:54:03 -0400 (EDT) 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 f6RFs0213490 for ; Fri, 27 Jul 2001 11:54:00 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Fri Jul 27 11:53:22 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Fri Jul 27 11:53:53 EDT 2001 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 LAA06625 for ; Fri, 27 Jul 2001 11:53:20 -0400 (EDT) Message-ID: <3B618E70.ADD92698@research.bell-labs.com> Date: Fri, 27 Jul 2001 11:53:20 -0400 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: NOP-Out closing the command window 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 the NOP-Out does not have the ping-bit set, then it is a ping response and *not* a new command being issued by the initiator. Hence, it seems that the NOP-OUT with P=0 need not carry a new cmdSN (Mark's 2nd option). Btw, I did not know the 2nd sequence (P=0 from initiator?) below was valid > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x -Sandeep Julian Satran wrote: > > Mark, > > Definitely a problem . How about stating (the obvious) that NOP as any > thing carying an ITT expectes an answer > wheter it carries an echo (P=1) or not (P=0). > > If it does not carry an ITT it does not. > > We can have the following sequences all valid: > > I->T NOP +P=1 +I=x+ Data > T->I NOP +P=0 + Data > > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x > > T->I NOP +P=1 +TTT > I->T NOP +P=0 I=1 + TTT (no ITT) > > All would be permitted today if we remove the tie between ITT and P say > that NOP must have an ITT if issued at initiators initiative. > > We might add as valid (today it is not, it is explicitly forbidden): > > T->I NOP +P=1 +TTT > I->T NOP +P=1+ I= 1 TTT + ITT + Data > T->I NOP +P=0 +ITT + Data > > The last requires us to "tweak" the termination rule (a target is forbiden > to answer a P=1 with a P=1 > > comments? > Julo > > Mark Bakke on 27-07-2001 16:25:20 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: NOP-Out closing the command window > > When sending a NOP-Out without the P bit set, there's > no response to update ExpCmdSN to keep the window open. > > On an otherwise idle session, sending a long enough > sequence of these NOP-Outs can close the command window > permanently. > > In case of a stuck command window, please break glass... > > The easy solution is to turn on the P bit, and get the > responses to update the window, but that defaults the > purpose of allowing the P bit to not be set in the first > place. > > Another easy solution (but I almost hate to mention it) > is not to have NOP-Out update the CmdSN. This seems to > have the possibility of breaking other things. > > I suppose we could come up with a more complicated rule, > like "if the NOP-Out's CmdSN would be the last (or perhaps > penultimate) CmdSN allowed by the current window, it MUST > set the P bit." Or something like that. > > Anyway, I see three possible solutions. Any thoughts? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 13:26:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04034 for ; Fri, 27 Jul 2001 12:31:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFPnh11745 for ips-outgoing; Fri, 27 Jul 2001 11:25:49 -0400 (EDT) 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 f6RFPm211741 for ; Fri, 27 Jul 2001 11:25:48 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA01002 for ; Fri, 27 Jul 2001 11:25:42 -0400 (EDT) Message-ID: <3B618757.9766AEA0@cisco.com> Date: Fri, 27 Jul 2001 10:23:03 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Re: iSCSI Login Questions 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, I don't think I was clear in my last message. My concern is not with the details of the handshake. I think those are clearly specified in the current draft. My concern is under what conditions the handshake is done. By my current (perhaps wrong) understanding of draft -07, if AuthMethod, HeaderDigest, or DataDigest is offered in the opening login cmd/login rsp, then the handshake is a MUST. If AuthMethod, HeaderDigest and DataDigest are all not offered, then the handshake is a MAY. It is the second part (the MAY) of this I am having trouble with. I believe it needs to be either a MUST (handshake all the time), or a MUST NOT (handshake not allowed if AuthMethod, HeaderDigest or DataDigest all not offered). Regards, Steve Senum Julian Satran wrote: > > Steve, > > The sequence was meant to end always with an I,T handshake. If T starts it > then we have a T,I,T exchange > This is what I suggest for the my new proposal too. Phase transition starts > always after a complete "instruction" (request response). > > Julo > > Steve Senum on 27-07-2001 02:35:41 > > Please respond to Steve Senum > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI Login Questions > > Julian: > > If the sequences mentioned below are all valid, > plus the trivial sequence: > > I-> Login > I-> Login-PR > > where these are all followed by Operational > Parameter negotiation, I have a concern. > > Since either side is allowed to initiate > the SecurityContextComplete=yes handshake, > I would think that either Initiator or Target > would transition to the next phase too soon > if one side thought the handshake was needed, > and the other side didn't. > > The only way I see to keep this from happening > is either: > > 1. Don't allow the SecurityContextComplete=yes handshake > unless AuthMethod, HeaderDigest, or DataDigest keys > have been offered. > > 2. Always require the SecurityContextComplete=yes handshake. > > Regards, > Steve Senum > > Julian Satran wrote: > > > > Yes that is (in 07) a legitmate sequence. Julo > > > > Steve Senum on 26-07-2001 00:25:19 > > > > Please respond to Steve Senum > > > > To: ietf-ips > > cc: > > Subject: Re: iSCSI Login Questions > > > > Julian, > > > > Is it valid (under draft -07) to offer the > > SecurityContextComplete key without the AuthMethod, > > HeaderDigest or DataDigest keys having been offered? > > > > In other words, are the following sequences valid? > > > > Sequence 1: > > > > I-> Login SecurityContextComplete=yes > > T-> Login-PR SecurityContextComplete=yes > > > > Sequence 2: > > > > I-> Login > > T-> Login-PR SecurityContextComplete=yes > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > Sequence 3: > > > > I-> Login > > I-> Login-PR > > I-> Text SecurityContextComplete=yes > > T-> Text SecurityContextComplete=yes > > > > Thanks, > > Steve Senum From owner-ips@ece.cmu.edu Fri Jul 27 13:26:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04003 for ; Fri, 27 Jul 2001 12:31:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RFnNq13167 for ips-outgoing; Fri, 27 Jul 2001 11:49:23 -0400 (EDT) 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 f6RFnM213162 for ; Fri, 27 Jul 2001 11:49:22 -0400 (EDT) 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 RAA102728 for ; Fri, 27 Jul 2001 17:49:14 +0200 Received: from d12hubm3.de.ibm.com (d12hubm3_tr0 [9.165.255.246]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RFnFL105758 for ; Fri, 27 Jul 2001 17:49:15 +0200 Importance: Normal Subject: RE: iSCSI login phasing To: "Dev - Platys" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Julian_Satran/Haifa/IBM%IBMIL Date: Fri, 27 Jul 2001 18:55:17 +0300 X-MIMETrack: Serialize by Router on D12HUBM3/12/H/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 17:53:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Deva, If there is no security phase the keywords SEcurityPhase start/end don't have to be used. Julo "Dev - Platys" on 27-07-2001 18:30:14 Please respond to "Dev - Platys" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI login phasing Julian, So this proposal allows the operational parameters to be issued during login request itself if it there is no authentication ? i.e. I ->FR Login -> Operational Parameters = Start key1=x, key2 =x, Operational Parameters = End T ->FR Login -> Operation Parameters = Start key=x, key2=x, key3=x In the above case, since no authentication is involved thre is no security phase start end. Also the keywords SecurityPhase=Start and SecurityPhase=end mandatory so to be used even during non authentication phases. Thanks Deva -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Thursday, July 26, 2001 11:14 PM To: ips@ece.cmu.edu Subject: iSCSI login phasing Dear colleagues, As some of you have complained about difficulty in implementing the login phase I thought it might be worthwhile to consider a slight departure from the current description. The current text assumes that negotiations are forming one tree and the "login machine" has to parse the tree. A leaf node will completely define a state and some pathes may get you to error. I was driven to this design by the need to keep the parsing tree minimal (under the assumption that any split in subtrees will result is some parameters needing to appear in several subtrees). However - after the noisy (mostly UPPERCASE) debate - I came to realize that few if any have done the generalized mapping I started with, and implemented a parser, and ad-hoc, man-glued, engines have to have smaller trees for the next plugfest (although by then some bright undergraduate student may take onto himself to give us an open-source yacc definition of the login phase!). I looked at the 2 phases and the number of key=values that they share are probably limited today at initiator and target names (some organizations/configurations want them for authentication while some others will object to them being revealed in the "open phase") and as such we may want to slit the login in 2, completely bracketed, phases each of them optional but not both: a security phase that if present must start with the login command and is bracketed by the pairs SecurityPhase=start and ended by SecurityPhase=end (on both initiator and target) an operational-parameter-negotiation phase that must follow security phase (if there is a security phase) and is bracketed by the pairs OperationalPhase=start and OperationalPhase=end (on both initiator and target) Some additional rules will apply: No request/response will span phases The phase closing handshake can start on both sides but if started at target will be followed by an "full initiator target handshake" - i.e a new phase or the "curtain close" end always with the target having the last word. keys will be clearly segregated and only a few (like names) should be allowed in both. Comments? Julo From owner-ips@ece.cmu.edu Fri Jul 27 15:08:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20931 for ; Fri, 27 Jul 2001 15:08:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGLSk15348 for ips-outgoing; Fri, 27 Jul 2001 12:21:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RGLR215344 for ; Fri, 27 Jul 2001 12:21:27 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 1614E132D for ; Fri, 27 Jul 2001 09:21:26 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id JAA01214 for ips@ece.cmu.edu; Fri, 27 Jul 2001 09:22:40 -0700 (PDT) Message-Id: <200107271622.JAA01214@core.rose.hp.com> Subject: Re: iSCSI: Draft-07, Response Code conflict (2.4.3) (fwd) To: ips@ece.cmu.edu Date: Fri, 27 Jul 2001 9:22:39 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk I assume Julian meant to send this to ips. Forwarded message: Importance: Normal Subject: Re: iSCSI: Draft-07, Response Code conflict (2.4.3) To: cbm@rose.hp.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 10:25:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 10:19:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Status: RO Greg, Yes it is SNACK rejected. Command in progress shlould appear only as a Reject reponse (06) in 2.19.1. I've made the required correction. Thanks, Julo "Mallikarjun C." on 27-07-2001 04:53:30 Please respond to cbm@rose.hp.com To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Draft-07, Response Code conflict (2.4.3) Greg, It is the latter - "SNACK rejected". Julian, may be we should remove the first listing, except stating the vendor-unique response codes. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > >Folks, > >While looking through section 2.4.3, I noticed the following: > >First mention of response code 0x05 is described as "Command in progress" > >In the table that follows (about two paragraphs later) 0x05 is "SNACK >rejected" > >Help me out and tell me which is correct! > >Thanks, > >Greg A. > From owner-ips@ece.cmu.edu Fri Jul 27 15:09:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21188 for ; Fri, 27 Jul 2001 15:09:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGSM315792 for ips-outgoing; Fri, 27 Jul 2001 12:28:22 -0400 (EDT) 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 f6RGQd215714 for ; Fri, 27 Jul 2001 12:26:40 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.171]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PV5XL1SM; Fri, 27 Jul 2001 12:26:28 -0400 Reply-To: From: "Eddy Quicksall" To: "'Julian Satran'" Cc: Subject: RE: iSCSI "bad practice" Date: Fri, 27 Jul 2001 12:26:21 -0400 Message-ID: <000401c116b8$dfb4b4c0$ab01a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Works for me. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 27, 2001 11:27 AM To: eddy_quicksall@ivivity.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI "bad practice" Sure I can - I wanted to point out that such an answer will be harder to read (infer) on a trace and I can change it to: For numerical (and binary) negotiations, the responding party SHOULD respond with the required key but the offering party MUST accept no answer as equivalent to answering with the default value. Thanks, Julo "Eddy Quicksall" on 27-07-2001 16:37:27 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI "bad practice" I don't think statements like "However not responding is considered bad practice and is discouraged." should be in a spec. The problem with this kind of statement is "well, what do I do if someone does that?". There can be all sorts of interpretations. If "not responding" is allowed, then so be it. If you don't want someone to "not respond", then say so. Can we please remove all of those ambiguous statements from the spec? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 15:13:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21574 for ; Fri, 27 Jul 2001 15:13:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGDX614802 for ips-outgoing; Fri, 27 Jul 2001 12:13:33 -0400 (EDT) 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 f6RGDV214796 for ; Fri, 27 Jul 2001 12:13:31 -0400 (EDT) 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 SAA121428 for ; Fri, 27 Jul 2001 18:13:25 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f6RGDOL177184 for ; Fri, 27 Jul 2001 18:13:24 +0200 Importance: Normal Subject: Re: iSCSI: NOP-Out closing the command window To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Fri, 27 Jul 2001 19:19:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 27/07/2001 19:13:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, They are 3 distinguishing elements P and the ITT+TTT. Julo Sandeep Joshi on 27-07-2001 18:53:20 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: NOP-Out closing the command window If the NOP-Out does not have the ping-bit set, then it is a ping response and *not* a new command being issued by the initiator. Hence, it seems that the NOP-OUT with P=0 need not carry a new cmdSN (Mark's 2nd option). Btw, I did not know the 2nd sequence (P=0 from initiator?) below was valid > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x -Sandeep Julian Satran wrote: > > Mark, > > Definitely a problem . How about stating (the obvious) that NOP as any > thing carying an ITT expectes an answer > wheter it carries an echo (P=1) or not (P=0). > > If it does not carry an ITT it does not. > > We can have the following sequences all valid: > > I->T NOP +P=1 +I=x+ Data > T->I NOP +P=0 + Data > > I->T NOP +P=0 +I=x+ Data > T->I NOP +P=0 +I=x > > T->I NOP +P=1 +TTT > I->T NOP +P=0 I=1 + TTT (no ITT) > > All would be permitted today if we remove the tie between ITT and P say > that NOP must have an ITT if issued at initiators initiative. > > We might add as valid (today it is not, it is explicitly forbidden): > > T->I NOP +P=1 +TTT > I->T NOP +P=1+ I= 1 TTT + ITT + Data > T->I NOP +P=0 +ITT + Data > > The last requires us to "tweak" the termination rule (a target is forbiden > to answer a P=1 with a P=1 > > comments? > Julo > > Mark Bakke on 27-07-2001 16:25:20 > > Please respond to Mark Bakke > > To: IPS > cc: > Subject: iSCSI: NOP-Out closing the command window > > When sending a NOP-Out without the P bit set, there's > no response to update ExpCmdSN to keep the window open. > > On an otherwise idle session, sending a long enough > sequence of these NOP-Outs can close the command window > permanently. > > In case of a stuck command window, please break glass... > > The easy solution is to turn on the P bit, and get the > responses to update the window, but that defaults the > purpose of allowing the P bit to not be set in the first > place. > > Another easy solution (but I almost hate to mention it) > is not to have NOP-Out update the CmdSN. This seems to > have the possibility of breaking other things. > > I suppose we could come up with a more complicated rule, > like "if the NOP-Out's CmdSN would be the last (or perhaps > penultimate) CmdSN allowed by the current window, it MUST > set the P bit." Or something like that. > > Anyway, I see three possible solutions. Any thoughts? > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 From owner-ips@ece.cmu.edu Fri Jul 27 15:16:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21771 for ; Fri, 27 Jul 2001 15:16:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGgxl16659 for ips-outgoing; Fri, 27 Jul 2001 12:42:59 -0400 (EDT) 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 f6RGgv216653 for ; Fri, 27 Jul 2001 12:42:57 -0400 (EDT) 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 f6RGgtN21405 for ; Fri, 27 Jul 2001 12:42:56 -0400 (EDT) content-class: urn:content-classes:message Subject: New Draft: FCIP Discovery MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 27 Jul 2001 12:42:55 -0400 Disposition-Notification-To: "Elizabeth Rodriguez" X-Mimeole: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D4538236498360435EE@nc8220exchange.ral.lucent.com> Thread-Topic: FCIP discovery: New draft Thread-Index: AcEWXT+FtW+NTtPKQ2OGhinX18NHCwAXXZPg From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Cc: "David Black (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f6RGgw216654 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, A request to create a new draft addressing FCIP discovery has been posed to the IPS WG chairs. This draft will focus on the use of SLP for dynamic discovery of FCIP based devices. (Per consensus call on 5/25/2001, discovery for FCIP based devices will use either static discovery or SLP for dynamic discovery). The chairs have approved the request for a new draft. A small design team will be working on the initial revision of this draft. Anyone interested in working on this draft should contact David or myself. The target will be to present the first draft at the IPS interim meeting on August 27. As such, this initial draft will need to be submitted to the IETF no later than the week of August 13. (Exact date yet to be determined). Thanks, Elizabeth Rodriguez IETF IPS Co-Chair From owner-ips@ece.cmu.edu Fri Jul 27 15:21:32 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22248 for ; Fri, 27 Jul 2001 15:21:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGSGv15780 for ips-outgoing; Fri, 27 Jul 2001 12:28:16 -0400 (EDT) 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 f6RGOn215587 for ; Fri, 27 Jul 2001 12:24:49 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.171]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PV5XL1S2; Fri, 27 Jul 2001 12:24:40 -0400 Reply-To: From: "Eddy Quicksall" To: "'Julian Satran'" Cc: "'ips'" Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 12:24:24 -0400 Message-ID: <000301c116b8$9db62cc0$ab01a8c0@eddylaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sounds good to me. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 27, 2001 11:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 15:24:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22443 for ; Fri, 27 Jul 2001 15:24:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGM6e15380 for ips-outgoing; Fri, 27 Jul 2001 12:22:06 -0400 (EDT) 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 f6RGM4215373 for ; Fri, 27 Jul 2001 12:22:04 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA26150 for ; Fri, 27 Jul 2001 12:21:59 -0400 (EDT) Message-ID: <3B619487.3D8AD06B@cisco.com> Date: Fri, 27 Jul 2001 11:19:19 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI login phasing 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, Questions on your proposal. 1. Is the Initiator then required to start with either a SecurityPhase=start or an OperationalPhase=start on the initial login command? 2. If the Initiator started with OperationalPhase=start, does the target have any way to force a SecurityPhase=start? Steve Senum Julian Satran wrote: > > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > Comments? > > Julo From owner-ips@ece.cmu.edu Fri Jul 27 15:43:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24622 for ; Fri, 27 Jul 2001 15:43:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RHLU118823 for ips-outgoing; Fri, 27 Jul 2001 13:21:30 -0400 (EDT) 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 f6RHLS218817 for ; Fri, 27 Jul 2001 13:21:28 -0400 (EDT) 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 KAA27451; Fri, 27 Jul 2001 10:21:22 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA08829; Fri, 27 Jul 2001 10:09:38 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 10:21:22 -0700 Message-ID: From: "Fischer, Michael" To: "'eddy_quicksall@ivivity.com'" , julian_satran@il.ibm.com Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 10:21:13 -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 Eddy, This discussion is purely based on semantics and the definition of the word. MUST indicates that it is REQUIRED. Yes? If it is REQUIRED that the padding be set to 0 and it is NOT then that implementation is in violation of the spec. Yes? You are correct that the RFC does not say that you must check it but it does imply it (or at least that it is checkable), which is what I stated. My concern is that Julian suggested that the spec say MUST be 0 and that he did NOT want people to check for 0. To insure that it is not checked, the statement MUST remain "SHOULD be 0." In the production environment, the checking of whether or not the padding has been set to zero may be bypassed for whatever reason, but in a testing environment (guess where I work. :) ), I am sure that if someone read the spec and implemented a test tool to verify that their implementation conforms to the spec they could generate a bug report if the padding was not 0. I am just trying to make sure that the spec is as unambiguous as possible and I apologize if I am stepping on any toes. Michael Fischer -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, July 27, 2001 9:32 AM To: 'Fischer, Michael'; julian_satran@il.ibm.com Subject: RE: iSCSI padding should be 0 The RFC says: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. How does that say that I MUST check to be sure it has been done? Is that requirement someplace else? Eddy -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Friday, July 27, 2001 12:26 PM To: 'Julian_Satran/Haifa/IBM%IBMIL'; eddy_quicksall@ivivity.com Cc: ips Subject: RE: iSCSI padding should be 0 Julian, I hate to butt in with this minor point, I think you guys are doing a great job in hammering out the specification and do not presume to know better. However, according to RFC2119 the word MUST indicates that it is a requirement of the specification and therefore implies that the receiver will need to check the value. If it MUST be zero and is not, then that would indicate a protocol error. Michael Fischer -----Original Message----- From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com] Sent: Friday, July 27, 2001 8:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 16:07:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27444 for ; Fri, 27 Jul 2001 16:07:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RIJ6322034 for ips-outgoing; Fri, 27 Jul 2001 14:19:06 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe46.law11.hotmail.com [64.4.16.18]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RIJ3222029 for ; Fri, 27 Jul 2001 14:19:03 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Jul 2001 11:18:53 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: Subject: iSCSI: IIN Date: Fri, 27 Jul 2001 14:18:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 27 Jul 2001 18:18:53.0074 (UTC) FILETIME=[974CAF20:01C116C8] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section "1.2.8 Persistent State" it says: The value pair IIN and ISID are used for this purpose. What is IIN? I assume it means Initiator Name. If so, shouldn't it be defined? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 16:11:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20932 for ; Fri, 27 Jul 2001 15:08:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RGPmX15668 for ips-outgoing; Fri, 27 Jul 2001 12:25:48 -0400 (EDT) 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 f6RGPk215664 for ; Fri, 27 Jul 2001 12:25:47 -0400 (EDT) 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 JAA21391; Fri, 27 Jul 2001 09:25:40 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02717; Fri, 27 Jul 2001 09:13:56 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 09:25:38 -0700 Message-ID: From: "Fischer, Michael" To: "'Julian_Satran/Haifa/IBM%IBMIL'" , eddy_quicksall@ivivity.com Cc: ips Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 09:25:30 -0700 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 Julian, I hate to butt in with this minor point, I think you guys are doing a great job in hammering out the specification and do not presume to know better. However, according to RFC2119 the word MUST indicates that it is a requirement of the specification and therefore implies that the receiver will need to check the value. If it MUST be zero and is not, then that would indicate a protocol error. Michael Fischer -----Original Message----- From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com] Sent: Friday, July 27, 2001 8:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 17:31:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05749 for ; Fri, 27 Jul 2001 17:31:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RJ6Wu24775 for ips-outgoing; Fri, 27 Jul 2001 15:06:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe25.law11.hotmail.com [64.4.16.82]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RJ6F224761 for ; Fri, 27 Jul 2001 15:06:19 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Jul 2001 12:06:01 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: "Julian_Satran/Haifa/IBM%IBMIL" Cc: "ips" References: Subject: Re: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 15:05:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 27 Jul 2001 19:06:01.0608 (UTC) FILETIME=[2D3CB880:01C116CF] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I saw one objection to this by Michael Fischer [Michael_Fischer@adaptec.com]. He pointed out that if there is no CRC then why require the padding to be 0. I agree with his point. The problem is with software only implementations ... if they use the sockets send function and if they are sending from a ULP buffer and if the data being sent needs padding, they will have to either copy to another buffer or do an extra tiny send for the pad. So, my thinking is that we say: iSCSI PDUs are padded to an integer number of 4 byte words. If CRC is being used, the padding MUST be 0. If CRC is not being used, the content of the padding is unpredictable and irrelevent. What do you think? Eddy ----- Original Message ----- From: "Julian_Satran/Haifa/IBM%IBMIL" To: Cc: "ips" Sent: Friday, July 27, 2001 11:45 AM Subject: Re: iSCSI padding should be 0 > > Perhaps we should say MUST be sent as 0 and keep quiet about what the > receiver should do (check for 0 - we don't want that). > > Thanks,Julo > > "Eddy Quicksall" on 27-07-2001 18:18:33 > > Please respond to eddy_quicksall@ivivity.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: iSCSI padding should be 0 > > > > > Julian, > > Section 2.1 says the padding should be 0. I guess that is correct because > one may not use CRC and therefore may not want to set them to 0. Wouldn't > it > be better if section 2.1 was more specific and mentioned when they must be > 0 > if there is a CRC. Also, I noticed at the UNH plug fest that at least one > person thought "should" meant "must". Therefore, I don't think it should > say > "should" ... I think it should not mention the 0'ness unless there is a CRC > present. > > Also, > > transmission. Padding bytes, when presents in a segment covered by > a > CRC, have to be set to 0 and are included in the CRC. > > should say "when present in". > > Eddy_Quicksall@iVivity.com > > > > > From owner-ips@ece.cmu.edu Fri Jul 27 17:31:34 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05796 for ; Fri, 27 Jul 2001 17:31:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RIgg623404 for ips-outgoing; Fri, 27 Jul 2001 14:42:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RIge223400 for ; Fri, 27 Jul 2001 14:42:40 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id OAA28011; Fri, 27 Jul 2001 14:42:37 -0400 (EDT) Date: Fri, 27 Jul 2001 14:42:37 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI login phasing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2068743714-53775563-996259357=:27946" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2068743714-53775563-996259357=:27946 Content-Type: TEXT/PLAIN; charset=US-ASCII All: Attached are 2 ASCII text files. Once contains a state diagram for the iSCSI Initiator login phase, the other a state diagram for the iSCSI Target login phase. The Initiator state machine has only 6 states with 10 allowed transitions, and the Target state machine has only 5 states with 7 allowed transitions. Both diagrams have the form of a single "spine" with minimal branching. Error/failure transitions are not shown, since they always result in closing the connection during login (on the target side a reject message may be sent first). Both of these diagrams are based on draft 7 with simplifications suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall, Stephen Bailey, Barry Reinhold, myself and others. These include: 1. Every login is split into 2 distinct subphases (security and operational) with a required demarcation line between them. 1. Every login starts in the security subphase and must contain at least the keys: TargetName, InitiatorName, HeaderDigest, DataDigest, AuthMethod, and optionally SessionType=Normal. 2. No operational parameters can be negotiated before or during the security subphase (informational parameters, like TargetName, although listed in Appendix D, do not require negotiation and are not considered "operational" here). 3. The security subphase ends with a required 2- or 3-way handshake of Text and Text Response PDUs containing only the SecurityContextComplete=yes key and ending with a message from the target to the initiator. The negotiated security functions become effective only at the successful conclusion of this handshake. 4. The operational subphase always begins immediately after the handshake had been completed. No security parameters can be negotiated during or after the operational subphase. 5. The operational subphase ends with a Login Response with F=1 from the target to the initiator, at which time both target and initiator are in Full Feature Phase (the final state in both diagrams). Comments please. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Fri, 27 Jul 2001, Julian Satran wrote: > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > > Comments? > > Julo > > > ---2068743714-53775563-996259357=:27946 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=i_states Content-ID: Content-Description: Content-Disposition: attachment; filename=i_states Content-Transfer-Encoding: BASE64 TG9naW4gUGhhc2UgUHJvY2Vzc2luZyBmb3IgYW4gaVNDU0kgSW5pdGlhdG9y DQoNClRoZSBpbml0aWF0b3IgaGFzIDYgc3RhdGVzOg0KDQogICAgSTE6IEF3 YWl0IENvbm5lY3Rpb24NCiAgICBJMjogQXdhaXQgTFBSDQogICAgSTM6IE5l Z290aWF0ZSBTZWN1cml0eQ0KICAgIEk0OiBMZWF2ZSBTZWN1cml0eQ0KICAg IEk1OiBOZWdvdGlhdGUgT3BlcmF0aW9uYWwNCiAgICBJNjogRnVsbCBGZWF0 dXJlIFBoYXNlDQoNClRoZXJlIGFyZSAxMCBhbGxvd2VkIHRyYW5zaXRpb25z Og0KDQogRnJvbSBcIFRvLT4gICAgSTEgIHwgICBJMiAgfCAgIEkzICB8ICAg STQgIHwgICBJNSAgfCAgIEk2ICB8DQogLS0tLS0tXC0tLSstLS0tLS0tLSst LS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAg STEgICAgIHwgICAgICAgIHwgICBYMSAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgfCAgICAgICB8DQogICAgLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0t LS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAgSTIgICAgIHwg ICAgICAgIHwgICAgICAgfCAgIFgyICB8ICAgWDMgIHwgICAgICAgfCAgICAg ICB8DQogICAgLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0t LS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAgSTMgICAgIHwgICAgICAgIHwg ICAgICAgfCAgIFg0ICB8ICAgWDUgIHwgICAgICAgfCAgICAgICB8DQogICAg LS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0rDQogICAgSTQgICAgIHwgICAgICAgIHwgICAgICAgfCAg IFg2ICB8ICAgWDcgIHwgICBYOCAgfCAgICAgICB8DQogICAgLS0tLS0tLSst LS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0t LS0rDQogICAgSTUgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAg ICAgIHwgICBYOSAgfCAgIFgxMCB8DQogICAgLS0tLS0tLSstLS0tLS0tLSst LS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAg STYgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAg ICAgfCAgICAgICB8DQogICAgLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0t LS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQoNCkluaXRpYWwgc3Rh dGU6DQogICAgSTEgIC0gZW50ZXJlZCB3aGVuIEluaXRpYXRvciB0cmllcyB0 byBvcGVuIGEgVENQIGNvbm5lY3Rpb24gdG8gYSB0YXJnZXQNCg0KDQpGaW5h bCBzdGF0ZToNCiAgICBJNiAgLSBhIHRyYW5zaXRpb24gaW50byB0aGlzIHN0 YXRlIGVudGVycyBGdWxsIEZlYXR1cmUgUGhhc2UNCg0KDQpUcmFuc2l0aW9u czoNCg0KWDE6IFRha2VuIHdoZW46ICAgICBDb25uZWN0aW9uIHRvIHRhcmdl dCBpcyBzdWNjZXNzZnVsbHkgZXN0YWJsaXNoZWQNCg0KICAgIEFjdGlvbjog ICAgICAgICBTZW5kIExvZ2luIENvbW1hbmQNCiAgICAgICAgICAgICAgICAg ICAgd2l0aCBGPTANCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBUYXJnZXRO YW1lPSBrZXkNCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBJbml0aWF0b3JO YW1lPSBrZXkNCiAgICAgICAgICAgICAgICBhbmQgaWYgZGVzaXJlZCwgd2l0 aCBTZXNzaW9uVHlwZT1Ob3JtYWwga2V5DQogICAgICAgICAgICAgICAgYW5k IHdpdGggSGVhZGVyRGlnZXN0PSBrZXkNCiAgICAgICAgICAgICAgICBhbmQg d2l0aCBEYXRhRGlnZXN0PSBrZXkNCiAgICAgICAgICAgICAgICBhbmQgd2l0 aCBBdXRoTWV0aG9kPSBrZXkNCg0KWDI6IFRha2VuIHdoZW46ICAgICBJbml0 aWF0b3IgcmVjZWl2ZXMgTG9naW4gUmVzcG9uc2UgZnJvbSB0YXJnZXQgd2l0 aCBGPTAsDQogICAgICAgICAgICAgICAgICAgIHdpdGggc3RhdHVzPTB4MDAw MSwgd2l0aCByZXBsaWVzIHRvIHNlY3VyaXR5IGtleXMNCiAgICAgICAgICAg ICAgICAgICAgaW5pdGlhdG9yIG9mZmVyZWQgb24gWDEsIGFuZCB3aXRoIGFu eSBzZWN1cml0eSBrZXlzDQogICAgICAgICAgICAgICAgICAgIG9mZmVyZWQg YnkgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIEluaXRpYXRvciBtdXN0 IHJlcGx5IHRvIHNlY3VyaXR5IGtleXMgZnJvbSB0YXJnZXQNCiAgICAgICAg ICAgICAgICAgICAgYW5kL29yIEluaXRpYXRvciB3YW50cyB0byBvZmZlciBh ZGRpdGlvbmFsIHNlY3VyaXR5DQogICAgICAgICAgICAgICAgICAgIGtleXMg dG8gdGFyZ2V0DQoNCiAgICBBY3Rpb246ICAgICAgICAgU2VuZCBUZXh0IENv bW1hbmQNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBGPTANCiAgICAgICAg ICAgICAgICBhbmQgd2l0aCBhbnkgcmVwbGllcyB0byBzZWN1cml0eSBrZXlz IG9mZmVyZWQgYnkgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIHdpdGgg YW55IGFkZGl0aW9uYWwgc2VjdXJpdHkga2V5cyB0byBvZmZlciB0byB0YXJn ZXQNCgwNClgzOiBUYWtlbiB3aGVuOiAgICAgSW5pdGlhdG9yIHJlY2VpdmVz IExvZ2luIFJlc3BvbnNlIGZyb20gdGFyZ2V0IHdpdGggRj0wLA0KICAgICAg ICAgICAgICAgICAgICB3aXRoIHN0YXR1cz0weDAwMDEsIHdpdGggcmVwbGll cyB0byBzZWN1cml0eSBrZXlzDQogICAgICAgICAgICAgICAgICAgIGluaXRp YXRvciBvZmZlcmVkIG9uIFgxLCBhbmQgd2l0aCBhbnkgc2VjdXJpdHkga2V5 cw0KICAgICAgICAgICAgICAgICAgICBvZmZlcmVkIGJ5IHRhcmdldA0KICAg ICAgICAgICAgICAgIGFuZCBJbml0aWF0b3IgZG9lcyBub3QgbmVlZCB0byBy ZXBseSB0byBzZWN1cml0eSBrZXlzIGZyb20NCiAgICAgICAgICAgICAgICAg ICAgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIEluaXRpYXRvciBkb2Vz IG5vdCB3YW50IHRvIG9mZmVyIHNlY3VyaXR5IGtleXMgdG8gdGFyZ2V0DQoN CiAgICBBY3Rpb246ICAgICAgICAgU2FtZSBhcyBBY3Rpb24gb24gWDUNCg0K WDQ6IFRha2VuIHdoZW46ICAgICBJbml0aWF0b3IgcmVjZWl2ZXMgVGV4dCBS ZXNwb25zZSBmcm9tIHRhcmdldCB3aXRoIEY9MCwNCiAgICAgICAgICAgICAg ICAgICAgd2l0aCByZXBsaWVzIHRvIHNlY3VyaXR5IGtleXMgaW5pdGlhdG9y IG9mZmVyZWQgb24gWDIsDQogICAgICAgICAgICAgICAgICAgIFg0IG9yIFg2 LCBhbmQgd2l0aCBhbnkgc2VjdXJpdHkga2V5cyBvZmZlcmVkIGJ5IHRhcmdl dA0KICAgICAgICAgICAgICAgIGFuZCBJbml0aWF0b3IgbmVlZHMgdG8gcmVw bHkgdG8gc2VjdXJpdHkga2V5cyBmcm9tIHRhcmdldA0KICAgICAgICAgICAg ICAgICAgICBhbmQvb3IgSW5pdGlhdG9yIHdhbnRzIHRvIG9mZmVyIGFkZGl0 aW9uYWwgc2VjdXJpdHkNCiAgICAgICAgICAgICAgICAgICAga2V5cyB0byB0 YXJnZXQgDQoNCiAgICBBY3Rpb246ICAgICAgICAgU2FtZSBhcyBBY3Rpb24g b24gWDINCg0KWDU6IFRha2VuIHdoZW46ICAgICBJbml0aWF0b3IgcmVjZWl2 ZXMgVGV4dCBSZXNwb25zZSBmcm9tIHRhcmdldCB3aXRoIEY9MCwNCiAgICAg ICAgICAgICAgICBlaXRoZXIgIHdpdGggcmVwbGllcyB0byBzZWN1cml0eSBr ZXlzIGluaXRpYXRvciBvZmZlcmVkIG9uDQogICAgICAgICAgICAgICAgICAg ICAgICBYMiwgWDQgb3IgWDYsIGFuZCB3aXRoIGFueSBzZWN1cml0eSBrZXlz IG9mZmVyZWQNCiAgICAgICAgICAgICAgICAgICAgICAgIGJ5IHRhcmdldA0K ICAgICAgICAgICAgICAgIG9yICAgICAgd2l0aCBTZWN1cml0eUNvbnRleHRD b21wbGV0ZT15ZXMgYXMgb25seSBrZXkgZnJvbQ0KICAgICAgICAgICAgICAg ICAgICAgICAgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIEluaXRpYXRv ciBkb2VzIG5vdCBuZWVkIHRvIHJlcGx5IHRvIHNlY3VyaXR5IGtleXMgZnJv bQ0KICAgICAgICAgICAgICAgICAgICB0YXJnZXQNCiAgICAgICAgICAgICAg ICBhbmQgSW5pdGlhdG9yIGRvZXMgbm90IHdhbnQgdG8gb2ZmZXIgYWRkaXRp b25hbCBzZWN1cml0eQ0KICAgICAgICAgICAgICAgICAgICBrZXlzIHRvIHRh cmdldA0KDQogICAgQWN0aW9uOiAgICAgICAgIFNlbmQgVGV4dCBDb21tYW5k DQogICAgICAgICAgICAgICAgICAgIHdpdGggRj0wDQogICAgICAgICAgICAg ICAgYW5kIHdpdGggU2VjdXJpdHlDb250ZXh0Q29tcGxldGU9eWVzIGFzIG9u bHkga2V5DQoNClg2OiBUYWtlbiB3aGVuOiAgICAgSW5pdGlhdG9yIHJlY2Vp dmVzIFRleHQgUmVzcG9uc2UgZnJvbSB0YXJnZXQgd2l0aCBGPTAsDQogICAg ICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFueSBzZWN1cml0eSBrZXlzIG9m ZmVyZWQgYnkgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIEluaXRpYXRv ciBuZWVkcyB0byByZXBseSB0byBzZWN1cml0eSBrZXlzIGZyb20gdGFyZ2V0 DQogICAgICAgICAgICAgICAgICAgIGFuZC9vciBJbml0aWF0b3Igd2FudHMg dG8gb2ZmZXIgc2VjdXJpdHkga2V5cyB0byB0YXJnZXQNCg0KICAgIEFjdGlv bjogICAgICAgICBTYW1lIGFzIEFjdGlvbiBvbiBYMg0KDQpYNzogVGFrZW4g d2hlbjogICAgIEluaXRpYXRvciByZWNlaXZlcyBUZXh0IFJlc3BvbnNlIGZy b20gdGFyZ2V0IHdpdGggRj0wLA0KICAgICAgICAgICAgICAgICAgICBhbmQg d2l0aCBzZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgdGFyZ2V0DQogICAgICAg ICAgICAgICAgYW5kIEluaXRpYXRvciBkb2VzIG5vdCBuZWVkIHRvIHJlcGx5 IHRvIHNlY3VyaXR5IGtleXMgZnJvbQ0KICAgICAgICAgICAgICAgICAgICB0 YXJnZXQNCg0KICAgIEFjdGlvbjogICAgICAgICBTYW1lIGFzIEFjdGlvbiBv biBYNQ0KDQpYODogVGFrZW4gd2hlbjogICAgIEluaXRpYXRvciByZWNlaXZl cyBUZXh0IFJlc3BvbnNlIGZyb20gdGFyZ2V0IHdpdGggRj0wDQogICAgICAg ICAgICAgICAgICAgIGFuZCB3aXRoIFNlY3VyaXR5Q29udGV4dENvbXBsZXRl PXllcyBhcyBvbmx5IGtleQ0KDQogICAgQWN0aW9uOiAxLiAgICAgIFB1dCBu ZWdvdGlhdGVkIHNlY3VyaXR5IG1lYXN1cmVzIGludG8gZWZmZWN0DQogICAg ICAgICAgICAyLiAgICAgIFNlbmQgVGV4dCBDb21tYW5kDQogICAgICAgICAg ICAgICAgICAgIHdpdGggRj0xDQogICAgICAgICAgICAgICAgYW5kIHdpdGgg YWxsIG9wZXJhdGlvbmFsIGtleXMgdG8gb2ZmZXIgdG8gdGFyZ2V0DQogICAg ICAgICAgICAgICAgICAgIChjYW4gYmUgZW1wdHkpDQoMDQpYOTogVGFrZW4g d2hlbjogICAgIEluaXRpYXRvciByZWNlaXZlcyBUZXh0IFJlc3BvbnNlIGZy b20gdGFyZ2V0IHdpdGggRj0wLA0KICAgICAgICAgICAgICAgICAgICB3aXRo IGFueSByZXBsaWVzIHRvIG9wZXJhdGlvbmFsIGtleXMgaW5pdGlhdG9yIG9m ZmVyZWQNCiAgICAgICAgICAgICAgICAgICAgb24gWDggb3IgWDksIGFuZCB3 aXRoIGFueSBvcGVyYXRpb25hbCBrZXlzIG9mZmVyZWQgYnkNCiAgICAgICAg ICAgICAgICAgICAgdGFyZ2V0DQogICAgICAgICAgICAgICAgYW5kIEluaXRp YXRvciBuZWVkcyB0byByZXBseSB0byBvcGVyYXRpb25hbCBrZXlzIGZyb20g dGFyZ2V0DQogICAgICAgICAgICAgICAgICAgIGFuZC9vciBJbml0aWF0b3Ig bmVlZHMgdG8gb2ZmZXIgb3BlcmF0aW9uYWwga2V5cyB0bw0KICAgICAgICAg ICAgICAgICAgICB0YXJnZXQNCg0KICAgIEFjdGlvbjogICAgICAgICBTZW5k IFRleHQgQ29tbWFuZA0KICAgICAgICAgICAgICAgICAgICB3aXRoIEY9MQ0K ICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFueSByZXBsaWVzIHRvIG9wZXJh dGlvbmFsIGtleXMgb2ZmZXJlZCBieSB0YXJnZXQNCiAgICAgICAgICAgICAg ICBhbmQgd2l0aCBhbGwgYWRkaXRpb25hbCBvcGVyYXRpb25hbCBrZXlzIHRv IG9mZmVyIHRvIHRhcmdldA0KDQpYMTA6VGFrZW4gd2hlbjogICAgIEluaXRp YXRvciByZWNlaXZlcyBMb2dpbiBSZXNwb25zZSBmcm9tIHRhcmdldCB3aXRo IEY9MSwNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBzdGF0dXM9MHgwMDAw LCB3aXRoIGFueSByZXBsaWVzIHRvIG9wZXJhdGlvbmFsIGtleXMNCiAgICAg ICAgICAgICAgICAgICAgaW5pdGlhdG9yIG9mZmVyZWQgb24gWDggb3IgWDks IGFuZCB3aXRoIG5vIG9wZXJhdGlvbmFsDQogICAgICAgICAgICAgICAgICAg IGtleXMgb2ZmZXJlZCBieSB0YXJnZXQgdGhhdCByZXF1aXJlIGEgcmVwbHkN Cg0KICAgIEFjdGlvbjogICAgICAgICBlbnRlciBGdWxsIEZlYXR1cmUgUGhh c2UNCg== ---2068743714-53775563-996259357=:27946 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=t_states Content-ID: Content-Description: Content-Disposition: attachment; filename=t_states Content-Transfer-Encoding: BASE64 TG9naW4gUGhhc2UgUHJvY2Vzc2luZyBmb3IgYW4gaVNDU0kgVGFyZ2V0DQoN ClRoZSB0YXJnZXQgaGFzIDUgc3RhdGVzOg0KDQogICAgVDE6IEF3YWl0IExv Z2luDQogICAgVDI6IE5lZ290aWF0ZSBTZWN1cml0eQ0KICAgIFQzOiBMZWF2 ZSBTZWN1cml0eQ0KICAgIFQ0OiBOZWdvdGlhdGUgT3BlcmF0aW9uYWwNCiAg ICBUNTogRnVsbCBGZWF0dXJlIFBoYXNlDQoNClRoZXJlIGFyZSA3IGFsbG93 ZWQgdHJhbnNpdGlvbnM6DQoNCiBGcm9tIFwgVG8tPiAgICBUMSAgfCAgIFQy ICB8ICAgVDMgIHwgICBUNCAgfCAgIFQ1ICB8DQogLS0tLS0tXC0tLSstLS0t LS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKw0KICAgIFQx ICAgICB8ICAgIFoxICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgICAg IHwNCiAgICAtLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0t LS0tKy0tLS0tLS0rDQogICAgVDIgICAgIHwgICAgICAgIHwgICBaMiAgfCAg IFozICB8ICAgWjQgIHwgICAgICAgfA0KICAgIC0tLS0tLS0rLS0tLS0tLS0r LS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSsNCiAgICBUMyAgICAg fCAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICBaNSAgfCAgICAgICB8DQog ICAgLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSst LS0tLS0tKw0KICAgIFQ0ICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAg fCAgIFo2ICB8ICAgWjcgIHwNCiAgICAtLS0tLS0tKy0tLS0tLS0tKy0tLS0t LS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAgVDUgICAgIHwgICAg ICAgIHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfA0KICAgIC0t LS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0t LSsNCg0KSW5pdGlhbCBzdGF0ZToNCiAgICBUMSAgLSBlbnRlcmVkIHdoZW4g VGFyZ2V0IHN1Y2Nlc3NmdWxseSBhY2NlcHRzIGEgVENQIGNvbm5lY3Rpb24g d2l0aCBhbg0KICAgICAgICAgIGluaXRpYXRvcg0KDQoNCkZpbmFsIHN0YXRl Og0KICAgIFQ1ICAtIGEgdHJhbnNpdGlvbiBpbnRvIHRoaXMgc3RhdGUgZW50 ZXJzIEZ1bGwgRmVhdHVyZSBQaGFzZQ0KDQoNClRyYW5zaXRpb25zOg0KDQpa MTogVGFrZW4gd2hlbjogICAgIFRhcmdldCByZWNlaXZlcyBMb2dpbiBDb21t YW5kIGZyb20gaW5pdGlhdG9yIHdpdGggRj0wLA0KICAgICAgICAgICAgICAg ICAgICB3aXRoIFRhcmdldE5hbWU9IGtleSwgd2l0aCBJbml0aWF0b3JOYW1l PSBrZXksDQogICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsbHkgd2l0aCBT ZXNzaW9uVHlwZT1Ob3JtYWwga2V5LCBhbmQgd2l0aA0KICAgICAgICAgICAg ICAgICAgICBzZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQoN CiAgICBBY3Rpb246ICAgICAgICAgU2VuZCBMb2dpbiBSZXNwb25zZQ0KICAg ICAgICAgICAgICAgICAgICB3aXRoIEY9MA0KICAgICAgICAgICAgICAgIGFu ZCB3aXRoIHN0YXR1cz0weDAwMDENCiAgICAgICAgICAgICAgICBhbmQgd2l0 aCByZXBsaWVzIHRvIHNlY3VyaXR5IGtleXMgb2ZmZXJlZCBieSBpbml0aWF0 b3INCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBhbnkgYWRkaXRpb25hbCBz ZWN1cml0eSBrZXlzIHRvIG9mZmVyIHRvIGluaXRpYXRvcg0KDQpaMjogVGFr ZW4gd2hlbjogICAgIFRhcmdldCByZWNlaXZlcyBUZXh0IENvbW1hbmQgZnJv bSBpbml0aWF0b3Igd2l0aCBGPTAsDQogICAgICAgICAgICAgICAgZWl0aGVy ICB3aXRoIGFueSByZXBsaWVzIHRvIHNlY3VyaXR5IGtleXMgb2ZmZXJlZCBv biBaMSBvcg0KICAgICAgICAgICAgICAgICAgICAgICAgWjIsIGFuZCB3aXRo IGFueSBzZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQogICAg ICAgICAgICAgICAgICAgIG9yICB3aXRoIFNlY3VyaXR5Q29udGV4dENvbXBs ZXRlPXllcyBhcyBvbmx5IGtleQ0KICAgICAgICAgICAgICAgIGFuZCBUYXJn ZXQgbmVlZHMgdG8gcmVwbHkgdG8gc2VjdXJpdHkga2V5cyBmcm9tIGluaXRp YXRvcg0KICAgICAgICAgICAgICAgICAgICBhbmQvb3IgVGFyZ2V0IHdhbnRz IHRvIG9mZmVyIHNlY3VyaXR5IGtleXMgdG8gaW5pdGlhdG9yDQoNCiAgICBB Y3Rpb246ICAgICAgICAgU2VuZCBUZXh0IFJlc3BvbnNlDQogICAgICAgICAg ICAgICAgICAgIHdpdGggRj0wDQogICAgICAgICAgICAgICAgYW5kIHdpdGgg YW55IHJlcGxpZXMgdG8gc2VjdXJpdHkga2V5cyBvZmZlcmVkIGJ5IGluaXRp YXRvcg0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFueSBhZGRpdGlvbmFs IHNlY3VyaXR5IGtleXMgdG8gb2ZmZXIgdG8gaW5pdGlhdG9yDQoMDQpaMzog VGFrZW4gd2hlbjogICAgIFRhcmdldCByZWNlaXZlcyBUZXh0IENvbW1hbmQg ZnJvbSBpbml0aWF0b3Igd2l0aCBGPTAsDQogICAgICAgICAgICAgICAgICAg IHdpdGggYW55IHJlcGxpZXMgdG8gc2VjdXJpdHkga2V5cyBvZmZlcmVkIG9u IFoxIG9yIFoyLA0KICAgICAgICAgICAgICAgICAgICBhbmQgd2l0aCBhbnkg c2VjdXJpdHkga2V5cyBvZmZlcmVkIGJ5IGluaXRpYXRvcg0KICAgICAgICAg ICAgICAgIGFuZCBUYXJnZXQgZG9lcyBub3QgbmVlZCB0byByZXBseSB0byBz ZWN1cml0eSBrZXlzIGZyb20NCiAgICAgICAgICAgICAgICAgICAgaW5pdGlh dG9yDQogICAgICAgICAgICAgICAgYW5kIFRhcmdldCBkb2VzIG5vdCB3YW50 IHRvIG9mZmVyIGFkZGl0aW9uYWwgc2VjdXJpdHkga2V5cw0KICAgICAgICAg ICAgICAgICAgICB0byBpbml0aWF0b3INCg0KICAgIEFjdGlvbjogICAgICAg ICBTZW5kIFRleHQgUmVzcG9uc2UNCiAgICAgICAgICAgICAgICAgICAgd2l0 aCBGPTANCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBTZWN1cml0eUNvbnRl eHRDb21wbGV0ZT15ZXMgYXMgb25seSBrZXkNCg0KWjQ6IFRha2VuIHdoZW46 ICAgICBUYXJnZXQgcmVjZWl2ZXMgVGV4dCBDb21tYW5kIGZyb20gaW5pdGlh dG9yIHdpdGggRj0wDQogICAgICAgICAgICAgICAgICAgIGFuZCB3aXRoIFNl Y3VyaXR5Q29udGV4dENvbXBsZXRlPXllcyBhcyBvbmx5IGtleQ0KICAgICAg ICAgICAgICAgIGFuZCBUYXJnZXQgZG9lcyBub3Qgd2FudCB0byBvZmZlciBh ZGRpdGlvbmFsIHNlY3VyaXR5IGtleXMNCiAgICAgICAgICAgICAgICAgICAg dG8gaW5pdGlhdG9yDQoNCiAgICBBY3Rpb246ICAgICAgICAgU2FtZSBhcyBh Y3Rpb25zIG9uIFo1DQoNClo1OiBUYWtlbiB3aGVuOiAgICAgVGFyZ2V0IHJl Y2VpdmVzIFRleHQgQ29tbWFuZCBmcm9tIGluaXRpYXRvciB3aXRoIEY9MA0K ICAgICAgICAgICAgICAgICAgICBhbmQgd2l0aCBTZWN1cml0eUNvbnRleHRD b21wbGV0ZT15ZXMgYXMgb25seSBrZXkNCg0KICAgIEFjdGlvbjogMS4gICAg ICBTZW5kIFRleHQgUmVzcG9uc2UNCiAgICAgICAgICAgICAgICAgICAgd2l0 aCBGPTANCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBTZWN1cml0eUNvbnRl eHRDb21wbGV0ZT15ZXMgYXMgb25seSBrZXkNCiAgICAgICAgICAgIDIuICAg ICAgUHV0IGFsbCBuZWdvdGlhdGVkIHNlY3VyaXR5IG1lYXN1cmVzIGludG8g ZWZmZWN0DQoNClo2OiBUYWtlbiB3aGVuOiAgICAgVGFyZ2V0IHJlY2VpdmVz IFRleHQgQ29tbWFuZCBmcm9tIGluaXRpYXRvciB3aXRoIEY9MSwNCiAgICAg ICAgICAgICAgICAgICAgd2l0aCBhbnkgcmVwbGllcyB0byBvcGVyYXRpb25h bCBrZXlzIHRhcmdldCBvZmZlcmVkDQogICAgICAgICAgICAgICAgICAgIG9u IFo2LCBhbmQgd2l0aCBhbnkgb3BlcmF0aW9uYWwga2V5cyBvZmZlcmVkIGJ5 DQogICAgICAgICAgICAgICAgICAgIGluaXRpYXRvcg0KICAgICAgICAgICAg ICAgIGFuZCBUYXJnZXQgd2FudHMgdG8gb2ZmZXIgYWRkaXRpb25hbCBvcGVy YXRpb25hbCBrZXlzDQogICAgICAgICAgICAgICAgICAgIHRoYXQgcmVxdWly ZSBhIHJlcGx5IGZyb20gaW5pdGlhdG9yDQoNCiAgICBBY3Rpb246ICAgICAg ICAgU2VuZCBUZXh0IFJlc3BvbnNlDQogICAgICAgICAgICAgICAgICAgIHdp dGggRj0wDQogICAgICAgICAgICAgICAgYW5kIHdpdGggYW55IHJlcGxpZXMg dG8gb3BlcmF0aW9uYWwga2V5cyBvZmZlcmVkIGJ5DQogICAgICAgICAgICAg ICAgICAgIGluaXRpYXRvcg0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFs bCBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsIGtleXMgdG8gb2ZmZXIgdG8NCiAg ICAgICAgICAgICAgICAgICAgaW5pdGlhdG9yDQoNClo3OiBUYWtlbiB3aGVu OiAgICAgVGFyZ2V0IHJlY2VpdmVzIFRleHQgQ29tbWFuZCBmcm9tIGluaXRp YXRvciB3aXRoIEY9MSwNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBhbnkg cmVwbGllcyB0byBvcGVyYXRpb25hbCBrZXlzIHRhcmdldCBvZmZlcmVkDQog ICAgICAgICAgICAgICAgICAgIG9uIFo2LCBhbmQgd2l0aCBhbnkgb3BlcmF0 aW9uYWwga2V5cyBvZmZlcmVkIGJ5DQogICAgICAgICAgICAgICAgICAgIGlu aXRpYXRvcg0KICAgICAgICAgICAgICAgIGFuZCBUYXJnZXQgZG9lcyBub3Qg d2FudCB0byBvZmZlciBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsDQogICAgICAg ICAgICAgICAgICAgIGtleXMgdGhhdCByZXF1aXJlIGEgcmVwbHkgZnJvbSBp bml0aWF0b3INCg0KICAgIEFjdGlvbjogICAgICAgICBTZW5kIExvZ2luIFJl c3BvbnNlDQogICAgICAgICAgICAgICAgICAgIHdpdGggRj0xDQogICAgICAg ICAgICAgICAgYW5kIHdpdGggYW55IHJlcGxpZXMgdG8gb3BlcmF0aW9uYWwg a2V5cyBvZmZlcmVkIGJ5DQogICAgICAgICAgICAgICAgICAgIGluaXRpYXRv ciAoY2FuIGJlIGVtcHR5KQ0K ---2068743714-53775563-996259357=:27946-- From owner-ips@ece.cmu.edu Fri Jul 27 17:39:26 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06362 for ; Fri, 27 Jul 2001 17:39:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RJXQM26212 for ips-outgoing; Fri, 27 Jul 2001 15:33:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RJTZ226009 for ; Fri, 27 Jul 2001 15:32:24 -0400 (EDT) Received: from london ([192.168.1.56]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id MAA03556; Fri, 27 Jul 2001 12:18:02 -0700 (PDT) From: "Rod Harrison" To: , "'Julian Satran'" Cc: "'ips'" Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 14:19:17 -0500 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.2314.1300 In-Reply-To: <000301c116b8$9db62cc0$ab01a8c0@eddylaptop> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Can we not leave the pad bytes out of the digest calculation and allow them to be any value. Having to zero the pad bytes is the only reason to touch the payload buffer. Is it really a security problem to allow the pad bytes to be any value? - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Friday, July 27, 2001 11:24 AM To: 'Julian Satran' Cc: 'ips' Subject: RE: iSCSI padding should be 0 Sounds good to me. Eddy -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, July 27, 2001 11:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 17:51:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07346 for ; Fri, 27 Jul 2001 17:51:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RKE2P28505 for ips-outgoing; Fri, 27 Jul 2001 16:14:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe67.law11.hotmail.com [64.4.16.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RKE0228501 for ; Fri, 27 Jul 2001 16:14:00 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 27 Jul 2001 13:13:50 -0700 X-Originating-IP: [216.135.246.226] From: "Eddy Quicksall" To: Cc: Subject: iSCSI: reason codes Date: Fri, 27 Jul 2001 16:13:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 27 Jul 2001 20:13:50.0294 (UTC) FILETIME=[A65CEF60:01C116D8] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section "2.4.3 Response" says: 0x05 - Command in progress But the table says | Code| Reason | with SCSI CHECK CONDITION | +-----+----------------+---------------------------+ |0x05 | SNACK rejected | ASC = 0x47 ASCQ = 0x03 | Which "0x05" is correct? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Jul 27 18:02:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08228 for ; Fri, 27 Jul 2001 18:02:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RKm5u00662 for ips-outgoing; Fri, 27 Jul 2001 16:48:05 -0400 (EDT) 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 f6RKm4200657 for ; Fri, 27 Jul 2001 16:48:04 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA09301; Fri, 27 Jul 2001 16:47:57 -0400 (EDT) Message-ID: <3B61D222.DC0FF2EF@cisco.com> Date: Fri, 27 Jul 2001 15:42:10 -0500 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: Eddy Quicksall CC: ips@ece.cmu.edu Subject: Re: iSCSI: IIN References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy- IIN stood for iSCSI Initiator Name. This is the only place in the document that this is still used. ITN is used for iSCSI Target Name within the login status code table, but is defined there, so it should be OK. Julian- Should change "IIN" in the first paragraph of 1.2.8 to "iSCSI Initiator Name". -- Mark Eddy Quicksall wrote: > > Section "1.2.8 Persistent State" it says: > > The value pair IIN and ISID are used for this purpose. > > What is IIN? I assume it means Initiator Name. If so, shouldn't it be > defined? > > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sat Jul 28 20:16:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05565 for ; Sat, 28 Jul 2001 20:16:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6SN80409364 for ips-outgoing; Sat, 28 Jul 2001 19:08:00 -0400 (EDT) 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 f6SN7w209359 for ; Sat, 28 Jul 2001 19:07:58 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Sat Jul 28 19:06:35 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Sat Jul 28 19:06:57 EDT 2001 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 TAA25818; Sat, 28 Jul 2001 19:06:30 -0400 (EDT) Message-ID: <3B634576.DC8EC4FD@research.bell-labs.com> Date: Sat, 28 Jul 2001 19:06:30 -0400 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: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: NOP-Out closing the command window References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The 3-way sequence is probably the simplest for the code to handle (no > special path for a request that has no answer). (I was almost going to drop the subject..but then) what if the command window is *already* full when the target sends the ping ? If the initiator doesnt respond, the connection will be broken. Are we going to add a rule that the target must not send a ping when the window is full ? This wont work with all the asynchrony (e.g. target sent a ping before the maxCmdSN limit was hit at the target) One should just turn around and send the ping response right away, otherwise the other-end may timeout and take action on failure. Treat pings as immediate commands. Allowing pings to test the queuing sub-system are undoubtedly noble ideas but these seldom make it (correctly) into practical systems. -sandeep Julian Satran wrote: > > Sandeep, > > You are right the sequences are not documented now and that is why I put > them out here - to hear comments. > > A PDU with P=0 from the target (no ITT) could be hadndled as a mistake. > > The 3-way sequence is probably the simplest for the code to handle (no > special path for a request that has no answer). > > Julo > > Sandeep Joshi on 27-07-2001 20:34:32 > > Please respond to Sandeep Joshi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: NOP-Out closing the command window > > Julian Satran wrote: > > > > Sandeep, > > > > They are 3 distinguishing elements P and the ITT+TTT. > > > > Julo > > > > I believe you are commenting on my question about the validity > about the 2nd sequence.. correct ? But this 2nd sequence isn't > documented in Sec 2.12 or 2.13. > > Incidentally, there is a similar ping type mentioned in Sec 2.13.1 > and its used to test the connection from the target end. Could > you please say what the response would be : > T->I NOP +P=0 T=ff I=ff > I->T < response or it none ? > > > And I still prefer that the ping response from the initiator *not* > have a valid ITT/cmdSN. A 3-way ping looks forbidding and may open > up new problems. > > -Sandeep > > > Sandeep Joshi on 27-07-2001 18:53:20 > > > > Please respond to Sandeep Joshi > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI: NOP-Out closing the command window > > > > If the NOP-Out does not have the ping-bit set, then it is a > > ping response and *not* a new command being issued by the > > initiator. > > > > Hence, it seems that the NOP-OUT with P=0 need not carry a > > new cmdSN (Mark's 2nd option). > > > > Btw, I did not know the 2nd sequence (P=0 from initiator?) > > below was valid > > > I->T NOP +P=0 +I=x+ Data > > > T->I NOP +P=0 +I=x > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > Mark, > > > > > > Definitely a problem . How about stating (the obvious) that NOP as any > > > thing carying an ITT expectes an answer > > > wheter it carries an echo (P=1) or not (P=0). > > > > > > If it does not carry an ITT it does not. > > > > > > We can have the following sequences all valid: > > > > > > I->T NOP +P=1 +I=x+ Data > > > T->I NOP +P=0 + Data > > > > > > I->T NOP +P=0 +I=x+ Data > > > T->I NOP +P=0 +I=x > > > > > > T->I NOP +P=1 +TTT > > > I->T NOP +P=0 I=1 + TTT (no ITT) > > > > > > All would be permitted today if we remove the tie between ITT and P say > > > that NOP must have an ITT if issued at initiators initiative. > > > > > > We might add as valid (today it is not, it is explicitly forbidden): > > > > > > T->I NOP +P=1 +TTT > > > I->T NOP +P=1+ I= 1 TTT + ITT + Data > > > T->I NOP +P=0 +ITT + Data > > > > > > The last requires us to "tweak" the termination rule (a target is > > forbiden > > > to answer a P=1 with a P=1 > > > > > > comments? > > > Julo > > > > > > Mark Bakke on 27-07-2001 16:25:20 > > > > > > Please respond to Mark Bakke > > > > > > To: IPS > > > cc: > > > Subject: iSCSI: NOP-Out closing the command window > > > > > > When sending a NOP-Out without the P bit set, there's > > > no response to update ExpCmdSN to keep the window open. > > > > > > On an otherwise idle session, sending a long enough > > > sequence of these NOP-Outs can close the command window > > > permanently. > > > > > > In case of a stuck command window, please break glass... > > > > > > The easy solution is to turn on the P bit, and get the > > > responses to update the window, but that defaults the > > > purpose of allowing the P bit to not be set in the first > > > place. > > > > > > Another easy solution (but I almost hate to mention it) > > > is not to have NOP-Out update the CmdSN. This seems to > > > have the possibility of breaking other things. > > > > > > I suppose we could come up with a more complicated rule, > > > like "if the NOP-Out's CmdSN would be the last (or perhaps > > > penultimate) CmdSN allowed by the current window, it MUST > > > set the P bit." Or something like that. > > > > > > Anyway, I see three possible solutions. Any thoughts? > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 From owner-ips@ece.cmu.edu Sat Jul 28 20:49:11 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13644 for ; Sat, 28 Jul 2001 20:49:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S3c3517406 for ips-outgoing; Fri, 27 Jul 2001 23:38:03 -0400 (EDT) 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 f6S3c1217402 for ; Fri, 27 Jul 2001 23:38:01 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Jul 27 23:37:34 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Jul 27 23:37:59 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id XAA05005 for ips@ece.cmu.edu; Fri, 27 Jul 2001 23:37:33 -0400 (EDT) Date: Fri, 27 Jul 2001 23:37:33 -0400 (EDT) Message-Id: <200107280337.XAA05005@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: iSCSI connection recovery Sender: owner-ips@ece.cmu.edu Precedence: bulk I had a "big-picture" question about the connection recovery model. The current draft suggests that, once the broken connection is logged out, the commands allegiant to the old connection can now be retried over *any* connection. (See Section 7.11.3 bullet 1 and also Appendix F Session Recovery algo for initiator.) I may be mistaken, but in previous drafts, this was not the case and commands always stayed allegiant to a CID. So the question is.. how does one use a Status cache belonging to the old connection in this new model (now that the commands are going to be retried over any connection) Doesnt this become more complex ? Secondly, this also means that one must walk the command list at the target and quiesce connection allegiance during logout - which may not be required if the commands were to be retried over the same connection always. Comments ? -Sandeep From owner-ips@ece.cmu.edu Sat Jul 28 20:49:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13646 for ; Sat, 28 Jul 2001 20:49:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S3Vw517194 for ips-outgoing; Fri, 27 Jul 2001 23:31:58 -0400 (EDT) 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 f6S3Vu217190 for ; Fri, 27 Jul 2001 23:31:56 -0400 (EDT) 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 FAA175528; Sat, 28 Jul 2001 05:31:41 +0200 Received: from d12hubm3.de.ibm.com (d12hubm3_tr0 [9.165.255.246]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S3Vgc174378; Sat, 28 Jul 2001 05:31:42 +0200 Importance: Normal Subject: RE: iSCSI padding should be 0 To: "Fischer, Michael" Cc: "eddy_quicksall" , "ips X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: Julian_Satran/Haifa/IBM%IBMIL Date: Sat, 28 Jul 2001 06:37:44 +0300 X-MIMETrack: Serialize by Router on D12HUBM3/12/H/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 05:35:45 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I thought the text says clearly "MUST be sent as 0" not "MUST be 0" and the difference is unequivocal to me. Julo "Fischer, Michael" on 27-07-2001 19:25:30 Please respond to "Fischer, Michael" To: Julian Satran/Haifa/IBM@IBMIL, eddy_quicksall@ivivity.com cc: ips Subject: RE: iSCSI padding should be 0 Julian, I hate to butt in with this minor point, I think you guys are doing a great job in hammering out the specification and do not presume to know better. However, according to RFC2119 the word MUST indicates that it is a requirement of the specification and therefore implies that the receiver will need to check the value. If it MUST be zero and is not, then that would indicate a protocol error. Michael Fischer -----Original Message----- From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com] Sent: Friday, July 27, 2001 8:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Jul 28 23:57:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01982 for ; Sat, 28 Jul 2001 23:57:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6SM1xO06942 for ips-outgoing; Sat, 28 Jul 2001 18:01:59 -0400 (EDT) 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 f6SM1w206937 for ; Sat, 28 Jul 2001 18:01:58 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Sat Jul 28 18:01:59 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Sat Jul 28 18:02:29 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id SAA24744 for ips@ece.cmu.edu; Sat, 28 Jul 2001 18:01:54 -0400 (EDT) Date: Sat, 28 Jul 2001 18:01:54 -0400 (EDT) Message-Id: <200107282201.SAA24744@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: Re: iSCSI connection recovery Sender: owner-ips@ece.cmu.edu Precedence: bulk Er..I mixed up the terminology. By "same connection", I meant "same CID" - so one could retry cmds ONLY on the new TCP connection with the same CID, after the old TCP connection had failed. This avoids having to change connection allegiance on the stuck commands, as part of connection logout. The main questions, however, were these : 1) What is the effect of a CID logout on the status (statSN) cache ? Can it be reused when the commands are retried ? (Think not..) 2) After one does a login for recovery using an old CID, can new SCSI commands be issued on that new TCP connection. (though it bears an old CID identifier) -Sandeep > Sandeep, > > Retry over any connection was always the case. > Commands can change allegiance only after a logout. > The commands get quiesced anyway and you have to mark them ready for a > retry anyhow (you don't want retry at arbitrary times to hit unpunished the > target). After that it doesn't matter where you retry (same connection, > another old one, a new one). > > The only new thing is command replay (after status was sent but before it > is acked). > > Regards, > Julo > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 06:37:33 > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > To: ips@ece.cmu.edu > cc: > Subject: iSCSI connection recovery > > > > > I had a "big-picture" question about the connection > recovery model. > > The current draft suggests that, once the broken connection > is logged out, the commands allegiant to the old connection > can now be retried over *any* connection. (See Section 7.11.3 > bullet 1 and also Appendix F Session Recovery algo for > initiator.) > > I may be mistaken, but in previous drafts, this was not > the case and commands always stayed allegiant to a CID. > > So the question is.. how does one use a Status cache > belonging to the old connection in this new model (now that > the commands are going to be retried over any connection) > Doesnt this become more complex ? > > Secondly, this also means that one must walk the command > list at the target and quiesce connection allegiance during > logout - which may not be required if the commands were to be > retried over the same connection always. > > Comments ? > > -Sandeep > > > From owner-ips@ece.cmu.edu Sat Jul 28 23:57:09 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01985 for ; Sat, 28 Jul 2001 23:57:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6SJWF101525 for ips-outgoing; Sat, 28 Jul 2001 15:32:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6SJVS201500 for ; Sat, 28 Jul 2001 15:31:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id 312131826; Sat, 28 Jul 2001 12:31:28 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id MAA24279; Sat, 28 Jul 2001 12:32:42 -0700 (PDT) Message-Id: <200107281932.MAA24279@core.rose.hp.com> Subject: Re: iSCSI: Reject, CmdSN, and DataSN To: mbakke@cisco.com Date: Sat, 28 Jul 2001 12:32:41 PDT Cc: ips@ece.cmu.edu In-Reply-To: <3B616F7B.B5F42A73@cisco.com>; from "Mark Bakke" at Jul 27, 101 7:32 am Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Mark, When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN is updated? If so, I see a problem with at least CmdSN. Let's consider commands first. The only Reject reason code that I see where a target could update its ExpCmdSN is when there is a payload-digest error on immediate data. In all the other cases, either the target doesn't care (immediate/retry/non-FFP), or can't know for sure (format error). I suggest that we _not_ advance the ExpCmdSN on immediate data digest error to give the initiator an opportunity to re-issue the command to preserve command ordering. Let's now consider data. Again the only Reject reason code I see for advancing ExpDataSN is payload-digest error ("2"). Either the target (a) would generate a recovery R2T (if DataSequenceOrder was negotiated as "no" and target supports Within-command recovery), or (b) eventually signal a service delivery subsystem failure for the command (iSCSI response code 0x02). For (b), it doesn't matter if the target updates ExpDataSN or not. For (a) OTOH, the target should update the ExpDataSN to deal with the current data burst (that reminds me that I need to fix this in Within-command algorithms in Appendix F!). So to summarize, I think a Reject'ed CmdSN should not be considered as successfully received on the target. Your comments are welcome. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >When a PDU is rejected, I assume that the CmdSN is still >updated, as well as the DataSN where applicable. That is, >a rejected command still uses up a SN. It probably wouldn't >hurt to state this in the reject section. > >Since the Reject response does not contain ExpCmdSN, if the >last command before the window is closed is rejected, the >initiator has to rely on prior commands completing to re-open >the window. This will usually work, but what if the window >size is reduced to one outstanding command for some reason? >Any command that is rejected will close the window for good. >A sequence of rejected commands equal to the window size will >do the same. > >Any thoughts? > >-- >Mark A. Bakke >Cisco Systems >mbakke@cisco.com >763.398.1054 > From owner-ips@ece.cmu.edu Sun Jul 29 00:24:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03748 for ; Sun, 29 Jul 2001 00:24:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S4qNM20162 for ips-outgoing; Sat, 28 Jul 2001 00:52:23 -0400 (EDT) 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 f6S4qM220157 for ; Sat, 28 Jul 2001 00:52:22 -0400 (EDT) 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 GAA64594 for ; Sat, 28 Jul 2001 06:52:15 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S4qF565472 for ; Sat, 28 Jul 2001 06:52:15 +0200 Importance: Normal Subject: Re: iSCSI: reason codes To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 07:58:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 07:52:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk snack rejected - Julo "Eddy Quicksall" on 27-07-2001 23:13:43 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: iSCSI: reason codes Section "2.4.3 Response" says: 0x05 - Command in progress But the table says | Code| Reason | with SCSI CHECK CONDITION | +-----+----------------+---------------------------+ |0x05 | SNACK rejected | ASC = 0x47 ASCQ = 0x03 | Which "0x05" is correct? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sun Jul 29 00:24:49 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03752 for ; Sun, 29 Jul 2001 00:24:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S4uAD20312 for ips-outgoing; Sat, 28 Jul 2001 00:56:10 -0400 (EDT) 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 f6S4u8220308 for ; Sat, 28 Jul 2001 00:56:08 -0400 (EDT) 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 GAA310752 for ; Sat, 28 Jul 2001 06:56:02 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S4u15146086 for ; Sat, 28 Jul 2001 06:56:01 +0200 Importance: Normal Subject: Re: iSCSI: IIN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 08:02:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 07:56:02 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I already did :-) Julo Mark Bakke on 27-07-2001 23:42:10 Please respond to Mark Bakke To: Eddy Quicksall cc: ips@ece.cmu.edu Subject: Re: iSCSI: IIN Eddy- IIN stood for iSCSI Initiator Name. This is the only place in the document that this is still used. ITN is used for iSCSI Target Name within the login status code table, but is defined there, so it should be OK. Julian- Should change "IIN" in the first paragraph of 1.2.8 to "iSCSI Initiator Name". -- Mark Eddy Quicksall wrote: > > Section "1.2.8 Persistent State" it says: > > The value pair IIN and ISID are used for this purpose. > > What is IIN? I assume it means Initiator Name. If so, shouldn't it be > defined? > > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 00:26:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03966 for ; Sun, 29 Jul 2001 00:26:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S5Ak420794 for ips-outgoing; Sat, 28 Jul 2001 01:10:46 -0400 (EDT) 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 f6S5Aj220790 for ; Sat, 28 Jul 2001 01:10:45 -0400 (EDT) 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 HAA114076 for ; Sat, 28 Jul 2001 07:10:38 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S5Ac542534 for ; Sat, 28 Jul 2001 07:10:38 +0200 Importance: Normal Subject: Re: iSCSI: data ordering To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 08:16:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 08:10:38 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sounds reasonable - Julo "Mallikarjun C." on 28-07-2001 04:22:14 Please respond to cbm@rose.hp.com To: ips@ece.cmu.edu cc: Subject: iSCSI: data ordering Julian, Rev 07 defines the text keys DataOrder and DataDeliveryOrder to distinguish sequence-level and PDU-level ordering. For clarity (since both have to do with data delivery ordering), can I suggest to rename them as - DataSequenceOrder and DataPDUOrder respectively? Also, both these are qualified by the sentence "The default is yes but targets MAY support no." I assume initiators have the same options (and not all initiators may support OOO data based on hardware constraints). I suggest stating it as: "Default is yes." as elsewhere. Thanks. -- 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 Sun Jul 29 00:26:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03970 for ; Sun, 29 Jul 2001 00:26:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S5Nrg21233 for ips-outgoing; Sat, 28 Jul 2001 01:23:53 -0400 (EDT) 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 f6S5Np221228 for ; Sat, 28 Jul 2001 01:23:51 -0400 (EDT) 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 HAA244240 for ; Sat, 28 Jul 2001 07:23:45 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S5Ni524932 for ; Sat, 28 Jul 2001 07:23:45 +0200 Importance: Normal Subject: Re: iSCSI login phasing To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 08:29:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 08:23:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The security purists will object (with good reason) to the names being disclosed before security is established when they are not needed for security. Mandating always 2 phases is wastefull for those cases in which the security negotiation is in fact bypassed. Stating the phase explicitly solves both those problems. Julo "Robert D. Russell" on 27-07-2001 21:42:37 Please respond to "Robert D. Russell" To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI login phasing All: Attached are 2 ASCII text files. Once contains a state diagram for the iSCSI Initiator login phase, the other a state diagram for the iSCSI Target login phase. The Initiator state machine has only 6 states with 10 allowed transitions, and the Target state machine has only 5 states with 7 allowed transitions. Both diagrams have the form of a single "spine" with minimal branching. Error/failure transitions are not shown, since they always result in closing the connection during login (on the target side a reject message may be sent first). Both of these diagrams are based on draft 7 with simplifications suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall, Stephen Bailey, Barry Reinhold, myself and others. These include: 1. Every login is split into 2 distinct subphases (security and operational) with a required demarcation line between them. 1. Every login starts in the security subphase and must contain at least the keys: TargetName, InitiatorName, HeaderDigest, DataDigest, AuthMethod, and optionally SessionType=Normal. 2. No operational parameters can be negotiated before or during the security subphase (informational parameters, like TargetName, although listed in Appendix D, do not require negotiation and are not considered "operational" here). 3. The security subphase ends with a required 2- or 3-way handshake of Text and Text Response PDUs containing only the SecurityContextComplete=yes key and ending with a message from the target to the initiator. The negotiated security functions become effective only at the successful conclusion of this handshake. 4. The operational subphase always begins immediately after the handshake had been completed. No security parameters can be negotiated during or after the operational subphase. 5. The operational subphase ends with a Login Response with F=1 from the target to the initiator, at which time both target and initiator are in Full Feature Phase (the final state in both diagrams). Comments please. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 On Fri, 27 Jul 2001, Julian Satran wrote: > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > > Comments? > > Julo > > > From owner-ips@ece.cmu.edu Sun Jul 29 00:26:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03991 for ; Sun, 29 Jul 2001 00:26:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S2Ei614284 for ips-outgoing; Fri, 27 Jul 2001 22:14:44 -0400 (EDT) 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 f6S2Eh214279 for ; Fri, 27 Jul 2001 22:14:43 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0T2NCH>; Fri, 27 Jul 2001 22:14:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AE4@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RFC 2119 and iSCSI padding should be 0 Date: Fri, 27 Jul 2001 22:10:00 -0400 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 > However, according to RFC2119 the word MUST indicates that it is a > requirement of the specification. Correct. Also note that MUST is only to be used for things that are crucial for interoperability or required to prevent harm (see Section 6 of RFC 2119). > and therefore implies that the receiver will need to check the value. Incorrect. This is at odds with the usual IETF dictum that one should be conservative in what is sent but liberal in what is accepted. It is ok to say "MUST be sent as zero" and "MUST not be checked by the receiver" (e.g., for reserved bits that may be used for something in the future). In this case, because the value of the pad bytes should not have any future use, "SHOULD be zero" is adequate. The security risks of sending non-zero bytes (where did they come from?, do they disclose sensitive information?) would need to be described either here or in the Security Considerations section. Inadvertent disclosure of information is the "minor security risk" and since it's a possible cause of harm, it justifies saying "SHOULD be zero". > If it MUST be zero and is not, then that > would indicate a protocol error. Correct, but that may only be of interest to a protocol test suite or the like. IMHO, protocol testers should report events that violate "SHOULD" statements in the standard. Also, let me warn everyone that upper vs. lower case matters. RFC-2119 definitions only apply when UPPER case is used, so "MUST" and "must" do not have the same meaning in an RFC (ditto "SHOULD" and "should", etc.). 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 --------------------------------------------------- From owner-ips@ece.cmu.edu Sun Jul 29 00:26:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04000 for ; Sun, 29 Jul 2001 00:26:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S2A9014113 for ips-outgoing; Fri, 27 Jul 2001 22:10:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6S2A8214108 for ; Fri, 27 Jul 2001 22:10:08 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id D950414C7 for ; Fri, 27 Jul 2001 19:10:07 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id TAA03617 for ips@ece.cmu.edu; Fri, 27 Jul 2001 19:11:21 -0700 (PDT) Message-Id: <200107280211.TAA03617@core.rose.hp.com> Subject: iSCSI: Reject reason codes To: ips@ece.cmu.edu Date: Fri, 27 Jul 2001 19:11:21 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, The following Reject reason codes are defined in rev07 that are related to retry - 4 - Command-Retry Reject 6 - Command-in-progress 7 - Command Replay Not Supported 9 - Immediate Command Retry Reject - task not found Since what we generically refer to as "retry" can be (section 7.1) one of (a) command plugging, or (b) command failover, or (c) command replay, I suggest that we define the Reject codes to specifically identify each of these three usages of retry bit. With that said, I propose to - - define a new reason code "Command failover not supported" specifically for (b). (see NOTE below) - drop "Command-Retry Reject" since it is too generic and can be inadvertently used for all flavors of retry rejects (which have separate codes, but are all technically retries). - drop "Immediate Command Retry Reject" since it could use o "Command-in-progress" for "proactive" retries (since command plugging is not really valid for an immediate command as it doesn't consume a CmdSN). o "Command failover not supported" for (b) o "Command Replay Not Supported" for (c) I am not sure about the current "task not found" qualifier - I assume that if the task is not found, it would be treated as a new immediate command and appropriately dealt with (reject-"too many immediate commands"/execute). NOTE: I also propose that a target that does not support command failover (CommandFailoverSupport=no) should fail the Logout Command with reason code "2" (recovery), with a TBD Logout Response code meaning "Connection recovery not supported.". Once this is done, the "Command failover not supported" Reject reason code (that I am proposing) is useful only for a transient period while the tasks are in the process of being cleaned up on target - though one could arguably use "Protocol Error" for those cases. My preference is to define the new Reject reason code for uniformity. -- 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 Sun Jul 29 00:26:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04016 for ; Sun, 29 Jul 2001 00:26:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S0BcU09731 for ips-outgoing; Fri, 27 Jul 2001 20:11:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from earth.vicom.com (206-14-133-15.ncal.verio.com [206.14.133.15] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6S0Bb209727 for ; Fri, 27 Jul 2001 20:11:37 -0400 (EDT) Received: by earth.vicom.com with Internet Mail Service (5.5.2650.21) id <3G0R5GJQ>; Fri, 27 Jul 2001 17:13:13 -0700 Message-ID: From: David Lee To: "'Rick Ellis'" , ips@ece.cmu.edu Subject: RE: Unsupported target LUN Date: Fri, 27 Jul 2001 17:13:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Rick, I would prefer not to see an iSCSI response at all, but rather a SCSI Check Condition status with appropriate Sense Data. David Lee Vicom Systems, Inc. 47821 Bayside Parkway Fremont, CA 94538 Phone: (510) 743-1162 Fax: (510) 743-1131 Email: david.lee@vicom.com -----Original Message----- From: Rick Ellis [mailto:rellis@integrix.com] Sent: Friday, July 27, 2001 4:13 PM To: ips@ece.cmu.edu Subject: Unsupported target LUN What response code should be sent from the target for a LUN that isn't valid? Would "target failure" suffice? From owner-ips@ece.cmu.edu Sun Jul 29 00:59:13 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01994 for ; Sat, 28 Jul 2001 23:57:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RLKlJ02412 for ips-outgoing; Fri, 27 Jul 2001 17:20:47 -0400 (EDT) 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 f6RLKk202408 for ; Fri, 27 Jul 2001 17:20:46 -0400 (EDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [161.44.68.87]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA01327; Fri, 27 Jul 2001 17:20:28 -0400 (EDT) Message-ID: <3B61D9C3.57F728E6@cisco.com> Date: Fri, 27 Jul 2001 16:14:43 -0500 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: Rod Harrison CC: eddy_quicksall@ivivity.com, "'Julian Satran'" , "'ips'" Subject: Re: iSCSI padding should be 0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod- The pad bytes are set to zero, rather than just sending whatever data is there, for minor security purposes. The pad bytes are included in the digest to simplify the hardware. I suggest we leave this as is. -- Mark Rod Harrison wrote: > > Can we not leave the pad bytes out of the digest > calculation and allow them to be any value. Having to zero > the pad bytes is the only reason to touch the payload > buffer. Is it really a security problem to allow the pad > bytes to be any value? > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Eddy Quicksall > Sent: Friday, July 27, 2001 11:24 AM > To: 'Julian Satran' > Cc: 'ips' > Subject: RE: iSCSI padding should be 0 > > Sounds good to me. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, July 27, 2001 11:46 AM > To: eddy_quicksall@ivivity.com > Cc: ips > Subject: Re: iSCSI padding should be 0 > > Perhaps we should say MUST be sent as 0 and keep quiet about > what the > receiver should do (check for 0 - we don't want that). > > Thanks,Julo > > "Eddy Quicksall" on 27-07-2001 > 18:18:33 > > Please respond to eddy_quicksall@ivivity.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: iSCSI padding should be 0 > > Julian, > > Section 2.1 says the padding should be 0. I guess that is > correct because > one may not use CRC and therefore may not want to set them > to 0. Wouldn't > it > be better if section 2.1 was more specific and mentioned > when they must be > 0 > if there is a CRC. Also, I noticed at the UNH plug fest that > at least one > person thought "should" meant "must". Therefore, I don't > think it should > say > "should" ... I think it should not mention the 0'ness unless > there is a CRC > present. > > Also, > > transmission. Padding bytes, when presents in a > segment covered by > a > CRC, have to be set to 0 and are included in the > CRC. > > should say "when present in". > > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 01:14:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA03982 for ; Sun, 29 Jul 2001 00:26:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S2Mnr14615 for ips-outgoing; Fri, 27 Jul 2001 22:22:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6S2Mm214610 for ; Fri, 27 Jul 2001 22:22:48 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id 6F0A91805 for ; Fri, 27 Jul 2001 19:22:47 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id TAA04966 for ips@ece.cmu.edu; Fri, 27 Jul 2001 19:19:01 -0700 (PDT) Message-Id: <200107280219.TAA04966@core.rose.hp.com> Subject: RE: Unsupported target LUN To: ips@ece.cmu.edu Date: Fri, 27 Jul 2001 19:19:01 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Shawn is right. So to answer Rick's original question, the SCSI Status for illegal LUN CHECK CONDITION should be qualified by the iSCSI response code of "0x00" - "Command Completed at Target". -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >From: "ERICKSON,SHAWN (HP-Roseville,ex1)" >To: "'David Lee'" , "'Rick Ellis'" , > ips@ece.cmu.edu >Subject: RE: Unsupported target LUN >Date: Fri, 27 Jul 2001 18:39:46 -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 >Status: RO > >The way things are currently defined for iSCSI (as most other SCSI >"transports") it doesn't really care about LUNs. iSCSI has fields to >transport the information regarding LUNs that matches with the SCSI protocol >but that is about where it ends. > >LUN handling is up the SCSI protocol. > >One could argue to have LUN discovery lifted up to iSCSI for "easy of use" >but I think the line should be drawn at that. > >-Shawn > >------------------------------------------------------- > Shawn Carl Erickson (805) 883-4319 [Telnet] > Hewlett Packard Company OV NSSO Joint Venture > Storage Resource Management R&D Lab (Santa Barbara) >------------------------------------------------------- > >------------------------------------------------------- > > > >> -----Original Message----- >> From: David Lee [mailto:David.Lee@vicom.com] >> Sent: Friday, July 27, 2001 5:13 PM >> To: 'Rick Ellis'; ips@ece.cmu.edu >> Subject: RE: Unsupported target LUN >> >> >> Rick, >> >> I would prefer not to see an iSCSI response at all, but >> rather a SCSI Check >> Condition status with appropriate Sense Data. >> >> David Lee >> Vicom Systems, Inc. >> 47821 Bayside Parkway >> Fremont, CA 94538 >> Phone: (510) 743-1162 >> Fax: (510) 743-1131 >> Email: david.lee@vicom.com >> >> >> -----Original Message----- >> From: Rick Ellis [mailto:rellis@integrix.com] >> Sent: Friday, July 27, 2001 4:13 PM >> To: ips@ece.cmu.edu >> Subject: Unsupported target LUN >> >> >> What response code should be sent from the target for a LUN >> that isn't valid? Would "target failure" suffice? >> From owner-ips@ece.cmu.edu Sun Jul 29 01:14:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04028 for ; Sun, 29 Jul 2001 00:26:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RHF5J18366 for ips-outgoing; Fri, 27 Jul 2001 13:15:05 -0400 (EDT) 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 f6RHF3218359 for ; Fri, 27 Jul 2001 13:15:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id <3W0TH54G>; Fri, 27 Jul 2001 13:14:58 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71E070AD8@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: Preliminary London Agenda Date: Fri, 27 Jul 2001 13:10:20 -0400 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 This will become a final agenda in the next few days. Comments to me, quickly please. Also, a reminder to all presenters - meeting time in London is NOT for presentations. ASSUME that your audience has read the draft and use the time to address open issues. Thanks, --David IETF IP Storage (IPS) Working Group London IETF Meeting, August 5-10, 2001 ------------------------------------------- CHAIRS: David Black Elizabeth Rodriguez PRELIMINARY AGENDA: SUBJECT TO CHANGE NOTE: The London IETF meetings conflict with T11 meetings (T11 is the standards organization for Fibre Channel). Therefore the IP Storage Working Group will not be able to work on the FCIP or iFCP protocols or related items in London. INTERIM MEETING: August 27-28, Orange County, CA, USA Main topics will be Fibre Channel related protocols (FCIP and iFCP) and Security for all IPS protocols (iSCSI, FCIP, and iFCP). An announcement with location and additional details is available at: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05297.html ---- Monday, August 6, 1930-2200 ---- - Agenda Bashing and Administrivia (10 min) - iSCSI Plugfest Results and Discussion (30 min) - iSCSI Security (40 min) draft-black-ips-iscsi-security-00.txt NOTE: This draft covers both security requirements and SRP keying. Use of IKE for keying and considerations for selecting ESP algorithms (authentication and encryption) for iSCSI will also be discussed. - iSCSI Framing Mechanism Requirements (30 min) draft-ietf-tsvwg-tcp-ulp-frame-00.txt NOTE: The contents of this draft will be discussed in TSVWG. This IPS WG time is to discuss iSCSI requirements for use of these mechanisms. - iSCSI (40 min) draft-ietf-ips-iscsi-07.txt Includes Error Recovery ---- Tuesday, August 21, 0900-1130 ---- - Agenda Bashing and Administrivia (5 min) - iSCSI [continued] (85 minutes) draft-ietf-ips-iscsi-07.txt Includes opportunities for simplification. - iSCSI Naming and Discovery Requirements (30 min) draft-ietf-ips-iscsi-name-disc-02.txt Includes mapping of SAM-2 SCSI abstractions to iSCSI and consequences. - iSCSI MIB (10 min) draft-ietf-ips-iscsi-mib-02.txt UML model diagram available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-02.pdf Table structure diagram available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-02.pdf - Use of SLP and iSNS with ISCSI (20 min) draft-ietf-ips-iscsi-slp-01.txt draft-ietf-ips-isns-04.txt DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html From owner-ips@ece.cmu.edu Sun Jul 29 01:14:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04030 for ; Sun, 29 Jul 2001 00:26:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RHanu19624 for ips-outgoing; Fri, 27 Jul 2001 13:36:49 -0400 (EDT) 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 f6RHa5219555 for ; Fri, 27 Jul 2001 13:36:10 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Jul 27 13:34:34 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Jul 27 13:34:58 EDT 2001 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 NAA11740; Fri, 27 Jul 2001 13:34:32 -0400 (EDT) Message-ID: <3B61A628.CE2C07B3@research.bell-labs.com> Date: Fri, 27 Jul 2001 13:34:32 -0400 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: Julian Satran CC: ips@ece.cmu.edu Subject: Re: iSCSI: NOP-Out closing the command window 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 Satran wrote: > > Sandeep, > > They are 3 distinguishing elements P and the ITT+TTT. > > Julo > I believe you are commenting on my question about the validity about the 2nd sequence.. correct ? But this 2nd sequence isn't documented in Sec 2.12 or 2.13. Incidentally, there is a similar ping type mentioned in Sec 2.13.1 and its used to test the connection from the target end. Could you please say what the response would be : T->I NOP +P=0 T=ff I=ff I->T < response or it none ? > And I still prefer that the ping response from the initiator *not* have a valid ITT/cmdSN. A 3-way ping looks forbidding and may open up new problems. -Sandeep > Sandeep Joshi on 27-07-2001 18:53:20 > > Please respond to Sandeep Joshi > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: NOP-Out closing the command window > > If the NOP-Out does not have the ping-bit set, then it is a > ping response and *not* a new command being issued by the > initiator. > > Hence, it seems that the NOP-OUT with P=0 need not carry a > new cmdSN (Mark's 2nd option). > > Btw, I did not know the 2nd sequence (P=0 from initiator?) > below was valid > > I->T NOP +P=0 +I=x+ Data > > T->I NOP +P=0 +I=x > > -Sandeep > > Julian Satran wrote: > > > > Mark, > > > > Definitely a problem . How about stating (the obvious) that NOP as any > > thing carying an ITT expectes an answer > > wheter it carries an echo (P=1) or not (P=0). > > > > If it does not carry an ITT it does not. > > > > We can have the following sequences all valid: > > > > I->T NOP +P=1 +I=x+ Data > > T->I NOP +P=0 + Data > > > > I->T NOP +P=0 +I=x+ Data > > T->I NOP +P=0 +I=x > > > > T->I NOP +P=1 +TTT > > I->T NOP +P=0 I=1 + TTT (no ITT) > > > > All would be permitted today if we remove the tie between ITT and P say > > that NOP must have an ITT if issued at initiators initiative. > > > > We might add as valid (today it is not, it is explicitly forbidden): > > > > T->I NOP +P=1 +TTT > > I->T NOP +P=1+ I= 1 TTT + ITT + Data > > T->I NOP +P=0 +ITT + Data > > > > The last requires us to "tweak" the termination rule (a target is > forbiden > > to answer a P=1 with a P=1 > > > > comments? > > Julo > > > > Mark Bakke on 27-07-2001 16:25:20 > > > > Please respond to Mark Bakke > > > > To: IPS > > cc: > > Subject: iSCSI: NOP-Out closing the command window > > > > When sending a NOP-Out without the P bit set, there's > > no response to update ExpCmdSN to keep the window open. > > > > On an otherwise idle session, sending a long enough > > sequence of these NOP-Outs can close the command window > > permanently. > > > > In case of a stuck command window, please break glass... > > > > The easy solution is to turn on the P bit, and get the > > responses to update the window, but that defaults the > > purpose of allowing the P bit to not be set in the first > > place. > > > > Another easy solution (but I almost hate to mention it) > > is not to have NOP-Out update the CmdSN. This seems to > > have the possibility of breaking other things. > > > > I suppose we could come up with a more complicated rule, > > like "if the NOP-Out's CmdSN would be the last (or perhaps > > penultimate) CmdSN allowed by the current window, it MUST > > set the P bit." Or something like that. > > > > Anyway, I see three possible solutions. Any thoughts? > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 01:14:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04037 for ; Sun, 29 Jul 2001 00:26:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RIUDO22708 for ips-outgoing; Fri, 27 Jul 2001 14:30:13 -0400 (EDT) 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 f6RHTt219231 for ; Fri, 27 Jul 2001 13:29:55 -0400 (EDT) Received: from EDDYLAPTOP ([192.168.1.171]) by mail.ivivity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id PV5XL1TZ; Fri, 27 Jul 2001 13:29:49 -0400 Reply-To: From: "Eddy Quicksall" To: "'Fischer, Michael'" , Cc: Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 13:29:40 -0400 Message-ID: <000901c116c1$b8846c70$ab01a8c0@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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mike, you're not stepping on toes nor are you butting in. We need this kind of input because no one on this reflector knows everything. Thanks for your input. In this case, I feel that MUST is appropriate and that if someone wants take the time to check it then they are within their rights to do that. In fact, your test tools SHOULD check it if we say MUST. But, I don't think there would be a requirement for a target or initiator to check it ... just to do it. Eddy -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Friday, July 27, 2001 1:21 PM To: 'eddy_quicksall@ivivity.com'; julian_satran@il.ibm.com Cc: 'ips@ece.cmu.edu' Subject: RE: iSCSI padding should be 0 Eddy, This discussion is purely based on semantics and the definition of the word. MUST indicates that it is REQUIRED. Yes? If it is REQUIRED that the padding be set to 0 and it is NOT then that implementation is in violation of the spec. Yes? You are correct that the RFC does not say that you must check it but it does imply it (or at least that it is checkable), which is what I stated. My concern is that Julian suggested that the spec say MUST be 0 and that he did NOT want people to check for 0. To insure that it is not checked, the statement MUST remain "SHOULD be 0." In the production environment, the checking of whether or not the padding has been set to zero may be bypassed for whatever reason, but in a testing environment (guess where I work. :) ), I am sure that if someone read the spec and implemented a test tool to verify that their implementation conforms to the spec they could generate a bug report if the padding was not 0. I am just trying to make sure that the spec is as unambiguous as possible and I apologize if I am stepping on any toes. Michael Fischer -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, July 27, 2001 9:32 AM To: 'Fischer, Michael'; julian_satran@il.ibm.com Subject: RE: iSCSI padding should be 0 The RFC says: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. How does that say that I MUST check to be sure it has been done? Is that requirement someplace else? Eddy -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Friday, July 27, 2001 12:26 PM To: 'Julian_Satran/Haifa/IBM%IBMIL'; eddy_quicksall@ivivity.com Cc: ips Subject: RE: iSCSI padding should be 0 Julian, I hate to butt in with this minor point, I think you guys are doing a great job in hammering out the specification and do not presume to know better. However, according to RFC2119 the word MUST indicates that it is a requirement of the specification and therefore implies that the receiver will need to check the value. If it MUST be zero and is not, then that would indicate a protocol error. Michael Fischer -----Original Message----- From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com] Sent: Friday, July 27, 2001 8:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sun Jul 29 01:14:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04044 for ; Sun, 29 Jul 2001 00:27:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RHigT20026 for ips-outgoing; Fri, 27 Jul 2001 13:44:42 -0400 (EDT) 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 f6RHid220020 for ; Fri, 27 Jul 2001 13:44:40 -0400 (EDT) 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 KAA29884; Fri, 27 Jul 2001 10:44:33 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA11257; Fri, 27 Jul 2001 10:32:49 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 10:44:33 -0700 Message-ID: From: "Fischer, Michael" To: "'eddy_quicksall@ivivity.com'" , julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 10:44:25 -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 Eddy, I guess I can live with that. I actually prefer the use of MUST myself. I guess I should have argued on the technical details rather than on the semantic technicalities. Since I zero the structure before I get started anyway so it doesn't really matter to me anyway. :) I was just concerned when the statement was made to the effect that someone may not want to leave it set to zero if they are not using crc. If later on the spec changes and they are no longer padding bytes, this will cause some serious trouble for any implementation that does not set the padding to zero. Keep up the good work. Michael Fischer -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, July 27, 2001 10:30 AM To: 'Fischer, Michael'; julian_satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI padding should be 0 Mike, you're not stepping on toes nor are you butting in. We need this kind of input because no one on this reflector knows everything. Thanks for your input. In this case, I feel that MUST is appropriate and that if someone wants take the time to check it then they are within their rights to do that. In fact, your test tools SHOULD check it if we say MUST. But, I don't think there would be a requirement for a target or initiator to check it ... just to do it. Eddy -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Friday, July 27, 2001 1:21 PM To: 'eddy_quicksall@ivivity.com'; julian_satran@il.ibm.com Cc: 'ips@ece.cmu.edu' Subject: RE: iSCSI padding should be 0 Eddy, This discussion is purely based on semantics and the definition of the word. MUST indicates that it is REQUIRED. Yes? If it is REQUIRED that the padding be set to 0 and it is NOT then that implementation is in violation of the spec. Yes? You are correct that the RFC does not say that you must check it but it does imply it (or at least that it is checkable), which is what I stated. My concern is that Julian suggested that the spec say MUST be 0 and that he did NOT want people to check for 0. To insure that it is not checked, the statement MUST remain "SHOULD be 0." In the production environment, the checking of whether or not the padding has been set to zero may be bypassed for whatever reason, but in a testing environment (guess where I work. :) ), I am sure that if someone read the spec and implemented a test tool to verify that their implementation conforms to the spec they could generate a bug report if the padding was not 0. I am just trying to make sure that the spec is as unambiguous as possible and I apologize if I am stepping on any toes. Michael Fischer -----Original Message----- From: Eddy Quicksall [mailto:eddy_quicksall@ivivity.com] Sent: Friday, July 27, 2001 9:32 AM To: 'Fischer, Michael'; julian_satran@il.ibm.com Subject: RE: iSCSI padding should be 0 The RFC says: MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. How does that say that I MUST check to be sure it has been done? Is that requirement someplace else? Eddy -----Original Message----- From: Fischer, Michael [mailto:Michael_Fischer@adaptec.com] Sent: Friday, July 27, 2001 12:26 PM To: 'Julian_Satran/Haifa/IBM%IBMIL'; eddy_quicksall@ivivity.com Cc: ips Subject: RE: iSCSI padding should be 0 Julian, I hate to butt in with this minor point, I think you guys are doing a great job in hammering out the specification and do not presume to know better. However, according to RFC2119 the word MUST indicates that it is a requirement of the specification and therefore implies that the receiver will need to check the value. If it MUST be zero and is not, then that would indicate a protocol error. Michael Fischer -----Original Message----- From: Julian_Satran/Haifa/IBM%IBMIL [mailto:julian_satran@il.ibm.com] Sent: Friday, July 27, 2001 8:46 AM To: eddy_quicksall@ivivity.com Cc: ips Subject: Re: iSCSI padding should be 0 Perhaps we should say MUST be sent as 0 and keep quiet about what the receiver should do (check for 0 - we don't want that). Thanks,Julo "Eddy Quicksall" on 27-07-2001 18:18:33 Please respond to eddy_quicksall@ivivity.com To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: iSCSI padding should be 0 Julian, Section 2.1 says the padding should be 0. I guess that is correct because one may not use CRC and therefore may not want to set them to 0. Wouldn't it be better if section 2.1 was more specific and mentioned when they must be 0 if there is a CRC. Also, I noticed at the UNH plug fest that at least one person thought "should" meant "must". Therefore, I don't think it should say "should" ... I think it should not mention the 0'ness unless there is a CRC present. Also, transmission. Padding bytes, when presents in a segment covered by a CRC, have to be set to 0 and are included in the CRC. should say "when present in". Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sun Jul 29 01:19:12 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08017 for ; Sun, 29 Jul 2001 01:19:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S3M7G16881 for ips-outgoing; Fri, 27 Jul 2001 23:22:07 -0400 (EDT) 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 f6S3M5216877 for ; Fri, 27 Jul 2001 23:22:05 -0400 (EDT) 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 FAA239472 for ; Sat, 28 Jul 2001 05:21:59 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S3Lwc48732 for ; Sat, 28 Jul 2001 05:21:58 +0200 Importance: Normal Subject: Re: iSCSI login phasing To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 06:27:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 06:21:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk If the initiator is willing to do security but would rather not offer anything it will start with a SecurityPhase - without any offering. If it starts with OperationalPhase it indicate it is not willing/capable of doing security. The target can only accept or reject. Julo Steve Senum on 27-07-2001 19:19:19 Please respond to Steve Senum To: ietf-ips cc: Subject: Re: iSCSI login phasing Julian, Questions on your proposal. 1. Is the Initiator then required to start with either a SecurityPhase=start or an OperationalPhase=start on the initial login command? 2. If the Initiator started with OperationalPhase=start, does the target have any way to force a SecurityPhase=start? Steve Senum Julian Satran wrote: > > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > Comments? > > Julo From owner-ips@ece.cmu.edu Sun Jul 29 01:51:54 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13670 for ; Sun, 29 Jul 2001 01:51:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S4UtO19303 for ips-outgoing; Sat, 28 Jul 2001 00:30:55 -0400 (EDT) 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 f6S4Ur219299 for ; Sat, 28 Jul 2001 00:30:53 -0400 (EDT) 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 GAA25588 for ; Sat, 28 Jul 2001 06:30:47 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S4Ul5193432 for ; Sat, 28 Jul 2001 06:30:47 +0200 Importance: Normal Subject: Re: iSCSI padding should be 0 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 07:36:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 07:30:46 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Is the software padding more expensive than checking if there is a CRC (or any other digest)? On the other hand CRCs don't require the bytes to be 0 they can be arbitrary values. The 0 was brought in to avoid "leakage" (security) by somebody on the list. We can choose to revert to arbitrary and leave the burden of cleaning to the applications for which security is a concern. Julo "Eddy Quicksall" on 27-07-2001 22:05:59 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: "ips" Subject: Re: iSCSI padding should be 0 I saw one objection to this by Michael Fischer [Michael_Fischer@adaptec.com]. He pointed out that if there is no CRC then why require the padding to be 0. I agree with his point. The problem is with software only implementations ... if they use the sockets send function and if they are sending from a ULP buffer and if the data being sent needs padding, they will have to either copy to another buffer or do an extra tiny send for the pad. So, my thinking is that we say: iSCSI PDUs are padded to an integer number of 4 byte words. If CRC is being used, the padding MUST be 0. If CRC is not being used, the content of the padding is unpredictable and irrelevent. What do you think? Eddy ----- Original Message ----- From: "Julian_Satran/Haifa/IBM%IBMIL" To: Cc: "ips" Sent: Friday, July 27, 2001 11:45 AM Subject: Re: iSCSI padding should be 0 > > Perhaps we should say MUST be sent as 0 and keep quiet about what the > receiver should do (check for 0 - we don't want that). > > Thanks,Julo > > "Eddy Quicksall" on 27-07-2001 18:18:33 > > Please respond to eddy_quicksall@ivivity.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: iSCSI padding should be 0 > > > > > Julian, > > Section 2.1 says the padding should be 0. I guess that is correct because > one may not use CRC and therefore may not want to set them to 0. Wouldn't > it > be better if section 2.1 was more specific and mentioned when they must be > 0 > if there is a CRC. Also, I noticed at the UNH plug fest that at least one > person thought "should" meant "must". Therefore, I don't think it should > say > "should" ... I think it should not mention the 0'ness unless there is a CRC > present. > > Also, > > transmission. Padding bytes, when presents in a segment covered by > a > CRC, have to be set to 0 and are included in the CRC. > > should say "when present in". > > Eddy_Quicksall@iVivity.com > > > > > From owner-ips@ece.cmu.edu Sun Jul 29 01:51:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13674 for ; Sun, 29 Jul 2001 01:51:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S4BDE18535 for ips-outgoing; Sat, 28 Jul 2001 00:11:13 -0400 (EDT) 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 f6S4BB218531 for ; Sat, 28 Jul 2001 00:11:11 -0400 (EDT) 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 GAA57492 for ; Sat, 28 Jul 2001 06:11:05 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S4B4c227192 for ; Sat, 28 Jul 2001 06:11:04 +0200 Importance: Normal Subject: Re: iSCSI: NOP-Out closing the command window To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 07:17:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 07:11:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, You are right the sequences are not documented now and that is why I put them out here - to hear comments. A PDU with P=0 from the target (no ITT) could be hadndled as a mistake. The 3-way sequence is probably the simplest for the code to handle (no special path for a request that has no answer). Julo Sandeep Joshi on 27-07-2001 20:34:32 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: NOP-Out closing the command window Julian Satran wrote: > > Sandeep, > > They are 3 distinguishing elements P and the ITT+TTT. > > Julo > I believe you are commenting on my question about the validity about the 2nd sequence.. correct ? But this 2nd sequence isn't documented in Sec 2.12 or 2.13. Incidentally, there is a similar ping type mentioned in Sec 2.13.1 and its used to test the connection from the target end. Could you please say what the response would be : T->I NOP +P=0 T=ff I=ff I->T < response or it none ? > And I still prefer that the ping response from the initiator *not* have a valid ITT/cmdSN. A 3-way ping looks forbidding and may open up new problems. -Sandeep > Sandeep Joshi on 27-07-2001 18:53:20 > > Please respond to Sandeep Joshi > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: NOP-Out closing the command window > > If the NOP-Out does not have the ping-bit set, then it is a > ping response and *not* a new command being issued by the > initiator. > > Hence, it seems that the NOP-OUT with P=0 need not carry a > new cmdSN (Mark's 2nd option). > > Btw, I did not know the 2nd sequence (P=0 from initiator?) > below was valid > > I->T NOP +P=0 +I=x+ Data > > T->I NOP +P=0 +I=x > > -Sandeep > > Julian Satran wrote: > > > > Mark, > > > > Definitely a problem . How about stating (the obvious) that NOP as any > > thing carying an ITT expectes an answer > > wheter it carries an echo (P=1) or not (P=0). > > > > If it does not carry an ITT it does not. > > > > We can have the following sequences all valid: > > > > I->T NOP +P=1 +I=x+ Data > > T->I NOP +P=0 + Data > > > > I->T NOP +P=0 +I=x+ Data > > T->I NOP +P=0 +I=x > > > > T->I NOP +P=1 +TTT > > I->T NOP +P=0 I=1 + TTT (no ITT) > > > > All would be permitted today if we remove the tie between ITT and P say > > that NOP must have an ITT if issued at initiators initiative. > > > > We might add as valid (today it is not, it is explicitly forbidden): > > > > T->I NOP +P=1 +TTT > > I->T NOP +P=1+ I= 1 TTT + ITT + Data > > T->I NOP +P=0 +ITT + Data > > > > The last requires us to "tweak" the termination rule (a target is > forbiden > > to answer a P=1 with a P=1 > > > > comments? > > Julo > > > > Mark Bakke on 27-07-2001 16:25:20 > > > > Please respond to Mark Bakke > > > > To: IPS > > cc: > > Subject: iSCSI: NOP-Out closing the command window > > > > When sending a NOP-Out without the P bit set, there's > > no response to update ExpCmdSN to keep the window open. > > > > On an otherwise idle session, sending a long enough > > sequence of these NOP-Outs can close the command window > > permanently. > > > > In case of a stuck command window, please break glass... > > > > The easy solution is to turn on the P bit, and get the > > responses to update the window, but that defaults the > > purpose of allowing the P bit to not be set in the first > > place. > > > > Another easy solution (but I almost hate to mention it) > > is not to have NOP-Out update the CmdSN. This seems to > > have the possibility of breaking other things. > > > > I suppose we could come up with a more complicated rule, > > like "if the NOP-Out's CmdSN would be the last (or perhaps > > penultimate) CmdSN allowed by the current window, it MUST > > set the P bit." Or something like that. > > > > Anyway, I see three possible solutions. Any thoughts? > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 01:51:55 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13692 for ; Sun, 29 Jul 2001 01:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S1L2G12485 for ips-outgoing; Fri, 27 Jul 2001 21:21:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6S1L1212480 for ; Fri, 27 Jul 2001 21:21:01 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel1.hp.com (Postfix) with ESMTP id 793E4165C for ; Fri, 27 Jul 2001 18:21:00 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id SAA27516 for ips@ece.cmu.edu; Fri, 27 Jul 2001 18:22:14 -0700 (PDT) Message-Id: <200107280122.SAA27516@core.rose.hp.com> Subject: iSCSI: data ordering To: ips@ece.cmu.edu Date: Fri, 27 Jul 2001 18:22:14 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Rev 07 defines the text keys DataOrder and DataDeliveryOrder to distinguish sequence-level and PDU-level ordering. For clarity (since both have to do with data delivery ordering), can I suggest to rename them as - DataSequenceOrder and DataPDUOrder respectively? Also, both these are qualified by the sentence "The default is yes but targets MAY support no." I assume initiators have the same options (and not all initiators may support OOO data based on hardware constraints). I suggest stating it as: "Default is yes." as elsewhere. Thanks. -- 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 Sun Jul 29 01:51:56 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13701 for ; Sun, 29 Jul 2001 01:51:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S1dpD13089 for ips-outgoing; Fri, 27 Jul 2001 21:39:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6S1do213085 for ; Fri, 27 Jul 2001 21:39:50 -0400 (EDT) Received: from xparelay2.corp.hp.com (unknown [15.58.137.112]) by palrel1.hp.com (Postfix) with ESMTP id A3CE318CE; Fri, 27 Jul 2001 18:39:49 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay2.corp.hp.com (Postfix) with ESMTP id 54FDD1F52E; Fri, 27 Jul 2001 18:39:48 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:39:48 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6508E9970C@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'David Lee'" , "'Rick Ellis'" , ips@ece.cmu.edu Subject: RE: Unsupported target LUN Date: Fri, 27 Jul 2001 18:39:46 -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 The way things are currently defined for iSCSI (as most other SCSI "transports") it doesn't really care about LUNs. iSCSI has fields to transport the information regarding LUNs that matches with the SCSI protocol but that is about where it ends. LUN handling is up the SCSI protocol. One could argue to have LUN discovery lifted up to iSCSI for "easy of use" but I think the line should be drawn at that. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: David Lee [mailto:David.Lee@vicom.com] > Sent: Friday, July 27, 2001 5:13 PM > To: 'Rick Ellis'; ips@ece.cmu.edu > Subject: RE: Unsupported target LUN > > > Rick, > > I would prefer not to see an iSCSI response at all, but > rather a SCSI Check > Condition status with appropriate Sense Data. > > David Lee > Vicom Systems, Inc. > 47821 Bayside Parkway > Fremont, CA 94538 > Phone: (510) 743-1162 > Fax: (510) 743-1131 > Email: david.lee@vicom.com > > > -----Original Message----- > From: Rick Ellis [mailto:rellis@integrix.com] > Sent: Friday, July 27, 2001 4:13 PM > To: ips@ece.cmu.edu > Subject: Unsupported target LUN > > > What response code should be sent from the target for a LUN > that isn't valid? Would "target failure" suffice? > From owner-ips@ece.cmu.edu Sun Jul 29 02:44:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13711 for ; Sun, 29 Jul 2001 01:51:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RNT8S08151 for ips-outgoing; Fri, 27 Jul 2001 19:29:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dominoe.integrix.com ([207.171.9.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6RNAX207375 for ; Fri, 27 Jul 2001 19:10:38 -0400 (EDT) Received: from integrix.com (rellis [192.9.200.208]) by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA18496 for ; Fri, 27 Jul 2001 16:09:13 -0700 (PDT) Message-ID: <3B61F570.8A0CEBB5@integrix.com> Date: Fri, 27 Jul 2001 16:12:48 -0700 From: Rick Ellis X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Unsupported target LUN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit What response code should be sent from the target for a LUN that isn't valid? Would "target failure" suffice? From owner-ips@ece.cmu.edu Sun Jul 29 02:44:16 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13667 for ; Sun, 29 Jul 2001 01:51:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6S5xO422457 for ips-outgoing; Sat, 28 Jul 2001 01:59:24 -0400 (EDT) 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 f6S5xN222452 for ; Sat, 28 Jul 2001 01:59:23 -0400 (EDT) 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 HAA42548 for ; Sat, 28 Jul 2001 07:59:17 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6S5xG5214204 for ; Sat, 28 Jul 2001 07:59:16 +0200 Importance: Normal Subject: Re: iSCSI connection recovery To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sat, 28 Jul 2001 09:05:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 28/07/2001 08:59:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Retry over any connection was always the case. Commands can change allegiance only after a logout. The commands get quiesced anyway and you have to mark them ready for a retry anyhow (you don't want retry at arbitrary times to hit unpunished the target). After that it doesn't matter where you retry (same connection, another old one, a new one). The only new thing is command replay (after status was sent but before it is acked). Regards, Julo sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 06:37:33 Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu cc: Subject: iSCSI connection recovery I had a "big-picture" question about the connection recovery model. The current draft suggests that, once the broken connection is logged out, the commands allegiant to the old connection can now be retried over *any* connection. (See Section 7.11.3 bullet 1 and also Appendix F Session Recovery algo for initiator.) I may be mistaken, but in previous drafts, this was not the case and commands always stayed allegiant to a CID. So the question is.. how does one use a Status cache belonging to the old connection in this new model (now that the commands are going to be retried over any connection) Doesnt this become more complex ? Secondly, this also means that one must walk the command list at the target and quiesce connection allegiance during logout - which may not be required if the commands were to be retried over the same connection always. Comments ? -Sandeep From owner-ips@ece.cmu.edu Sun Jul 29 02:44:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13724 for ; Sun, 29 Jul 2001 01:51:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RMp1J06494 for ips-outgoing; Fri, 27 Jul 2001 18:51:01 -0400 (EDT) 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 f6RMp0206490 for ; Fri, 27 Jul 2001 18:51:00 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Fri, 27 Jul 2001 18:50:53 -0400 Message-ID: <25369470B6F0D41194820002B328BDD20266E1@ATLOPS> From: Sanjay Goyal To: "'Mark Bakke'" Cc: Eddy Quicksall , "'Julian Satran'" , "'ips'" Subject: RE: iSCSI padding should be 0 Date: Fri, 27 Jul 2001 18:50:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi Mark What are those "minor security purposes", would you please elaborate that. Sanjay G -----Original Message----- From: Mark Bakke [mailto:mbakke@cisco.com] Sent: Friday, July 27, 2001 5:15 PM To: Rod Harrison Cc: eddy_quicksall@ivivity.com; 'Julian Satran'; 'ips' Subject: Re: iSCSI padding should be 0 Rod- The pad bytes are set to zero, rather than just sending whatever data is there, for minor security purposes. The pad bytes are included in the digest to simplify the hardware. I suggest we leave this as is. -- Mark Rod Harrison wrote: > > Can we not leave the pad bytes out of the digest > calculation and allow them to be any value. Having to zero > the pad bytes is the only reason to touch the payload > buffer. Is it really a security problem to allow the pad > bytes to be any value? > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On > Behalf Of > Eddy Quicksall > Sent: Friday, July 27, 2001 11:24 AM > To: 'Julian Satran' > Cc: 'ips' > Subject: RE: iSCSI padding should be 0 > > Sounds good to me. > > Eddy > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, July 27, 2001 11:46 AM > To: eddy_quicksall@ivivity.com > Cc: ips > Subject: Re: iSCSI padding should be 0 > > Perhaps we should say MUST be sent as 0 and keep quiet about > what the > receiver should do (check for 0 - we don't want that). > > Thanks,Julo > > "Eddy Quicksall" on 27-07-2001 > 18:18:33 > > Please respond to eddy_quicksall@ivivity.com > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: iSCSI padding should be 0 > > Julian, > > Section 2.1 says the padding should be 0. I guess that is > correct because > one may not use CRC and therefore may not want to set them > to 0. Wouldn't > it > be better if section 2.1 was more specific and mentioned > when they must be > 0 > if there is a CRC. Also, I noticed at the UNH plug fest that > at least one > person thought "should" meant "must". Therefore, I don't > think it should > say > "should" ... I think it should not mention the 0'ness unless > there is a CRC > present. > > Also, > > transmission. Padding bytes, when presents in a > segment covered by > a > CRC, have to be set to 0 and are included in the > CRC. > > should say "when present in". > > Eddy_Quicksall@iVivity.com -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 02:44:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13731 for ; Sun, 29 Jul 2001 01:51:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RMp0c06489 for ips-outgoing; Fri, 27 Jul 2001 18:51:00 -0400 (EDT) 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 f6RMow206484 for ; Fri, 27 Jul 2001 18:50:58 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id SAA20741 for ; Fri, 27 Jul 2001 18:50:53 -0400 (EDT) Message-ID: <3B61EFAD.EBE2CCA9@cisco.com> Date: Fri, 27 Jul 2001 17:48:13 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI login phasing 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, I like the intent of your proposal, with explict keys to mark the beginning of the phases. I still think we could achieve most of this with the existing handshake protocols (SecurityContextComplete for the SecurityPhase phase, F=1 bits for the OperationalPhase). We just need to define exactly when the SecurityPhase is (and is not) entered. I still vote for going through the SecurityPhase all the time. But, your proposal is a bit more precise on these points, and a more complete solution. Regards, Steve Senum Julian Satran wrote: > > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > Comments? > > Julo From owner-ips@ece.cmu.edu Sun Jul 29 02:44:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13743 for ; Sun, 29 Jul 2001 01:51:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6RN0Oc06868 for ips-outgoing; Fri, 27 Jul 2001 19:00:24 -0400 (EDT) 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 f6RN0N206864 for ; Fri, 27 Jul 2001 19:00:23 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-173.cisco.com [161.44.68.173]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA09380 for ; Fri, 27 Jul 2001 19:00:17 -0400 (EDT) Message-ID: <3B61F1E1.9CBE77FA@cisco.com> Date: Fri, 27 Jul 2001 17:57:37 -0500 From: Steve Senum X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI login phasing References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, I like your overall approach, but at this point, I would favor Julian's proposal. If the WG wanted to minimize the changes though, I think your approach should be looked at some more. Comment: I am a bit confused by your iSCSI Target state diagram. I would think you should be able to go from T1 to either T2 or T4, depending on what the login command contained. Something like login command with SecurityContextComplete=yes goes to T4, else goes to T2. Also, I would not expect to see T3 (Leave Security) as a state. Regards, Steve Senum "Robert D. Russell" wrote: > > All: > > Attached are 2 ASCII text files. Once contains a state diagram > for the iSCSI Initiator login phase, the other a state diagram > for the iSCSI Target login phase. > > The Initiator state machine has only 6 states with 10 allowed > transitions, and the Target state machine has only 5 states > with 7 allowed transitions. Both diagrams have the form of > a single "spine" with minimal branching. Error/failure > transitions are not shown, since they always result in > closing the connection during login (on the target side > a reject message may be sent first). > > Both of these diagrams are based on draft 7 with simplifications > suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall, > Stephen Bailey, Barry Reinhold, myself and others. > > These include: > > 1. Every login is split into 2 distinct subphases (security and > operational) with a required demarcation line between them. > > 1. Every login starts in the security subphase and must contain > at least the keys: TargetName, InitiatorName, HeaderDigest, > DataDigest, AuthMethod, and optionally SessionType=Normal. > > 2. No operational parameters can be negotiated before or during > the security subphase (informational parameters, like > TargetName, although listed in Appendix D, do not require > negotiation and are not considered "operational" here). > > 3. The security subphase ends with a required 2- or 3-way handshake of > Text and Text Response PDUs containing only the > SecurityContextComplete=yes key and ending with a message from > the target to the initiator. The negotiated security functions > become effective only at the successful conclusion of this handshake. > > 4. The operational subphase always begins immediately after the > handshake had been completed. No security parameters can be > negotiated during or after the operational subphase. > > 5. The operational subphase ends with a Login Response with F=1 from > the target to the initiator, at which time both target and > initiator are in Full Feature Phase (the final state in both > diagrams). > > Comments please. > > Bob Russell > InterOperability Lab > University of New Hampshire > rdr@iol.unh.edu > 603-862-3774 > > On Fri, 27 Jul 2001, Julian Satran wrote: > > > Dear colleagues, > > > > As some of you have complained about difficulty in implementing the login > > phase I thought it might be worthwhile to consider a slight departure from > > the current description. > > > > The current text assumes that negotiations are forming one tree and the > > "login machine" has to parse the tree. > > A leaf node will completely define a state and some pathes may get you to > > error. > > > > I was driven to this design by the need to keep the parsing tree minimal > > (under the assumption that any split in subtrees > > will result is some parameters needing to appear in several subtrees). > > > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > > that few if any have done the generalized mapping I started with, and > > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > > trees for the next plugfest (although by then some bright undergraduate > > student may take onto himself to give us an open-source yacc definition of > > the login phase!). > > > > I looked at the 2 phases and the number of key=values that they share are > > probably limited today at initiator and target names (some > > organizations/configurations want them for authentication while some others > > will object to them being revealed in the "open phase") and as such we may > > want to slit the login in 2, completely bracketed, phases each of them > > optional but not both: > > > > > > a security phase that if present must start with the login command and > > is bracketed by the pairs SecurityPhase=start and ended by > > SecurityPhase=end (on both initiator and target) > > an operational-parameter-negotiation phase that must follow security > > phase (if there is a security phase) and is bracketed by the pairs > > OperationalPhase=start and OperationalPhase=end (on both initiator and > > target) > > > > > > Some additional rules will apply: > > > > No request/response will span phases > > The phase closing handshake can start on both sides but if started at > > target will be followed by an "full initiator target handshake" - i.e a > > new phase or the "curtain close" end always with the target having the > > last word. > > keys will be clearly segregated and only a few (like names) should be > > allowed in both. > > > > > > Comments? > > > > Julo > > > > > > > > -------------------------------------------------------------------------------- > Name: i_states > i_states Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 > > Name: t_states > t_states Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 From owner-ips@ece.cmu.edu Sun Jul 29 02:50:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26403 for ; Sun, 29 Jul 2001 02:50:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6T5lrW23044 for ips-outgoing; Sun, 29 Jul 2001 01:47:53 -0400 (EDT) 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 f6T5lp223040 for ; Sun, 29 Jul 2001 01:47:51 -0400 (EDT) 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 HAA88428 for ; Sun, 29 Jul 2001 07:47:34 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6T5lXn31530 for ; Sun, 29 Jul 2001 07:47:34 +0200 Importance: Normal Subject: Re: iSCSI: Reject, CmdSN, and DataSN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sun, 29 Jul 2001 08:53:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 29/07/2001 08:47:33 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikurjun, I thought that my earlier comment on this was clear - but apparently it was not. The problem is real. There as trivial case in which a format error in a command, will force the window to close as the reject may be the only trafic and it does not carry ExpCmdSN etc. There are several things to be done (and as I mentioned earlier I fixed both): the reject command should carry the same updates as all others (ExpCmdSN etc.) - good practice anyhow the local fields should be updated even if the command is rejected - whenever possible (there is no digest error) The command slot should be considered filled Here is the proposed new text for 2.19 1.1 Reject 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|1|1| 0x3f |1| Reserved (0) | +---------------+---------------+---------------+---------------+ 4| Reserved (0) | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8/ Reserved (0) / +/ / +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 26| Reserved (0) | +---------------+---------------+---------------+---------------+ 40| Reason | Reserved (0) | First Bad Byte or Rsvd(0) | +---------------+---------------+---------------+---------------+ 44| Reserved (0) | +---------------+---------------+---------------+---------------+ 48| Digests if any... | +---------------+---------------+---------------+---------------+ xx/ Complete Header of Bad PDU / +/ / +---------------+---------------+---------------+---------------+ yy It may happen that a target receives a PDU with a format error (e.g., inconsistent fields etc.) or a digest error (e.g., invalid payload or header). The target returns the header (not including digest) of the PDU in error as the data of the response. 1.1.1 Reason The reject Reason is coded as follows: 1 - Format Error 2 - Data (payload) Digest Error 3 - Data-SNACK Reject 4 - Command-Retry Reject 5 - Protocol Error (e.g., SNACK request for a status that was already acknowledged) 6 - Command-in-progress 7 - Command Replay Not Supported 8 - Immediate Command Reject - too many immediate commands 9 - Immediate Command Retry Reject - task not found 10 - Bookmark rejected (old or different ITT) 11 - command not supported in this session type 15 - Full Feature Phase Command before login Some of the reject reasons terminate or prevent the creation of a task at the target and no retry is possible in those cases. Format error for a command, Command Retry Reject and Full Feature Phase Command before login are in this category. In all the cases in which creation of a SCSI task is prevented or a SCSI task is terminated because of the reject, the target must issue a proper SCSI command response including a Check Condition Status (0x02). The sense key to be used is iSCSI REJECT (the numeric value and format for additional-sense-data to be coordinated with T10). If the error is detected while data from the initiator is still expected (the command PDU did not contain all the data and the target has not received a Data PDU with the final bit Set) the target MUST wait until it receives the Data PDU with the F bit set before sending the Response PDU. In all the cases in which the rejected PDU is a non-retry numbered request PDU with a valid CmdSN field that number MUST be considered as received and acknowledged appropriately. Julo "Mallikarjun C." on 28-07-2001 22:32:41 Please respond to cbm@rose.hp.com To: mbakke@cisco.com cc: ips@ece.cmu.edu Subject: Re: iSCSI: Reject, CmdSN, and DataSN Mark, When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN is updated? If so, I see a problem with at least CmdSN. Let's consider commands first. The only Reject reason code that I see where a target could update its ExpCmdSN is when there is a payload-digest error on immediate data. In all the other cases, either the target doesn't care (immediate/retry/non-FFP), or can't know for sure (format error). I suggest that we _not_ advance the ExpCmdSN on immediate data digest error to give the initiator an opportunity to re-issue the command to preserve command ordering. Let's now consider data. Again the only Reject reason code I see for advancing ExpDataSN is payload-digest error ("2"). Either the target (a) would generate a recovery R2T (if DataSequenceOrder was negotiated as "no" and target supports Within-command recovery), or (b) eventually signal a service delivery subsystem failure for the command (iSCSI response code 0x02). For (b), it doesn't matter if the target updates ExpDataSN or not. For (a) OTOH, the target should update the ExpDataSN to deal with the current data burst (that reminds me that I need to fix this in Within-command algorithms in Appendix F!). So to summarize, I think a Reject'ed CmdSN should not be considered as successfully received on the target. Your comments are welcome. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >When a PDU is rejected, I assume that the CmdSN is still >updated, as well as the DataSN where applicable. That is, >a rejected command still uses up a SN. It probably wouldn't >hurt to state this in the reject section. > >Since the Reject response does not contain ExpCmdSN, if the >last command before the window is closed is rejected, the >initiator has to rely on prior commands completing to e-open >the window. This will usually work, but what if the window >size is reduced to one outstanding command for some reason? >Any command that is rejected will close the window for good. >A sequence of rejected commands equal to the window size will >do the same. > >Any thoughts? > >-- >Mark A. Bakke >Cisco Systems >mbakke@cisco.com >763.398.1054 > From owner-ips@ece.cmu.edu Sun Jul 29 06:07:05 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14885 for ; Sun, 29 Jul 2001 06:07:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6T8sAi09581 for ips-outgoing; Sun, 29 Jul 2001 04:54:10 -0400 (EDT) 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 f6T8s7209575 for ; Sun, 29 Jul 2001 04:54:08 -0400 (EDT) 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 KAA203954 for ; Sun, 29 Jul 2001 10:54:01 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6T8s0848732 for ; Sun, 29 Jul 2001 10:54:00 +0200 Importance: Normal Subject: Re: iSCSI: NOP-Out closing the command window To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Julian Satran" Date: Sun, 29 Jul 2001 12:00:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 29/07/2001 11:54:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The target knows that the window is closed and so does the initiator. The initiator may send only an answer (P= 0 + no ITT+ yes TTT). The ping is answered and the connection is not broken (for a while :-)). As a sumary the semantics and possible combinations - if we are to allow only 2-way hanshakes - are: I->T ITT valid means "Initiator initiated Nop Exchange" P=1 means "copy my data in your answer" TTT valid means "answer in a target initiated Nop exchange" The following combinations are correct: ITT valid, P=0, TTT invalid ITT valid, P=1, TTT invalid ITT invalid, P=0, TTT valid/invalid The following combination is incorrect: ITT invalid, P=1, TTT valid/invalid ITT valid, P=0/1, TTT valid T->I ITT valid means "answer in an initiator initiated NOP exchange" TTT valid means "target initiated NOP exchange" P=1 means "copy my data" The following combinations are correct: ITT valid, P=0, TTT invalid ITT invalid, P=0, TTT valid/invalid ITT invalid, P=1, TTT valid The following combinations are incorrect: ITT=valid, P=0/1, TTT valid ITT=valid/invalid, P=1, TTT invalid this allows for 2 way and 1 way nops. Nops without an ITT will not carry CmdSN. Comments? Julo Sandeep Joshi on 29-07-2001 02:06:30 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI: NOP-Out closing the command window > The 3-way sequence is probably the simplest for the code to handle (no > special path for a request that has no answer). (I was almost going to drop the subject..but then) what if the command window is *already* full when the target sends the ping ? If the initiator doesnt respond, the connection will be broken. Are we going to add a rule that the target must not send a ping when the window is full ? This wont work with all the asynchrony (e.g. target sent a ping before the maxCmdSN limit was hit at the target) One should just turn around and send the ping response right away, otherwise the other-end may timeout and take action on failure. Treat pings as immediate commands. Allowing pings to test the queuing sub-system are undoubtedly noble ideas but these seldom make it (correctly) into practical systems. -sandeep Julian Satran wrote: > > Sandeep, > > You are right the sequences are not documented now and that is why I put > them out here - to hear comments. > > A PDU with P=0 from the target (no ITT) could be hadndled as a mistake. > > The 3-way sequence is probably the simplest for the code to handle (no > special path for a request that has no answer). > > Julo > > Sandeep Joshi on 27-07-2001 20:34:32 > > Please respond to Sandeep Joshi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: NOP-Out closing the command window > > Julian Satran wrote: > > > > Sandeep, > > > > They are 3 distinguishing elements P and the ITT+TTT. > > > > Julo > > > > I believe you are commenting on my question about the validity > about the 2nd sequence.. correct ? But this 2nd sequence isn't > documented in Sec 2.12 or 2.13. > > Incidentally, there is a similar ping type mentioned in Sec 2.13.1 > and its used to test the connection from the target end. Could > you please say what the response would be : > T->I NOP +P=0 T=ff I=ff > I->T < response or it none ? > > > And I still prefer that the ping response from the initiator *not* > have a valid ITT/cmdSN. A 3-way ping looks forbidding and may open > up new problems. > > -Sandeep > > > Sandeep Joshi on 27-07-2001 18:53:20 > > > > Please respond to Sandeep Joshi > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI: NOP-Out closing the command window > > > > If the NOP-Out does not have the ping-bit set, then it is a > > ping response and *not* a new command being issued by the > > initiator. > > > > Hence, it seems that the NOP-OUT with P=0 need not carry a > > new cmdSN (Mark's 2nd option). > > > > Btw, I did not know the 2nd sequence (P=0 from initiator?) > > below was valid > > > I->T NOP +P=0 +I=x+ Data > > > T->I NOP +P=0 +I=x > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > Mark, > > > > > > Definitely a problem . How about stating (the obvious) that NOP as any > > > thing carying an ITT expectes an answer > > > wheter it carries an echo (P=1) or not (P=0). > > > > > > If it does not carry an ITT it does not. > > > > > > We can have the following sequences all valid: > > > > > > I->T NOP +P=1 +I=x+ Data > > > T->I NOP +P=0 + Data > > > > > > I->T NOP +P=0 +I=x+ Data > > > T->I NOP +P=0 +I=x > > > > > > T->I NOP +P=1 +TTT > > > I->T NOP +P=0 I=1 + TTT (no ITT) > > > > > > All would be permitted today if we remove the tie between ITT and P say > > > that NOP must have an ITT if issued at initiators initiative. > > > > > > We might add as valid (today it is not, it is explicitly forbidden): > > > > > > T->I NOP +P=1 +TTT > > > I->T NOP +P=1+ I= 1 TTT + ITT + Data > > > T->I NOP +P=0 +ITT + Data > > > > > > The last requires us to "tweak" the termination rule (a target is > > forbiden > > > to answer a P=1 with a P=1 > > > > > > comments? > > > Julo > > > > > > Mark Bakke on 27-07-2001 16:25:20 > > > > > > Please respond to Mark Bakke > > > > > > To: IPS > > > cc: > > > Subject: iSCSI: NOP-Out closing the command window > > > > > > When sending a NOP-Out without the P bit set, there's > > > no response to update ExpCmdSN to keep the window open. > > > > > > On an otherwise idle session, sending a long enough > > > sequence of these NOP-Outs can close the command window > > > permanently. > > > > > > In case of a stuck command window, please break glass... > > > > > > The easy solution is to turn on the P bit, and get the > > > responses to update the window, but that defaults the > > > purpose of allowing the P bit to not be set in the first > > > place. > > > > > > Another easy solution (but I almost hate to mention it) > > > is not to have NOP-Out update the CmdSN. This seems to > > > have the possibility of breaking other things. > > > > > > I suppose we could come up with a more complicated rule, > > > like "if the NOP-Out's CmdSN would be the last (or perhaps > > > penultimate) CmdSN allowed by the current window, it MUST > > > set the P bit." Or something like that. > > > > > > Anyway, I see three possible solutions. Any thoughts? > > > > > > -- > > > Mark A. Bakke > > > Cisco Systems > > > mbakke@cisco.com > > > 763.398.1054 From owner-ips@ece.cmu.edu Sun Jul 29 15:00:15 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00007 for ; Sun, 29 Jul 2001 15:00:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6THWjY26485 for ips-outgoing; Sun, 29 Jul 2001 13:32:45 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from netdns.netas.com.tr ([195.155.2.162]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6THWg226477 for ; Sun, 29 Jul 2001 13:32:43 -0400 (EDT) Received: by netdns with Internet Mail Service (5.5.2650.21) id ; Sun, 29 Jul 2001 20:31:01 +0300 Message-ID: From: Demir YAVAS To: ips@ece.cmu.edu Subject: Remove Date: Sun, 29 Jul 2001 20:31:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ips@ece.cmu.edu Precedence: bulk Remove From owner-ips@ece.cmu.edu Sun Jul 29 17:36:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04900 for ; Sun, 29 Jul 2001 17:36:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6TKJ9q02490 for ips-outgoing; Sun, 29 Jul 2001 16:19:09 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pluto.he.net (pluto.he.net [216.218.167.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6TKJ7202486 for ; Sun, 29 Jul 2001 16:19:08 -0400 (EDT) Received: from interceptor (adsl-63-197-19-16.dsl.snfc21.pacbell.net [63.197.19.16]) by pluto.he.net (8.8.6/8.8.2) with SMTP id NAA24105 for ; Sun, 29 Jul 2001 13:19:05 -0700 Reply-To: From: "Ashwini Choudhary" To: Subject: Remove Date: Sun, 29 Jul 2001 13:28:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C11832.671ADE10" 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 V6.00.2462.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C11832.671ADE10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C11832.671DEB50" ------=_NextPart_001_0002_01C11832.671DEB50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Remove Ashwini Choudhary (408) 966 8309 ashwini@aarohi-inc.com Aarohi Communications, Inc ------=_NextPart_001_0002_01C11832.671DEB50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Remove
Ashwini Choudhary
(408) 966 8309
ashwini@aarohi-inc.com<= /DIV>
 
Aarohi Communications, = Inc
 
------=_NextPart_001_0002_01C11832.671DEB50-- ------=_NextPart_000_0001_01C11832.671ADE10 Content-Type: text/x-vcard; name="Ashwini Choudhary.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Ashwini Choudhary.vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Choudhary;Ashwini FN:Ashwini Choudhary EMAIL;PREF;INTERNET:ashwini@aarohi-inc.com REV:20010520T080331Z END:VCARD ------=_NextPart_000_0001_01C11832.671ADE10-- From owner-ips@ece.cmu.edu Sun Jul 29 22:09:50 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10956 for ; Sun, 29 Jul 2001 22:09:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6U0oG012725 for ips-outgoing; Sun, 29 Jul 2001 20:50:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6U0ne212680 for ; Sun, 29 Jul 2001 20:49:40 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id CDE16125E for ; Sun, 29 Jul 2001 17:49:39 -0700 (PDT) Received: (from cbm@localhost) by core.rose.hp.com (8.8.6 (PHNE_14041)/8.8.6 SMKit7.02) id RAA25966 for ips@ece.cmu.edu; Sun, 29 Jul 2001 17:50:54 -0700 (PDT) Message-Id: <200107300050.RAA25966@core.rose.hp.com> Subject: Re: iSCSI: Reject, CmdSN, and DataSN To: ips@ece.cmu.edu Date: Sun, 29 Jul 2001 17:50:53 PDT Reply-To: cbm@rose.hp.com From: "Mallikarjun C." X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Three comments. - I am *not* arguing against your latest changes adding more fields to Reject PDU. I think they are required, sorry if my note came across differently. - You seem to think that targets can pick out CmdSN on format errors, my argument is that targets may not be able to - from *badly-formatted* PDUs (certainly not, if in the worst case, the "format errors" are a result of broken framing sync). - OTOH, targets can definitely decode the CmdSN on one class of "data digest errors" - those on immediate data. You seem to discount this possibility. Please review my note closely and offer comments on my proposal not to advance CmdSN for any Rejects as the general case. I suppose we can talk about this as well during our scheduled phone call tomorrow. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Subject: Re: iSCSI: Reject, CmdSN, and DataSN >To: ips@ece.cmu.edu >From: "Julian Satran" >Date: Sun, 29 Jul 2001 08:53:42 +0300 >Sender: owner-ips@ece.cmu.edu >Precedence: bulk >Status: RO > >Mallikurjun, > >I thought that my earlier comment on this was clear - but apparently it was >not. >The problem is real. >There as trivial case in which a format error in a command, will force the >window to close as the reject may be the only trafic and it does not carry >ExpCmdSN etc. > >There are several things to be done (and as I mentioned earlier I fixed >both): > > the reject command should carry the same updates as all others (ExpCmdSN > etc.) - good practice anyhow > the local fields should be updated even if the command is rejected - > whenever possible (there is no digest error) > The command slot should be considered filled > >Here is the proposed new text for 2.19 > >1.1 Reject > > > 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|1|1| 0x3f |1| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 4| Reserved (0) | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8/ Reserved (0) / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 26| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 40| Reason | Reserved (0) | First Bad Byte or Rsvd(0) | > +---------------+---------------+---------------+---------------+ > 44| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > xx/ Complete Header of Bad PDU / > +/ / > +---------------+---------------+---------------+---------------+ > yy > > > It may happen that a target receives a PDU with a format error (e.g., > inconsistent fields etc.) or a digest error (e.g., invalid payload or > header). The target returns the header (not including digest) of the PDU > in error as the data of the response. > >1.1.1 Reason > > The reject Reason is coded as follows: > > 1 - Format Error > 2 - Data (payload) Digest Error > 3 - Data-SNACK Reject > 4 - Command-Retry Reject > 5 - Protocol Error (e.g., SNACK request for a status that was already > acknowledged) > 6 - Command-in-progress > 7 - Command Replay Not Supported > 8 - Immediate Command Reject - too many immediate commands > 9 - Immediate Command Retry Reject - task not found > 10 - Bookmark rejected (old or different ITT) > 11 - command not supported in this session type > 15 - Full Feature Phase Command before login > > Some of the reject reasons terminate or prevent the creation of a task > at the target and no retry is possible in those cases. Format error for > a command, Command Retry Reject and Full Feature Phase Command before > login are in this category. > > In all the cases in which creation of a SCSI task is prevented or a SCSI > task is terminated because of the reject, the target must issue a proper > SCSI command response including a Check Condition Status (0x02). The > sense key to be used is iSCSI REJECT (the numeric value and format for > additional-sense-data to be coordinated with T10). If the error is > detected while data from the initiator is still expected (the command > PDU did not contain all the data and the target has not received a Data > PDU with the final bit Set) the target MUST wait until it receives the > Data PDU with the F bit set before sending the Response PDU. > > In all the cases in which the rejected PDU is a non-retry numbered > request PDU with a valid CmdSN field that number MUST be considered as > received and acknowledged appropriately. > > >Julo > >"Mallikarjun C." on 28-07-2001 22:32:41 > >Please respond to cbm@rose.hp.com > >To: mbakke@cisco.com >cc: ips@ece.cmu.edu >Subject: Re: iSCSI: Reject, CmdSN, and DataSN > > > > >Mark, > >When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN >is updated? If so, I see a problem with at least CmdSN. > >Let's consider commands first. The only Reject reason code that >I see where a target could update its ExpCmdSN is when there >is a payload-digest error on immediate data. In all the other >cases, either the target doesn't care (immediate/retry/non-FFP), >or can't know for sure (format error). I suggest that we _not_ >advance the ExpCmdSN on immediate data digest error to give the >initiator an opportunity to re-issue the command to preserve >command ordering. > >Let's now consider data. Again the only Reject reason code I see >for advancing ExpDataSN is payload-digest error ("2"). Either the >target > (a) would generate a recovery R2T (if DataSequenceOrder was > negotiated as "no" and target supports Within-command > recovery), or > (b) eventually signal a service delivery subsystem failure for > the command (iSCSI response code 0x02). > >For (b), it doesn't matter if the target updates ExpDataSN or not. >For (a) OTOH, the target should update the ExpDataSN to deal with >the current data burst (that reminds me that I need to fix this >in Within-command algorithms in Appendix F!). > >So to summarize, I think a Reject'ed CmdSN should not be considered >as successfully received on the target. > >Your comments are welcome. >-- >Mallikarjun > > >Mallikarjun Chadalapaka >Networked Storage Architecture >Network Storage Solutions Organization >MS 5668 Hewlett-Packard, Roseville. >cbm@rose.hp.com > > >>When a PDU is rejected, I assume that the CmdSN is still >>updated, as well as the DataSN where applicable. That is, >>a rejected command still uses up a SN. It probably wouldn't >>hurt to state this in the reject section. >> >>Since the Reject response does not contain ExpCmdSN, if the >>last command before the window is closed is rejected, the >>initiator has to rely on prior commands completing to e-open >>the window. This will usually work, but what if the window >>size is reduced to one outstanding command for some reason? >>Any command that is rejected will close the window for good. >>A sequence of rejected commands equal to the window size will >>do the same. >> >>Any thoughts? >> >>-- >>Mark A. Bakke >>Cisco Systems >>mbakke@cisco.com >>763.398.1054 >> > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 04:51:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09220 for ; Mon, 30 Jul 2001 04:51:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6U7D3d26874 for ips-outgoing; Mon, 30 Jul 2001 03:13:03 -0400 (EDT) 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 f6U7D1226866 for ; Mon, 30 Jul 2001 03:13:01 -0400 (EDT) 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 JAA135742 for ; Mon, 30 Jul 2001 09:12:43 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6U7ChN13866 for ; Mon, 30 Jul 2001 09:12:43 +0200 Importance: Normal Subject: Re: iSCSI: Reject, CmdSN, and DataSN To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 30 Jul 2001 10:18:49 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 30/07/2001 10:12:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, We are talking past one another. My comment did not say anything about considering the rejected command as received rather than they may get the window closed as the rejects did not convey feedback. We will certainly take it up on the phone. Regards, Julo "Mallikarjun C." on 30-07-2001 03:50:53 Please respond to cbm@rose.hp.com To: ips@ece.cmu.edu cc: Subject: Re: iSCSI: Reject, CmdSN, and DataSN Julian, Three comments. - I am *not* arguing against your latest changes adding more fields to Reject PDU. I think they are required, sorry if my note came across differently. - You seem to think that targets can pick out CmdSN on format errors, my argument is that targets may not be able to - from *badly-formatted* PDUs (certainly not, if in the worst case, the "format errors" are a result of broken framing sync). - OTOH, targets can definitely decode the CmdSN on one class of "data digest errors" - those on immediate data. You seem to discount this possibility. Please review my note closely and offer comments on my proposal not to advance CmdSN for any Rejects as the general case. I suppose we can talk about this as well during our scheduled phone call tomorrow. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com >Subject: Re: iSCSI: Reject, CmdSN, and DataSN >To: ips@ece.cmu.edu >From: "Julian Satran" >Date: Sun, 29 Jul 2001 08:53:42 +0300 >Sender: owner-ips@ece.cmu.edu >Precedence: bulk >Status: RO > >Mallikurjun, > >I thought that my earlier comment on this was clear - but apparently it was >not. >The problem is real. >There as trivial case in which a format error in a command, will force the >window to close as the reject may be the only trafic and it does not carry >ExpCmdSN etc. > >There are several things to be done (and as I mentioned earlier I fixed >both): > > the reject command should carry the same updates as all others (ExpCmdSN > etc.) - good practice anyhow > the local fields should be updated even if the command is rejected - > whenever possible (there is no digest error) > The command slot should be considered filled > >Here is the proposed new text for 2.19 > >1.1 Reject > > > 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|1|1| 0x3f |1| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 4| Reserved (0) | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8/ Reserved (0) / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 26| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 40| Reason | Reserved (0) | First Bad Byte or Rsvd(0) | > +---------------+---------------+---------------+---------------+ > 44| Reserved (0) | > +---------------+---------------+---------------+---------------+ > 48| Digests if any... | > +---------------+---------------+---------------+---------------+ > xx/ Complete Header of Bad PDU / > +/ / > +---------------+---------------+---------------+---------------+ > yy > > > It may happen that a target receives a PDU with a format error (e.g., > inconsistent fields etc.) or a digest error (e.g., invalid payload or > header). The target returns the header (not including digest) of the PDU > in error as the data of the response. > >1.1.1 Reason > > The reject Reason is coded as follows: > > 1 - Format Error > 2 - Data (payload) Digest Error > 3 - Data-SNACK Reject > 4 - Command-Retry Reject > 5 - Protocol Error (e.g., SNACK request for a status that was already > acknowledged) > 6 - Command-in-progress > 7 - Command Replay Not Supported > 8 - Immediate Command Reject - too many immediate commands > 9 - Immediate Command Retry Reject - task not found > 10 - Bookmark rejected (old or different ITT) > 11 - command not supported in this session type > 15 - Full Feature Phase Command before login > > Some of the reject reasons terminate or prevent the creation of a task > at the target and no retry is possible in those cases. Format error for > a command, Command Retry Reject and Full Feature Phase Command before > login are in this category. > > In all the cases in which creation of a SCSI task is prevented or a SCSI > task is terminated because of the reject, the target must issue a proper > SCSI command response including a Check Condition Status (0x02). The > sense key to be used is iSCSI REJECT (the numeric value and format for > additional-sense-data to be coordinated with T10). If the error is > detected while data from the initiator is still expected (the command > PDU did not contain all the data and the target has not received a Data > PDU with the final bit Set) the target MUST wait until it receives the > Data PDU with the F bit set before sending the Response PDU. > > In all the cases in which the rejected PDU is a non-retry numbered > request PDU with a valid CmdSN field that number MUST be considered as > received and acknowledged appropriately. > > >Julo > >"Mallikarjun C." on 28-07-2001 22:32:41 > >Please respond to cbm@rose.hp.com > >To: mbakke@cisco.com >cc: ips@ece.cmu.edu >Subject: Re: iSCSI: Reject, CmdSN, and DataSN > > > > >Mark, > >When you say "uses up a SN", do you mean the ExpCmdSN/ExpDataSN >is updated? If so, I see a problem with at least CmdSN. > >Let's consider commands first. The only Reject reason code that >I see where a target could update its ExpCmdSN is when there >is a payload-digest error on immediate data. In all the other >cases, either the target doesn't care (immediate/retry/non-FFP), >or can't know for sure (format error). I suggest that we _not_ >advance the ExpCmdSN on immediate data digest error to give the >initiator an opportunity to re-issue the command to preserve >command ordering. > >Let's now consider data. Again the only Reject reason code I see >for advancing ExpDataSN is payload-digest error ("2"). Either the >target > (a) would generate a recovery R2T (if DataSequenceOrder was > negotiated as "no" and target supports Within-command > recovery), or > (b) eventually signal a service delivery subsystem failure for > the command (iSCSI response code 0x02). > >For (b), it doesn't matter if the target updates ExpDataSN or not. >For (a) OTOH, the target should update the ExpDataSN to deal with >the current data burst (that reminds me that I need to fix this >in Within-command algorithms in Appendix F!). > >So to summarize, I think a Reject'ed CmdSN should not be considered >as successfully received on the target. > >Your comments are welcome. >-- >Mallikarjun > > >Mallikarjun Chadalapaka >Networked Storage Architecture >Network Storage Solutions Organization >MS 5668 Hewlett-Packard, Roseville. >cbm@rose.hp.com > > >>When a PDU is rejected, I assume that the CmdSN is still >>updated, as well as the DataSN where applicable. That is, >>a rejected command still uses up a SN. It probably wouldn't >>hurt to state this in the reject section. >> >>Since the Reject response does not contain ExpCmdSN, if the >>last command before the window is closed is rejected, the >>initiator has to rely on prior commands completing to e-open >>the window. This will usually work, but what if the window >>size is reduced to one outstanding command for some reason? >>Any command that is rejected will close the window for good. >>A sequence of rejected commands equal to the window size will >>do the same. >> >>Any thoughts? >> >>-- >>Mark A. Bakke >>Cisco Systems >>mbakke@cisco.com >>763.398.1054 >> > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 11:36:30 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29115 for ; Mon, 30 Jul 2001 11:36:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UEZNS24569 for ips-outgoing; Mon, 30 Jul 2001 10:35:23 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6UEZJ224562 for ; Mon, 30 Jul 2001 10:35:20 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Jul 30 10:30:34 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Mon Jul 30 10:34:23 EDT 2001 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 KAA16560; Mon, 30 Jul 2001 10:33:49 -0400 (EDT) Message-ID: <3B65704D.588B8E3E@research.bell-labs.com> Date: Mon, 30 Jul 2001 10:33:49 -0400 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: Julian Satran , ips@ece.cmu.edu Subject: Re: iSCSI connection recovery 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, The explanation helps. Now that the model is clear, let me ask if something like this would work.. It seems possible for the target to send back SCSI responses during recovery logout, even before commands are retried. The recovery logout could act as a final (& appetizing) SNACK. Since the target still has a statSN index on the responses, it could use the expStatSN field in the Logout Command and send all responses from [expStatSN-endStatSN]. Initiator Target --------- --------- Logout (for recovery) ---->> <<--- SCSI Data+Responses from [expStatSN-endStatSN] <<--- Logout Response Once the logout occurs, the statSN ranges for the CID are lost and command retry cannot be avoided. This logout optimization has larger benefits for Writes. Retrying Write Commands (e.g. tape backup) may involve sending all the data (or minimally FirstBurst) all over again! Of course, cost-benefit depends on queue lengths, bandwidth, frequency of connection recovery, transfer sizes, ULP timeouts, etc. Comments ? -Sandeep Julian Satran wrote: > > Sandeep, > > Your status cache is made of some task related structures. You can reuse > those - just link them to a new connection. > As for StatSN - you can't reuse those as each connection establishes its > own (new) StatSN at login (even if reusing the old CID). > > Regardless of what CID the connection bears - it is a new connection and > you can issue new commands. Even for the old ones by reissuing you in fact > indicate the new allegiance (the logout suspended them and the retry > establishes the new allegiance). > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54 > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI connection recovery > > Er..I mixed up the terminology. By "same connection", I meant > "same CID" - so one could retry cmds ONLY on the new TCP connection > with the same CID, after the old TCP connection had failed. > This avoids having to change connection allegiance on > the stuck commands, as part of connection logout. > > The main questions, however, were these : > > 1) What is the effect of a CID logout on the status (statSN) > cache ? Can it be reused when the commands are retried ? > (Think not..) > > 2) After one does a login for recovery using an old CID, > can new SCSI commands be issued on that new TCP connection. > (though it bears an old CID identifier) > > -Sandeep > > > Sandeep, > > > > Retry over any connection was always the case. > > Commands can change allegiance only after a logout. > > The commands get quiesced anyway and you have to mark them ready for a > > retry anyhow (you don't want retry at arbitrary times to hit unpunished > the > > target). After that it doesn't matter where you retry (same connection, > > another old one, a new one). > > > > The only new thing is command replay (after status was sent but before it > > is acked). > > > > Regards, > > Julo > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 06:37:33 > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI connection recovery > > > > > > > > > > I had a "big-picture" question about the connection > > recovery model. > > > > The current draft suggests that, once the broken connection > > is logged out, the commands allegiant to the old connection > > can now be retried over *any* connection. (See Section 7.11.3 > > bullet 1 and also Appendix F Session Recovery algo for > > initiator.) > > > > I may be mistaken, but in previous drafts, this was not > > the case and commands always stayed allegiant to a CID. > > > > So the question is.. how does one use a Status cache > > belonging to the old connection in this new model (now that > > the commands are going to be retried over any connection) > > Doesnt this become more complex ? > > > > Secondly, this also means that one must walk the command > > list at the target and quiesce connection allegiance during > > logout - which may not be required if the commands were to be > > retried over the same connection always. > > > > Comments ? > > > > -Sandeep > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 11:37:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29178 for ; Mon, 30 Jul 2001 11:37:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UEhBo24952 for ips-outgoing; Mon, 30 Jul 2001 10:43:11 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe68.law11.hotmail.com [64.4.16.203]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UEh9224946 for ; Mon, 30 Jul 2001 10:43:10 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 30 Jul 2001 07:43:04 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: , "Julian Satran" References: Subject: Re: iSCSI padding should be 0 Date: Mon, 30 Jul 2001 10:43:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 30 Jul 2001 14:43:04.0131 (UTC) FILETIME=[F05E0930:01C11905] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Software padding can be expensive if their is a requirement that the pad must be 0. I have given the reason below. BTW, where is the security problem? In an earlier EMAIL, I suggested a security issue but I gave a paranoid case. Do you have a simple security case? Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, July 28, 2001 12:36 AM Subject: Re: iSCSI padding should be 0 > Is the software padding more expensive than checking if there is a CRC (or > any other digest)? > On the other hand CRCs don't require the bytes to be 0 they can be > arbitrary values. > The 0 was brought in to avoid "leakage" (security) by somebody on the list. > We can choose to revert to arbitrary and leave the burden of cleaning to > the applications for which security is a concern. > > Julo > > "Eddy Quicksall" on 27-07-2001 22:05:59 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "ips" > Subject: Re: iSCSI padding should be 0 > > > > > I saw one objection to this by Michael Fischer > [Michael_Fischer@adaptec.com]. He pointed out that if there is no CRC then > why require the padding to be 0. I agree with his point. > > The problem is with software only implementations ... if they use the > sockets send function and if they are sending from a ULP buffer and if the > data being sent needs padding, they will have to either copy to another > buffer or do an extra tiny send for the pad. > > So, my thinking is that we say: > > iSCSI PDUs are padded to an integer number of 4 byte words. If CRC is > being used, the padding MUST be 0. If CRC is not being used, the content of > the padding is unpredictable and irrelevent. > > What do you think? > > Eddy > ----- Original Message ----- > From: "Julian_Satran/Haifa/IBM%IBMIL" > To: > Cc: "ips" > Sent: Friday, July 27, 2001 11:45 AM > Subject: Re: iSCSI padding should be 0 > > > > > > Perhaps we should say MUST be sent as 0 and keep quiet about what the > > receiver should do (check for 0 - we don't want that). > > > > Thanks,Julo > > > > "Eddy Quicksall" on 27-07-2001 18:18:33 > > > > Please respond to eddy_quicksall@ivivity.com > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: iSCSI padding should be 0 > > > > > > > > > > Julian, > > > > Section 2.1 says the padding should be 0. I guess that is correct because > > one may not use CRC and therefore may not want to set them to 0. Wouldn't > > it > > be better if section 2.1 was more specific and mentioned when they must > be > > 0 > > if there is a CRC. Also, I noticed at the UNH plug fest that at least one > > person thought "should" meant "must". Therefore, I don't think it should > > say > > "should" ... I think it should not mention the 0'ness unless there is a > CRC > > present. > > > > Also, > > > > transmission. Padding bytes, when presents in a segment covered > by > > a > > CRC, have to be set to 0 and are included in the CRC. > > > > should say "when present in". > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 11:37:23 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29195 for ; Mon, 30 Jul 2001 11:37:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UEo8c25339 for ips-outgoing; Mon, 30 Jul 2001 10:50:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (oe21.law11.hotmail.com [64.4.16.125]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UEo6225328 for ; Mon, 30 Jul 2001 10:50:06 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 30 Jul 2001 07:50:00 -0700 X-Originating-IP: [66.31.75.202] From: "Eddy Quicksall" To: "Julian Satran" Cc: References: Subject: Re: iSCSI: reason codes Date: Mon, 30 Jul 2001 10:50:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: X-OriginalArrivalTime: 30 Jul 2001 14:50:00.0794 (UTC) FILETIME=[E8B7C3A0:01C11906] Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Then it seems the words "Code", "response codes " and "service response codes" are confusing when used within the same context. Since one would assume they mean the same thing. As worded, "Code" and "response codes" apparently do not refer to the "service response codes" given a few lines earlier. 0x01-0x04 do but 0x05 does not. Can you change the wording to make that clear? Eddy_Quicksall@iVivity.com ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, July 28, 2001 12:58 AM Subject: Re: iSCSI: reason codes > snack rejected - Julo > > "Eddy Quicksall" on 27-07-2001 23:13:43 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: iSCSI: reason codes > > > > > > Section "2.4.3 Response" says: > > 0x05 - Command in progress > > But the table says > | Code| Reason | with SCSI CHECK CONDITION | > +-----+----------------+---------------------------+ > |0x05 | SNACK rejected | ASC = 0x47 ASCQ = 0x03 | > > Which "0x05" is correct? > > Eddy_Quicksall@iVivity.com > > > > From owner-ips@ece.cmu.edu Mon Jul 30 11:37:28 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29211 for ; Mon, 30 Jul 2001 11:37:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UF24026080 for ips-outgoing; Mon, 30 Jul 2001 11:02:04 -0400 (EDT) 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 f6UF22226075 for ; Mon, 30 Jul 2001 11:02:02 -0400 (EDT) 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 RAA169428 for ; Mon, 30 Jul 2001 17:01:54 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6UF1rN49166 for ; Mon, 30 Jul 2001 17:01:53 +0200 Importance: Normal Subject: Re: iSCSI padding should be 0 To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 30 Jul 2001 18:08:00 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 30/07/2001 18:01:53 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The security concern (as far as I can understand it) is leaking information from old buffers. Julo "Eddy Quicksall" on 30-07-2001 17:43:02 Please respond to "Eddy Quicksall" To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI padding should be 0 Software padding can be expensive if their is a requirement that the pad must be 0. I have given the reason below. BTW, where is the security problem? In an earlier EMAIL, I suggested a security issue but I gave a paranoid case. Do you have a simple security case? Eddy ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, July 28, 2001 12:36 AM Subject: Re: iSCSI padding should be 0 > Is the software padding more expensive than checking if there is a CRC (or > any other digest)? > On the other hand CRCs don't require the bytes to be 0 they can be > arbitrary values. > The 0 was brought in to avoid "leakage" (security) by somebody on the list. > We can choose to revert to arbitrary and leave the burden of cleaning to > the applications for which security is a concern. > > Julo > > "Eddy Quicksall" on 27-07-2001 22:05:59 > > Please respond to "Eddy Quicksall" > > To: Julian Satran/Haifa/IBM@IBMIL > cc: "ips" > Subject: Re: iSCSI padding should be 0 > > > > > I saw one objection to this by Michael Fischer > [Michael_Fischer@adaptec.com]. He pointed out that if there is no CRC then > why require the padding to be 0. I agree with his point. > > The problem is with software only implementations ... if they use the > sockets send function and if they are sending from a ULP buffer and if the > data being sent needs padding, they will have to either copy to another > buffer or do an extra tiny send for the pad. > > So, my thinking is that we say: > > iSCSI PDUs are padded to an integer number of 4 byte words. If CRC is > being used, the padding MUST be 0. If CRC is not being used, the content of > the padding is unpredictable and irrelevent. > > What do you think? > > Eddy > ----- Original Message ----- > From: "Julian_Satran/Haifa/IBM%IBMIL" > To: > Cc: "ips" > Sent: Friday, July 27, 2001 11:45 AM > Subject: Re: iSCSI padding should be 0 > > > > > > Perhaps we should say MUST be sent as 0 and keep quiet about what the > > receiver should do (check for 0 - we don't want that). > > > > Thanks,Julo > > > > "Eddy Quicksall" on 27-07-2001 18:18:33 > > > > Please respond to eddy_quicksall@ivivity.com > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: iSCSI padding should be 0 > > > > > > > > > > Julian, > > > > Section 2.1 says the padding should be 0. I guess that is correct because > > one may not use CRC and therefore may not want to set them to 0. Wouldn't > > it > > be better if section 2.1 was more specific and mentioned when they must > be > > 0 > > if there is a CRC. Also, I noticed at the UNH plug fest that at least one > > person thought "should" meant "must". Therefore, I don't think it should > > say > > "should" ... I think it should not mention the 0'ness unless there is a > CRC > > present. > > > > Also, > > > > transmission. Padding bytes, when presents in a segment covered > by > > a > > CRC, have to be set to 0 and are included in the CRC. > > > > should say "when present in". > > > > Eddy_Quicksall@iVivity.com > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 11:37:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29250 for ; Mon, 30 Jul 2001 11:37:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UE9kr23149 for ips-outgoing; Mon, 30 Jul 2001 10:09:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gifw.genroco.com (genroco.com [205.254.195.202]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UE9j223144 for ; Mon, 30 Jul 2001 10:09:45 -0400 (EDT) Received: from gi2.genroco.com (IDENT:root@gi2.genroco.com [192.133.120.3]) by gifw.genroco.com (8.9.3/8.9.3) with ESMTP id JAA00901 for ; Mon, 30 Jul 2001 09:09:44 -0500 Received: from nt5200 (nt5200.genroco.com [192.133.120.33]) by gi2.genroco.com (8.9.3/8.9.3) with SMTP id JAA05267 for ; Mon, 30 Jul 2001 09:09:43 -0500 Message-ID: <001501c11901$4838fac0$217885c0@genroco.com> From: "Larry Beine" To: Subject: remove Date: Mon, 30 Jul 2001 09:09:43 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C118D7.5F4D6EF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C118D7.5F4D6EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0012_01C118D7.5F4D6EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0012_01C118D7.5F4D6EF0-- From owner-ips@ece.cmu.edu Mon Jul 30 12:13:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02283 for ; Mon, 30 Jul 2001 12:13:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UFTGW27659 for ips-outgoing; Mon, 30 Jul 2001 11:29:16 -0400 (EDT) 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 f6UFTF227655 for ; Mon, 30 Jul 2001 11:29:15 -0400 (EDT) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6UFTJ310584 for ; Mon, 30 Jul 2001 08:29:19 -0700 (PDT) Received: from cisco.com (rtp-dial-1-182.cisco.com [10.83.97.182]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ADW01342 (AUTH jgw); Mon, 30 Jul 2001 08:29:06 -0700 (PDT) Message-ID: <3B657DA8.D5BFB638@cisco.com> Date: Mon, 30 Jul 2001 11:30:49 -0400 From: "John G. Waclawsky" Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: Remove References: <001501c11901$4838fac0$217885c0@genroco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit remove From owner-ips@ece.cmu.edu Mon Jul 30 12:13:53 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02299 for ; Mon, 30 Jul 2001 12:13:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UFBQ326593 for ips-outgoing; Mon, 30 Jul 2001 11:11:26 -0400 (EDT) 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 f6UFBL226583 for ; Mon, 30 Jul 2001 11:11:21 -0400 (EDT) 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 RAA23710 for ; Mon, 30 Jul 2001 17:11:13 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6UFBCm172436 for ; Mon, 30 Jul 2001 17:11:12 +0200 Importance: Normal Subject: Re: iSCSI connection recovery To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 30 Jul 2001 18:15:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 30/07/2001 18:11:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Both Login (with the X bit it is a logout/login) and Logout have an ExpStatSN just for this reason. If this does not come through clear in the text please let me know. Regards, Julo Sandeep Joshi on 30-07-2001 17:33:49 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: Re: iSCSI connection recovery Julian, The explanation helps. Now that the model is clear, let me ask if something like this would work.. It seems possible for the target to send back SCSI responses during recovery logout, even before commands are retried. The recovery logout could act as a final (& appetizing) SNACK. Since the target still has a statSN index on the responses, it could use the expStatSN field in the Logout Command and send all responses from [expStatSN-endStatSN]. Initiator Target --------- --------- Logout (for recovery) ---->> <<--- SCSI Data+Responses from [expStatSN-endStatSN] <<--- Logout Response Once the logout occurs, the statSN ranges for the CID are lost and command retry cannot be avoided. This logout optimization has larger benefits for Writes. Retrying Write Commands (e.g. tape backup) may involve sending all the data (or minimally FirstBurst) all over again! Of course, cost-benefit depends on queue lengths, bandwidth, frequency of connection recovery, transfer sizes, ULP timeouts, etc. Comments ? -Sandeep Julian Satran wrote: > > Sandeep, > > Your status cache is made of some task related structures. You can reuse > those - just link them to a new connection. > As for StatSN - you can't reuse those as each connection establishes its > own (new) StatSN at login (even if reusing the old CID). > > Regardless of what CID the connection bears - it is a new connection and > you can issue new commands. Even for the old ones by reissuing you in fact > indicate the new allegiance (the logout suspended them and the retry > establishes the new allegiance). > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54 > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > To: ips@ece.cmu.edu > cc: > Subject: Re: iSCSI connection recovery > > Er..I mixed up the terminology. By "same connection", I meant > "same CID" - so one could retry cmds ONLY on the new TCP connection > with the same CID, after the old TCP connection had failed. > This avoids having to change connection allegiance on > the stuck commands, as part of connection logout. > > The main questions, however, were these : > > 1) What is the effect of a CID logout on the status (statSN) > cache ? Can it be reused when the commands are retried ? > (Think not..) > > 2) After one does a login for recovery using an old CID, > can new SCSI commands be issued on that new TCP connection. > (though it bears an old CID identifier) > > -Sandeep > > > Sandeep, > > > > Retry over any connection was always the case. > > Commands can change allegiance only after a logout. > > The commands get quiesced anyway and you have to mark them ready for a > > retry anyhow (you don't want retry at arbitrary times to hit unpunished > the > > target). After that it doesn't matter where you retry (same connection, > > another old one, a new one). > > > > The only new thing is command replay (after status was sent but before it > > is acked). > > > > Regards, > > Julo > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 06:37:33 > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > To: ips@ece.cmu.edu > > cc: > > Subject: iSCSI connection recovery > > > > > > > > > > I had a "big-picture" question about the connection > > recovery model. > > > > The current draft suggests that, once the broken connection > > is logged out, the commands allegiant to the old connection > > can now be retried over *any* connection. (See Section 7.11.3 > > bullet 1 and also Appendix F Session Recovery algo for > > initiator.) > > > > I may be mistaken, but in previous drafts, this was not > > the case and commands always stayed allegiant to a CID. > > > > So the question is.. how does one use a Status cache > > belonging to the old connection in this new model (now that > > the commands are going to be retried over any connection) > > Doesnt this become more complex ? > > > > Secondly, this also means that one must walk the command > > list at the target and quiesce connection allegiance during > > logout - which may not be required if the commands were to be > > retried over the same connection always. > > > > Comments ? > > > > -Sandeep > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 12:23:44 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03177 for ; Mon, 30 Jul 2001 12:23:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UFi0328493 for ips-outgoing; Mon, 30 Jul 2001 11:44:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mms1.broadcom.com (mms1.broadcom.com [63.70.210.58]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6UFhw228488 for ; Mon, 30 Jul 2001 11:43:58 -0400 (EDT) Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom MMS-1 SMTP Relay (MMS v4.7)); Mon, 30 Jul 2001 08:43:40 -0700 X-Server-Uuid: 1e1caf3a-b686-11d4-a6a3-00508bfc9ae5 Received: from mail-sj1-1.sj.broadcom.com (mail-sj1-1.sj.broadcom.com [10.16.128.231]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id IAA27712 for ; Mon, 30 Jul 2001 08:43:31 -0700 (PDT ) Received: from lt7ifv9 (dhcpe2-sj1-119 [10.16.75.119]) by mail-sj1-1.sj.broadcom.com (8.8.8/8.8.8/MS01) with SMTP id IAA26577 for ; Mon, 30 Jul 2001 08:43:32 -0700 (PDT) From: "Dan Eakins" To: ips@ece.cmu.edu Subject: remove Date: Mon, 30 Jul 2001 08:43:46 -0700 Message-ID: <00d301c1190e$6c3713f0$774b100a@lt7ifv9> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal X-WSS-ID: 177B5F26146215-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Mon Jul 30 12:25:22 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03464 for ; Mon, 30 Jul 2001 12:25:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UFNWm27279 for ips-outgoing; Mon, 30 Jul 2001 11:23:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UFNV227275 for ; Mon, 30 Jul 2001 11:23:31 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id LAA25517; Mon, 30 Jul 2001 11:23:26 -0400 (EDT) Date: Mon, 30 Jul 2001 11:23:26 -0400 From: "Robert D. Russell" To: Steve Senum cc: ietf-ips Subject: Re: iSCSI login phasing In-Reply-To: <3B61F1E1.9CBE77FA@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Steve: > I am a bit confused by your iSCSI Target state diagram. > I would think you should be able to go from T1 to > either T2 or T4, depending on what the login command > contained. Something like login command with > SecurityContextComplete=yes goes to T4, else goes to T2. I was assuming that the SecurityContextComplete=yes key could not appear in the same list as other keys, and therefore could not be in the login command because these were required to carry the 3 security keys HeaderDigest=, DataDigest=, and AuthMethod=. > Also, I would not expect to see T3 (Leave Security) as > a state. This state is needed for the case when it is the target, not the initiator, that is the first one to send the SecurityContextComplete=yes key (on the Z3 transition). The target must now wait for the initiator to reply with SecurityContextComplete=yes, and then send SecurityContextComplete=yes again because, as described in one of Julian's recent e-mails, the handshake must always end with the Target sending this key to the Initiator. There is another assumption in this diagram, which I believe is true for all the security negotiation dialogues proposed for iSCSI, but I would like verification of this from others, and that is that once one side sends SecurityContextComplete=yes, the other side will in fact also be finished and will send the same key back (assuming successful negotiation). This is certainly true for all the examples shown in draft 7, but, of course, these are only examples and do not exhaust all the possibilities. If there are situations where the other side needs to continue the negotiation, then 2 more transitions would be needed: one from state T3 back to itself, labeled with conditions and actions similar to transition Z3, and one from state T3 back to state T2, labeled with conditions and actions similar to transition Z2. Adding these transitions makes the target diagram more similar to the initiator diagram for the two states Negotiate Security and Leave Security. Bob > > Regards, > Steve Senum > > "Robert D. Russell" wrote: > > > > All: > > > > Attached are 2 ASCII text files. Once contains a state diagram > > for the iSCSI Initiator login phase, the other a state diagram > > for the iSCSI Target login phase. > > > > The Initiator state machine has only 6 states with 10 allowed > > transitions, and the Target state machine has only 5 states > > with 7 allowed transitions. Both diagrams have the form of > > a single "spine" with minimal branching. Error/failure > > transitions are not shown, since they always result in > > closing the connection during login (on the target side > > a reject message may be sent first). > > > > Both of these diagrams are based on draft 7 with simplifications > > suggested by Julian, Rod Harrison, Steve Senum, Eddy Quicksall, > > Stephen Bailey, Barry Reinhold, myself and others. > > > > These include: > > > > 1. Every login is split into 2 distinct subphases (security and > > operational) with a required demarcation line between them. > > > > 1. Every login starts in the security subphase and must contain > > at least the keys: TargetName, InitiatorName, HeaderDigest, > > DataDigest, AuthMethod, and optionally SessionType=Normal. > > > > 2. No operational parameters can be negotiated before or during > > the security subphase (informational parameters, like > > TargetName, although listed in Appendix D, do not require > > negotiation and are not considered "operational" here). > > > > 3. The security subphase ends with a required 2- or 3-way handshake of > > Text and Text Response PDUs containing only the > > SecurityContextComplete=yes key and ending with a message from > > the target to the initiator. The negotiated security functions > > become effective only at the successful conclusion of this handshake. > > > > 4. The operational subphase always begins immediately after the > > handshake had been completed. No security parameters can be > > negotiated during or after the operational subphase. > > > > 5. The operational subphase ends with a Login Response with F=1 from > > the target to the initiator, at which time both target and > > initiator are in Full Feature Phase (the final state in both > > diagrams). > > > > Comments please. > > > > Bob Russell > > InterOperability Lab > > University of New Hampshire > > rdr@iol.unh.edu > > 603-862-3774 > > > > On Fri, 27 Jul 2001, Julian Satran wrote: > > > > > Dear colleagues, > > > > > > As some of you have complained about difficulty in implementing the login > > > phase I thought it might be worthwhile to consider a slight departure from > > > the current description. > > > > > > The current text assumes that negotiations are forming one tree and the > > > "login machine" has to parse the tree. > > > A leaf node will completely define a state and some pathes may get you to > > > error. > > > > > > I was driven to this design by the need to keep the parsing tree minimal > > > (under the assumption that any split in subtrees > > > will result is some parameters needing to appear in several subtrees). > > > > > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > > > that few if any have done the generalized mapping I started with, and > > > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > > > trees for the next plugfest (although by then some bright undergraduate > > > student may take onto himself to give us an open-source yacc definition of > > > the login phase!). > > > > > > I looked at the 2 phases and the number of key=values that they share are > > > probably limited today at initiator and target names (some > > > organizations/configurations want them for authentication while some others > > > will object to them being revealed in the "open phase") and as such we may > > > want to slit the login in 2, completely bracketed, phases each of them > > > optional but not both: > > > > > > > > > a security phase that if present must start with the login command and > > > is bracketed by the pairs SecurityPhase=start and ended by > > > SecurityPhase=end (on both initiator and target) > > > an operational-parameter-negotiation phase that must follow security > > > phase (if there is a security phase) and is bracketed by the pairs > > > OperationalPhase=start and OperationalPhase=end (on both initiator and > > > target) > > > > > > > > > Some additional rules will apply: > > > > > > No request/response will span phases > > > The phase closing handshake can start on both sides but if started at > > > target will be followed by an "full initiator target handshake" - i.e a > > > new phase or the "curtain close" end always with the target having the > > > last word. > > > keys will be clearly segregated and only a few (like names) should be > > > allowed in both. > > > > > > > > > Comments? > > > > > > Julo > > > > > > > > > > > > > -------------------------------------------------------------------------------- > > Name: i_states > > i_states Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > > > > Name: t_states > > t_states Type: Plain Text (TEXT/PLAIN) > > Encoding: BASE64 > From owner-ips@ece.cmu.edu Mon Jul 30 14:36:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14535 for ; Mon, 30 Jul 2001 14:36:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UHe3H04987 for ips-outgoing; Mon, 30 Jul 2001 13:40:03 -0400 (EDT) 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 f6UHe1204982 for ; Mon, 30 Jul 2001 13:40:02 -0400 (EDT) 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 TAA288314 for ; Mon, 30 Jul 2001 19:39:55 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6UHdsm42100 for ; Mon, 30 Jul 2001 19:39:54 +0200 Importance: Normal Subject: Re: iSCSI connection recovery To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Mon, 30 Jul 2001 20:46:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 30/07/2001 20:39:54 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, There is nothing to stop them sending the state but there is no way for the initiator to acknowledge those (Logout takes it out of the full feature phase - nothing valid after) and a new connection is a new day ... I assume you are not suggesting a FinalLogout ;-), are you? Regards, Julo Sandeep Joshi on 30-07-2001 18:38:48 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI connection recovery Julian Wait..! I was proposing that the expStatSN could be used to send back the responses (even *before* commands get retried) See below -Sandeep Julian Satran wrote: > > Sandeep, > > Both Login (with the X bit it is a logout/login) and Logout have an > ExpStatSN just for this reason. > If this does not come through clear in the text please let me know. > > Regards, > Julo > > Sandeep Joshi on 30-07-2001 17:33:49 > > Please respond to Sandeep Joshi > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > cc: > Subject: Re: iSCSI connection recovery > > Julian, > > The explanation helps. Now that the model is clear, let me > ask if something like this would work.. > > It seems possible for the target to send back SCSI responses > during recovery logout, even before commands are retried. > The recovery logout could act as a final (& appetizing) SNACK. > > Since the target still has a statSN index on the responses, > it could use the expStatSN field in the Logout Command > and send all responses from [expStatSN-endStatSN]. > > Initiator Target > --------- --------- > Logout (for recovery) ---->> > <<--- SCSI Data+Responses from [expStatSN-endStatSN] > <<--- Logout Response > > Once the logout occurs, the statSN ranges for the CID are > lost and command retry cannot be avoided. > > This logout optimization has larger benefits for Writes. > Retrying Write Commands (e.g. tape backup) may involve > sending all the data (or minimally FirstBurst) all over > again! Of course, cost-benefit depends on queue lengths, > bandwidth, frequency of connection recovery, transfer > sizes, ULP timeouts, etc. > > Comments ? > > -Sandeep > > Julian Satran wrote: > > > > Sandeep, > > > > Your status cache is made of some task related structures. You can > reuse > > those - just link them to a new connection. > > As for StatSN - you can't reuse those as each connection establishes its > > own (new) StatSN at login (even if reusing the old CID). > > > > Regardless of what CID the connection bears - it is a new connection and > > you can issue new commands. Even for the old ones by reissuing you in > fact > > indicate the new allegiance (the logout suspended them and the retry > > establishes the new allegiance). > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54 > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > To: ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI connection recovery > > > > Er..I mixed up the terminology. By "same connection", I meant > > "same CID" - so one could retry cmds ONLY on the new TCP connection > > with the same CID, after the old TCP connection had failed. > > This avoids having to change connection allegiance on > > the stuck commands, as part of connection logout. > > > > The main questions, however, were these : > > > > 1) What is the effect of a CID logout on the status (statSN) > > cache ? Can it be reused when the commands are retried ? > > (Think not..) > > > > 2) After one does a login for recovery using an old CID, > > can new SCSI commands be issued on that new TCP connection. > > (though it bears an old CID identifier) > > > > -Sandeep > > > > > Sandeep, > > > > > > Retry over any connection was always the case. > > > Commands can change allegiance only after a logout. > > > The commands get quiesced anyway and you have to mark them ready for a > > > retry anyhow (you don't want retry at arbitrary times to hit unpunished > > the > > > target). After that it doesn't matter where you retry (same connection, > > > another old one, a new one). > > > > > > The only new thing is command replay (after status was sent but before > it > > > is acked). > > > > > > Regards, > > > Julo > > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 06:37:33 > > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: iSCSI connection recovery > > > > > > > > > > > > > > > I had a "big-picture" question about the connection > > > recovery model. > > > > > > The current draft suggests that, once the broken connection > > > is logged out, the commands allegiant to the old connection > > > can now be retried over *any* connection. (See Section 7.11.3 > > > bullet 1 and also Appendix F Session Recovery algo for > > > initiator.) > > > > > > I may be mistaken, but in previous drafts, this was not > > > the case and commands always stayed allegiant to a CID. > > > > > > So the question is.. how does one use a Status cache > > > belonging to the old connection in this new model (now that > > > the commands are going to be retried over any connection) > > > Doesnt this become more complex ? > > > > > > Secondly, this also means that one must walk the command > > > list at the target and quiesce connection allegiance during > > > logout - which may not be required if the commands were to be > > > retried over the same connection always. > > > > > > Comments ? > > > > > > -Sandeep > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 14:36:48 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14558 for ; Mon, 30 Jul 2001 14:36:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UHFxC03807 for ips-outgoing; Mon, 30 Jul 2001 13:15:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from esply02.cnt.com (mailhost.cnt.com [139.93.128.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UHFv203802 for ; Mon, 30 Jul 2001 13:15:57 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 12:15:52 -0500 Message-ID: <3C7122FAF06DD5118ED60050047336482630BA@esply01.cnt.com> From: Michael Schoberg To: "'ips@ece.cmu.edu'" Subject: Re: iSCSI login phasing Date: Mon, 30 Jul 2001 12:13:09 -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 13 x 13 login state chart and the state diagrams may confuse some people out there (including me). Because of all the transactions that need to take place, I don't think you'll ever make it trivial, but there may be a few things that can be done to simplify it: 1. How about adding a flags field into the login command that describes negotiations that are expected from the alternate. Something like: LOGIN FLAGS (example only) ----------- CID Recovery Requested (FALSE = New CID Requested) Custom configuration pending (FALSE = Current configuration accepted) Security Method Required (FALSE = Security method defined) Security Login Required (FALSE = Authentication complete) Target Not Yet Identified (FALSE = Target identified) Initiator Not Yet Identified (FALSE = Initiator identified) In Login (FALSE = Full feature mode accepted) The login from I->T describes the options it requires from the target. The initiator may want to recover a previous session, set custom configuration options, authenticate the target, etc. Messages T->I may state requirements for the initiator: authentication, identification, etc. Login messages can be exchanged until all requirements have been met. When both initiator and target have satisfied their login requirements, a login/login response is issued with a completed status. By setting requirement bits in the requests/responses, the sequence of login events can be orchestrated. 2. Do we really want to use TEXT= based messages for sending and receiving configuration and authentication requests? One of the things I'm concerned about is the use of English (or English acronym) to provide the parse keys for the transactions. Can we use something a little more international? The spec already describes mode pages for iSCSI. Mode pages are easily translated to other languages and avoids parsing problems (LoWeR CaSe translation, decimal/hexadecimal translation, etc.) Perhaps extending mode pages into variable and login negotiations would be useful. However, rather than creating a bunch of different mode pages, we can limit it to just a few: Parameter negotiation page +--------+--------+--------+--------+ | PageID | Variable page length | +-----------------------------------+ | Variable Identification | +-----------------------------------+ | Number of array elements | +-----------------------------------+ | Value(s) | . . . . +-----------------------------------+ Page lengths are word aligned. Null pad bytes are used to extend lengths to even words. Variable Identification 1=MarkerType 2=TargetName 3=MaxConnections 4=TargetAddress 5=... Security page +--------+--------+--------+--------+ | Sec-Pg | Security page length | +-----------------------------------+ | Value | . . . . +-----------------------------------+ PageID 0=Respond with the current value of this variable. 1=Respond with array of known/possible values for this variable. 2=Set and respond with the default value for this variable. 3=Request this variable take on this new value. Respond with actual value. 4=Request the alternate select from a value listed. The response will be as a '3'=set request. 5=Security question phase page 6=Security answer phase page .. Variables or requests not understood are responded with a zero element page with a zero value length. Multiple pages can be attached to the login request/response messages as needed. The Login Request & Login Response messages are used at all times throughout the login negotiation process. From owner-ips@ece.cmu.edu Mon Jul 30 15:14:35 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16708 for ; Mon, 30 Jul 2001 15:14:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UI3KK06319 for ips-outgoing; Mon, 30 Jul 2001 14:03:20 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6UI3I206314 for ; Mon, 30 Jul 2001 14:03:18 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Mon Jul 30 13:59:50 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Mon Jul 30 14:03:32 EDT 2001 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 OAA01793 for ; Mon, 30 Jul 2001 14:03:05 -0400 (EDT) Message-ID: <3B65A158.F6397BE6@research.bell-labs.com> Date: Mon, 30 Jul 2001 14:03:04 -0400 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 connection recovery References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I assume you are not suggesting a FinalLogout ;-), are you? No I was not :-) I missed reading the 4th paragraph of Section 2.14 which alludes to this logout processing. The spec is getting monstrous at 185 pages. regards, -Sandeep Julian Satran wrote: > > Sandeep, > > There is nothing to stop them sending the state but there is no way for the > initiator to acknowledge those (Logout takes it out of the full feature > phase - nothing valid after) and a new connection is a new day ... > > I assume you are not suggesting a FinalLogout ;-), are you? > > Regards, > Julo > > Sandeep Joshi on 30-07-2001 18:38:48 > > Please respond to Sandeep Joshi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI connection recovery > > Julian > > Wait..! I was proposing that the expStatSN could be used to send back > the responses (even *before* commands get retried) See below > > -Sandeep > > Julian Satran wrote: > > > > Sandeep, > > > > Both Login (with the X bit it is a logout/login) and Logout have an > > ExpStatSN just for this reason. > > If this does not come through clear in the text please let me know. > > > > Regards, > > Julo > > > > Sandeep Joshi on 30-07-2001 17:33:49 > > > > Please respond to Sandeep Joshi > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI connection recovery > > > > Julian, > > > > The explanation helps. Now that the model is clear, let me > > ask if something like this would work.. > > > > It seems possible for the target to send back SCSI responses > > during recovery logout, even before commands are retried. > > The recovery logout could act as a final (& appetizing) SNACK. > > > > Since the target still has a statSN index on the responses, > > it could use the expStatSN field in the Logout Command > > and send all responses from [expStatSN-endStatSN]. > > > > Initiator Target > > --------- --------- > > Logout (for recovery) ---->> > > <<--- SCSI Data+Responses from [expStatSN-endStatSN] > > <<--- Logout Response > > > > Once the logout occurs, the statSN ranges for the CID are > > lost and command retry cannot be avoided. > > > > This logout optimization has larger benefits for Writes. > > Retrying Write Commands (e.g. tape backup) may involve > > sending all the data (or minimally FirstBurst) all over > > again! Of course, cost-benefit depends on queue lengths, > > bandwidth, frequency of connection recovery, transfer > > sizes, ULP timeouts, etc. > > > > Comments ? > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > Sandeep, > > > > > > Your status cache is made of some task related structures. You can > > reuse > > > those - just link them to a new connection. > > > As for StatSN - you can't reuse those as each connection establishes > its > > > own (new) StatSN at login (even if reusing the old CID). > > > > > > Regardless of what CID the connection bears - it is a new connection > and > > > you can issue new commands. Even for the old ones by reissuing you in > > fact > > > indicate the new allegiance (the logout suspended them and the retry > > > establishes the new allegiance). > > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54 > > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: Re: iSCSI connection recovery > > > > > > Er..I mixed up the terminology. By "same connection", I meant > > > "same CID" - so one could retry cmds ONLY on the new TCP connection > > > with the same CID, after the old TCP connection had failed. > > > This avoids having to change connection allegiance on > > > the stuck commands, as part of connection logout. > > > > > > The main questions, however, were these : > > > > > > 1) What is the effect of a CID logout on the status (statSN) > > > cache ? Can it be reused when the commands are retried ? > > > (Think not..) > > > > > > 2) After one does a login for recovery using an old CID, > > > can new SCSI commands be issued on that new TCP connection. > > > (though it bears an old CID identifier) > > > > > > -Sandeep > > > > > > > Sandeep, > > > > > > > > Retry over any connection was always the case. > > > > Commands can change allegiance only after a logout. > > > > The commands get quiesced anyway and you have to mark them ready for > a > > > > retry anyhow (you don't want retry at arbitrary times to hit > unpunished > > > the > > > > target). After that it doesn't matter where you retry (same > connection, > > > > another old one, a new one). > > > > > > > > The only new thing is command replay (after status was sent but > before > > it > > > > is acked). > > > > > > > > Regards, > > > > Julo > > > > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 > 06:37:33 > > > > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > > > > > To: ips@ece.cmu.edu > > > > cc: > > > > Subject: iSCSI connection recovery > > > > > > > > > > > > > > > > > > > > I had a "big-picture" question about the connection > > > > recovery model. > > > > > > > > The current draft suggests that, once the broken connection > > > > is logged out, the commands allegiant to the old connection > > > > can now be retried over *any* connection. (See Section 7.11.3 > > > > bullet 1 and also Appendix F Session Recovery algo for > > > > initiator.) > > > > > > > > I may be mistaken, but in previous drafts, this was not > > > > the case and commands always stayed allegiant to a CID. > > > > > > > > So the question is.. how does one use a Status cache > > > > belonging to the old connection in this new model (now that > > > > the commands are going to be retried over any connection) > > > > Doesnt this become more complex ? > > > > > > > > Secondly, this also means that one must walk the command > > > > list at the target and quiesce connection allegiance during > > > > logout - which may not be required if the commands were to be > > > > retried over the same connection always. > > > > > > > > Comments ? > > > > > > > > -Sandeep > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Jul 30 15:18:07 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16927 for ; Mon, 30 Jul 2001 15:18:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UIBLh06804 for ips-outgoing; Mon, 30 Jul 2001 14:11:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f6UIBJ206797 for ; Mon, 30 Jul 2001 14:11:19 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Mon Jul 30 14:06:33 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by scummy; Mon Jul 30 14:10:21 EDT 2001 Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id OAA02170 for ips@ece.cmu.edu; Mon, 30 Jul 2001 14:09:47 -0400 (EDT) Date: Mon, 30 Jul 2001 14:09:47 -0400 (EDT) Message-Id: <200107301809.OAA02170@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu Subject: iSCSI: negotiation failure Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Sec 7.7 (Negotiation failure) says a text sequence during full feature phase can be aborted but I could not find the mechanism to do this. Is this done using the OpParmReset key ? The key description says it is "IO" only (not full-feature) > A failure in negotiation while in the full-feature phase MUST > terminate the entire negotiation sequence possibly consisting > of a series of text commands using the same Initiator Task > Tag. The operational parameters of the session or the > connection MUST continue to be the values agreed upon during > an earlier successful negotiation - i.e. any partial results > of this unsuccessful negotiation must be undone. -Sandeep From owner-ips@ece.cmu.edu Mon Jul 30 16:06:17 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20702 for ; Mon, 30 Jul 2001 16:06:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UIqc009075 for ips-outgoing; Mon, 30 Jul 2001 14:52:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from dominoe.integrix.com ([207.171.9.89]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UGQA201055 for ; Mon, 30 Jul 2001 12:26:10 -0400 (EDT) Received: from integrix.com (rellis [192.9.200.208]) by dominoe.integrix.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA01590 for ; Mon, 30 Jul 2001 09:24:47 -0700 (PDT) Message-ID: <3B658B31.1307F2AA@integrix.com> Date: Mon, 30 Jul 2001 09:28:33 -0700 From: Rick Ellis X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: RE: Unsupported target LUN Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Shawn is right. So to answer Rick's original question, >the SCSI Status for illegal LUN CHECK CONDITION should be >qualified by the iSCSI response code of "0x00" - "Command >Completed at Target". Thanks, that sounds good. From owner-ips@ece.cmu.edu Mon Jul 30 17:03:59 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24659 for ; Mon, 30 Jul 2001 17:03:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UJenX11981 for ips-outgoing; Mon, 30 Jul 2001 15:40:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UJem211975 for ; Mon, 30 Jul 2001 15:40:48 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id PAA03697; Mon, 30 Jul 2001 15:40:45 -0400 (EDT) Date: Mon, 30 Jul 2001 15:40:45 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI login phasing In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2068743714-331272192-996522045=:3575" Sender: owner-ips@ece.cmu.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2068743714-331272192-996522045=:3575 Content-Type: TEXT/PLAIN; charset=US-ASCII > The security purists will object (with good reason) to the names being > disclosed before security is established > when they are not needed for security. > > Mandating always 2 phases is wastefull for those cases in which the > security negotiation is in fact bypassed. > > Stating the phase explicitly solves both those problems. > > Julo Julian: 1. Requiring the InitiatorName and TargetName keys on the login is independent of whether the phase is stated explicitly. a) If the phase is explicitly stated, we could still mandate that these keys always be required in the security phase. This makes your proposal identical to mine with respect to this issue. b) If the phase is not explicitly stated, we could drop the mandate that these keys always be required. This makes my proposal identical to yours with respect to this issue. As you state, security purists would argue that these keys not be required before security is established. Fine, but that does not argue either for or against your new proposal to explicitly state the phase. 2. Your new proposal to require a handshake at the end of both the security phase and the operational phase can also be considered wasteful, because now it will require two handshakes when both security and operational parameters are to be negotiated, whereas only one handshake is required in my approach. To compare the two approaches: a) No security, no operational: New proposal - no handshakes (if this is legal, see below) Previous proposal - 1 handshake b) Security, no operational: New proposal - 1 handshake Previous proposal - 1 handshake c) No security, operational: New proposal - 1 handshake Previous proposal - 1 handshake d) Security, operational New proposal - 2 handshakes Previous proposal - 1 handshake So which is more wasteful -- your new proposal that requires 2 handshakes in case d, or my previous proposal that requires 1 handshake in case a? Note also that my previous proposal always required exactly 1 handshake, wherease your new proposal has a varying number, depending on the context. 3. I do not believe the new proposal solves either problem, nor do I believe it simplifies anything. Attached is an ASCII text file containing the state diagram of the target for your new proposal as I interpret it, and I would welcome your comments/corrections to it, as I may not be interpreting it correctly. If my interpretation of your new proposal is correct, then your target requires 7 states and 14 transitions, instead of 5 states and 7 transitions in my previous target state diagram. Clearly the previous target is simpler by the measure of the number of states and/or the number of transitions. I have not had time to produce a detailed diagram for the initiator, but your proposal does not seem to either add or delete states from my previous initiator state diagram. To make this new diagram easier to compare with my previous diagram for the target, I labeled the new states T6 and T7, and the new transitions Z8 through Z14. If this new proposal is accepted, I would certainly relabel the states and transitions to be easier to follow. In his e-mail of 27-July Steve Senum asked 2 questions, which I repeat here: 1. Is the Initiator required to start with either a SecurityPhase=start or an OperationalPhase=start on the initial login command? 2. If the Initiator started with OperationalPhase=start, does the target have any way to force a SecurityPhase=start? In your reply of 28-July you did not answer either question directly, so I am assuming that the answer to both questions is No. Is this a correct assumption? If this is not true for question 1, (i.e., if the login must contain either SecurityPhase=start or OperationalPhase=start), then just eliminate the transition labeled Z9 in my new diagram. If this is not true for question 2, (i.e., if the target can force SecurityPhase=start), then there will be a need to add additional states and/or transitions to the new diagram. One final point about simplification -- your new proposal requires the addition of 4 new key-value pairs (SecurityPhase=start, SecurityPhase=end, OperationalPhase=start, OperationalPhase=end) and the elimination of 1 existing key-value pair (SecurityContextComplete=yes). My proposal keeps the SecurityContextComplete=yes key, and introduces no new keys. (I believe the OpParmReset key would be eliminated in both proposals.) Which is simpler and by what measure? Clearly there is a direct cost to your proposal in terms of added states and transitions. Comments please. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---2068743714-331272192-996522045=:3575 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=jt_states Content-ID: Content-Description: Content-Disposition: attachment; filename=jt_states Content-Transfer-Encoding: BASE64 TG9naW4gUGhhc2UgUHJvY2Vzc2luZyBmb3IgYW4gaVNDU0kgVGFyZ2V0DQpC YXNlZCBvbiB0aGUgcHJvcG9zYWwgYnkgSnVsaWFuIFNhdHJhbiBpbiBoaXMg ZS1tYWlsIG9mIDI3LUp1bHkNCg0KVGhlIHRhcmdldCBoYXMgNyBzdGF0ZXM6 DQoNCiAgICBUMTogQXdhaXQgTG9naW4NCiAgICBUMjogTmVnb3RpYXRlIFNl Y3VyaXR5DQogICAgVDM6IExlYXZlIFNlY3VyaXR5DQogICAgVDY6IEF3YWl0 IENvbnRpbnVhdGlvbg0KICAgIFQ0OiBOZWdvdGlhdGUgT3BlcmF0aW9uYWwN CiAgICBUNzogTGVhdmUgT3BlcmF0aW9uYWwNCiAgICBUNTogRnVsbCBGZWF0 dXJlIFBoYXNlDQoNClRoZXJlIGFyZSAxNCBhbGxvd2VkIHRyYW5zaXRpb25z Og0KDQogRnJvbSBcIFRvLT4gICAgVDEgIHwgICBUMiAgfCAgIFQzICB8ICAg VDQgIHwgICBUNSAgfCAgIFQ2ICB8ICAgVDcgIHwNCiAtLS0tLS1cLS0tKy0t LS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0t LSstLS0tLS0tKw0KICAgIFQxICAgICB8ICAgICAgICB8ICAgWjEgIHwgICAg ICAgfCAgIFo4ICB8ICAgWjkgIHwgICAgICAgfCAgIFoxMCB8DQogICAgLS0t LS0tLSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0t Ky0tLS0tLS0rLS0tLS0tLSsNCiAgICBUMiAgICAgfCAgICAgICAgfCAgIFoy ICB8ICAgWjMgIHwgICAgICAgfCAgICAgICB8ICAgWjQgIHwgICAgICAgfA0K ICAgIC0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0r LS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rDQogICAgVDMgICAgIHwgICAgICAg IHwgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgIFo1ICB8ICAg ICAgIHwNCiAgICAtLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSst LS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKw0KICAgIFQ2ICAgICB8 ICAgICAgICB8ICAgICAgIHwgICAgICAgfCAgIFoxMSB8ICAgWjEyIHwgICAg ICAgfCAgIFoxMyB8DQogICAgLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tKy0t LS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSsNCiAgICBU NCAgICAgfCAgICAgICAgfCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAg ICB8ICAgICAgIHwgICBaMTQgfA0KICAgIC0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0r DQogICAgVDcgICAgIHwgICAgICAgIHwgICAgICAgfCAgICAgICB8ICAgWjYg IHwgICBaNyAgfCAgICAgICB8ICAgICAgIHwNCiAgICAtLS0tLS0tKy0tLS0t LS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSst LS0tLS0tKw0KICAgIFQ1ICAgICB8ICAgICAgICB8ICAgICAgIHwgICAgICAg fCAgICAgICB8ICAgICAgIHwgICAgICAgfCAgICAgICB8DQogICAgLS0tLS0t LSstLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0t LS0tLS0rLS0tLS0tLSsNCg0KSW5pdGlhbCBzdGF0ZToNCiAgICBUMSAgLSBl bnRlcmVkIHdoZW4gVGFyZ2V0IHN1Y2Nlc3NmdWxseSBhY2NlcHRzIGEgVENQ IGNvbm5lY3Rpb24gd2l0aCBhbg0KICAgICAgICAgIGluaXRpYXRvcg0KDQoN CkZpbmFsIHN0YXRlOg0KICAgIFQ1ICAtIGEgdHJhbnNpdGlvbiBpbnRvIHRo aXMgc3RhdGUgZW50ZXJzIEZ1bGwgRmVhdHVyZSBQaGFzZQ0KDQoNClRyYW5z aXRpb25zOg0KDQpaMTogVGFrZW4gd2hlbjogICAgIFRhcmdldCByZWNlaXZl cyBMb2dpbiBDb21tYW5kIGZyb20gaW5pdGlhdG9yIHdpdGggRj0wLA0KICAg ICAgICAgICAgICAgICAgICB3aXRoIFNlY3VyaXR5UGhhc2U9c3RhcnQsDQog ICAgICAgICAgICAgICAgICAgIG9wdGlvbmFsbHkgd2l0aCBTZXNzaW9uVHlw ZT1Ob3JtYWwga2V5LCBhbmQgd2l0aA0KICAgICAgICAgICAgICAgICAgICBz ZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQoNCiAgICBBY3Rp b246ICAgICAgICAgU2VuZCBMb2dpbiBSZXNwb25zZQ0KICAgICAgICAgICAg ICAgICAgICB3aXRoIEY9MA0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIHN0 YXR1cz0weDAwMDEgb3IgMHgwMDAyIGFzIGFwcHJvcHJpYXRlDQogICAgICAg ICAgICAgICAgYW5kIHdpdGggcmVwbGllcyB0byBzZWN1cml0eSBrZXlzIG9m ZmVyZWQgYnkgaW5pdGlhdG9yDQogICAgICAgICAgICAgICAgYW5kIHdpdGgg YW55IGFkZGl0aW9uYWwgc2VjdXJpdHkga2V5cyB0byBvZmZlciB0byBpbml0 aWF0b3INCgwNCloyOiBUYWtlbiB3aGVuOiAgICAgVGFyZ2V0IHJlY2VpdmVz IFRleHQgQ29tbWFuZCBmcm9tIGluaXRpYXRvciB3aXRoIEY9MCwNCiAgICAg ICAgICAgICAgICAgICAgd2l0aCBhbnkgcmVwbGllcyB0byBzZWN1cml0eSBr ZXlzIG9mZmVyZWQgb24gWjEgb3INCiAgICAgICAgICAgICAgICAgICAgWjIs IGFuZCB3aXRoIGFueSBzZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlh dG9yLA0KICAgICAgICAgICAgICAgICAgICBhbmQgcG9zc2libHkgd2l0aCBT ZWN1cml0eVBoYXNlPWVuZCBrZXkNCiAgICAgICAgICAgICAgICBhbmQgVGFy Z2V0IHdhbnRzIHRvIG9mZmVyIGFkZGl0aW9uYWwgc2VjdXJpdHkga2V5cyB0 bw0KICAgICAgICAgICAgICAgICAgICBpbml0aWF0b3IgdGhhdCByZXF1aXJl IGEgcmVwbHkgZnJvbSBpbml0aWF0b3INCg0KICAgIEFjdGlvbjogICAgICAg ICBTZW5kIFRleHQgUmVzcG9uc2UNCiAgICAgICAgICAgICAgICAgICAgd2l0 aCBGPTANCiAgICAgICAgICAgICAgICBhbmQgd2l0aCBhbnkgcmVwbGllcyB0 byBzZWN1cml0eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQogICAgICAg ICAgICAgICAgYW5kIHdpdGggYW55IGFkZGl0aW9uYWwgc2VjdXJpdHkga2V5 cyB0byBvZmZlciB0byBpbml0aWF0b3INCg0KWjM6IFRha2VuIHdoZW46ICAg ICBUYXJnZXQgcmVjZWl2ZXMgVGV4dCBDb21tYW5kIGZyb20gaW5pdGlhdG9y IHdpdGggRj0wLA0KICAgICAgICAgICAgICAgICAgICB3aXRoIGFueSByZXBs aWVzIHRvIHNlY3VyaXR5IGtleXMgb2ZmZXJlZCBvbiBaMSBvciBaMiwNCiAg ICAgICAgICAgICAgICAgICAgYW5kIHdpdGggYW55IHNlY3VyaXR5IGtleXMg b2ZmZXJlZCBieSBpbml0aWF0b3INCiAgICAgICAgICAgICAgICBhbmQgVGFy Z2V0IGRvZXMgbm90IHdhbnQgdG8gb2ZmZXIgYWRkaXRpb25hbCBzZWN1cml0 eSBrZXlzDQogICAgICAgICAgICAgICAgICAgIHRvIGluaXRpYXRvciB0aGF0 IHJlcXVpcmUgYSByZXBseSBmcm9tIGluaXRpYXRvcg0KDQogICAgQWN0aW9u OiAgICAgICAgIFNlbmQgVGV4dCBSZXNwb25zZQ0KICAgICAgICAgICAgICAg ICAgICB3aXRoIEY9MA0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFueSBy ZXBsaWVzIHRvIHNlY3VyaXR5IGtleXMgb2ZmZXJlZCBieSBpbml0aWF0b3IN CiAgICAgICAgICAgICAgICBhbmQgd2l0aCBhbnkgYWRkaXRpb25hbCBzZWN1 cml0eSBrZXlzIHRvIG9mZmVyIHRvIGluaXRpYXRvcg0KICAgICAgICAgICAg ICAgIGFuZCB3aXRoIFNlY3VyaXR5UGhhc2U9ZW5kDQoNClo0OiBUYWtlbiB3 aGVuOiAgICAgVGFyZ2V0IHJlY2VpdmVzIFRleHQgQ29tbWFuZCBmcm9tIGlu aXRpYXRvciB3aXRoIEY9MCwNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBh bnkgcmVwbGllcyB0byBzZWN1cml0eSBrZXlzIG9mZmVyZWQgb24gWjEgb3Ig WjIsDQogICAgICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFueSBzZWN1cml0 eSBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQogICAgICAgICAgICAgICAg ICAgIGFuZCB3aXRoIFNlY3VyaXR5UGhhc2U9ZW5kDQogICAgICAgICAgICAg ICAgYW5kIFRhcmdldCBkb2VzIG5vdCBuZWVkIHRvIHJlcGx5IHRvIHNlY3Vy aXR5IGtleXMgZnJvbQ0KICAgICAgICAgICAgICAgICAgICBpbml0aWF0b3IN CiAgICAgICAgICAgICAgICBhbmQgVGFyZ2V0IGRvZXMgbm90IHdhbnQgdG8g b2ZmZXIgYWRkaXRpb25hbCBzZWN1cml0eSBrZXlzDQogICAgICAgICAgICAg ICAgICAgIHRvIGluaXRpYXRvcg0KDQogICAgQWN0aW9uOiAxLiAgICAgIFNl bmQgVGV4dCBSZXNwb25zZQ0KICAgICAgICAgICAgICAgICAgICB3aXRoIEY9 MA0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIFNlY3VyaXR5UGhhc2U9ZW5k IGFzIG9ubHkga2V5DQogICAgICAgICAgICAyLiAgICAgIFB1dCBhbGwgbmVn b3RpYXRlZCBzZWN1cml0eSBtZWFzdXJlcyBpbnRvIGVmZmVjdA0KDQpaNTog VGFrZW4gd2hlbjogICAgIFRhcmdldCByZWNlaXZlcyBUZXh0IENvbW1hbmQg ZnJvbSBpbml0aWF0b3Igd2l0aCBGPTANCiAgICAgICAgICAgICAgICAgICAg YW5kIHdpdGggU2VjdXJpdHlQaGFzZT1lbmQgYXMgb25seSBrZXkNCg0KICAg IEFjdGlvbjogICAgICAgICBTYW1lIGFzIGFjdGlvbnMgb24gWjQNCg0KWjY6 IFRha2VuIHdoZW46ICAgICBUYXJnZXQgcmVjZWl2ZXMgVGV4dCBDb21tYW5k IGZyb20gaW5pdGlhdG9yIHdpdGggRj0xLA0KICAgICAgICAgICAgICAgICAg ICB3aXRoIGFueSByZXBsaWVzIHRvIG9wZXJhdGlvbmFsIGtleXMgdGFyZ2V0 IG9mZmVyZWQNCiAgICAgICAgICAgICAgICAgICAgb24gWjE0LCBhbmQgd2l0 aCBhbnkgb3BlcmF0aW9uYWwga2V5cyBvZmZlcmVkIGJ5DQogICAgICAgICAg ICAgICAgICAgIGluaXRpYXRvcg0KICAgICAgICAgICAgICAgIGFuZCBUYXJn ZXQgd2FudHMgdG8gb2ZmZXIgYWRkaXRpb25hbCBvcGVyYXRpb25hbCBrZXlz DQogICAgICAgICAgICAgICAgICAgIHRoYXQgcmVxdWlyZSBhIHJlcGx5IGZy b20gaW5pdGlhdG9yDQoNCiAgICBBY3Rpb246ICAgICAgICAgU2VuZCBUZXh0 IFJlc3BvbnNlDQogICAgICAgICAgICAgICAgICAgIHdpdGggRj0wDQogICAg ICAgICAgICAgICAgYW5kIHdpdGggYW55IHJlcGxpZXMgdG8gb3BlcmF0aW9u YWwga2V5cyBvZmZlcmVkIGJ5DQogICAgICAgICAgICAgICAgICAgIGluaXRp YXRvcg0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFsbCBhZGRpdGlvbmFs IG9wZXJhdGlvbmFsIGtleXMgdG8gb2ZmZXIgdG8NCiAgICAgICAgICAgICAg ICAgICAgaW5pdGlhdG9yDQoMDQpaNzogVGFrZW4gd2hlbjogICAgIFRhcmdl dCByZWNlaXZlcyBUZXh0IENvbW1hbmQgZnJvbSBpbml0aWF0b3Igd2l0aCBG PTEsDQogICAgICAgICAgICAgICAgICAgIHdpdGggYW55IHJlcGxpZXMgdG8g b3BlcmF0aW9uYWwga2V5cyB0YXJnZXQgb2ZmZXJlZA0KICAgICAgICAgICAg ICAgICAgICBvbiBaMTIgb3IgWjE0LCB3aXRoIGFueSBvcGVyYXRpb25hbCBr ZXlzIG9mZmVyZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgaW5pdGlhdG9y IHRoYXQgZG8gbm90IHJlcXVpcmUgYSByZXBseSBmcm9tIHRhcmdldCwgYW5k DQogICAgICAgICAgICAgICAgICAgIHdpdGggT3BlcmF0aW9uYWxQaGFzZT1l bmQga2V5DQogICAgICAgICAgICAgICAgYW5kIFRhcmdldCBkb2VzIG5vdCB3 YW50IHRvIG9mZmVyIGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwNCiAgICAgICAg ICAgICAgICAgICAga2V5cyB0aGF0IHJlcXVpcmUgYSByZXBseSBmcm9tIGlu aXRpYXRvcg0KDQogICAgQWN0aW9uOiAgICAgICAgIFNlbmQgTG9naW4gUmVz cG9uc2UNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBGPTENCiAgICAgICAg ICAgICAgICBhbmQgd2l0aCBzdGF0dXM9MHgwMDAwDQogICAgICAgICAgICAg ICAgYW5kIHdpdGggT3BlcmF0aW9uYWxQaGFzZT1lbmQgYXMgb25seSBrZXkN Cg0KWjg6IFRha2VuIHdoZW46ICAgICBUYXJnZXQgcmVjZWl2ZXMgTG9naW4g Q29tbWFuZCBmcm9tIGluaXRpYXRvciB3aXRoIEY9MCwNCiAgICAgICAgICAg ICAgICAgICAgd2l0aCBPcGVyYXRpb25hbFBoYXNlPXN0YXJ0LCBhbmQgd2l0 aCBhbnkgb3BlcmF0aW9uYWwNCiAgICAgICAgICAgICAgICAgICAga2V5cyBv ZmZlcmVkIGJ5IGluaXRpYXRvcg0KICAgICAgICAgICAgICAgIGFuZCBUYXJn ZXQgd2FudHMgdG8gb2ZmZXIgYWRkaXRpb25hbCBvcGVyYXRpb25hbCBrZXlz DQogICAgICAgICAgICAgICAgICAgIHRoYXQgcmVxdWlyZSBhIHJlcGx5IGZy b20gaW5pdGlhdG9yDQoNCiAgICBBY3Rpb246ICAgICAgICAgU2VuZCBMb2dp biBSZXNwb25zZQ0KICAgICAgICAgICAgICAgICAgICB3aXRoIEY9MA0KICAg ICAgICAgICAgICAgIGFuZCB3aXRoIHN0YXR1cz0weDAwMDEgb3IgMHgwMDAy IGFzIGFwcHJvcHJpYXRlDQogICAgICAgICAgICAgICAgYW5kIHdpdGggYW55 IHJlcGxpZXMgdG8gb3BlcmF0aW9uYWwga2V5cyBvZmZlcmVkIGJ5IGluaXRp YXRvcg0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIGFsbCBhZGRpdGlvbmFs IG9wZXJhdGlvbmFsIGtleXMgdG8gb2ZmZXIgdG8gaW5pdGlhdG9yDQoNClo5 OiBUYWtlbiB3aGVuOiAgICAgVGFyZ2V0IHJlY2VpdmVzIExvZ2luIENvbW1h bmQgZnJvbSBpbml0aWF0b3Igd2l0aCBGPTEsDQogICAgICAgICAgICAgICAg ICAgIGFuZCBubyBzZWN1cml0eSBvciBvcGVyYXRpb25hbCBrZXlzIG9mZmVy ZWQgYnkgaW5pdGlhdG9yDQogICAgICAgICAgICAgICAgYW5kIFRhcmdldCBk b2VzIG5vdCB3YW50IHRvIG9mZmVyIGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwg a2V5cw0KICAgICAgICAgICAgICAgICAgICB0aGF0IHJlcXVpcmUgYSByZXBs eSBmcm9tIGluaXRpYXRvcg0KDQogICAgQWN0aW9uOiAgICAgICAgIFNlbmQg TG9naW4gUmVzcG9uc2UNCiAgICAgICAgICAgICAgICAgICAgd2l0aCBGPTEN CiAgICAgICAgICAgICAgICBhbmQgd2l0aCBzdGF0dXM9MHgwMDAwDQogICAg ICAgICAgICAgICAgYW5kIHdpdGggb25seSBpbmZvcm1hdGlvbmFsIGtleXMg dG8gb2ZmZXIgdG8gaW5pdGlhdG9yDQoNCloxMDpUYWtlbiB3aGVuOiAgICAg VGFyZ2V0IHJlY2VpdmVzIExvZ2luIENvbW1hbmQgZnJvbSBpbml0aWF0b3Ig d2l0aCBGPTAsDQogICAgICAgICAgICAgICAgICAgIHdpdGggT3BlcmF0aW9u YWxQaGFzZT1zdGFydCwgYW5kIHdpdGggYW55IG9wZXJhdGlvbmFsDQogICAg ICAgICAgICAgICAgICAgIGtleXMgb2ZmZXJlZCBieSBpbml0aWF0b3INCiAg ICAgICAgICAgICAgICBhbmQgVGFyZ2V0IGRvZXMgbm90IHdhbnQgdG8gb2Zm ZXIgYWRkaXRpb25hbCBvcGVyYXRpb25hbCBrZXlzDQogICAgICAgICAgICAg ICAgICAgIHRoYXQgcmVxdWlyZSBhIHJlcGx5IGZyb20gaW5pdGlhdG9yDQoN CiAgICBBY3Rpb246ICAgICAgICAgU2VuZCBMb2dpbiBSZXNwb25zZQ0KICAg ICAgICAgICAgICAgICAgICB3aXRoIEY9MA0KICAgICAgICAgICAgICAgIGFu ZCB3aXRoIHN0YXR1cz0weDAwMDEgb3IgMHgwMDAyIGFzIGFwcHJvcHJpYXRl DQogICAgICAgICAgICAgICAgYW5kIHdpdGggYW55IHJlcGxpZXMgdG8gb3Bl cmF0aW9uYWwga2V5cyBvZmZlcmVkIGJ5IGluaXRpYXRvcg0KICAgICAgICAg ICAgICAgIGFuZCB3aXRoIGFsbCBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsIGtl eXMgdG8gb2ZmZXIgdG8gaW5pdGlhdG9yDQogICAgICAgICAgICAgICAgICAg ICh0aGF0IGRvIG5vdCByZXF1aXJlIGEgcmVwbHkgZnJvbSBpbml0aWF0b3Ip DQogICAgICAgICAgICAgICAgYW5kIHdpdGggT3BlcmF0aW9uYWxQaGFzZT1l bmQNCg0KWjExOlRha2VuIHdoZW46ICAgICBUYXJnZXQgcmVjZWl2ZXMgVGV4 dCBDb21tYW5kIGZyb20gaW5pdGlhdG9yIHdpdGggRj0wLA0KICAgICAgICAg ICAgICAgICAgICB3aXRoIE9wZXJhdGlvbmFsUGhhc2U9c3RhcnQsIGFuZCB3 aXRoIGFueSBvcGVyYXRpb25hbA0KICAgICAgICAgICAgICAgICAgICBrZXlz IG9mZmVyZWQgYnkgaW5pdGlhdG9yDQogICAgICAgICAgICAgICAgYW5kIFRh cmdldCB3YW50cyB0byBvZmZlciBhZGRpdGlvbmFsIG9wZXJhdGlvbmFsIGtl eXMNCiAgICAgICAgICAgICAgICAgICAgdGhhdCByZXF1aXJlIGEgcmVwbHkg ZnJvbSBpbml0aWF0b3INCg0KICAgIEFjdGlvbjogICAgIFNhbWUgYXMgYWN0 aW9uIG9uIFo2DQoMDQpaMTI6VGFrZW4gd2hlbjogICAgIFRhcmdldCByZWNl aXZlcyBUZXh0IENvbW1hbmQgZnJvbSBpbml0aWF0b3Igd2l0aCBGPTEsDQog ICAgICAgICAgICAgICAgICAgIGFuZCBubyBvcGVyYXRpb25hbCBrZXlzIG9m ZmVyZWQgYnkgaW5pdGlhdG9yDQoNCiAgICBBY3Rpb246ICAgICAgICAgU2Vu ZCBMb2dpbiBSZXNwb25zZQ0KICAgICAgICAgICAgICAgICAgICB3aXRoIEY9 MQ0KICAgICAgICAgICAgICAgIGFuZCB3aXRoIHN0YXR1cz0weDAwMDANCiAg ICAgICAgICAgICAgICBhbmQgd2l0aCBvbmx5IGluZm9ybWF0aW9uYWwga2V5 cyB0byBvZmZlciB0byBpbml0aWF0b3INCg0KWjEzOlRha2VuIHdoZW46ICAg ICBUYXJnZXQgcmVjZWl2ZXMgVGV4dCBDb21tYW5kIGZyb20gaW5pdGlhdG9y IHdpdGggRj0wLA0KICAgICAgICAgICAgICAgICAgICB3aXRoIE9wZXJhdGlv bmFsUGhhc2U9c3RhcnQsIGFuZCB3aXRoIGFueSBvcGVyYXRpb25hbA0KICAg ICAgICAgICAgICAgICAgICBrZXlzIG9mZmVyZWQgYnkgaW5pdGlhdG9yDQog ICAgICAgICAgICAgICAgYW5kIFRhcmdldCBkb2VzIG5vdCB3YW50IHRvIG9m ZmVyIGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwga2V5cw0KICAgICAgICAgICAg ICAgICAgICB0aGF0IHJlcXVpcmUgYSByZXBseSBmcm9tIGluaXRpYXRvcg0K DQogICAgQWN0aW9uOiAgICAgICAgIFNlbmQgVGV4dCBSZXNwb25zZQ0KICAg ICAgICAgICAgICAgICAgICB3aXRoIEY9IDANCiAgICAgICAgICAgICAgICBh bmQgd2l0aCBhbnkgcmVwbGllcyB0byBvcGVyYXRpb25hbCBrZXlzIG9mZmVy ZWQgYnkgaW5pdGlhdG9yDQogICAgICAgICAgICAgICAgYW5kIHdpdGggYWxs IGFkZGl0aW9uYWwgb3BlcmF0aW9uYWwga2V5cyB0byBvZmZlciB0byBpbml0 aWF0b3INCiAgICAgICAgICAgICAgICAgICAgKHRoYXQgZG8gbm90IHJlcXVp cmUgYSByZXBseSBmcm9tIGluaXRpYXRvcikNCiAgICAgICAgICAgICAgICBh bmQgd2l0aCBPcGVyYXRpb25hbFBoYXNlPWVuZA0KDQpaMTQ6VGFrZW4gd2hl bjogICAgIFRhcmdldCByZWNlaXZlcyBUZXh0IENvbW1hbmQgZnJvbSBpbml0 aWF0b3Igd2l0aCBGPTAsDQogICAgICAgICAgICAgICAgICAgIHdpdGggcmVw bGllcyB0byBvcGVyYXRpb25hbCBrZXlzIG9mZmVyZWQgaW4gWjYgb3IgWjEx LA0KICAgICAgICAgICAgICAgICAgICBhbmQgd2l0aCBhbnkgb3BlcmF0aW9u YWwga2V5cyBvZmZlcmVkIGJ5IGluaXRpYXRvcg0KICAgICAgICAgICAgICAg IGFuZCBUYXJnZXQgZG9lcyBub3Qgd2FudCB0byBvZmZlciBhZGRpdGlvbmFs IG9wZXJhdGlvbmFsIGtleXMNCiAgICAgICAgICAgICAgICAgICAgdGhhdCBy ZXF1aXJlIGEgcmVwbHkgZnJvbSBpbml0aWF0b3INCg0KICAgIEFjdGlvbjog ICAgIFNhbWUgYXMgYWN0aW9uIG9uIFoxMw0K ---2068743714-331272192-996522045=:3575-- From owner-ips@ece.cmu.edu Mon Jul 30 17:54:33 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28086 for ; Mon, 30 Jul 2001 17:54:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UKrLh16006 for ips-outgoing; Mon, 30 Jul 2001 16:53:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail2.tor.primus.ca (mail.tor.primus.ca [216.254.136.21]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UKrJ216001 for ; Mon, 30 Jul 2001 16:53:19 -0400 (EDT) Received: from dsl-216-254-190-87.tor.primus.ca ([216.254.190.87] helo=perfisan4) by mail2.tor.primus.ca with smtp (Exim 2.11 #1) id 15RKBb-0003Yi-04 for ips@ece.cmu.edu; Mon, 30 Jul 2001 17:02:47 -0400 Reply-To: From: "Trang Nguyen" To: "IPS" Subject: How to obtain LUN field Date: Mon, 30 Jul 2001 16:55:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Could anyone please help me with this question? I can't find it in the mailing list archive. Q: Regarding the LUN field (8 bytes) in the iSCSI PDUs, how does iSCSI initiator get the LUN field? From the SAM-2 document, Service response = Execute Command (IN(I_T_L_x Nexus, CDB, [Task Attribute], [Data-In Buffer Size], [Data-Out Buffer], [Data-Out Buffer Size], [Autosense Request], [Command Reference Number]), OUT([Data-In Buffer], [Sense Data], Status)) I guess iSCSI initiator gets the LUN field from I_T_L_x nexus. But I can't find the data format of this nexus. Thank you in advance, ********************************* Trang Nguyen tnguyen@perfisans.com ********************************* From owner-ips@ece.cmu.edu Mon Jul 30 19:13:37 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02202 for ; Mon, 30 Jul 2001 19:13:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UIsqA09247 for ips-outgoing; Mon, 30 Jul 2001 14:54:52 -0400 (EDT) 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 f6UIsp209243 for ; Mon, 30 Jul 2001 14:54:51 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Jul 2001 14:53:02 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD513@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Cc: agenda@ietf.org Subject: IP Storage Agenda for London Date: Mon, 30 Jul 2001 14:49:56 -0400 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 IETF IP Storage (IPS) Working Group London IETF Meeting, August 5-10, 2001 ------------------------------------------- CHAIRS: David Black Elizabeth Rodriguez AGENDA: SUBJECT TO CHANGE NOTE: The London IETF meetings conflict with T11 meetings (T11 is the standards organization for Fibre Channel). Therefore the IP Storage Working Group will not be able to work on the FCIP or iFCP protocols or related items in London. INTERIM MEETING: August 27-28, Orange County, CA, USA Main topics will be Fibre Channel related protocols (FCIP and iFCP) and Security for all IPS protocols (iSCSI, FCIP, and iFCP). An announcement with location and additional details is available at: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg05297.html ---- Monday, August 6, 1930-2200 ---- - Agenda Bashing and Administrivia (10 min) - iSCSI Plugfest Results and Discussion (30 min) - iSCSI Security (35 min) draft-black-ips-iscsi-security-00.txt NOTE: This draft covers both security requirements and SRP keying. Use of IKE for keying and considerations for selecting ESP algorithms (authentication and encryption) for iSCSI will also be discussed. - iSCSI Framing Mechanism Requirements (30 min) draft-ietf-tsvwg-tcp-ulp-frame-00.txt NOTE: The contents of this draft will be discussed in TSVWG. This IPS WG time is to discuss iSCSI requirements for use of these mechanisms. - iSCSI (45 min) draft-ietf-ips-iscsi-07.txt Includes Error Recovery ---- Tuesday, August 21, 0900-1130 ---- - Agenda Bashing and Administrivia (5 min) - iSCSI [continued] (65 minutes) draft-ietf-ips-iscsi-07.txt Includes opportunities for simplification. - iSCSI Naming and Discovery Requirements (45 min) draft-ietf-ips-iscsi-name-disc-02.txt Includes mapping of SAM-2 SCSI abstractions to iSCSI and consequences. - Use of SLP and iSNS with ISCSI (20 min) draft-ietf-ips-iscsi-slp-01.txt draft-ietf-ips-isns-04.txt - iSNS MIB (5 min) draft-gibbons-isnsmib-00.txt NOTE: The authors would like the WG to adopt this as an official work item. - iSCSI MIB (10 min) draft-ietf-ips-iscsi-mib-02.txt UML model diagram available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-02.pdf Table structure diagram available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-02.pdf DESCRIPTION: The IP Storage WG works on using IP-based networks to transport block storage traffic. See http://www.ietf.org/html.charters/ips-charter.html From owner-ips@ece.cmu.edu Mon Jul 30 20:07:40 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03437 for ; Mon, 30 Jul 2001 20:07:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UMjAe21462 for ips-outgoing; Mon, 30 Jul 2001 18:45:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UMj8221453 for ; Mon, 30 Jul 2001 18:45:08 -0400 (EDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 685432AE; Mon, 30 Jul 2001 17:45:02 -0500 (CDT) Received: from exchou-gh02.cca.cpqcorp.net (exchou-gh02.cca.cpqcorp.net [16.110.248.202]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 5AC0C1C3 for ; Mon, 30 Jul 2001 17:45:02 -0500 (CDT) Received: by exchou-gh02.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Mon, 30 Jul 2001 17:45:02 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6014D68EB@cceexc17.americas.cpqcorp.net> From: "Elliott, Robert" To: "'ips@ece.cmu.edu'" Subject: iSCSI: draft 7: IPv6 addresses Date: Mon, 30 Jul 2001 17:44:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk In iSCSI revision 7, section 1.2.7 (page 27) and appendix E (page 172) describe specifying IPv6 addresses with "dotted decimal notation." According to RFC2373 the preferred representation for IPv6 addresses is hex numbers with colons, with a few variations: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. 2. ...The use of "::" indicates multiple groups of 16-bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress the leading and/or trailing zeros in an address. 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). I suggest that iSCSI follow these conventions. The reference for section 11 would be: [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing Architecture," July 1998. This was mentioned on the IPS list back during revision 5: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03735.html apparently without resolution. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Mon Jul 30 20:46:39 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04608 for ; Mon, 30 Jul 2001 20:46:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6UNXIN23470 for ips-outgoing; Mon, 30 Jul 2001 19:33:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r09.mx.aol.com (imo-r09.mx.aol.com [152.163.225.105]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6UNXH223465 for ; Mon, 30 Jul 2001 19:33:17 -0400 (EDT) Received: from Txk15@aol.com by imo-r09.mx.aol.com (mail_out_v31.9.) id 3.54.18163486 (4005) for ; Mon, 30 Jul 2001 19:33:11 -0400 (EDT) From: Txk15@aol.com Message-ID: <54.18163486.289748b7@aol.com> Date: Mon, 30 Jul 2001 19:33:11 EDT Subject: Remove To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 4.0 for Windows sub 109 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Remove From owner-ips@ece.cmu.edu Tue Jul 31 03:40:27 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08863 for ; Tue, 31 Jul 2001 03:40:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6V6Rkh08829 for ips-outgoing; Tue, 31 Jul 2001 02:27:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from yamuna.ctd.hcltech.com ([202.140.153.6]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6V6Rg208825 for ; Tue, 31 Jul 2001 02:27:43 -0400 (EDT) Received: by YAMUNA with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 12:01:21 +0530 Message-ID: <219446B9B371D511A353000244192476190D19@DEVI> From: Sharan Basappa To: "'ips@ece.cmu.edu'" Subject: can i discuss infiniband here Date: Tue, 31 Jul 2001 12:11:28 +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 Just wanted to know if infiniband can be discussed in this forum. Sharan From owner-ips@ece.cmu.edu Tue Jul 31 03:40:31 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08874 for ; Tue, 31 Jul 2001 03:40:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6V6oH409648 for ips-outgoing; Tue, 31 Jul 2001 02:50:17 -0400 (EDT) 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 f6V6oE209637 for ; Tue, 31 Jul 2001 02:50:15 -0400 (EDT) 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 IAA225802 for ; Tue, 31 Jul 2001 08:50:07 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6V6o6L79464 for ; Tue, 31 Jul 2001 08:50:06 +0200 Importance: Normal Subject: Re: iSCSI: negotiation failure To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 31 Jul 2001 09:56:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 31/07/2001 09:50:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, The only mechanism I considered is OpParmReset (the IO is a mistake) - the new text I suggest is: 01 OpParmReset Use: All Who can send: Initiator and Target OpParmReset= OpParmReset enables an Initiator or Target to request the operational parameters to be reset to the values they had before the negotiation. Either the initiator or target may choose to do so but only within an operational parameter negotiation exchange within login or during full feature phase. The resetting should involve only parameters that where set during operational parameter negotiation on the connection in which the OpParmReset is issued. Please note that since either initiator or target may request this behavior there is no need to reply. However please note that 7.7 has also a "negative connotation" - that parameters that did not get agreed upon on a successfully completed text exchange do not get "committed". Comments ? Julo sandeepj@research.bell-labs.com (Sandeep Joshi) on 30-07-2001 21:09:47 Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) To: ips@ece.cmu.edu cc: Subject: iSCSI: negotiation failure Julian, Sec 7.7 (Negotiation failure) says a text sequence during full feature phase can be aborted but I could not find the mechanism to do this. Is this done using the OpParmReset key ? The key description says it is "IO" only (not full-feature) > A failure in negotiation while in the full-feature phase MUST > terminate the entire negotiation sequence possibly consisting > of a series of text commands using the same Initiator Task > Tag. The operational parameters of the session or the > connection MUST continue to be the values agreed upon during > an earlier successful negotiation - i.e. any partial results > of this unsuccessful negotiation must be undone. -Sandeep From owner-ips@ece.cmu.edu Tue Jul 31 03:41:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08890 for ; Tue, 31 Jul 2001 03:41:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6V6Rwf08840 for ips-outgoing; Tue, 31 Jul 2001 02:27:58 -0400 (EDT) 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 f6V6Ru208835 for ; Tue, 31 Jul 2001 02:27:56 -0400 (EDT) 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 IAA152350 for ; Tue, 31 Jul 2001 08:27:49 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6V6Rlf165582 for ; Tue, 31 Jul 2001 08:27:48 +0200 Importance: Normal Subject: Re: iSCSI connection recovery To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 31 Jul 2001 09:33:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 31/07/2001 09:27:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, Don't blame me for size. I would prefer the spec to be 10-20 pages and have a formal spec. The past of this list has clearly shown that more text helps at least to gain consensus :-) Regards, Julo Sandeep Joshi on 30-07-2001 21:03:04 Please respond to Sandeep Joshi To: ips@ece.cmu.edu cc: Subject: Re: iSCSI connection recovery > I assume you are not suggesting a FinalLogout ;-), are you? No I was not :-) I missed reading the 4th paragraph of Section 2.14 which alludes to this logout processing. The spec is getting monstrous at 185 pages. regards, -Sandeep Julian Satran wrote: > > Sandeep, > > There is nothing to stop them sending the state but there is no way for the > initiator to acknowledge those (Logout takes it out of the full feature > phase - nothing valid after) and a new connection is a new day ... > > I assume you are not suggesting a FinalLogout ;-), are you? > > Regards, > Julo > > Sandeep Joshi on 30-07-2001 18:38:48 > > Please respond to Sandeep Joshi > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI connection recovery > > Julian > > Wait..! I was proposing that the expStatSN could be used to send back > the responses (even *before* commands get retried) See below > > -Sandeep > > Julian Satran wrote: > > > > Sandeep, > > > > Both Login (with the X bit it is a logout/login) and Logout have an > > ExpStatSN just for this reason. > > If this does not come through clear in the text please let me know. > > > > Regards, > > Julo > > > > Sandeep Joshi on 30-07-2001 17:33:49 > > > > Please respond to Sandeep Joshi > > > > To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI connection recovery > > > > Julian, > > > > The explanation helps. Now that the model is clear, let me > > ask if something like this would work.. > > > > It seems possible for the target to send back SCSI responses > > during recovery logout, even before commands are retried. > > The recovery logout could act as a final (& appetizing) SNACK. > > > > Since the target still has a statSN index on the responses, > > it could use the expStatSN field in the Logout Command > > and send all responses from [expStatSN-endStatSN]. > > > > Initiator Target > > --------- --------- > > Logout (for recovery) ---->> > > <<--- SCSI Data+Responses from [expStatSN-endStatSN] > > <<--- Logout Response > > > > Once the logout occurs, the statSN ranges for the CID are > > lost and command retry cannot be avoided. > > > > This logout optimization has larger benefits for Writes. > > Retrying Write Commands (e.g. tape backup) may involve > > sending all the data (or minimally FirstBurst) all over > > again! Of course, cost-benefit depends on queue lengths, > > bandwidth, frequency of connection recovery, transfer > > sizes, ULP timeouts, etc. > > > > Comments ? > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > Sandeep, > > > > > > Your status cache is made of some task related structures. You can > > reuse > > > those - just link them to a new connection. > > > As for StatSN - you can't reuse those as each connection establishes > its > > > own (new) StatSN at login (even if reusing the old CID). > > > > > > Regardless of what CID the connection bears - it is a new connection > and > > > you can issue new commands. Even for the old ones by reissuing you in > > fact > > > indicate the new allegiance (the logout suspended them and the retry > > > establishes the new allegiance). > > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 29-07-2001 01:01:54 > > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > > > To: ips@ece.cmu.edu > > > cc: > > > Subject: Re: iSCSI connection recovery > > > > > > Er..I mixed up the terminology. By "same connection", I meant > > > "same CID" - so one could retry cmds ONLY on the new TCP connection > > > with the same CID, after the old TCP connection had failed. > > > This avoids having to change connection allegiance on > > > the stuck commands, as part of connection logout. > > > > > > The main questions, however, were these : > > > > > > 1) What is the effect of a CID logout on the status (statSN) > > > cache ? Can it be reused when the commands are retried ? > > > (Think not..) > > > > > > 2) After one does a login for recovery using an old CID, > > > can new SCSI commands be issued on that new TCP connection. > > > (though it bears an old CID identifier) > > > > > > -Sandeep > > > > > > > Sandeep, > > > > > > > > Retry over any connection was always the case. > > > > Commands can change allegiance only after a logout. > > > > The commands get quiesced anyway and you have to mark them ready for > a > > > > retry anyhow (you don't want retry at arbitrary times to hit > unpunished > > > the > > > > target). After that it doesn't matter where you retry (same > connection, > > > > another old one, a new one). > > > > > > > > The only new thing is command replay (after status was sent but > before > > it > > > > is acked). > > > > > > > > Regards, > > > > Julo > > > > > > > > sandeepj@research.bell-labs.com (Sandeep Joshi) on 28-07-2001 > 06:37:33 > > > > > > > > Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi) > > > > > > > > To: ips@ece.cmu.edu > > > > cc: > > > > Subject: iSCSI connection recovery > > > > > > > > > > > > > > > > > > > > I had a "big-picture" question about the connection > > > > recovery model. > > > > > > > > The current draft suggests that, once the broken connection > > > > is logged out, the commands allegiant to the old connection > > > > can now be retried over *any* connection. (See Section 7.11.3 > > > > bullet 1 and also Appendix F Session Recovery algo for > > > > initiator.) > > > > > > > > I may be mistaken, but in previous drafts, this was not > > > > the case and commands always stayed allegiant to a CID. > > > > > > > > So the question is.. how does one use a Status cache > > > > belonging to the old connection in this new model (now that > > > > the commands are going to be retried over any connection) > > > > Doesnt this become more complex ? > > > > > > > > Secondly, this also means that one must walk the command > > > > list at the target and quiesce connection allegiance during > > > > logout - which may not be required if the commands were to be > > > > retried over the same connection always. > > > > > > > > Comments ? > > > > > > > > -Sandeep > > > > > > > > > > > > From owner-ips@ece.cmu.edu Tue Jul 31 03:43:58 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08937 for ; Tue, 31 Jul 2001 03:43:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6V71Xn09984 for ips-outgoing; Tue, 31 Jul 2001 03:01:33 -0400 (EDT) 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 f6V71V209979 for ; Tue, 31 Jul 2001 03:01:31 -0400 (EDT) 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 JAA49380 for ; Tue, 31 Jul 2001 09:01:24 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6V71Nf96206 for ; Tue, 31 Jul 2001 09:01:23 +0200 Importance: Normal Subject: Re: iSCSI: draft 7: IPv6 addresses To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 31 Jul 2001 10:07:31 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 31/07/2001 10:01:24 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, This was long on our ToDo list and we got to it recently (fixed according to RFC2373 and RFC2732 ). 1.2.7 now reads: 1.1.1 Naming and Addressing All iSCSI initiators and targets are named. Each target or initiator is known by an iSCSI Name. The iSCSI Name is independent of the location of the initiator and target; two formats are provided that allow the use of existing naming authorities when generating them. One of these formats allows the use of a registered domain name as a naming authority; it is important not to confuse this with an address. The iSCSI Name is a UTF-8 text string, and is defined in [NDT]. iSCSI Names are used to provide: - a target identifier for configurations that present multiple targets behind a single IP address and port. - a method to recognize multiple paths to the same device on different IP addresses and ports. - an identifier for source and destination targets for use in third party commands. - an identifier for initiators and targets to enable them to recognize each other regardless of IP address and port mapping on intermediary firewalls. The initiator MUST present both its iSCSI Initiator Name and the iSCSI Target Name to which it wishes to connect during the login phase. The only exception is if a discovery session (see 1.4) is to be established; the iSCSI Initiator Name is still required, but the iSCSI Target Name may be ignored. The key "SessionType=Discovery" is sent by the initiator at login to indicate a discovery session. The default name "iSCSI" is reserved, and is not used as an individual initiator or target name. iSCSI Names do not require special handling within iSCSI; they are opaque and case-sensitive for the purposes of comparison. Examples of iSCSI Names: iqn.5886.com.disk-vendor.diskarrays.sn.45678 iqn.5886.com.gateways.yourtargets.24 iqn.5886.com.os-vendor.plan9.cdrom.12345 iqn.5886.com.service-provider.users.customer235.host90 eui.02004567A425678D iSCSI targets also have addresses. An iSCSI address specifies a single path on which to find an iSCSI target. [:] Where is one of: - IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by dots (.), where each number is in the range 0..255. - IPv6 address, in colon-separated hexadecimal notation, as specified in [RFC2373] and enclosed in "[" and "]" characters, as specified in [RFC2732]. - Fully Qualified Domain Name (host name). Assumed if the is neither an IPv4 nor an IPv6 address. The in the address is optional; if specified it is the TCP port on which the target is listening for connections. If is not specified, a default port, to be assigned by IANA, will be assumed. Examples of addresses: 10.40.1.2 [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] [1080:0:0:0:8:800:200C:417A] [3ffe:2a00:100:7031::1] [1080::8:800:200C:417A] [::192.9.5.5] mydisks.example.com To assist in providing a more human-readable user interface for devices containing iSCSI targets and initiators, a target or initiator may also provide an alias. This alias is a simple UTF-8 string, is not globally unique, and is never interpreted or used to identify an initiator or device within the iSCSI protocol. Its use is described in [NDT]. Third party commands require that protocol-specific addresses be communicated within SCSI CDBs. The iSCSI protocol-specific address consists of an iSCSI name, or an iSCSI name + TCP address. Work on this mechanism is in progress in T10. An initiator may discover the iSCSI Target Names to which it has access, along with their addresses, using the SendTargets text command, or by other techniques discussed in [NDT]. Changes where made in other parts too (examples, SendTargets etc). Thanks, Julo "Elliott, Robert" on 31-07-2001 01:44:57 Please respond to "Elliott, Robert" To: "'ips@ece.cmu.edu'" cc: Subject: iSCSI: draft 7: IPv6 addresses In iSCSI revision 7, section 1.2.7 (page 27) and appendix E (page 172) describe specifying IPv6 addresses with "dotted decimal notation." According to RFC2373 the preferred representation for IPv6 addresses is hex numbers with colons, with a few variations: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the hexadecimal values of the eight 16-bit pieces of the address. 2. ...The use of "::" indicates multiple groups of 16-bits of zeros. The "::" can only appear once in an address. The "::" can also be used to compress the leading and/or trailing zeros in an address. 3. An alternative form that is sometimes more convenient when dealing with a mixed environment of IPv4 and IPv6 nodes is x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of the six high-order 16-bit pieces of the address, and the 'd's are the decimal values of the four low-order 8-bit pieces of the address (standard IPv4 representation). I suggest that iSCSI follow these conventions. The reference for section 11 would be: [RFC2373] Hinden, R. and Deering, S. "IP Version 6 Addressing Architecture," July 1998. This was mentioned on the IPS list back during revision 5: http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03735.html apparently without resolution. --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Tue Jul 31 06:13:10 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.236.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11231 for ; Tue, 31 Jul 2001 06:13:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6V8l3D23827 for ips-outgoing; Tue, 31 Jul 2001 04:47:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from kodos.tinet.ie (mail1.tinet.ie [159.134.237.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6V8l1223822 for ; Tue, 31 Jul 2001 04:47:01 -0400 (EDT) Received: from [159.134.199.212] (helo=methode_nt.methode.ie) by kodos.tinet.ie with smtp (Exim 2.05 #1) id 15RVB0-0002XI-00 for ips@ece.cmu.edu; Tue, 31 Jul 2001 09:46:54 +0100 Received: from SMTP agent by mail gateway Tue, 31 Jul 2001 09:43:27 -0000 Received: by METHODE_NT with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 09:45:04 +0100 Message-ID: <4448BB382D71D511A4380002A551921E055851@METHODE_NT> From: Tom Allen To: "'ips@ece.cmu.edu'" Subject: remove Date: Tue, 31 Jul 2001 09:45:03 +0100 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 remove From owner-ips@ece.cmu.edu Tue Jul 31 09:56:49 2001 Received: from ece.cmu.edu ([128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16024 for ; Tue, 31 Jul 2001 09:56:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VCZp300319 for ips-outgoing; Tue, 31 Jul 2001 08:35:51 -0400 (EDT) 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 f6VCWp201218 for ; Tue, 31 Jul 2001 08:32:51 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 08:31:01 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD529@CORPMX14> From: Black_David@emc.com To: sharan@ctd.hcltech.com, ips@ece.cmu.edu Subject: RE: can i discuss infiniband here Date: Tue, 31 Jul 2001 08:27:56 -0400 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 This is the mailing group for the IETF IP Storage WG. See http://www.ietf.org/html.charters/ips-charter.html for an explanation of what we do. InfiniBand could be discussed here in the context of proposing new work (e.g., SRP over IP in some form), but discussion of InfiniBand as it currently exists belongs elsewhere - you might start with the InfiniBand Trade Association (www.infinibandta.org) to look for a suitable forum. --David (WG co-chair) > -----Original Message----- > From: Sharan Basappa [mailto:sharan@ctd.hcltech.com] > Sent: Tuesday, July 31, 2001 2:41 AM > To: 'ips@ece.cmu.edu' > Subject: can i discuss infiniband here > > > Just wanted to know if infiniband can be discussed in this forum. > Sharan > From owner-ips@ece.cmu.edu Tue Jul 31 10:09:00 2001 Received: from ece.cmu.edu ([128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16594 for ; Tue, 31 Jul 2001 10:08:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VDHkZ02498 for ips-outgoing; Tue, 31 Jul 2001 09:17:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from best.eurologic.com ([193.120.246.5]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VDHi302494 for ; Tue, 31 Jul 2001 09:17:44 -0400 (EDT) Received: from KINGBARNES ([192.168.7.103]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id OAA24985 for ; Tue, 31 Jul 2001 14:11:39 +0100 (BST) From: "Tom Sargeant" To: Subject: remove Date: Tue, 31 Jul 2001 14:18:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit From owner-ips@ece.cmu.edu Tue Jul 31 13:08:46 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00219 for ; Tue, 31 Jul 2001 13:08:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VFwIR11732 for ips-outgoing; Tue, 31 Jul 2001 11:58:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (2711-2rce-338.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VFwG311725 for ; Tue, 31 Jul 2001 11:58:16 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 17:57:41 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9773@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'IPS Reflector'" Subject: Iscsi: Fault tolerance Date: Tue, 31 Jul 2001 17:57:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119D9.874B9640" 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_01C119D9.874B9640 Content-Type: text/plain; charset="iso-8859-1" Hi Consider a case where the clients of a Windows NT server are accessing the iSCSI target with iSCSI initiator driver installed on the Windows NT server to access a ISCSI target on NET. So all the clients on this Windows NT server can share the iSCSI target of this server. In case the server goes down , will the clients still be able to access the iSCSI Target?? I hope I have put my question peoperly. In case not then please feel free to call me at +31 624685051 Sincerely, Sanjeev Bhagat Tripace Europe ------_=_NextPart_001_01C119D9.874B9640 Content-Type: text/html; charset="iso-8859-1"
Hi
 
Consider a case where the clients of a Windows NT server are accessing the iSCSI target with iSCSI initiator driver installed  on the Windows NT server to access a ISCSI target on NET. So all the clients on this Windows NT server can share the iSCSI target of this server. In case the server goes down , will the clients still be able to access the iSCSI Target??
 
I hope I have put my question peoperly. In case not then please feel free to call me at +31 624685051
 
 
Sincerely,

Sanjeev Bhagat

Tripace Europe

------_=_NextPart_001_01C119D9.874B9640-- From owner-ips@ece.cmu.edu Tue Jul 31 13:11:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00427 for ; Tue, 31 Jul 2001 13:11:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VGT7a13452 for ips-outgoing; Tue, 31 Jul 2001 12:29:07 -0400 (EDT) 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 f6VGT5313443 for ; Tue, 31 Jul 2001 12:29:05 -0400 (EDT) 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 SAA163088 for ; Tue, 31 Jul 2001 18:28:58 +0200 Received: from d10hubm1.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay01.de.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6VGSvf116734 for ; Tue, 31 Jul 2001 18:28:57 +0200 Importance: Normal Subject: Re: Iscsi: Fault tolerance To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 31 Jul 2001 19:35:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.6 |December 14, 2000) at 31/07/2001 19:28:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk How exactly will the clients use the initiator on the server? Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 31-07-2001 18:57:41 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'IPS Reflector'" cc: Subject: Iscsi: Fault tolerance Hi Consider a case where the clients of a Windows NT server are accessing the iSCSI target with iSCSI initiator driver installed on the Windows NT server to access a ISCSI target on NET. So all the clients on this Windows NT server can share the iSCSI target of this server. In case the server goes down , will the clients still be able to access the iSCSI Target?? I hope I have put my question peoperly. In case not then please feel free to call me at +31 624685051 Sincerely, Sanjeev Bhagat Tripace Europe - att1.htm From owner-ips@ece.cmu.edu Tue Jul 31 15:44:06 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15248 for ; Tue, 31 Jul 2001 15:44:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VIIYK19668 for ips-outgoing; Tue, 31 Jul 2001 14:18:34 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zoetermeer.tripace.com (2711-2rce-338.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VIIW319664 for ; Tue, 31 Jul 2001 14:18:32 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 20:17:58 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9776@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: Iscsi: Fault tolerance Date: Tue, 31 Jul 2001 20:17:57 +0200 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 Julian and all!! The server connects to the iscsi target (Say just a disk) with the help of an iSCSI initiator driver installed on the server. The NT server thus shows an extra physical disk present on the server. The sys admin then assigns the permission to other clients/users to share this target. The clients can then access this this disk (iscsi target) or any sharable directory on this disk (iscsi target)present on the server by connecting to the network. Hope it is clear by now!! If it is not then please provide me your contact number and I will try to explain you better. I am sorry if there is any ambiguity but i cant find better words to explain. Sanjeev -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 31, 2001 6:35 PM To: ips@ece.cmu.edu Subject: Re: Iscsi: Fault tolerance How exactly will the clients use the initiator on the server? Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 31-07-2001 18:57:41 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'IPS Reflector'" cc: Subject: Iscsi: Fault tolerance Hi Consider a case where the clients of a Windows NT server are accessing the iSCSI target with iSCSI initiator driver installed on the Windows NT server to access a ISCSI target on NET. So all the clients on this Windows NT server can share the iSCSI target of this server. In case the server goes down , will the clients still be able to access the iSCSI Target?? I hope I have put my question peoperly. In case not then please feel free to call me at +31 624685051 Sincerely, Sanjeev Bhagat Tripace Europe - att1.htm From owner-ips@ece.cmu.edu Tue Jul 31 16:46:00 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20324 for ; Tue, 31 Jul 2001 16:45:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VJ6C622625 for ips-outgoing; Tue, 31 Jul 2001 15:06:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from neptune.he.net (neptune.he.net [216.218.166.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VJ6A322620 for ; Tue, 31 Jul 2001 15:06:10 -0400 (EDT) Received: from lose ([64.171.32.198] (may be forged)) by neptune.he.net (8.8.6/8.8.2) with SMTP id MAA25262; Tue, 31 Jul 2001 12:06:11 -0700 From: "Nate Lawson" To: Cc: Subject: RE: Iscsi: Fault tolerance Date: Tue, 31 Jul 2001 12:05:22 -0700 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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm guessing he means that clients are accessing a server over SMB (windows networking) and the server accesses its drives through iSCSI. In that case, if the server goes down, the drives are inaccessible. Generally, it would be a bad idea to have the clients also able to access the drives directly via iSCSI since they would then circumvent the share permissions the server has set up. Better instead to have multiple SMB servers accessing the drives and do failover at that level. -Nate > -----Original Message----- > > How exactly will the clients use the initiator on the server? > > Julo > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 31-07-2001 > 18:57:41 > > Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" > > > Hi > > Consider a case where the clients of a Windows NT server are accessing the > iSCSI target with iSCSI initiator driver installed on the Windows NT > server > to access a ISCSI target on NET. So all the clients on this Windows NT > server can share the iSCSI target of this server. In case the server goes > down , will the clients still be able to access the iSCSI Target?? > > I hope I have put my question peoperly. In case not then please feel free > to > call me at +31 624685051 > > > Sincerely, > > Sanjeev Bhagat > > Tripace Europe > > > - att1.htm > > > > From owner-ips@ece.cmu.edu Tue Jul 31 16:51:36 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20701 for ; Tue, 31 Jul 2001 16:51:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VJG5323173 for ips-outgoing; Tue, 31 Jul 2001 15:16:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from va2mc.ummailbox.net (va2mc.ummailbox.net [64.210.247.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VJG3323168 for ; Tue, 31 Jul 2001 15:16:03 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id U0731-1515-7ae500; Tue, 31 Jul 2001 19:15:50 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 31 Jul 2001 14:15:21 -0500 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: RE: Iscsi: Fault tolerance Date: Tue, 31 Jul 2001 14:15:21 -0500 Message-ID: Thread-Topic: Iscsi: Fault tolerance Thread-Index: AcEZ8e2jbzAjw5wfR3GuOqwArw7I9wAAXuAw From: "Robert Griswold" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "Julian Satran" , X-OriginalArrivalTime: 31 Jul 2001 19:15:21.0625 (UTC) FILETIME=[24AF8890:01C119F5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f6VJG3323169 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Sanjeev: What you are referring to (share this target) is conceptually the same as assigning access to a volume using CIFS, whereby the admin allows authenticated domain users to get to the file-system of the volume. Whether or not controlled by iSCSI, FC or ATA, the access to the clients is always dependant on the health of the host machine that has the iSCSI drive mapped (and allocated through some iSCSI fabric management). Windows NT (or 2000 for that matter) does not have a concept of sharing out block-level access of host attached (whether direct or through a fabric) drives for client use, that is all done from the file-system level and above. What you may be proposing is the mapping (not sharing, but rather host based mapping) of an iSCSI target through a Windows iSCSI initiator, out to other iSCSI initiators, thereby making the original host a sort of iSCSI proxy, but the sharing of the disk to clients would then be the responsibility of the proxy holder. Hope that helps, Bob Robert Griswold Technologist Crossroads Systems, Inc. 512-928-7272 -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Tuesday, July 31, 2001 1:18 PM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: Iscsi: Fault tolerance Julian and all!! The server connects to the iscsi target (Say just a disk) with the help of an iSCSI initiator driver installed on the server. The NT server thus shows an extra physical disk present on the server. The sys admin then assigns the permission to other clients/users to share this target. The clients can then access this this disk (iscsi target) or any sharable directory on this disk (iscsi target)present on the server by connecting to the network. Hope it is clear by now!! If it is not then please provide me your contact number and I will try to explain you better. I am sorry if there is any ambiguity but i cant find better words to explain. Sanjeev -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, July 31, 2001 6:35 PM To: ips@ece.cmu.edu Subject: Re: Iscsi: Fault tolerance How exactly will the clients use the initiator on the server? Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" on 31-07-2001 18:57:41 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'IPS Reflector'" cc: Subject: Iscsi: Fault tolerance Hi Consider a case where the clients of a Windows NT server are accessing the iSCSI target with iSCSI initiator driver installed on the Windows NT server to access a ISCSI target on NET. So all the clients on this Windows NT server can share the iSCSI target of this server. In case the server goes down , will the clients still be able to access the iSCSI Target?? I hope I have put my question peoperly. In case not then please feel free to call me at +31 624685051 Sincerely, Sanjeev Bhagat Tripace Europe - att1.htm From owner-ips@ece.cmu.edu Tue Jul 31 18:29:08 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28328 for ; Tue, 31 Jul 2001 18:29:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VKwUE29212 for ips-outgoing; Tue, 31 Jul 2001 16:58:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VKwT329207 for ; Tue, 31 Jul 2001 16:58:29 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6VKwRT28167 for ; Tue, 31 Jul 2001 16:58:27 -0400 (EDT) content-class: urn:content-classes:message Subject: FCIP: FCIP Discovery design team MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 31 Jul 2001 16:58:26 -0400 X-Mimeole: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D453823649836040846@nc8220exchange.ral.lucent.com> Thread-Topic: FCIP Discovery design team Thread-Index: AcEZTfRwzqAkeIFJQJ69J6JtKzZzNgArD99Q 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 f6VKwT329208 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello all, Last week, it was announced that a new design team would be forming to address FCIP discovery. David and I received responses to that email from 5 people. The following group will be tasked with producing the initial draft of the discovery document: Dave Peterson, Cisco Todd Sperry, Adaptec Ravi Natarajan, Lightsand Communications Bob Snively, Brocade Venkat Rangan, Rhapsody Networks Dave Peterson will be editor of this document. Murali Rajagopal, TC for FCIP, will work with the group in the role of technical coordinator, providing assistance as needed. As per usual IETF procedures, the draft submitted by this group will be reviewed by the IPS WG, and its acceptability/suitability will be subject to IPS WG consensus call. Thanks, Elizabeth Rodriguez David Black IPS WG Co-chairs BTW: The above are the only people I received notice of interest from. If anyone else responded to the initial email, please let me know. -- Elizabeth From owner-ips@ece.cmu.edu Tue Jul 31 19:24:29 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02578 for ; Tue, 31 Jul 2001 19:24:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VLxcR02843 for ips-outgoing; Tue, 31 Jul 2001 17:59:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VLxa302837 for ; Tue, 31 Jul 2001 17:59:37 -0400 (EDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id RAA17411; Tue, 31 Jul 2001 17:57:40 -0400 (EDT) Date: Tue, 31 Jul 2001 17:57:40 -0400 (EDT) From: Scott Bradner Message-Id: <200107312157.RAA17411@newdev.harvard.edu> To: Black_David@emc.com, ips@ece.cmu.edu, sharan@ctd.hcltech.com Subject: RE: can i discuss infiniband here Sender: owner-ips@ece.cmu.edu Precedence: bulk or the new IP over infiniband working group Scott --- From owner-ips@ece.cmu.edu Tue Jul 31 20:59:47 2001 Received: from ece.cmu.edu (ECE.CMU.EDU [128.2.136.200]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10826 for ; Tue, 31 Jul 2001 20:59:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f6VNBZM06304 for ips-outgoing; Tue, 31 Jul 2001 19:11:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f6VNBN306294 for ; Tue, 31 Jul 2001 19:11:33 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 44E4B1781 for ; Tue, 31 Jul 2001 16:11:22 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay1.corp.hp.com (Postfix) with ESMTP id D47A81F50A for ; Tue, 31 Jul 2001 16:11:21 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 16:11:21 -0700 Message-ID: <499DC368E25AD411B3F100902740AD65BC5BC9@xrose03.rose.hp.com> From: "WENDT,JIM (HP-Roseville,ex1)" To: ips@ece.cmu.edu Cc: "WENDT,JIM (HP-Roseville,ex1)" Subject: TCP Framing Support in iSCSI - Proposal Date: Tue, 31 Jul 2001 16:11:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ips@ece.cmu.edu Precedence: bulk The following rough proposal for iSCSI TCP Framing Support has been generated by the Framing Team as a result of the Face-to-Face Design Teams meeting and subsequent discussions. It consists of changes to the "ULP Framing for TCP" and "iSCSI" internet-drafts as summarized below. An I-D detailing these, and other related, changes is forthcoming. Regards, Jim Wendt jim_wendt@hp.com -------- iSCSI TCP Framing Support Proposal - Summary ------ A) Proposed changes to the "ULP Framing for TCP" I-D are: 1) Modify I-D to include two framing modes: - "Marker mode" for unmodified TCP stacks - "PDU-alignment mode" for modified TCP stacks Note: An updated version of the "ULP Framing for TCP I-D" reflecting these changes has been posted (7/9/01) to TSVWG for comments (draft-ietf-tsvwg-tcp-ulp-frame-00) 2) ULP is responsible for negotiating use of a framing mode and enabling framing behavior on the TCP connection in an unambiguous manner. 3) There are "Senders" and "Receivers" on each unidirectional data flow of a framing TCP connection. The use of framing, the framing mode, and framing operational parameters values are negotiated separately for each direction of a framing TCP connection. This means that framing behavior may be in use on one direction of a TCP connection but not the reverse direction, or that different framing modes may be in use. 4) Creation of the following operational parameters and semantics: - Marker period (in Marker mode) - Receiver maximum PDU size (in Marker mode) - Framing keys (in PDU-alignment mode) - ULP packing behavior (in PDU-alignment mode) 5) ULP is responsible for negotiating use of a specific framing mode over the TCP connection, and for negotiating values for the framing operation parameters 6) Change the marker fields to be 16-bits rather than 32-bits (and refer to as "offsets" rather than "pointers") B) Proposed changes to the iSCSI spec are: 1) Remove Markers appendix from iSCSI spec (Appendix D. Synch and Steering with Fixed Interval Markers) 2) iSCSI spec adds wording to the effect of: Framing Protocol: * iSCSI initiator and target framing behavior over a TCP connection is defined in draft-ietf-tsvwg-tcp-ulp-frame-00 (or eventual RFC#) * an iSCSI initiator or target is both a sender and receiver with respect to framing behavior over a TCP connection. iSCSI Sender: * an iSCSI framing sender SHOULD implement PDU-alignment mode, as defined in * if an iSCSI framing sender does not implement PDU-alignment mode, it MUST implement Marker mode, as defined in iSCSI Receiver: * an iSCSI receiver may choose to not implement any framing mode * an iSCSI framing receiver MAY implement PDU-alignment mode, or Marker mode, or both as defined in * an iSCSI framing receiver on a TCP connection dictates use of the highest framing mode desired from the sender by progressing through the following sequence: - if the receiver requests PDU-alignment mode from the sender, and the sender supports PDU-alignment mode, then the sender MUST enable use of PDU-alignment mode on the TCP connection - else if the sender does not support PDU-alignment mode, then the receiver MAY request Marker mode from the sender. If the sender also supports Marker mode, then the sender MUST enable use of Marker mode - otherwise, the receiver has not requested use of a framing mode and the sender MUST NOT enable use of any framing mode on the TCP connection - [Note: the above rules may be moved to the Framing I-D] Interoperation: * the framing mode or modes that a receiver implementation chooses to support will determine which senders it can perform direct data placement for (since senders can choose to implemented either of the framing modes). It is anticipated that there will be receiver implementations which support the following combinations of framing modes: 1. PDU-alignment + Markers 2. PDU-alignment only 3. no framing Chunking: * Use of PDU-alignment mode requires that a dynamic chunking layer be implemented above the framing TCP layer. 3) > Still need to determine iSCSI mechanism for turning on Framing protocol Marker mode operation 4) > Still need to determine iSCSI mechanism for negotiating values for framing operational parameters 5) Perhaps there is some description of probable framing scenarios capturing the most likely combinations of the following attributes: - initiator or target - software implementation or hardware implementation - unmodified or modified TCP stack - sender AND receiver framing behaviors (no framing, or Marker mode, or PDU-Alignment mode) - values for framing operational parameters ------------------------------------------------------- The reasoning for these proposed changes is as follows: 1) iSCSI use of direct data placement and framing a) Direct data placement allows a HW-accelerated interface card to place each incoming ULP PDU (and ideally each TCP segment payload) directly into its final application buffer in end-system memory, even when the underlying TCP segments arrive out of order. The ULP PDU carries the buffer location information for doing the direct placement. This means that the TCP doesn't need to hold application data in an internal receive queue while sequence gaps are filled, nor subsequently copy that data into final application buffers. This allows the interface card to minimize or eliminate the very fast and large receive queue memory that would normally be required when running over networks with large bandwidth-delay products (10-100 Gbps, 200msec RTT). b) In order to perform direct data placement, the placement function must be able to locate ULP headers in the TCP segment stream, and extract placement information, even when TCP segments arrive out of order. A framing mechanism provides the underlying wire protocol and behaviors to enable this. c) The I-D "The Case for RDMA" (draft-csapuntz-caserdma-00.txt) discusses the benefits of direct data placement in the context of a generalized RDMA facility. 2) Merging Marker mode into "ULP Framing for TCP" I-D a) The TCP-related framing work already has mindshare in TSVWG and this work is embodied in the current framing I-D. Rather than dilute the framing effort with additional I-Ds, all framing related work should be collected into a modified version of the existing framing I-D. b) Other ULPs may also find Marker mode useful in software-only unmodified-TCP client scenarios c) The framing I-D appears to be a reasonable literary vehicle for documenting the collection of framing schemes. The I-D could be extended in the future to include a byte or word stuffing frame marker method such as COBS. d) A single framing I-D may help to encourage a single consistent interface with the ULP regardless of which framing mode is employed. e) The iSCSI spec can simply reference the one framing I-D. 3) Specifying iSCSI sender and receiver framing support a) Receivers can choose to not implement framing. Software implementations of receivers may incur extra data movements in processing framing and generally get no benefit from using framing. It is anticipated that these receiver software implementations will not support framing. b) Hardware-accelerated receivers that want to perform direct data placement and eliminate or minimize the amount of TCP reassembly memory (for links with large bandwidth-delay products) will require senders to support framing behavior. These receiver implementations are only viable if they can rely on the fact that all senders are capable of supporting some framing mode. c) Framing is done for the receiver's benefit, and is mostly a minor inconvenience for the sender. However, senders may have limitations regarding which framing mode(s) they can support. So, a sender is allowed to implement the framing mode(s) most suited to it, and the receiver is allowed to select from these supported framing modes, or choose not to utilize framing on the connection. d) There isn't one framing mode that is best for all senders: - Marker mode is best suited to software implementations that run over unmodified TCP stacks - PDU-alignment mode is best suited to hardware implementations that want to minimize or eliminate buffer memory and reduce per-packet processing complexity e) Marker mode is the best choice for a framing mechanism that can operate completely above a client TCP stack and not require any modification to that stack. - Other interval-based approaches (periodic PDU alignment, fixed length PDU) require padding and waste bandwidth - bit-stuffing and byte-stuffing schemes (COBS, etc) have a much higher processing overhead f) Marker mode supports one potentially compelling application for iSCSI involving software-only implementations on mainstream desktops and laptops operating over unmodified TCP stacks to access centralized storage arrays. These software implementations are likely to exist far into the future. Individual software-only clients may not operate at 10Gbps, but may be combined together with other clients that could aggregate to 10Gbps, thus making direct data placement compelling for a 10Gbps receiver even if the senders are only operating at 1Gbps. g) Marker mode doesn't completely eliminate the need for buffer memory on the receiver. The receiver still needs to use "eddy buffers" that temporarily hold incoming data after a dropped segment containing a ULP header up until the next ULP header is located in the packet stream, and which exist for as long as the original ULP header segment is outstanding. But Marker mode does greatly reduce the amount of memory needed as compared to a traditional TCP receiver's reassembly memory requirements (often equal to number-of-connections X round-trip-pipe-size). The Marker mode small memory requirements are dependent upon the period of the marker, and the size of the ULP PDUs being restricted to a reasonably small value. The larger that either one is, the larger the eddy buffer memory requirements. Also, an eddy buffer is required each time a ULP header is dropped, so that multiple ULP header drops in close proximity may cause multiple eddy buffers to be temporarily pending on a connection. h) PDU-alignment framing mode allows each ULP PDU to be aligned with, and sent in, a single TCP segment under normal conditions (with the added requirement that a chunking layer needs to be implemented between iSCSI and the framing TCP stack). This behavior allows each TCP segment to be fully self-describing with respect to direct placment. Thus, each incoming TCP segment payload can be processed and direct placed as it arrives with no residual state information nor eddy buffer memory required. i) PDU-alignment framing mode does require the use of a small number of "eddy buffers" when dynamic changes in the network path MTU occur and packets arrive out of order. j) The PDU-alignment framing mode is preferred. However, it may be several years before all of the different software TCP/IP implementations will be able to support framing behavior. To do this, software interfaces will need to change, and something needs to drag them there. This will take some time, so we have markers to help out in the meantime. If all receivers that can use framing can do either one, and senders that can do PDU-alignment should do so, we will have a larger set of PDU-alignment implementations that may help pull the rest of the software interfaces along with the k) It is anticipated that a receiver will not implement only Markers. The receiver implementations will probably be: 1. PDU-alignment + Markers 2. PDU-alignment only 3. no framing ----------------------------------------------------------- Open Issues: 1) Interoperability between sender and receiver - Given that both senders and receivers have a choice in which framing mode(s) they implement, there is the potential for the sender to implement one framing mode and the receiver to implement a different framing mode (e.g. the sender implements only Marker mode, and the receiver implements only PDU-alignment mode). - In this situation, the receiver and sender would not enable framing on the TCP connection, and the receiver would not be able to perform direct data placement. Throughput from sender to receiver would likely be greatly reduced should any TCP segment drops occur. 2) None of the current framing schemes take TCP data integrity into account. It either needs to be decided: a) how to detect when a data integrity problem occurs within a framing header, and what to do about it (even if it just kills the TCP connection), b) or that a sufficient level of data integrity needs to be provided for all protocols running over TCP via a more holistic approach. 3) Acceptability of the PDU-Alignment framing mode's reliance on "key+length" matching across resegmenting middleboxes - In PDU-Alignment mode each TCP segment payload contains one complete framing PDU (consisting of an 8 byte framing header followed by one or more complete ULP PDUs). Thus, every TCP segment has the TCP header followed immediately by the framing header. - In certain cases a single framing PDU must be broken across multiple TCP segments (such as dynamic Path MTU reductions), resulting in TCP segments where a framing header doesn't immediately follow the TCP header. - The framing I-D defines sender behaviors that allow PDU-alignment mode to function deterministically and correctly in all cases where the TCP segmentation flowing from sender to receiver is not altered. - If the TCP segmentation from sender to receiver is altered by an intermediary (resegmenting middlebox), and a framing-header-containing segment drop or reordering has occurred such that the receiver is attempting to locate the next framing header in the segment stream, then the receiver must examine the first 8 bytes of each incoming TCP segment payload for a valid framing header containing valid Key(6B) and Length(2B) fields. - A false-positive occurs if, upon resegmentation by a middlebox, the receiver gets a TCP segment in which the first 8 bytes of the payload indicate a valid framing header (the first 6 bytes match the previously exchanged random key value, and the next 2 bytes contain a valid length), yet the TCP segment payload isn't actually a framing header. - While it is felt that the probability of a false-positive in these resegmenting-middlebox scenarios will be sufficiently low, further analysis work may be may be required in this area. - Note that this mechanism is NOT a scanning technique for locating start-of-frame across an arbitrary byte stream. It only provides an indication of PDU alignment or not. The first 8 bytes of the TCP segment payload are examined to determine if the segment contains the start of a ULP PDU. 4) Do Markers work at 10Gbps? - The feasibility of markers at 10Gbps has been questioned. It would be beneficial to hear specifics regarding why Markers won't work at 10Gbps. Markers don't allow for a no-memory direct data placement NIC since eddy-buffers are required. So, support for clients with unmodified TCP stacks comes at a cost, which is the cost of supporting eddy buffers on the NIC. - One question is whether the eddy buffers can be contained entirely in the ASIC or need to be in off-chip memory. ----------------------------------------------------------