RE: iSCSI: ISIDs

[Black_David@emc.com]

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