Re: LU access through an iSCSI session

[julian_satran@il.ibm.com]

Pierre,

Sorry for the delay.

1. Yes. The session is the delivery-port (in SAM terminology).

2.As in 1 - it is the same LUN as a session is a delivery-port


and yes you can do load balancing based on connection capalities and the
need perceived
by the initiator.

Thanks for your patience,
Julo

Pierre Labat <pierre_labat@hp.com> on 19/09/2000 20:44:06

Please respond to Pierre Labat <pierre_labat@hp.com>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  LU access through an iSCSI session




Julo,


Thinking about what could be an implementation of an iSCSI
session, several questions came to my mind for which
i was unable to find an answer in the draft.

1) Do commands directed to a particular LU through a session are
able to use any of the TCP connections within the  session?

As the TCP connections could connect to various "service delivery ports"
it is
not guarantee that a particular LU is visible through all the
connections.


2) Do commands directed to a particular LU through a session
need to be associated to different LUNs depending on the TCP
connection used or is it always the same LUN for all
the connections?

As the TCP connections could connect to various "service delivery ports"

of the target, it seems that the LUN could differ depending on the
connection used.
In the iSCSI draft in 2.2.1 there is:
"The group of TCP connections linking an initiator with a target forms
a session (loosely equivalent to a SCSI nexus)." Does it means that
the same LUN is used across the TCP connections?

Depending on the answer to these questions the failover/load balancing
can
be handled in different ways:


-> If the answer for 1)  is "All TCP connections can be used" and
the answer for 2) is "Same LUN regardless of the connexion"

For fail over and load balancing inside a session, there is no need to
work
at the (thin) LU granularity,  working at the granularity of the TCP
connexion is sufficient. For example in case of failed TCP connexion
all the traffic for this failed TCP connexion can be directed on the
other
connections regardless of the LU. It is very quick, straight forward
and may add value compared to the legacy solutions that are doing
the fail over on a LU basis (one LU command returns an error or
timeout, the next commands for this LU will use an alternate path)
In the case where a large number (N) of LUs access are multiplexed to
a target port, N switch over are needed.
The same result could be achieved in one operation (TCP connection
switch over).

-> If the answer for 1)  is "All TCP connections can be used" and
the answer for 2) is "different  LUN depending on the connexion"
We need to work at the LU granularity. For each command the
right LUN as to be determined depending on the tcp connection
selected.

-> If the answer for 1) is "not all TCP connections can be used, it is
LU dependent"
On top of the previous case extra work, for each LU  it must be a list
of
TCP connections usable that needs to be looked into before routing
the command to one TCP connection.
It means that some LUs access using a session could survive
to a TCP connection failure some other LUs no.


Regards,

Pierre