Re: iSCSI: session login and ISID

["John Hufferd" <hufferd@us.ibm.com>]

Pierre, et.al.
There should be no reason that a specific OS, can not have multiple session
to the same Target, as long as the ISID is different.  It is up to the
installation/vendor to determine how to arrive at ISID.  They can also
determine that they want each iSCSI HBA to have a different ISID, and
arrive at unique ISIDs for each.  Then, as we talked, months and months
ago, it is then up to a Wedge Driver to sort out who get what requests, and
attempts to do load balancing.

The wedge driver is needed to make sure that the application does not have
to care which Session it is connected too, since they have no way to
specify it anyhow.  That is, the wedge driver needs to insure that it sends
no I/O to a LU on a specific session if it has sent previous I/O to that
same LU, on a different session, and still has its I/O outstanding.
Otherwise, out of order things will happen.  But this is a fairly easy
thing to handle in the  Wedge Driver.  There are some issues with
Persistence Reserve, but those can be handled also, by sending LU's I/O to
the Reserved LUs only on the same Session, on which the Reserve was issued.

Remember, it is only the multiple connections per session model that does
not require the Wedge Driver in order handle multiple connections.


.
.
.
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: hufferd@us.ibm.com


Pierre Labat <pierre_labat@hp.com>@ece.cmu.edu on 04/10/2001 08:12:22 AM

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


To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI: session login and ISID



julian_satran@il.ibm.com wrote:

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

I think that several sessions should be allowed between a pair of wwuis
at least to handle the simple case where the initiator and the target have

two adapters each and each session wants to use a pair of adapter.

Regards,

Pierre

>
> Julo
>
> sandeepj@research.bell-labs.com (Sandeep Joshi) on 09/04/2001 20:27:46
>
> Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI: session login and ISID
>
> There seems to be a problem in distinguishing session logins, using
> only the ISID field in the Login Command.   It is possible that
> different initiators could try to start a session using the same ISID
> value.   One of those attempts will get rejected, since the ISID is
> the sole key to find if a session already exists. (note: TSID was
> sent as zero for the leading connection of session)
>
> The initiator WWUI does not seem to be available at this time.
> a) Appendix D.10 states that InitiatorWWUI is optional and defaults
>    to iSCSI.
> b) Section 2.10.9 on Login Command states that "initiator MAY provide
>    some basic parameters".
>
> On the other hand, Section 1.2.7 states that "the initiator MUST
> present both its initiator WWUI and target WWUI to which it wishes
> to connect during the login phase".
>
> The WWUI is also needed if we are to support multiple I_T nexuses
> between the same initiator and target.
>
> So it seems like Section 1.2.7 has the right spec.   Appendix D and
> Section 2.10.9 must then be corrected.  The descriptions in Sec 4.1
> and Section 1.2.3 may also need to be changed to reflect the fact
> that initiator WWUI must be supplied at session login.
>
> -Sandeep