Re: iSCSI: ISIDs

[JP Raghavendra Rao <Jp.Raghavendra@sun.com>]

If an interface/adapter is sharing Initiator Name with other
interfaces/adapters, iSCSI *REQUIRES* that there be a higher
level "session manager" (in the OS) to manage various things
like Task Tags, Sequence numbers, Exp StatSN, etc. And I don't
understand why ISID assignment can not be managed by the
same "session manager". How is ISID assignment a unique problem
compared to the rest of various shared session level parameters ?

If an interface has a unique Initiator Name, it can assign
an ISID of its own.

-JP

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