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

["Douglas Otis" <dotis@sanlight.net>]

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

> 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)"
> <marjorie_krueger@hp.com>@ece.cmu.edu
> on 05/04/2001 05:39:35 PM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   "'Matt Wakeley'" <matt_wakeley@agilent.com>, ips@ece.cmu.edu
> 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
>
>
>
>