RE: iSCSI: ISIDs

["Julian Satran" <Julian_Satran@il.ibm.com>]

There is no logical difference between the current split allocation scheme
and having only the target allocate it
(a port could be associated with anything) and the initiator could remember
a SSID as well as a ISID.

The major difference is "control". In the current scheme the initiator and
target could independently allocate and reuse their parts.

The target allocates only scheme leaves this to the target (it has to do
garbage collection) under the assumption that the target (unlike the
initiator) has a central point of control.

Aren't targets going to have several HBA and have to carefully allocate
their SSIDs?

In the event an initiator wants to rebuild a session does he have to
connect to the same HBA and thus a failover to another HBA can't be done.

For all the above no to happen we have to add some management somewhere and
it looks to me that the current scheme is simpler than a target centric one
as it keeps the allocation and release of numbers at the same end.

Julo

Black_David@emc.com@ece.cmu.edu on 07-09-2001 20:48:22

Please respond to Black_David@emc.com

Sent by:  owner-ips@ece.cmu.edu


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