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

["Jim Hafner" <hafner@almaden.ibm.com>]

Santosh,

There may be lack of synchronization between the two drafts (not unexpected
since they are being worked on in parallel).

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.

There was a similar requirement in draft...05.txt in 2.11.5 (though that
was ambiguous about whether ISIDs are unique within a target across all
initiator names or just with respect to a given initiator name).
Apparently that requirement is now gone from draft...06.txt!

The requirement forces carving up ISID namespaces between iSCSI adapters
(session managers) in a given node.  They each get their name and a piece
of the ISID space from configuration information.  You mentioned this
yourself in a related reply in this thread to Hari.

So, we get multiple sessions between nodes (named things), single sessions
between ports (one per ISID+TSID pair) and a framework for restoring
necessary nexus state (uniqueness of Name+ISID at the target -- no reuse of
ISID).   (I think Julo's comment is that he has had time to keep up with
the formalization done in N&DT within the last week.)

I think/hope this has everything needed.

[But I have to admit, this is sort of a hack to get the iSCSI constructs to
shoe-horn into the SAM constructs.  All of this would have been a lot
easier if we hadn't gone to multiple connections per session. iSCSI is the
first protocol to allow for such constructs.]

Jim Hafner


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 04/25/2001 04:34:39 PM

Sent by:  owner-ips@ece.cmu.edu


To:   Julian Satran/Haifa/IBM@IBMIL, IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: multiple sessions b/n a pair of WWUIs.



> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: session login and ISID
> From: julian_satran@il.ibm.com
> Date: Tue, 10 Apr 2001 14:21:49 +0300


> WWUI can be presented during login phase (2.10.9 is correct and in-line
with 1.2.7) Two > sesions can have the same ISID but will have different
TSID. The question of whether
> more than one session should be allowed between a pair of wuis is under
debate.

> Julo


Julian,

There seems to be some disconnect between your comments above and the
name-disc draft. As per the name-disc draft Section 2(d) :

"There can be only one iSCSI  session with a given ISID between an iSCSI
Intiator Node and an iSCSI Target Node."

The iSCSI [&name-disc] drafts should explicitly state that ISID is
uniquely assigned for a given initiator. Similarly, the TSID is uniquely
assigned for a given target.

On the subject of multiple sessions for a given pair of WWUIs, this MUST
be a requirement. iSCSI must allow multiple sessions for a given pair of
WWUIs.

This is required because single-connection session models would like to
setup multiple sessions b/n initiator hosts and multi-ported targets and
export the multiple paths to LUs to upper layer wedge drivers like EMC
Powerpath, Veritas VxVm, etc.

Inability to establish multiple sessions b/n a pair of WWUIs implies
iSCSI layer will only export one path to the upper layer wedge drivers,
thereby, breaking such applications.

This also implies iSCSI would then take on all the responsibilities of
providing load balancing and fail-over capabilities and would require
the use of multi-connection sessions for that purpose.

By allowing multiple sessions for a given WWUI pair, iSCSI layer could
achieve equivalent functionality using single connection sessions and
would also not break existing wedge drivers.

Regards,
Santosh