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?
Don't
know how you got so confused, so I'm not sure what will untangle you.
The target doesn't "expect" anything regarding ISID, it merely used ISID to
enforce "no parallel nexus between port pairs" rule. The TSID rule just
says that the TSID provides the "unique SSID" between an initiator and target
node, since initiator are to treat ISID's as "static port numbers".
It doesn't "assume the initiator will break the ISID rule", it
just assists the target in detecting initiator
errors.
-------------------------------------------------------------------------
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.
-------------------------------------------------------------------------
Where's
TPG? If these are all sessions to the same TPG, then "b4" would be
rejected by the target as a leading login, cause he already has an active
session with this initiator port (session
#1)
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.
If the
initiator's no longer active, then it can't be performing session
reinstatement
(??)
(#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.
