Subject: RE: iSCSI: multiple sessions b/n a pair of WWUIs.

From: "Jim Hafner" <[email-masked]>
Date: Mon, 7 May 2001 19:44:25 -0700

Marj,

I think you've stretched my words too far.  The requirement is for a single
logical unit to recover enough identity information provided through the
I_T_L nexus to reestablish the reservation.  That means that the name+ISID
must be unique *from the viewpoint of a single iSCSI target device*.  So
it's more like the
"initiator must have unique ISID for all sessions with <delete>all
targets</delete> any given target device".

The best way to think about this is the following:
1) only a single target's (actually logical unit's) view of the initiator
counts in this regard
2) there are no rules in SCSI concerning multi-target device interactions
In other words, for these rules, look only from inside a target going out.

Jim Hafner

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>@ece.cmu.edu
on 05/04/2001 05:39:35 PM

Sent by:  [email-masked]

To:   "'Matt Wakeley'" <[email-masked]>, [email-masked]
cc:
Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.

> One clarification: these are unique between any I-T *pair*.
> (you make it sound like an initiator must have a unique ISID
> for all sessions
> with all targets)
>
> -Matt

The ISID must be unique within the iSCSI layer on an iSCSI device - that
amounts to "initiator must have unique ISID for all sessions with all
targets".

To quote Jim "The requirement in name+disc that a given initiator name
cannot reuse an ISID for two different sessions comes as a consequence a
number of things (which are described in the draft).  The gist is that this
is needed to provide the correct context for restoration of reservations
state (and other nexus state) to a particular nexus after logout/login. In
other words, if the session goes down for some reason, the target needs
clear context to restore nexus state to a rebuilt session. The only tool it
has is uniqueness of Name+ISID combination within its name space."

-Marj

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 8 May 2001 10:21:23 -0700

Jim,

It does seem reasonable to expect the Initiator to maintain a database of
ISIDs within its own domain that may cross-reference to Targets on which it
holds reservations.  This cross-reference will likely map into OS dependent
views as well.  A simple means to ensure ISID is unique for any Target is to
ensure an Initiator ISID is unique for all Targets.  It would become a
tangled mess to allow replicate ISIDs for different Targets as now a
database must sort on ISID+Target Label.  There is no assurance that TSID
will be reissued from what I can tell.  It seems rather messy to change the
sort from ISID, to ISID+Target Label.  Do you see this added restriction of
ALL instead of ANY as a limitation?  I can see how in practice this prevents
many problems and is a good rule if not a guideline.

Doug