Subject: RE: iSCSI - opcodes

From: [email-masked]
Date: Mon, 28 May 2001 14:53:54 +0300

The new codes are in the 07 draft.   Although I've put back the bit that
shows direction I seriously doubt that
it's original purpose (to make life easier for analyzers) is as relevant as
it was.

Julo

"Martin, Nick" <[email-masked]> on 01-05-2001 01:48:00

Please respond to "Martin, Nick" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - opcodes

Julian,

I was not among the incensed.  I would say puzzled.  Although the bit may
not be not critical to initiators or targets who presumably know what they
are, it is handy at least for network analyzer displays.

Since it now still consumes a bit, I would have made it the MSB of the
Opcode field as in previous drafts (currently bit 5 or 0x20).  However I
can
cope with your selection ((Opcode & 0x3e)>>1) :).

The 2F reject instead of 3F (or 1f) for reject was another puzzler.
Presumably you wanted a fence between unused reserved opcodes and vendor
specific codes.

Thanks,
Nick Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 27, 2001 12:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: iSCSI - opcodes

Fellow iSCSI fans,

Some were incesed by the lak of a "direction bit" in the opcodes in draft
06.
Here is an attempt to a new list (having a bit for direction back - as the
LSB ).
To gain some reserved space I've curtailed the vendo-specific codes to 4 in
each direction.

Please comment,
Julo

1.1.1.1   Opcode

   The Opcode indicates what type of iSCSI PDU the header encapsulates.

   The Opcodes are divided into two categories: initiator opcodes and
   target opcodes. Initiator opcodes are in PDUs sent by the initiators
   (request PDUs), and target opcodes are in PDUs sent by the target
   (response PDUs).

   Initiators MUST NOT use target opcodes and targets MUST NOT use
   initiator opcodes.

   Valid initiator opcodes defined in this specification are:

      0x00 NOP-Out (from initiator to target)
      0x02 SCSI Command (encapsulates a SCSI Command Descriptor Block)
      0x04 SCSI Task Management Command
      0x06 Login Command
      0x08 Text Command
      0x0a SCSI Data-out (for WRITE operations)
      0x0c Logout Command
      0x10 SNACK Request

   Valid target opcodes are:

      0x01 NOP-In (from target to initiator)
      0x03 SCSI Response (contains SCSI status and possibly sense
      information or other response information)
      0x05 SCSI Task Management Response
      0x07 Login Response
      0x09 Text Response
      0x0b SCSI Data-in (for READ operations)
      0x0d Logout Response
      0x11 Ready To Transfer (R2T - sent by target to initiator when it is
      ready to receive data from initiator)
      0x13 Asynchronous Message (sent by target to initiator to indicate
      certain special conditions)
      0x2f Reject

   Initiator opcodes 0x38, 0x3a, 0x3c and 0x3e and target opcodes 0x39,
   0x3b, 0x3d and 0x3f are vendor specific codes.

---

From: [email-masked]
Date: Tue, 29 May 2001 15:38:44 +0300

Brian,

Vendors can negotiate the use of their specific opcodes at login through
... vendor specific text-keys.
I am not a big fan of vendor-specific op-codes or keys but they give people
an opportunity to experiment with new things without having to get to a
"rough consensus".

Julo

Brian Pawlowski <[email-masked]> on 28-05-2001 22:39:02

Please respond to Brian Pawlowski <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI - opcodes

I have a problem with this statement.

Vendor specific opcodes in a shared opcode space are subject to collision
unless a management framework wi specified to deal with the opcode
space.

What is the intention here?  Is there a precedent in SCSI (FCP or whatever)
for such use?

If they are just unused codes, I would propose they be left RESERVED.

If you intend to use them, I would like to hear how it will be managed
to ensure interoperability.