What is SCSI-3? (RE- CLARI
jlohmeye at ncr-mpd.FtCollinsCO.NCR.COM
Tue Aug 30 10:41:47 PDT 1994
I don't recall seeing any responses to the SCSI Reflector regarding your
posting, so I'll attempt to answer your questions. These are, of course,
only my opinions...
> I have a question regarding how the SCSI-3 standards are written.
> There seems to be a bit of confusion (mine perhaps) between "strictly
> SCSI-3 behaviour" versus the behaviour of a SCSI-3 device that is also
> SCSI-2 and SCSI-1 compatible. Do the SCSI-3 specifications (SAM & friends)
> specify only "strictly SCSI-3" behaviour or do they also fill out the
> details and exceptions of what to do to be SCSI-2 and SCSI-1 compatible?
SAM & friends (I like this phrase!) only document SCSI-3 behavior. Although
we strive to maintain as much backwards compatibility as feasible. Of course,
SCSI product developers will try, as much as is possible, to be compatible
with existing products (and hence will be largely SCSI-2 compatible).
I think you are assuming that a device cannot be both SCSI-3 and SCSI-2
compatible. My goal is to ensure that SCSI-3 devices can comply with both
SCSI-3 and SCSI-2. Where there are differences in the protocols, the devices
should be able to 'discover' what protocol the other device is expecting.
Of course, this all depends on the skills of the implementors, but most SCSI-2
devices work perfectly fine when plugged into a SCSI-1 system. I hope that
SCSI-3 implementors will do equally well.
> If the former, they wouldn't specify a realistic device, since most will
> strive to be SCSI-1 and SCSI-2 compatible. That is, they wouldn't specify
> SCSI-3 as it is intended since it is meant to be compatible. If the latter,
> then much of the recent discussion should have been covered by the specs,
> which isn't the case.
> Did I miss anything?
> Maybe this is a more fundamental question. What is SCSI-3? Is it (A)
> a protocol/standard that, if adhered to, will interoperate with SCSI-1,
> SCSI-2 and SCSI-3? Or is it (B) a protocol/standard that is related to
> but distinct from SCSI-1 and SCSI-2, that if adhered to is only guaranteed
> to interoperate with other SCSI-3 devices but somehow allows (or not?) in
> its design to be made compatible with SCSI-2 and SCSI-1 -- implying that
> realistic SCSI devices have to implement something that will interoperate
> with SCSI-3, SCSI-2 and SCSI-1 yet is neither of those three (strictly
I think we have the latter case. Except, I doubt there is much need to
consider SCSI-1 compatibility these days. There aren't too many left.
SCSI-3 really isn't singular, although we all treat it as if it were. SCSI-3
really is a flock of related standards. A Fibre Channel implementation of
SCSI-3 certainly does not interoperate with SCSI-1 or SCSI-2 at a hardware
level, but it should work fine at the command set level.
> For example, if SCSI-3 defines the LUN field of command bytes strictly
> as reserved, then strictly speaking, SCSI-3 is not compatible with SCSI-1.
> A device could be made that interoperates with both SCSI-3 and SCSI-1,
> but *strictly speaking*, it wouldn't be SCSI-3 since under certain
> conditions it wouldn't operate according to SCSI-3 specs. So ironically,
> we are encouraged to make SCSI-3 devices that don't follow specs
> (for backward compatibility).
Partly true. But only if you really need to go all the way back to SCSI-1.
I wouldn't recommend it. One can be fully compliant with both SCSI-2 and
SCSI-3 by leaving these bits zero. Even SCSI-1 recommended using the
IDENTIFY message for specifying the logical unit number, so you could be
SCSI-1 compatible as well. By the way, a recent change in reserved field
checking rules (which I do not entirely support) permits the target to
ignore nonzero reserved bits. So, as long as the SCSI-1 initiator uses
the IDENTIFY message, the SCSI-1/2/3 target can cheerfully ignore these bits.
> It would be nice to have (A), but if (B), shouldn't there be a standard
> or guidelines on how to make a SCSI-3 device interoperable with SCSI-2
> and SCSI-1? (solutions don't all seem so obvious as to not be written
Sure would be nice. But since our committee is entirely made up of
volunteers, it won't happen without a volunteer. I'd think this would
be a excellent topic for a Technical Report.
> [In this question SCSI-3 is viewed with SIP and SPI at the protocol and
> interconnect layers. SAM r.12 doesn't address this question. I don't
> have a copy of SIP, and SPI is rather low-level with little behavioural
> specifications (none or little that depend on versions of SCSI that is).]
> Marc E. Gauthier
> Software Engineering Lab, Institute for Information Technology (SEL,IIT)
> National Research Council Canada, Bldg M-50, Ottawa ON Canada K1A 0R6
> +1 613 991 6975 fax: +1 613 952 7151 email: mgauthier at iit.nrc.ca
PS: Thanks for mailing me your state diagrams. I want to share them with
several committee members to see if they think we can incorporate them
John Lohmeyer E-Mail: John.Lohmeyer at FtCollinsCO.NCR.COM
NCR Microelectronics Voice: 719-573-3362
1635 Aeroplaza Dr. Fax: 719-597-8225
Colo Spgs, CO 80916 SCSI BBS: 719-574-0424 300--14400 baud
More information about the T10