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

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

John Hufferd wrote:
> 
> Santosh,
> I think I am beginning to see the problem.  A given iSCSI Initiator Port
> can NOT have a second session with the same iSCSI Initiator Port and be

John,
                                             ^^^^^^^^^^^^^^^^^^^^^
Is the above "same iSCSI target port" (?).


> consistent with SCSIness.  The second session could be started with another
> ISID, (to the same iSCSI Target Port) but if the session was established it
> would not have any of its commands and data handled via any techniques
> defined by SCSI or iSCSI.  In fact its use would require a wedge driver.

Perhaps, some of my confusion arises from a lack of understanding of
your definition of iSCSI Initiator Port and iSCSI Target Port. Some
clarification on your definition of these would help make things more
clear.


> This is the exact confusion I was trying to avoid.  Technically if you were
> actually able to start another Session to the same Target Port, it would
> be, by definition another iSCSI Initiator Port.   The two different Ports
> would need to be coordinated by what we have been calling a Wedge Driver.


I'm not sure why you believe a wedge driver would be required to handle
such a configuration.(?) Per my understanding [which may be missing some
aspect], the host can operate in such a configuration in the absence of
a wedge driver.

Also, the host could create such multiple sessions to the same target
port in order to separate sub-sets of LUNs into different sessions and
apply different session properties to each such LUN subset. 


> 
> Today, the way we use multiple Fibre Channel Initiator Ports connected to
> the same Fibre Channel Target Ports is by use of Wedge Drivers. 

With FC, connecting multiple initiator ports from the *same* host to a
single target port makes little or no sense. The host would see the same
LUNs twice through different initiator ports. 

A more typical configuration is to connect multiple FC initiator ports
from *different* hosts to the same target port as a high availability
configuration. Yes, in such a case, some type of cluster application
would be managing the switch-over from one initiator port to another.
(Is this the case being referred to ?).


> I think
> what you are suggesting causes the need for a Wedge Drivers to integrate
> the iSCSI Initiator Ports. 


(I guess we wandered off into a different line of discussion which is
"whether multiple sessions between an initiator port and target port are
legal and required" ? :)

My answer to that would be, yes, they are legal and required. They also
do not require the use of a wedge driver. The host may configure
multiple sessions from one iSCSI initiator NIC to a given iSCSI
TargetAddress so as to access LUN subsets from different sessions, and
apply different session properties to different LUN sub-sets.

Such multiple sessions that are originated on the same initiator NIC
need to use different ISIDs [for all of the sessions for that given
target node] and thereby, are considered multiple iSCSI Initiator Ports,
based on the current name-disc draft's defn.


 Not sure that we want to cause this type of
> thinking, by accident.  One of the reasons for Multiple Connections per
> Session was to remove the "Hard" need for Wedge Drivers.

IMHO, "multiple connections per session" complements wedge drivers in
their functionality but may not comletely replace them. A lot of wedge
drivers have code specific to the SCSI properties of the target and
moving all of this functionality into the iSCSI layer would imply adding
device specific code into this layer. Not the cleanest of layering
schemes. 

Also, some wedge drivers claim to utilize device proprietary features,
which a device independent iSCSI initiator layer could not provide
through "multiple connections per session".

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