Re: Associating initiator names with SCSI commands

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Tue, 7 May 2002, Ken Craig wrote:

> In the parallel SCSI world association of an
> initiator with a new command is very
> straight-forward as the initiator's ID is
> encapsulated in the Identify message that
> occurs with the SCSI Selection phase that
> precedes receiving the new command.

It's straight-forward here too. See paragraph 2 of section 2.2.3 (the one
you mention). Each connection can be part of at most one session, and each
session forms an I_T nexus. Thus only one initiator can send commands down
a given connection.

> When I read the latest version of the iSCSI
> draft (rev. 12) the only statement I seem to
> find that correlates to this association is
> in Section 2.2.3 on page 34 in the 2nd
> sentence of the 3rd paragraph.
>
> "Any persistent state (e.g., persistent reservations)
> on the target that is associated with a SCSI
> initiator port is identified based on the
> value pair (InitiatorName, ISID)."
>
> When I searched the mailing list archives I
> came across statements that said this
> association was done using ISID and TSID (now
> TSIH?) but I do not see these statements in the
> latest draft so I'm assuming that there was some
> reason this association method was dropped.

Take a look at the table in the middle of page 69, section 4.3.1 Login
start, to see what is going on. Both ISID and TSIH only make sense in
terms of a given initiator or target; they are not world-unique numbers.

> My question is:
> In order to associate initiators with incoming
> commands to a SCSI Target do I have to compare
> the Initiator Name and ISID (up to ~268 bytes?)
> for every command I receive against a list of
> logged in initiators or is there another method
> using a lot fewer number of bytes?

No.

As above, only one initiator will be sending commands over a connection.
Since you know what connection the command came over, you implicitly know
the initiator (and the session too).

Take care,

Bill