iSCSI: Questions about naming, multi-pathing, multi-port targets

["Pittman, Joseph" <Joseph.Pittman@netapp.com>]

I am fairly new to the iSCSI effort, and this is my first question
to the IPS mailing list.  But I have been following the mailing list
for awhile now, particularly the recent system identification
discussions.  And I am now working in earnest on an iSCSI target
implementation, which has brought into focus the need for me to get
a more complete understanding of the concepts.

What is the expected naming and access model for a target with
multiple physical ports/IP addresses?  I understand from the iSCSI
Naming and Discovery document that a target node presents one or
more Portal Groups, and that an iSCSI session is conducted over
exactly one portal group.

Is it expected that a target with 4 ports will have a single
"portal group"?  Or 4 separate portal groups?  Would operating
system SCSI initiator code prefer to see 4 independent paths into
the target, or a single session-layer path with multiple lower-level
paths of connectivity?  And how is the OS supposed to discover the
association between target portals and their portal groups?

In the FCP-SCSI world, each FC port on a multi-ported target device
(e.g. SAN-connected disk array) is an independent communicating
entity, with its own FC port and WWN.  There is no concept of a
networking session which spans multiple physical connections.  As I
understand it, the existence of multiple paths to the same
underlying set of LUNs is detected by examining SCSI inquiry data
from the detected devices.  A driver (or a "wedge layer") within an
operating system examines all available LUNs through all FCP HBAs
under its control, and uses SCSI inquiry to detect the existence of
multiple paths to the same LUN.  The driver or wedge layer then
advertises to the higher layers of the SCSI block storage stack
only the set of unique target devices.  The driver routes incoming
SCSI requests from above to to one of the available paths, based
on some algorithm which may take into account availability and
relative performance of the paths.

Now consider the case of adding support for iSCSI connectivity
into an existing OS SCSI request stack.  The most straightforward
way for an iSCSI driver to drop into an existing infrastructure
would be for a 4-port target to appear as 4 distinct DEVICES.
The driver or "wedge layer", using IP address as the fundamental
identifier for its notion of target identifier, would detect the
presence of 4 separate "targets", use inquiries to detect multiple
paths to the LUNs through these separate devices, etc.

An approach which is more iSCSI-aware could take advantage of
available config info (via static configuration? SLP? iSNS?) to
recognize that all 4 IP addresses map to the same iSCSI Target
Node.

The ISID rule states that there can be only one session with a
given ISID between an iSCSI Initiator and an iSCSI Target Portal
Group.  So how does the initiator discover the relationship
between portals and groups on the target?  And what would the
OS implementors rather do, establish a separate session to each
IP address, or establish a single session over each portal group?

Impact on the target-mode implementer: should a target
implementation endeavor to present a single portal group?  Or a
different group for each portal?  Or a different group for each
HBA (which may have one or more ports)?  One factor in deciding
this is the diversity of the possible approaches to handling
iSCSI processing:

  - onboard a single-port HBA
  - onboard a multi-port HBA
  - within a driver in an embedded OS which uses a per-instance
    driver architecture
  - within a driver in an embedded OS which uses a per-device class
    driver architecture
  - within an overarching iSCSI management layer

Any thoughts or guidance would be greatly appreciated.
--
Joe Pittman
jpittman@netapp.com