TO: X3T9.2 SCSI Committee Page 1 of 3 89-036R1 FROM: Gary R. Stephens, IBM Corp. September 8, 1989 SUBJ: SCSI-3 Preparations for New Physical Layer(s) SCSI-2 has mandatory asynchronous protocol requirements which will not work on the newer non-parallel physical interfaces being proposed. Fundamental changes must be made in SCSI-3 or the transition will not be possible. Consider the transfer of messages and commands over 2km in asynchronous mode. The problem arises, partly, from the SCSI-2 imposed requirement that only data transfers can be handled in synchronous mode and all message responses must be on a message-by- message basis (except for one). Our recent experience in SCSI-2 has shown that it is possible to change one layer without affecting other layers. The connector issue, although somewhat bloody at times, did not center on fundamental problems in the architecture of SCSI, but rather on which of several alternative implementations to pick. Such is not the case with the fiber channel. The layer names used below are chosen to be consistent with IPI-3. IPI-3 is not ready for a switch to fiber at this time either, but it is much closer. Adding the "B" cable in SCSI-2 affected Layers 0 and 1 (the connectors/cables and the electrical/signal protocol). Adding the 16- bit alternative cable is of similar difficulty. The terminator studies and recommendations affected, mostly, layer 1, the electrical/signal protocol layer. These changes have all been on a parallel signal implementations and have had little effect on layer 3, the logical protocol. In the parallel interface world, SCSI is somewhat independent between Level 0, the physical connector and cable layer, and Levels 1 and 3, the signal protocol and the logical layers. In addition, the "B" cable and the 16-bit options show some independence between Levels 0 and 1 and Level 3. The area of "logical" difficulty occurs, mostly, in the message system which is a mix of both physical and logical elements (e.g., IDENTIFY - logical, and SDTR - physical; or COMMAND COMPLETE - logical, and SAVE DATA POINTERS - physical). In a review of the SCSI-2 document, I have found some areas of the interface protocol where SCSI-3 must change to divorce itself from a parallel mode of information transfer. I have also identified items which must be added. This list is not exhaustive. No specific text changes are recommended. Rather, I urge the X3T9.2 members to consider this list, amend it, and then use it as a guide for decisions in forming SCSI-3. When the list is reasonably complete, we attack the text. 1. All principal initiators must implement target mode and support Asynchronous Event Notification. CONTINUED TO: X3T9.2 SCSI Committee Page 2 of 3 89-036R1 FROM: Gary R. Stephens, IBM Corp. September 8, 1989 SUBJ: SCSI-3 Preparations for New Physical Layer(s) 2. All principal targets must implement initiator mode and support Asynchronous Event Notification. Note that all temporary initiators already have both modes but may not support AEN. AEN must be extended to temporary initiators during operations where they are acting as temporary initiators (e.g., COPY). 3. Mandatory processing on a byte-by-byte basis of messages and commands must be dropped. Synchronous processing must be allowed and probably will be mandatory on some physical layers for ALL transfers. 4. Messages, CDBs, and most parameter data must be formed as a single information transfer packet. Where parameter data is too long to be handled in such a packet, the parameter data may be transferred as data in synchronous mode with disconnection between bursts. This applies to both initiators and targets. 5. Disconnection is mandatory and not controllable; recover the bit in the Identify message. 6. Combine Command Complete or Linked Command Complete messages, Status, and Sense data into a single transfer unit in synchronous mode. The status and sense elements may be null to allow Linked Command Complete. 7. Recover, for future use, the MESSAGE OUT and MESSAGE IN phases. Recover, for future use, the COMMAND OUT and STATUS IN phases. Add in from the reserved phases, new OUT and IN phases to handle the new command/response transfers. See Items 4 and 6. 8. The resulting four "phases" on the interface are "NEXUS ELEMENT TRANSFER" (messages, commands, and parameter data), DATA OUT, DATA IN, and "NEXUS STATUS" (intermediate and final messages, status, and sense data). See Item 7. 9. The area of resets needs lots of attention. 10. Move all message response handling to CHECK Status with sense data containing new ASC/ASCQ combinations. Handle parity errors in like manner. Add Parity error reporting from the initiator to target. 11. Mandate disconnection at burst boundaries (Maximum size TBD). 12. Define a MODE SELECT/SENSE page for maximum Nexus Element transfer length and maximum Nexus Status length, similar to the burst length today. CONTINUED TO: X3T9.2 SCSI Committee Page 3 of 3 89-036R1 FROM: Gary R. Stephens, IBM Corp. September 8, 1989 SUBJ: SCSI-3 Preparations for New Physical Layer(s) 13. Add reject ASC/ASCQ if either transfer in Item 12 is too long during actual transfer. See Item 10. 14. Add new path identification "messages" to identify 2 or more initiators to the same "host". Allow requests/responses to use alternate paths to/from the same "host". This adds a higher reliability element to the interface by recognizing and allowing multiple, equivalent ports to the same "host". the inverse may also be required for targets (i.e., multiple ports). 15. Modify contingent allegiance to extend to a "host" rather than an initiator when multiple initiators are defined for the same path. 16. Define Nexus Element Transfer and Nexus Status packets to meet the following requirements: a. Allow Multiple messages (1-n bytes). b. Allow CDB (0-n bytes) c. Allow parameter data (0-n bytes). d. Allow flag for sending Parameter data as DATA OUT phase. e. Allow multiple sets of items a. through d. (i.e., a complete nexus). f. Add an initiator/path unique value for communicating which nexus is requesting service (data in/out and parameter data out, status in). g. Disallow multiple nexus transfers in a single information transfer. h. Allow command message (COMMAND COMPLETE, LINKED COMMAND COMPLETE), status, and sense data in one packet. 17. Define a "retransmit packet" response for all transfers in either direction. [NOTE: Revision 1 of this document was edited by John Lohmeyer from the discussion at the September Working Group meeting. He re-entered the last half of the document starting in the middle of item 6, because the file was damaged. Blame him for any typos. jbl] END OF DOCUMENT 89-036R1