Re: iscsi : target port definition

["Jim Hafner" <hafner@almaden.ibm.com>]

Santosh,

There are many alternatives here, but I think the simplest is to establish
multiple sessions to the one target portal group.  Each session can connect
to one, some or all of the target ipaddresses in the portal group, so you
have a lot of flexibility.  What you see then in the wedge driver is
multiple "SCSI Initiator Ports" in the host connecting to one SCSI Target
Port.  That should be sufficient for the multipathing logic.    So, it's
many to one, not one to many.

Note that according to the model in -08, if there were more than one target
portal group, you could see two different things, depending on how you
implemented your host.  You could have an "implementation" of one host SCSI
Initiator Port connecting to multiple SCSI Target Ports if you used the
same ISID for all those sessions.  Or you could have an implementation of
multipel SCSI Initiator Ports connecting in arbitrary ways to the multiple
SCSI Target Ports if you used a set of ISIDs.  In other words, the reuse of
an ISID to a different target portal group implies a one to many setup.
And you can overlay lots of one-to-many (or one-to-one) sessions as you
enable different ISIDs.  In other words, the "many" SCSI Initator Ports are
based on multiple use of ISIDs and multiple SCSI Target Ports are based on
multiple target portal groups as advertised by the target.

On the other hand, there is no requirement of the target that if advertise
itself as having only one target portal group, even if it was capable.  It
can subdivide its ipaddress space in any way it wants.   A high end target
with many many ip interfaces will probably do that.  Additionally, any
truly high end target (in the long term) will have many iSCSI HBAs (most
likely) each functioning as a target portal group and you'd see this
modeling FC (at the target side) closer.

There might be other reasons besides multiple iSCSI HBA configuration for
the target to advertise multiple target portal groups. The SCSI Asymmetric
Port behavior for controllers in particular (for failover, primary pathing,
etc.) can take advantage of that kind of structure.  You may have a
dual-headed controller each with independent power supplies.  They might
have enough coordination to run sessions across all of them, but it might
make more sense to separate them.  [Give me more time and I can probably
come up with lots of other reasons too...]

The model then is flexible enough to handle arbitrary software
implementations using arbitrary network or TCP hardware cards as well as
any implementations of iSCSI HBAs or any combination of the two. And that's
true on both the initiator and the target side.

Jim Hafner


Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 09/13/2001 05:37:45 pm

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


To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iscsi : target port definition



Hello,

I have a question on the interpretation of the iscsi target port
definition. The iscsi rev 08 defines the iscsi target port to map to an
iscsi target portal group.

Thus, any iscsi target that wishes to allow multiple SCSI paths to be
established to the target node MUST provide at least 2 iscsi target
portal groups.

The above definition of an iscsi target port somewhat alters the
semantics of a target portal group. A target portal group, by
definition, is a collection of a set of network portals within the
target across which a session can be spanned.

Thus, if a target supports a multi-connection session spanning across
all its network portals, such a target would use a single target portal
group to indicate that 1 big fat session pipe could be established to
all its network portals. This, in turn, would have the side effect of
only providing 1 scsi path to the upper layer wedge drivers, if the
iscsi initiators establish a session per target portal group. [which is
the target port].

From an initiator's perspective, what should be the target side
end-point of an initiator's sessions when it may need to support upper
layer wedge drivers ? Should the initiator establish a session per
target
portal group [, in which case the above issue exists] ? Or, should it
establish a session per TargetAddress ??

Regards,
Santosh