RE: iSCSI: SendTargets in login or FFP?

["Robert D. Russell" <rdr@mars.iol.unh.edu>]

Matthew:

Interesting -- in draft 0.6 the label was IO, but it has been
changed to LO in draft 0.7.  However, other parts of draft 0.7 still
clearly indicate this is a per-connection parameter.  See for example,
the description in Appendix C page 155 which says in the 3rd paragraph:

"The use of markers is negotiable.  The initiator and target MAY
indicate their readiness to receive and/or send markers during login
separately for each connection."

Furthermore, the definition of keys 19 (FMarker), 20 (RFMarkInt),
21 (SFMarkInt) all contain the explicit statement:

"This is a connection specific parameter."

Therefore, I would conclude that the change of IO in version 0.6 to
LO in version 0.7 is a typo, and should revert back to IO for these
3 keys.

Julian, is this correct?

Thanks,

Bob


On Fri, 3 Aug 2001, BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) wrote:

> Hi Robert,
> 
> In your attachment, you have stated that FMarker (and its dependencies) are
> per connection.  I believe this was the case in 0.6 but in 0.7 it is now on
> the LO connection and therefore is it not per session or am I missing
> something here?
> 
> Cheers
> 
> Matthew Burbridge
> Senior Development Engineer
> NIS-Bristol
> Hewlett Packard
> Telnet: 312 7010
> E-mail: matthewb@bri.hp.com
>  
> 
> -----Original Message-----
> From: Robert D. Russell [mailto:rdr@mars.iol.unh.edu]
> Sent: Thursday, August 02, 2001 6:49 PM
> To: Julian Satran
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI: SendTargets in login or FFP?
> 
> 
> Julian:
> 
> In order to try to organize information about the key parameters,
> I developed the attached ASCII text file which characterizes each
> key from draft 7 according to 4 attributes:
> 
> 1.  what type of key it is, which determines in which login phase
>     it can be used.
> 2.  when the key can be negotiated.
> 3.  who can send the key.
> 4.  the scope of application of the key's information.
> 
> The values of these attributes were drawn from Appendixes A and D.
> The only new information added (i.e., information not in draft 7)
> is the characterization of keys into 3 types - security, operational,
> and informational, where the new category "informational"
> applies to keys, such as TargetAddress, TargetName, InitiatorName,
> etc. which can be sent in either the security or operational
> subphases of login, and which simply provide information rather
> than negotiate values.
> 
> There is still a question with regard to the SendTargets key
> -- many of the recent postings regarding the use of SendTargets for
> discovery sessions indicates that people expect this key to be used
> only in Full Feature Phase.  Quoting from Mark Bakke's e-mail of
> 24-July:
> 
> > "Anyway, SendTargets is always done in full feature phase, and
> > never during the login phase."
> 
> and later in the same message:
> 
> > 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.
> 
> Is this limitation correct?  Or does this limitation apply only for
> discovery sessions?
> 
> The draft currently characterizes SendTargets as ALL, which
> does not imply this limitation.
> 
> If SendTargets is so limited, it would be the only key that could not
> be used somewhere during login.  To cover this case in the attached table
> I have added the category FFP to the 3 existing categories IO, LO,
> and ALL.  Draft 7 would have to be modified to reflect this.
> 
> If this limitation is not correct, the category FPP
> disappears and the ALL category would continue to apply to SendTargets
> (and targest can expect to receive SendTargets during login).
> 
> Thanks,
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
> 
> 
> 
> On Tue, 24 Jul 2001, Julian Satran wrote:
> 
> > 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" <EQuicksall@mediaone.net> on 24-07-2001 04:15:56
> > 
> > Please respond to "Eddy Quicksall" <EQuicksall@mediaone.net>
> > 
> > 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
> > 
> > 
> > 
> > 
>