RE: iSCSI: ISIDs

[Black_David@emc.com]

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

No - if one is prepared to treat every interface/adapter
as a separate portal group (i.e., an individual session uses
only one interface/adapter), one can share the Initiator
Name without the need for a "session manager", but the
"isid manager" would still be needed to manage ISIDs across
the interfaces/adapters.

Thanks,
--David

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