Subject: Associating initiator names with SCSI commands

From: "Ken Craig" <[email-masked]>
Date: Tue, 7 May 2002 09:11:47 -0700

I have a question concerning associating
incoming SCSI commands with an initiator.
I come from a parallel SCSI background and
now find myself implementing a SCSI Target
port in an iSCSI world.  I have searched
the mailing list archives for discussions
on this subject but have been unable to find
anything that succinctly answers my question
so please bear with me.

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.

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.

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?

I had thought about using the IP address in the
IP header but the draft seems to say that is not
allowed because IP addresses can change.  It
seems like I must perform this potentially rather
long comparison if I support multiple initiators
because I can not be guaranteed that different
initiators would not use the same ISID during
their login.  Am I wrong?

Thanks in advance,
Kenneth Ray Craig, Jr.

---

From: Bill Studenmund <[email-masked]>
Date: Tue, 7 May 2002 14:02:04 -0700 (PDT)

> 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.

> 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.

> 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