Date: Tuesday, February 13, 1990 Subject: Comment on the AEN (Asynchronous Event Notification) reporting mechanism in document number BSR X3.131-198x, and Hewlett Packard's intention to do a vendor unique AEN reporting mechanism. Textual additions to the document are offered. TO: Ms. Lynn Barra CBEMA (X3 Secretariat) 311 First St NW, Suite 500 Washington, DC 20001-2178 CC: ANSI Board of Standards Review 1430 Broadway New York, NY 10018 John Lohmeyer (X3T9.2 Chairman) NCR Corporation 3718 N. Rock Rd. Wichita, KS 67226 FROM: Eric Tausheck Hewlett Packard Company 8000 Foothills Blvd. Roseville, CA 95678 I recognize the need for peripherals to notify hosts of state changes that can occur asynchronously and in the absence of pending host requests. The SCSI-2 AEN (Asynchronous Event Notification) protocol was developed to answer this need. This comment is on the mechanism used to report AENs and on the alternative that Hewlett Packard has chosen for peripherals which implement only the target role of a SCSI device but which still must provide the ability to notify hosts of asynchronous events. My comments on the current AEN reporting mechanism -------------------------------------------------- My understanding of the development of the AEN protocol comes from talking with long standing committee members and from reviewing X3T9.2/87-52. I am aware that various alternative AEN protocols were considered but I do not know the details of these rejected alternatives. The idea of using reselection for the AEN reporting mechanism was considered, but was rejected in favor of an "architecturally clean" solution using the "full peer-to-peer interface" provided in the SCSI-2 specification. The committee did arrive at a technically useful solution. However, after experiencing implementation, I have found that the AEN reporting mechanism is neither "clean", "peer-to-peer", nor "simple to implement". I have never considered SCSI to present a peer-to-peer interface between a host and a peripheral I/O device and think such an argument was a poor justification for elimination of AEN mechanisms which allow target-only implementations. At the interface level, SCSI can be "peer-to-peer" and is "architecturally clean", however, when the device type protocols are laid over the interface level of SCSI, the clean, peer-to-peer potential is dissolved by the device type model which makes restrictions on the use of the interface layer through the specification of commands, sense data, and sequences. Only the interaction between processor device type with processor device type and communication device type with communication device type have true peer-to-peer potential. In fact, the current AEN reporting mechanism limits the reception of AENs to the processor device type. I think this limitation is unclean and architecturally unnecessary and, ironically, particularly so with respect to the peer-to-peer arguments. The currently defined AEN reporting mechanism may prove acceptable for implementation on SCSI devices which must employ initiator capability as part of more extensive functionality such as the COPY command. However, software firmware and hardware resources, both in development and material cost, are unnecessarily high for a peripheral which otherwise has no need to support the initiator role. These problems led us to develop an alternative AEN reporting mechanism. I came up with a mechanism which we have found can be easily implemented by peripheral devices without having to support initiator mode operation. Although it was designed to accommodate target-only implementations, the alternative may also be used by all peripheral devices. The alternative also will work with initiator designs without modification in most cases. Hewlett Packard's alternative AEN reporting mechanism ----------------------------------------------------- The alternative is built on top of the specification of the AEN protocol currently in the SCSI-2 specification. This alternative is just a different notification mechanism and does not change other aspects of the AEN protocol as currently defined. The alternative method of reporting AENs is for the target to perform a status phase reconnection. The difference between this and a normal reconnection is that there is no I/O process to continue in this case. The status reported shall be CHECK CONDITION. The specific sequence that the target would perform on the SCSI bus for each initiator to be notified would be identical to a "vanilla" status phase reconnection: 1. win SCSI bus arbitration 2. reselect the intended initiator 3. change phase to MESSAGE IN and handshake the appropriate IDENTIFY message byte 4. change phase to STATUS and handshake a CHECK CONDITION status byte 5. change phase to MESSAGE IN and handshake the COMMAND COMPLETE message byte 6. change phase to BUS FREE From the target implementation perspective, this unsolicited report leaves the target in the same state as if the AEN had been disabled or not supported. For example, the next I/O process, if not a REQUEST SENSE command (or INQUIRY command) would receive CHECK CONDITION status. From the initiator implementation perspective, the notification serves only as a stimulus to issue a REQUEST SENSE command (or, for initiators not supporting this asynchronous notification, it can be ignored or logged). The sequence is subject to normal target operation. For example, if the reselection takes too long, the AEN attempt is aborted, or, if the initiator raises ATN, the target must respond to initiator messages just as in normal target operation. For the case where the reselection takes too long, at least two solutions can be used to prevent the SCSI bus from being tied up waiting for initiator reselections for non-existent or non-responding initiators. One method is to use a shorter reselection time-out than the one recommended by SCSI-2. The other is to avoid attempting to reselect initiators which failed to respond to the previous reselection attempt. For initiators to coexist with this alternative protocol, they must be willing to participate in a status phase from an unsolicited I_T_L nexus or they must abort such a reconnection. Either method will allow current initiators to coexist with targets implementing the alternative as long as the initiator does not affect the state of the target by issuing more severe methods of cancelling such as BUS DEVICE RESET or SCSI bus RST. The only additional requirement on an initiator that wishes to support this method of AEN reporting is that it note the I_T_L nexus that posted this spontaneous status so that a REQUEST SENSE command can be later issued to the I_T_L nexus. At the time of the REQUEST SENSE, the target may then establish EXTENDED CONTINGENT ALLEGIANCE if required. This alternative is one which essentially avoids the target sourcing spontaneous sense data to the host and replaces it with an asynchronous CHECK CONDITION which the host may or may not chose to follow up on. I present this in hopes that our vendor unique solution will remain compatible with the SCSI-2 specification. We believe that it is compatible. Textual additions to the SCSI-2 standard ---------------------------------------- I know that not all current initiator implementations will tolerate spontaneous reselection, however I believe that thorough initiator designs should do at least something with unexpected reconnections and I recommend that they be aborted (unless they wish to use them as a stimulus to perform a REQUEST SENSE command). I recommend clarification text to this effect be added to the SCSI-2 specification. The most logical place seems like it would be after 6.5.2 "Incorrect Initiator Connection" and before "Selection of an Invalid Logical Unit". Using wording similar to 6.5.2, the following text is offered: 6.5.? Unexpected Target Reselection An unexpected target reselection occurs if a target attempts to reconnect to an I/O process that the initiator has not initiated. An initiator that detects an unexpected target reselection shall either: 1) abort the reconnection using the ABORT message, or 2) tolerate the reconnection by allowing the target to go to BUS FREE phase. SCSI devices which employ the AEN reporting alternative detailed above, and hosts which employ periodic polling of peripheral devices to detect power-on state, should use reselection time-out values less than the recommended one of 250 milliseconds so that they don't use a significant portion of SCSI bus bandwidth in waiting for (RE)SELECTION time-out. I recommend text in the specification to note this reason why SCSI devices may wish to use shorter (RE)SELECTION time-out values. The following implementors note is offered to be placed below the current definition of the Selection Time-out Delay as follows: 4.7.17 Selection Time-out Delay The minimum time that an initiator (or target) should wait for a BSY response during the SELECTION (or RESELECTION) phase before starting the time-out procedure. Note that this is only a recommended time period. IMPLEMENTORS NOTE: Shorter periods may offer better overall SCSI bus utilization and are recommended for initiators or targets which poll other devices periodically via SELECTION (or RESELECTION) to determine device state. Thank you for the opportunity to make this comment on document number BSR X3.131-198x, Eric Tausheck ___________________________________________ At the time of this writing, I could be communicated with through email, surface mail, or the SCSI electronic bulletin board: email: egt@hprnd.rose.hp.com surface mail: Eric Tausheck MailStop R3NF Hewlett Packard 8000 Foothills Blvd Roseville, CA. 95678 phone: (916) 785-4510 fax: (916) 786-9185