RE: iSCSI: ISIDs

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

I guess I screwed up what I wanted to say in my previous
posting. I was trying to compare ISID assignment problem
with "session management" with regard to the need for an
independent, OS level management entity. We need an in-kernel
"session manager" to manage sessions spanning interfaces/adapters.
And why can not a similar manager (call it "isid manager")
exist if an interface/adapter is to share Initiator name ?

I understand that not all operating systems would ship
with these OS level "resource managers" in the nearest
possible future - what this means is that you can not
share Initiator Name if no such "isid manager" exists
at the OS level. Isn't the same true for "session manager" ?

-JP 


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