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

From: "John Hufferd" <[email-masked]>
Date: Tue, 8 May 2001 20:38:53 -0700

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
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.
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.

Today, the way we use multiple Fibre Channel Initiator Ports connected to
the same Fibre Channel Target Ports is by use of Wedge Drivers.  I think
what you are suggesting causes the need for a Wedge Drivers to integrate
the iSCSI Initiator Ports.  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.

OK, that's what I think our misunderstanding is all about.  If I am
mistaken, please set me straight.
.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Santosh Rao <[email-masked]>@cup.hp.com on 05/08/2001 05:44:41 PM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   [email-masked], [email-masked]
Subject:  Re: iSCSI: multiple sessions b/n a pair of WWUIs.

John,

By the name-disc definition, an iSCSI initiator or target port is a
logical entity that constitutes the end points of a session.

Hence, there never can be 2 sessions b/n the *same* 2  initiator &
target port. Each session established spawns a *new* initiator and
target iSCSI port.

Going by the above semantics, there is always only 1 ISID/TSID per iSCSI
Initiator/Target port.

Hence, I'm unable to understand your statements below.

As for the uniqueness of ISID across all initiators, is there any reason
not to allow implementations to do that ? I would have thought that is
the most typical use of an ISID and also allows initiators to lookup
their target structures based on ISID.

Regards,
Santosh

John Hufferd wrote:
>
> Also, since a second session by the same iSCSI Initiator Port, to the
same
> iSCSI Target Port is not, in my opinion "legal", it is not clear to me
that
> any given iSCSI Port needs any more then one ISID.  I
>
> Therefore, I suggest that we Not put any such notes, like you suggest, in
> the draft, but in fact encourage a single ISID/TSID per iSCSI
> Initiator/Target Port.

> To:   Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
> cc:   [email-masked]
> Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.
>
> While Jim's correct ... in Marj's defense, what
> she wrote is a fairly obvious way to implement
> it, and that might be worth noting in the draft.
>
> --David

---

From: Pierre Labat <[email-masked]>
Date: Wed, 09 May 2001 09:52:50 -0700

> Session was to remove the "Hard" need for Wedge Drivers.

John,
Could you give your exact definition of a iSCSI port.
Till your mails they were the definition of
- a "portal" (IP add),
- a SCSI service delivery port (=session end point from what i hearded in
Nashua)

It seems that you want to tie the  notion of SCSI service delivery port
to hardware, the opposite of what was presented in Nashua.

Do i miss something?

I see nothing wrong against SCSI or iSCSI to have two sessions (with 2 #
ISID) flowing from the same initiator adapter to the same target adapter.
Each session end point represents a SDP.

Regards,

Pierre

---

From: Santosh Rao <[email-masked]>
Date: Wed, 09 May 2001 10:41:34 -0700

> can NOT have a second session with the same iSCSI Initiator Port and be

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

> 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.

> 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. 

> 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
> 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
> 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