RE: iSCSI: ISIDs

[Black_David@emc.com]

Jim,

> 1) I think there's some confusion on what Michael's suggestion really is.
> Some seem to think that the idea *replace* the SSID=ISID||TSID with just a
> 32bit TSID (so there is no ISID component at all).  The other is that the
> target provides SSID but it is still viewed as two components (and each
> component has some role to play).
> Can we get this clarified?  I was under the assumption that it's the first
> option here.
> 
> Your note about 32bit TSID of which part of the name was the portal group
> tag made me think that you're in the first camp.   But your comment below
> about <InitiatorName,ISID> makes me think you're in the second camp.

I'm in the first camp.  The "<InitiatorName,ISID>" text was meant
to refer to the current situation in which that pair is the
visible identity of the SCSI Initiator Port.

> 2) I don't understand your comment below:
>   > Do we actually need an externally visible identifier for the SCSI
>   >Initiator Port?  There's clearly a session endpoint on the Initiator
>   >side that corresponds to the <iSCSI Initiator Name, ISID>, and the
>   >implementation is clearly able to identify it internally to keep its
>   >sessions straight, and this identification will be (at least
implicitly)
>   >visible through a management interface that looks at all the open
sessions
>   >on a host or device.  In essence, I'm suggesting keeping the current
>   >mapping, but allowing part of the endpoint identifier to not be
>   >visible in the protocol.

> Where is the ISID coming from (see the question above)?  What part of the
> endpoint identifier is NOT visible?

The ISID goes away, and what replaces it could be the TSID
(which you have problems with) or something internal to
the Initiator implementation ...

> There are lots of ways for an implementation to identify internally it's
> sessions, and need  not at all rely on any part of the SSID (e.g., my
> connection structure contains a pointer to an open socket and a pointer
> to a session structure, so any message on that socket must be related to
> that session).   The point being that my implementation doesn't have to
> care at all about SSID.

Yes, use something like that as the identifier for the session endpoint
that gets mapped to the iSCSI Initiator Port.

> Nobody has really asked for an 'externally visible identifier' for the
SCSI
> Initiator Port (at least I don't think I have directly).  What I'm looking
> for is the thing the SCSI device server (implicitly) uses to identify the
> "I" in the I_T nexus.

Good, that was the answer I was hoping for.

> Up till now, SCSI/SAM has had a static hardware
> identifier for that thing (parallel bus address, the FC nodename, etc.)
> because there was a hardware component on which to bind the SCSI Initiator
> Port.  So, that name/identifier was an inherent component of the SCSI
> Initiator Port implementation that was propogated *from the intiator side
> to the target side* in protocol specific ways.  My model(c) and what I
> think you're suggesting says that we're allowing the iSCSI target to pass
> to the iSCSI initiator the 'name' that the constructed SCSI Initiator Port
> will/shall/must use.    So, the naming authority is not on the initiator
> side and the name doesn't flow from the initiator to the target, but is
> reversed in both cases.

Actually I'm suggesting something different.  The Initiator implementation
knows that it wants to create a session to the Target, and has a notion
of that session when it sends the Login - this is well before
the target has assigned a TSID.  In essence, that internal notion of
session is an implicit naming authority that avoids the concern about
the iSCSI Initiator Port obtaining its identity from the Target - in
essence the iSCSI Initiator Port has to exist in order to send the Login
to the Target, and hence has a notion of identity independent of the
Target to which it wants to connect because the iSCSI Initiator Port
exists prior to establishment of that connection or assignment of
the TSID to the session.

[... Rest snipped, as I departed from your assumptions in the above
 paragraph ...]

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
---------------------------------------------------