Re: iSCSI: ISIDs

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

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