|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Rev 11 minor issuesJulian,
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!
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, March 20, 2002 9:08 AM To: Michael Schoberg Cc: IPS Reflector (E-mail); owner-ips@ece.cmu.edu Subject: Re: iSCSI: Rev 11 minor issues
Home Last updated: Wed Mar 20 20:18:14 2002 9223 messages in chronological order |