[SSS] SCSI Command Conflicts?

Keith W. Parker diogenes at europa.com
Wed Jul 8 08:00:21 PDT 1998

* From the T10 (formerly SCSI) Reflector (t10 at symbios.com), posted by:
* "Keith W. Parker" <diogenes at europa.com>
Does anyone know of any conflicts with the following
SCSI command numbers being assigned to the
"SCSI Socket Services (SSS)" project T10/1246-D?

They all need to be OPTIONAL for ALL SCSI device types.
They are all SCSI Group Code #4 (16 byte) commands.

#define SSS_RPC_MGMT_GET        0x90
#define SSS_RPC_MGMT_PUT        0x91
#define SSS_RPC_XFER_GET        0x92
#define SSS_RPC_XFER_PUT        0x93
#define SSS_PKT_MGMT_GET        0x94
#define SSS_PKT_MGMT_PUT        0x95
#define SSS_PKT_XFER_GET        0x96
#define SSS_PKT_XFER_PUT        0x97

According to "SCSI Primary Commands-2 (SPC-2)
T10/1236-D rev.3 (98-05-22) Table B.2,
these command numbers are currently unassigned.

I am requesting that these SCSI command numbers be tentatively
assigned to project T10/1246-D.
Final assignment would not occur until the SSS has been discussed
and voted upon.
The tentative assignment would allow people that are ready to work
on developmental phase implementation to begin without requiring
changing code once final command numbers are assigned.

All commands use the exact same format with the exception that the
Pkt_count and Data_len fields specify the actual amounts to be
transferred during SSS_xxx_xxxx_PUT commands and the maximum amounts
that can be transferred during the SSS_xxx_xxxx_GET commands.

Byte  |Bits| Type   | Field Name
 0    |  8 | BE_uchar SCSI_Cmd_Num
 1    |  8 | BE_uchar Func_Code 
 2-3  | 16 | BE_short Pkt_Count
 4-7  | 32 | BE_long  Data_Len
 8-11 | 32 | BE_long  Cmd_Key
12-13 | 16 | BE_short Channel_Token
14    |  8 | BE_uchar Func_Flags
15    |  8 | BE_uchar Control ( SAM r18 5.1, 5.6 ; SAM-2 r5a 5.1.2, 5.6 )

SSS_RPC_xxxx_xxx - These commands support the 
SSS Remote Procedure Call (RPC) mechanism.
This connects systems together at the "top" of the protocol stack.
This method has the highest performance/management potential since 
it does not use the TCP/IP protocol stack.
It is the most complex to implement.

SSS_PKT_xxxx_xxx - These commands support the 
SSS "IP Packets over SCSI" mechanism.
This is an alternate method of accomplishing the same objective:
providing a high performance (i.e. SCSI bandwidth) Platform/Device
Independent (PDI) "Socket" Application Programming Interface (API).
This connects systems together at the "bottom" of the protocol stack.
This method is much easier to implement if a system already has a
TCP/IP protocol stack.
This is new to the SSS project.  It an extension for the sake of
pragmatism, it is much easier (therefore more likely) to implement.
It also addresses the issue of situations that are intrinsically
packet oriented such as using SCSI as an expansion bus for
bridges, routers, hubs and switches or as an intermediate link
in a data stream that has already been broken down into packets.
While the primary focus is Internet IP Packets (IPv4 & IPv6), 
other packets (802.3, USB, IrDA, etc.) may be transported.

SSS_xxx_MGMT_xxx - These commands support communication management
functions.  These are handled separately from the transfer (_XFER_)
functions because they may be relatively large and infrequently used
so it is desirable for them to be unloaded from memory when not needed.

SSS_xxx_XFER_xxx - These commands support the actual transfer of data.
These are more compact and often used so they need to be left in memory.

SSS_xxx_xxxx_GET & SSS_xxx_xxxx_PUT - These commands GET and PUT
packets into the transport buffers.  They allow symmetric communications
even when one of the SCSI devices is "Initiator Only" capable.

Please resopond via posting since I am unable to attend the 
July T10 meeting.

Keith W. Parker
diogenes at europa.com

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list