Convergence of X3T10 and SAF-TE enclosure specifications
Bob.Snively at Eng.Sun.COM
Wed Nov 15 20:03:50 PST 1995
To: Mr. Bernie Wu
bernie.wu at conner.com
From: Bob Snively
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
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.
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
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
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
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 18.104.22.168 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
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
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
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
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.
More information about the T10