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

[Santosh Rao <santoshr@cup.hp.com>]

Jim,

Thanks for the clarification. Both the iSCSI and the name-disc drafts
need to explicitly state that ISID is uniquely assigned for all sessions
within a given initiator. Similarly, TSID is uniquely assigned for all
sessions within a given target.

Regards,
Santosh

Jim Hafner wrote:
> 
> 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
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard