Convergence of X3T10 and SAF-TE enclosure specifications

[Bob Snively]

To:		Mr. Bernie Wu
		Conner Peripherals
		bernie.wu at conner.com

From:		Bob Snively
		Sun Microsystems
		bob.snively at sun.com

CC:		scsi at symbios.com

Date:		November 15, 1995

Subject:	Convergence of X3T10 and SAF-TE enclosure specifications



Dear Mr. Wu,

I have prepared the following recommendations for modifications to the
SAF-TE Interface Specification, Revision 1.0, dated October 17, 1995.
While not formerly representing X3T10, I believe that these recommendations
reflect the inputs that I have received from the members of the SCSI
standards committee.  Taken together, the SAF-TE and X3T10 documents 
represent a very useful addition to the capabilities of SCSI. 

These capabilities become especially important now that Fibre Channel
disk drives are available, where many devices may be included in an
enclosure.

GENERAL RECOMMENDATIONS:

1)	Choice of device model.

	The X3T10 committee has recommended that an Enclosure 
	Services device model be created, rather than using the 
	Processor device model. The Processor device model 
	contains mandatory artifacts of its more normal use 
	for transmitting messages among host devices and
	is not appropriate for enclosure services.  X3T10/95-324, Revision 1
	provides an appropriate model and command set that includes
	the commands INQUIRY, RELEASE(6), RELEASE(10), REQUEST SENSE,
	RESERVE(6), RESERVE(10), TEST UNIT READY, and WRITE BUFFER (download)
	in addition to the two mandatory commands for communicating
	the enclosure services information to and from the initiator.

	The two mandatory commands have the additional advantage that they
	can accepted by any other type of device that has enclosure
	services functions available through some other port.  An example
	of such a device is the SCSI disk drive defined by SFF-8045, which
	has pins reserved for communicating information from a simple
	enclosure error detection system.

2)	Choice of send/sense commands.

	The X3T10 committee recommended that the Enclosure Services
	device model make use of the RECEIVE DIAGNOSTIC RESULTS and the
	SEND DIAGNOSTIC commands to access the enclosure services 
	information.  The RECEIVE DIAGNOSTIC RESULTS command was modified
	by X3T10 to contain a page code that allows direct access to
	the enclosure status information.  Corresponding page codes 
	are used in the SEND DIAGNOSTIC command's data field to send
	control information to the enclosure.  These commands were
	selected because they had no odd behaviors like those
	associated with the READ BUFFER and WRITE BUFFER commands.
	The commands are described in X3T10/95-324, Revision 1.  The
	content of the transmitted information is not described by this
	revision of the document.

3)	Inclusion in the standard of the SAF-TE information formats

	The X3T10 committee has not yet selected detailed bit strings
	to standardize the status information available from the enclosure and
	the control information sent to the enclosure.  The SAF-TE
	information formats appear to meet many common enclosure requirements
	and should probably be picked up with only minor improvements
	by the X3T10 committee.  

	The usage of some of these bits needs to be further clarified
	and certain bits should be made optional.

	I would recommend that a new revision of X3T10/95-324 be
	prepared to reflect these information formats and page definitions.

4)	Additional vendor unique capability is required

	Sun's experience with disk enclosures indicates that there
	are many extensions to the SAF-TE information formats that 
	will be required to manage certain additional functions.
	These functions tend to be very vendor unique.  I suggest that
	some pages be provided for such functions, either as vendor
	unique pages or as pages for certain generic purposes that
	contain only vendor unique bit strings.

SPECIFIC RECOMMENDATIONS:

Section 2.0  Device type

	I recommend that a new device type be defined for inclusion in
	the SCSI-3 Primary Command document, rather than using the 
	processor device model.  The processor device model requires
	that the SEND command be implemented.  

Section 2.0  Disconnection

	I recommend that the maximum response time of the SEP device
	not be included in the standard document (although such a
	value would clearly be allowed in the specification profile) and
	that disconnection be allowed to prevent performance impacts
	on other devices attached to the SCSI bus.

Section 2.0  LUN definition

	LUN 0 is reserved as a sort of "master" LUN for SCSI devices.
	It must always exist and has the capability of presenting
	lots of special information about other LUNs that may be
	at the same target address.

	I believe that the Enclosure Services device should be
	allowed to have any address, just as any normal LUN may.
	Its location and type should be reportable by LUN 0 as
	defined for SCSI-3.  Note that RAID type devices as
	defined by the SCSI-3 Controller Commands and the RAB
	profiles already contain some enclosure information.  As
	a result, I would expect the Enclosure Services device
	model to be used principally by JBOD enclosures.  Of 
	course the drives in such enclosures may be part of
	a RAID environment.

	Note that SCAM and FC-AL addressing flexibility may
	require the enclosure services device to have some special
	capabilities to identify which disks are actually within
	its enclosure.

Section 2.1 Messages

	The messages should additionally include DISCONNECT (in)
	and IDENTIFY (in) to allow disconnection.

	The messages should actually not be included in the standard
	document, since the commands may be used by both FCP
	and SIP devices.  As a profile specification for parallel
	SCSI only, it may be appropriate to specify which messages
	are used, but all mandatory messages should be accepted.

	The profile should clearly state the behavior of a SEP on
	a wide and fast SCSI bus, since SCSI transfer negotiation
	messages will surely be generated by initiators for
	all attached logical units.

	It is probably not necessary to define the details of
	the message behavior for the enclosure services device, 
	since the message behavior is totally defined by the
	SCSI-2 and SCSI-3 documents.

Section 2.1  IDENTIFY

	The interface should use the IDENTIFY command for SCSI-3, 
	which allows the definition of up to 32 logical units.

	The inbound use of IDENTIFY should be allowed so that
	disconnection can be used.

Section 2.2  SCSI commands (all)

	The SCSI-2 and SCSI-3 standards require the use
	of the INQUIRY message to select the logical unit.
	While SCSI-2 reluctantly allows the insertion of 
	the logical unit number in byte 1 of the CDB, SCSI-3
	requires the value to be zero.  (See SCSI-2
	paragraphs 7.2.2)

Section 2.2  SCSI commands (all)

	Most of these commands are exhaustively defined in
	both the SCSI-2 and SCSI-3 standards and should not
	be redefined, but only referenced, in this document.
	As a specification, the document may choose to require
	or discourage the use of certain options.

Section 2.2  INQUIRY

	Bytes 56 - 95 of the INQUIRY command's data field
	is reserved and cannot be used for vendor unique
	parameters.

	Bytes 32-35 of the INQUIRY command's data field contain
	a product revision level, which may or may not have
	anything to do with a firmware revision level.

	Byte 0 of the INQUIRY command's data field should contain
	the peripheral device type, which for an Enclosure
	Services model device should be a newly defined value.

	Byte 7 of the INQUIRY command's data field should not
	be constrained to a 0 value, since wide SCSI and synchronous
	capability may be desired of an Enclosure Services device.

	The Enclosure Identifier should be contained in the
	Vital Product Data page 80 (Unit Serial Number page), as
	described in section 8.3.4.5 of the SCSI-2 standard.

	It is likely that vendor specific Vital Product Data pages
	should also be defined for the ASCII values indicating
	SAF-TE compliance and SAF-TE revision levels, since VPD
	pages are reserved particularly for this type of function.

Section 2.2  READ BUFFER

	This should be replaced with the modified definition of
	RECEIVE DIAGNOSTIC RESULTS specified in X3T10/95-324, Revision 1.
	Additional pages should be defined for that version of the
	command to carry the information strings specified by
	SAF-TE.

	Since this command will be replaced anyway, it is not so important
	to note that Mode 01 is defined as vendor specific and has
	already been used for other purposes by other vendors.

Section 2.2 REQUEST SENSE

	All the defined ASC/ASCQ codes are already defined by
	the SCSI-2 and SCSI-3 standards except 09/80/xx and 09/81/xx
	and need not be restated in the profile.  Depending on the
	implementation of the Enclosure Services device, the
	stated error codes may or may not be relevant and additional
	error codes may be required.  It is not appropriate to
	constrain the error code presentations beyond the requirements
	of the standard.

	Vendor specific values have been used by other devices in
	ways not compatible with this definition and so should
	be avoided where possible.  In particular, there are no
	special Enclosure Services errors defined elsewhere in the
	document that would require the presentation of these
	indications.

Section 2.2  SEND DIAGNOSTIC

	This should additionally contain the information specified in
	X3T10/95-324, Revision 1 for transfer of control information
	out to the Enclosure Services device.

	The self-test bit should be set to 1 to invoke the required
	self-test.

Section 2.2   WRITE BUFFER

	This command should be reduced to providing only the
	download microcode functions.  The SEND DIAGNOSTIC
	command should be used for transmitting control information
	to the Enclosure Services device.

Section 3.1  Read Enclosure Configuration

	The number of fans, number of power supplies, number
	of device slots, and number of temperature sensors
	indications should not contain the number of devices
	currently installed, but the maximum number expected
	to be installable.  As an example, it is not very
	interesting to know that 3 power supplies are installed
	when the really useful information is that 5 power
	supplies could be installed.  From the context of
	the Read Enclosure Status page, it is likely that this
	was the original intent of the Read Enclosure Configuration
	page.

	It might also be useful to indicate how many need to be
	operational for proper operation.  As an example, if
	3 out of 5 power supplies are required to support 
	a full complement of devices, then the host could 
	choose not to pull the panic button when 1 of 5 is not
	installed or is non-operational.

Section 3.1  Temperature out of range flags

	This only allows for 15 temperature sensors, a fairly small
	number for some very large enclosures.

Sectioon 3.1  Read Device Slot Status

	There are assumptions made in the definition of the
	byte 3 flag bits that are not necessarily characteristic
	of all enclosures and all architectures.  As an example,
	a true hot-pluggable system may never require a "prepared
	for operation" flag.  The definition of "ready for
	removal" is extremely vague.  As an example, does that
	mean that the device is spun down (controllable only
	directly to the device and not knowable to the 
	enclosure services device), that the mechanical interlocks
	are removed (which could be set by the enclosure
	services device), or that the slot is powered down (which
	could be set by the enclosure services device).

Section 3.2  Write Device Slot Status

	There are assumptions made in the definition of the
	byte 0 flags that are not necessarily characteristic of
	all enclosures and all architectures.

	It appears that this flag byte is intended to provide
	host to host messaging about the state of a particular
	drive.  This information should be kept in a more quickly
	accessible area and should be managed by high level software
	locks.  SCSI does not guarantee the atomic test and set 
	functionality required to make these values useful.

	If this is not intended for host to host messaging, then
	it is not useful at all, since that information is already
	known to the managing host.

	Note that most of these operations should only be
	performed to reserved devices, preferably using the
	Persistent Reservation protocol.

Additional functions desirable

	The capability of illuminating individual device indicators
	should be provided.

	The capability of reading device management switches
	should be provided.  The number and meaning of switches
	tends to be vendor unique.  The presentation should be
	treated as a simple bit string to be interpreted by
	vendor unique libraries, utilities, or drivers.

	The capability of communicating with display devices (as
	an example, an ASCII LCD) should be provided.  Such display
	devices are likely to be vendor unique in character set and
	should be treated as simple string output devices.  The
	string should be provided by vendor unique libraries,
	utilities, or drivers.