RE: iSCSI: ISIDs

["Rod Harrison" <rod.harrison@windriver.com>]

	I don't see how having the target assign the ISID, and effectively
the whole SSID helps with the original problem of recovery from an
uncontrolled restart. In fact, I think it makes it worse.

	Without and initiator assigned ISID the target is presented with no
information with which to distinguish HBAs in a host. Assuming that
HBA 1 has an existing session, how can the target tell the difference
between HBA 2 sending a leading login with the intent of starting a
new session, and HBA 1 sending a leading login after an uncontrolled
restart?

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Black_David@emc.com
Sent: Thursday, September 06, 2001 10:40 PM
To: ips@ece.cmu.edu
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
---------------------------------------------------