iSCSI: SAM-iSCSI mapping (alternative)

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

Folks,

This note addresses an alternative (and hopefully) better approach to
mapping the SCSI Architecture Model (SAM) constructs onto the iSCSI
constructs.  This is being recommended by the Naming and Discovery Team.

[Note: This is mostly esoteric stuff that shouldn't impact much of the
main line use of iSCSI, though part of this alternative proposal is
intended to make implementations a bit easier.]

Here's a quick summary of relevant iSCSI constructs:

a) iSCSI node (either initiator or target) is a WWU named entity

b) iSCSI login occurs between an iSCSI initiator node and an iSCSI
target node (and names are exchanged during login)

c) an iSCSI node can have multiple IPnames/IPaddresses/TCPports

d) the IPnames/IPaddresses/TCPports can be organized into "portal
groups"; a multi-connection session may ONLY be established within a
portal group (not across ip address/ports in two different portal
groups).

The relevant SAM constructs are "initiator port", "target port",
"nexus (a relationship between an initiator port and a target port)"
and only as secondary constructs the notion of "initiator device" and
"target device".  (We need not worry about logical unit wrt iSCSI.)

CURRENT PROPOSED MAPPING of SAM to iSCSI:

a) a SAM nexus maps to an iSCSI session

b) there is at most one SCSI Device (initiator or target) contained
within an iSCSI node (in other words, the SCSI device is the SCSI-ness
of the iSCSI node); the SCSI device name is the iSCSI name.

c) a SCSI Initiator port (which is, by definition, the entity at the
initiator side of a nexus) maps to the iSCSI initiator endpoint of the
session (and is identified/names by its iSCSI Name + ISID of the
session).

d) a SCSI Target port (the entity at the target side of the nexus)
maps to the iSCSI target endpoint of the session (and is
identified/named by its iSCSI Name + TSID).

ISID RULE: A consequence of this mapping (to handle some specific SCSI
features) is the restriction that between a given iSCSI initiator and
iSCSI target, there can be only one session with a given ISID.  Note
that this does not preclude use of the same ISID with a different
iSCSI target, nor does it preclude other sessions with different ISIDs
to the same iSCSI target.

This model implies some implementation requirements on both the
initiator and the target and it "stretches" some notions in SCSI.  To
minimize these effects (detailed more carefully below), I'd like to
propose the following alternative mapping of SAM constructs:

ALTERNATIVE PROPOSED MAPPING:

a) SAM nexus as above

b) SCSI device as above

c) SCSI initiator port as above

d) SCSI target port is an iSCSI target portal group and is identified
by its iSCSI name + portal group tag (as reported in SendTargets);
this is very different from above.

ISID RULE (modified): Between a given iSCSI initiator and iSCSI target
portal group, there can be only one session with a given ISID.  Note
that this is a much weaker restriction than above.  This does not
preclude use of the same ISID with different target portal group on
the same iSCSI target (or on other iSCSI targets), nor does it
preclude other sessions with different ISIDs to the same target portal
group.

WHY THE CHANGE?

1) The new model better fits with SCSI's sense that target ports are
static things, not totally dynamic (like session endpoints).  There's
less of a static requirement for initiator ports.

2) In spite of the asymmetry of the model, the implementation
requirements are actually more symmetric and simpler (more details
next).

IMPLEMENTATION REQUIREMENTS:

                OLD                             NEW
--------------------------------------------------------------------------
Initiator       ISIDs must be partitioned       ISIDs must be partitioned
                between initiator portal        between initiator portal
                groups                          groups

                iSCSI name must be configurable iSCSI name must be
configurable
                to each portal group            to each portal group

Target          TSIDs must be partitioned       TSIDs must be partitioned
                between target portal           between target portal
                groups                          groups

                iSCSI name must be configurable iSCSI name must be
configurable
                to each portal group            to each portal group

                Active Initiator name+ISID      No requirement: each portal
                lists must be shared across     group can separately manage
                portal groups (to enforce       its own active
InitiatorName+ISID
                ISID RULE)                      lists; no sharing of active
state
                                                is required across portal
groups
                                                within a target

NOTES:

1) As noted, implementation on the iSCSI target is analogous to the
iSCSI initiator with respect to ISID and TSIDs and names.  Portal
groups should be configured (by the iSCSI node) with their iSCSI name
and with a piece of the [I/T]SID namespace.  There need be no other
shared state across portal groups.

2) The nexus is still a session, but it connects a dynamic SCSI
initiator port (identified by iSCSI name+ISID) with a static target
port (identified by iSCSI name+portal group tag).

3) The old model required finessing a reservation requirement that the
logical unit device server remember the SCSI target port used for the
reservation (so the TSID).  Without going into the subtlties here, note
only that the new model requires the device server to only remember
the portal group.

4) In the old model, changes to port-specific mode pages affected all
iSCSI initiators who see the same TSID (odd, but true).  In the new
model, changes to port-specific mode pages affect all iSCSI initiators
logged in to the same portal group (independent of TSID).  So, the
affect is broader, but makes more sense in that it is scoped to more
static constructs (the portal group).

5) This is analogous to how the SCSI over RDMA Protocol (i.e.,
Infiniband and VI) are modeling SAM.

Jim Hafner