iSCSI: value of Session ID

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

Folks,

I know this is bordering on heresy, but I'm trying to understand the value
of the Session ID (ISID+TSID) in the iSCSI protocol.

My understanding is that this was an attempt to mimic the S_ID and D_ID
components of the FCP payloads.  Consequently, the ISID would mean the SCSI
"initiator identifier" and the TSID would be the "target identifier".
Additionally, the SessionID would then uniquely define the SAM-2 I_T nexus
object from the perspective of the SCSI domain.

The problem I see is a question of scoping.  In FCP, the S_ID and D_ID are
imposed from the outside (by the network configuration) on the initiator
and target.  This also means that they are both externally visible to
parties other than the initiator and target AND each are unique within a
fabric (SCSI domain).   As such they suffice both in the context of
"initiator and target identifiers" AND for the purpose of identifying a
nexus (internal within a target and, as a bonus, externally in the domain
itself).

In iSCSI, the identifiers are generated internal to the initiator and
target.  Consequently, they only have meaning in the context of the
internal relationship between the initiator and target. They do not provide
either external visibility or uniqueness within the "SCSI domain".
Additionally, as currently defined, they are not even necessarily unique
internal to a target device.   As a result, I'm having trouble
understanding what they're to be used for.

Clearly, between the iSCSI layer and the SCSI layer within a target device
(and implicitly to the device server within a logical unit in that target
device), there must be some unique "handle" that gets associated to the I_T
nexus in order to distinguish associations like "where does the device
server return data for a command as it hands the data context down through
the layers", who sent the command (for the purposes of checking
reservations), etc.   In effect the target at least needs an internally
unique pointer for the session context that it can pass around between
layers.

For half the problem (internal uniqueness), one possible solution is to
require that the target generate it's TSID in such a way that the resulting
SessionID is unique within the target.  This seems artificial as it
effectively defines the internal algorithm that the target uses for it's
pointers.   The alternative is to just leave this "pointer" to the
implementation -- but then what value is the SessionID?

Your collective guidance is welcome!

Jim Hafner