RE: iSCSI: ISIDs

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

David,

Two points.

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.

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 visibile?  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.

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

It's not "my name is Bob!", it's "who do you want *me* to be today?" (to
paraphrase Oingo-Boingo).

So, what I said was that this 'might work' but I think it stretches the SAM
model in ways that haven't been explored yet.
A property of the just defined (by T10) SCSI Port Name is that it is (a)
world wide unique (within the protocol) AND (b) that it is persistent.  So,
if two different iSCSI targets choose the same TSID=SSID for their sessions
with a given iSCSI initiator, they have both 'implicitly' connected to the
same 'I' in the I_T1, I_T2 nexus.  Does that make sense?

Also, it means that for all possible TSID=SSIDs there is an implicit
(sleeping) SCSI Initiator Port waiting to be awoken.  That's also true in
the current model with ISID generated by the initiator, however, the
difference is that the initiator wakes up the sleeping SCSI Port by first
use of the ISID value in the login.  In this new approach, the port isn't
woken up until the target sends back the TSID (in effect, the TSID in the
response can be viewed as a 'request to wake up that partial SCSI Initiator
Port').

As I said, it might work, but it certainly has odd implications.  I'm more
comfortable with the current model (and I think all the ISID partitioning
issues are just a matter of convention), however, I don't have (as I said)
a strong argument against the new one.  It just "feels funny".


Jim Hafner


Black_David@emc.com on 09/07/2001 10:48:22 am

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



> We have (so far) relied on the ISID (along with the iSCSI Name) for the
> SCSI Initiator Port name (and identifier) and relied on the "iSCSI
> initiator endpoint of the session" for the SCSI Initiator Port.  The ISID
> RULE (no reuse of ISID to a given target portal group -- and whose
> enforcement rule we've been debating) was intended to prevent parallel
> nexus from being created.
>
> If we abandon any notion of the initiator providing the ISID then we've
> somehow lost our handle on what constitutes the SCSI
> Initiator Port.

Let me take a whack at preserving something approximating the existing
situation.  Starting from your option c):

> c) use the model we now use (SCSI Initiator Port = initiator end of
> session) but find something other than the ISID to define the SCSI Port
> Name.  The only choice seems to be the SSID (=TSID).  This might work
more
> or less as David outlined.  It's a little odd, however, that the target
is
> now *assigning* an identifier/name to the SCSI Initiator Port; that is,
the
> SCSI Initiator Port doesn't have a name 'all to itself', but only in the
> context of a target.

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.

--David

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Friday, September 07, 2001 11:47 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: ISIDs
>
>
>
> David,
>
> I've been mulling over your question concerning how Michael's proposal
> (which I read as removing the ISID from the SSID and leaving
> it up to the
> target to assign the SSID) affects the SAM-2 mapping.  I
> don't have a good
> answer.  So, I'm going to brain dump here.
>
> We have (so far) relied on the ISID (along with the iSCSI
> Name) for the
> SCSI Initiator Port name (and identifier) and relied on the "iSCSI
> initiator endpoint of the session" for the SCSI Initiator
> Port.  The ISID
> RULE (no reuse of ISID to a given target portal group -- and whose
> enforcement rule we've been debating) was intended to prevent parallel
> nexus from being created.
>
> If we abandon any notion of the initiator providing the ISID
> then we've
> somehow lost our handle on what constitutes the SCSI
> Initiator Port.  We
> effectively have to go back to square one to sort out the
> initiator side of
> the model mapping.  I think we all pretty much agree that the
> iSCSI Node
> and the SCSI Device are intimately bound together.  Our
> choice for SCSI
> Initiator Port come down to three
> possibilities (as they always have):
>
> a) view all iSCSI-type SCSI Initiator Devices as being single (SCSI)
> -ported.  Then the SCSI Initiator Port can be identified by
> the iSCSI Name.
> There are similarities between this and a single ported FC HBA.  Our
> problem is then the parallel nexus issue.  We need a rule
> that says that we
> can't have more than one session between a given iSCSI
> Initiator and iSCSI
> Target Portal Group; and we need to define the target's response to a
> second such login.  In effect, we've doubled our problems.
> We have limited
> our connectivity possibilities between a given iSCSI Initiator (max
> sessions = number of target portal groups) and we still have
> a 'rejection'
> rule to decide (option A or option B).
>
> b) use the model we have for the target; namely, map the
> iSCSI Initiator
> Portal Group to a SCSI Initiator Port.  With this, we get a
> SCSI Initiator
> Port name equal to the iSCSI Name + portal group tag. So far
> so good.  But
> we are limited to one session per (initiator portal group,
> target portal
> group tag).  This has similarities to a multi-HBA FC host.
> We again limit
> (to a lesser extent) our
> connectivity possibilities: max sessions = (number of initiator portal
> groups x number of target port groups).   [In spite of the
> simplicity of
> this model which is independent of session identifiers, I
> didn't pick this
> because people felt that there was a legitimate reason to
> build multiple
> sessions between two portal groups (e.g., in the case where
> both initiator
> and target have only one HBA (so one portal group) and the
> target doesn't
> support more than one connection per session, I may want to
> build multiple
> sessions for extra parallelism, etc.).]
>
> c) use the model we now use (SCSI Initiator Port = initiator end of
> session) but find something other than the ISID to define the
> SCSI Port
> Name.  The only choice seems to be the SSID (=TSID).  This
> might work more
> or less as David outlined.  It's a little odd, however, that
> the target is
> now *assigning* an identifier/name to the SCSI Initiator
> Port; that is, the
> SCSI Initiator Port doesn't have a name 'all to itself', but
> only in the
> context of a target.  The mind sort of boggles with this (and
> it certain
> stretches the credibility of the SAM-2 model of SCSI
> Initiator Port, Port
> Name and Port Identifier). We could instead pick for the SCSI
> Initiator
> Port Name/identifier the
> union of the ipaddresses:tcpports of all the connections
> involved in that
> session, but I don't think that really gains us anything.
>
> In short, I don't know what approach to take here.
>
> We are effectively being constrained by SAM-2's model.  We've already
> stretched that model a lot by what's currently in the draft.
> Summarizing
> above, we can either limit our functionality (fewer sessions)
> or stretch
> the model further by having the target assign names to SCSI Initiator
> Ports.
>
> It's not a good place to be.
>
> Jim Hafner
>
>
> Black_David@emc.com@ece.cmu.edu on 09/06/2001 02:40:19 pm
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: ISIDs
>
>
>
> Time to back up and regroup on this topic.  It's clear that ISID
> management needs more attention, and hence there are some issues
> more basic than the attempted consensus call to work out.  So,
> I'm going to abandon the attempted consensus call, and try to
> make progress on the underlying ISID issue.  Those whose posts
> have called ISID management into question should not feel it
> necessary to apologize - this is an important issue to unscramble.
>
> A rough summary of where we find ourselves is:
> - iSCSI Initiator Names span network interfaces/adapters,
>      as do iSCSI Target Names.
> - Multiple sessions are allowed between an iSCSI Initiator
>      and Target.  These are identified by an ISID and a
>      TSID.
> - The ISID is the Initiator portion of the Session identifier
>      and is used to track certain resources associated with
>      the session (e.g., persistent reserves).
> - The TSID is the Target portion of the Session identifier,
>      and serves primarily to make sure that all session
>      identifiers (SSID = ISID||TSID) are unique at the
>      Target.
>
> Michael Schoberg suggest getting rid of the ISID:
>
> > ISID - initiator-defined session-identifier
> >
> > Since initiators don't know about other initiators connected to this
> target,
> > this has the potential of causing problems.  Eliminate it.
> The initiator
> > should simply state it's intentions of establishing a new session or
> adding
> > a connection to an existing session (via binary flags).
>
> The implication of this would be to make SSID = TSID, dynamically
> assigned by the Target (0 is a reserved value on Login asking Target
> to do this assignment), and partitioned appropriately across
> interfaces.
> Recoverable session resources would be associated with the combination
> of <iSCSI Initiator Name, TSID> at the iSCSI Target, and the initiator
> tracks via <iSCSI Target Name, TSID> - in both cases the TSID replaces
> the ISID.  From a functional standpoint, this looks like it works,
> and has the nice additional property that session resources can be
> recovered through any iSCSI Initiator interface vs. having to go back
> to the one that's allowed to use the ISID for that session if ISIDs
> are statically partitioned.
>
> Does this cause any problems for the SAM-2 to iSCSI mapping?
>
> 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
> ---------------------------------------------------
>
>
>
>
>