RE: iSCSI: ISIDs

["Jim Hafner" <hafner@almaden.ibm.com>]

David,

OK, I see where you're going.  The SCSI Initiator Port is created by the
initiator side and has an identity defined internal to that implementation
(say, the pointer to the session structure).  What the target's device
server uses is the 'identifier' the iSCSI layer assigns to that SCSI
Initiator Port, namely the <initiator Name, TSID>.

Let's see where this goes.
First, it means we don't really have "name" (as defined by SCSI/SAM) for
the SCSI initiator Port, but we do have well-defined "port identifier" (the
device server's identifier mentioned above).  I read SAM as saying that the
name is an intrinsic property of the SCSI Initiator Port.  So, we don't
have a name because haven't associated an intrinsic property.

Now, SCSI has two notions, port identifier (think FC S_ID, as an address)
and port name (think FC WWportname).  The current wording of SCSI says that
it's the port identifier that is the thing that identifies the owner of a
reservation (e.g.) [in the context of a given SCSI target port].  There's
extra language to deal with the identifier for a given named port changing
by events in the service delivery subsystem (think FC network
reconfiguration).    Proposed new text would make this more clear.  The
named port would own the reservation independent of identifier, *provided*
a name was available for the initiator port.

So, where we're going here is that for iSCSI, there would be no name for
the SCSI initiator port, just the identifier (as assigned by the target).
So long as the target was happy with the association of that identifier
with the SCSI initiator port (that it didn't think the identifier somehow
moved to a different actual SCSI initiator port), then recovery of state
would be as you suggest -- the initiator just re-establishes the session by
requesting the SSID=TSID.

It's an open question that if the session collapses or even is politely
logged out, whether the TSID identifier and all the resources associated
with it are cleared or not.  I would guess not, but I'm not sure.  Also,
there's cleanup issues on TSID (when does the target decide it can recycle
a TSID?  when there are no persistent state to track for it?).

So far so good, I think.

Now comes a slight kicker!  There is proposed language for SCSI that would
allow a device server to associate a reservation with a SCSI initiator port
*independent of the SCSI target port*, so I could have a path from one SCSI
Initiator port through each SCSI target port and the reservation state
would be equivalent over all the paths (sort of I_*_L nexus).  This new
language is based on one fundamental principle, that is, that the SCSI
initiator port has a world wide unique persistent intrinsic NAME on which
to base the unambiguous recognition of that SCSI Initiator Port independent
of the target port.  In other words, with a name, the device server can
recognize the same initiator port through any of its target ports and so
grant equivalent access rights.   Remove the name from iSCSI's SCSI
Initiator Port (which you are effectively doing no matter how you look at
it), and you can not take advantage of this proposal's new functionality.

This is the kind of functionality that many people not intimate with SCSI
assumed was already there (and in fact there were assumptions that
reservations went so far as to span initiator ports).   Unfortunately,
that's not the model in SCSI. This pending proposal is an attempt to get to
that functionality defined within the parameters defined by SAM-2.

Note that with the initiator generated ISID as part of the SCSI Initiator
Port Name (it's intrinsic), we had the ability to reuse that same ISID for
each target portal group (without problem) and get this equivalent
reservation state across all those target portal groups (aka, SCSI Target
Ports).

I don't know if that is too much of a monkey wrench in the works, but it
bothers me some.

Jim Hafner


Black_David@emc.com on 09/07/2001 03:41:43 pm

To:   Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI: ISIDs



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