Re: iSCSI: Rev 11 minor issues

[Santosh Rao <santoshr@cup.hp.com>]

Michael,

I don't believe the individual connections that comprise a session can
use different iscsi initiator names. The initiator name is intended to
be the node name of that initiator. A session cannot span multiple
nodes.

Also, there is a one to one correspondence b/n an I-T nexus and an iscsi
session. Hence, the following does'nt seem quite right to me :

> Each login requires the InitiatorName because although 
> it may be an additional connection to an existing session, 
> it may not be for the same I_T nexus.

and, since a session can't involve multiple initiator names, this
does'nt seem right either :

> -------------------------------------------------------------------------
>  InitiatorName      ISID     CID  TSID TgtName Session I_T Nexus
> a1 Fred          010203040506  0000 0001 idisk *   #1     it-1
> a2 Bob           010203040506  0001 0001 idisk     #1     it-2
> a3 Joe           010203040506  0002 0001 idisk     #1     it-3
> a4 Fred          010203040506  0003 0001 idisk     #1     it-1


In the above example, if Fred, Bob & Joe belong to a single node, then,
they need to use a single iscsi initiator name, and only then, can they
share a session.

Thanks,
Santosh





Julian,
 
Thanks for the follow-up.  Forgive me for being slow with this, but I'm
still confused by your statement.  Let me walk
you through some of my thoughts.
 
An initiator is defined to be an "initiator node".  It's identification
is through the initiator port name, which
includes the InitiatorName, ISID, etc.  Each login requires the
InitiatorName because although it may be an additional
connection to an existing session, it may not be for the same I_T nexus.
 
Initiators are added to a session like this:
 
-------------------------------------------------------------------------
   InitiatorName      ISID     CID  TSID TgtName Session I_T Nexus
a1 Fred          010203040506  0000 0001 idisk *   #1     it-1
a2 Bob           010203040506  0001 0001 idisk     #1     it-2
a3 Joe           010203040506  0002 0001 idisk     #1     it-3
a4 Fred          010203040506  0003 0001 idisk     #1     it-1
a5 Ted           010203040506  0000 0001 idisk *   #2     it-4
a6 Fred          010203040506  0000 0001 idisk *   ??
a7 Ted           010203040506  0004 0001 idisk     ??
a8 Ted           010203040506  0001 0001 idisk     ??
 
* Leading login TSID=0000 was sent by initiator, TSID value assigned by
target.
-------------------------------------------------------------------------
 
Within any single session there will be one or more I_T nexus formed
(see a1, a2, a3, a4).
 
           ISID RULE: Between a given iSCSI Initiator and iSCSI Target
Portal 
           Group (SCSI target port), there can be only one session with
a given 
           value for ISID that identifies the SCSI initiator port. See
Section 
           9.12.5 ISID.

My interpretation: any initiator's attempt to reuse the same ISID for
creating an additional session (TSID = 0000) with
the same target-portal-group breaks the ISID rule; initiators must
provide different ISID values to create new sessions
with the same target-portal-group (see a6, breaks ISID rule).  However,
since the "initiator port identifier" includes
InitiatorName, alternate initiators may simultaneously use the same ISID
value (see a5, does not break ISID rule).
 
           TSID RULE: The iSCSI Target SHOULD NOT select a TSID for a
given login 
           request if the resulting SSID is already in use by an
existing session 
           between the target and the requesting iSCSI Initiator. See
Section 
           8.1.1 Conservative Reuse of ISIDs.
 
My interpretation: a target should expect (and accept) initiator
attempts to login with the same ISID and can select the
same TSID as long it's from a different initiator (see a5).  However, if
an existing initiator is identified, then the
target should select a TSID that forms a unique SSID (see b4).  This is
confusing because it assumes that the initiator
will break the ISID rule?  Also, does this break session reinstatement?
 
-------------------------------------------------------------------------
   InitiatorName        ISID      CID    TSID    TargetName  Session
b1 Fred            010203040506   0000   0001    idisk *       #1
b2 Bob             010203040506   0000   0001    idisk *       #2
b3 Joe             010203040506   0000   0001    idisk *       #3
b4 Fred            010203040506   0000   0002    idisk *       #4
 
* Leading login TSID=0000 was sent by initiator, TSID value assigned by
target.
-------------------------------------------------------------------------
 
How does this work with 4.3.5 Session Reinstatement:

           Session reinstatement is the process of initiator logging in
with an 
           ISID that is possibly active from the target's perspective -
thus 
           implicitly logging out the session state machine
corresponding to the 
           ISID and reinstating a new iSCSI session in its place (with
the same 
           ISID).  Thus, the TSID in the Login PDU MUST be zero to
signal session 
           reinstatement.  All the tasks that were active on the old
session are 
           internally terminated on a session reinstatement.
 
           The initiator session state MUST be FAILED (Section 5.3
Session State 
           Diagrams) for attempting a session reinstatement.
 
My interpretation (#1 of 2): Session reinstatement only occurs when the
target has identified and authenticated that an
existing initiator (identified by InitiatorName & ISID) has performed a
second leading login.  Then and only then can
session reinstatement be performed.  Unfortunately, this assumes that
sessions will always have the same initiator
performing the leading login (so in a1->a4, only Fred can perform
session reinstatement for that session.)  That's bad
news if that particular initiator is no longer active.
 
(#2 of 2):  ANY leading login received by the iSCSI target with an
existing and target-perspective active ISID is assumed
to be session reinstatement.  This means that the logins described by [
a5 & b1..b4 ] are invalid.  Further, this
conflicts with your note saying that the initiator must be completely
identified on every login.
 
Now look at connection reinstatement (4.3.4)

           Connection reinstatement is the process of initiator logging
in with a 
           ISID-TSID-CID combination that is possibly active from the
target's 
           perspective - thus implicitly logging out the connection
state 
           machine corresponding to the CID and reinstating a new
full-feature 
           phase iSCSI connection in its place (with the same CID). 
Thus, the 
           TSID in the Login PDU MUST be non-zero and CID does not
change during 
           a connection reinstatement.  The Login command  performs the
logout 
           function of the old connection if an explicit logout was not
performed 
           earlier. In sessions with a single connection, this may imply
the 
           opening of a second connection with the sole purpose of
cleaning up 
           the first. Targets should support opening a second connection
even 
           when they do not support multiple connections in full feature
phase.  
 
           If the operational ErrorRecoveryLevel is 2, connection
reinstatement 
           enables future task reassignment.  If the operational
ErrorRecovery-
           Level is less than 2, connection reinstatement is the
replacement of 
           the old CID without enabling task reassignment.  In this
case, all the 
           tasks that were active on the old CID are internally
terminated.
 
           The initiator connection state MUST be CLEANUP_WAIT (section
5.1) for 
           attempting a connection reinstatement. 
 
If an iSCSI connection is attempted in which multiple initiator-sessions
are available with the same ISID + TSID, to
which session should the iSCSI target attach it?  In [a7] above, there
are two active sessions with the same SSID, to
which should a7 be attached?  Another special case [a8] will result in
either a new connection on session #2 or
connection reinstatement (or possible conflict) with session #1.
 
Thanks for your time on this!
 
-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################