RE: iSCSI: ISIDs

[Black_David@emc.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".

That's not exactly true.  There are two sorts of coordination that
can be necessary if an Initiator Name spans interfaces/adapters:

(1) Task Tags, Sequence Numbers, ExpStatSN, etc. WHEN an individual
	session spans interfaces/adapters.  The set of spannable
	interfaces/adapters is called a "portal group".
(2) ISID assignment to different sessions in the same or different
	portal groups.

> How is ISID assignment a unique problem
> compared to the rest of various shared session level parameters ?

Because ISID assignment is a separate problem.  One still has to
coordinate ISID assignment across interfaces/adapters even if
*every* session has exactly one connection and hence can't span
interfaces/adapters.

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

Right, but if every interface is its own portal group underneath
the same Initiator Name (i.e., sessions don't span interfaces,
but the iSCSI Initiator does), ISID assignment still has to be
coordinated across interfaces/adapters even though there's no
"session manager" needed across interfaces/adapters.

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


> -----Original Message-----
> From: JP Raghavendra Rao [mailto:Jp.Raghavendra@sun.com]
> Sent: Friday, September 07, 2001 10:32 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: ISIDs
> 
> 
> 
> 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
> > ---------------------------------------------------
> 
>