Mandatory and Optional
Charles Monia, SHR3-2/W3, 237-6757 10-Sep-1994 1912
monia at starch.enet.dec.com
Sat Sep 10 16:13:19 PDT 1994
Quoting from Jim McGrath's reply:
>My problem is that if I have a question about queuing, it is unacceptable for
>SCSI-3 to say that it can be implemented in either the host or the target -
>that ducks the issue, and makes practical hash out of SCSI.
As I read your concerns, you feel that in SCSI-2 there were fixed
hardware-enforced boundaries between functions. Targets and logical
units sat in a black box at one end of the wire. Initiators lived
in another black box at the other end of the wire. Since the
boundaries between these functions were cast into the hardware, there
could be few questions about how and where certain functions were
implemented. Also, since there there was really only one
architecture there could only be one way to implement things.
In SCSI-3, on the other hand, while there is only one reference model,
there may now be many implementation architectures. How can we avoid chaos
unless all SCSI-3 protocol standards and implementation
architectures are described in SAM?
Ok, let look at the problem a different, way. SAM defines a generic
reference model. Rather than burden SAM with describing all the
SCSI-3 implementation models that correspond to the reference model,
SAM delegates that job to each protocol standard (where it belongs).
ie. An SCSI-3 protocol standard translates the reference
model into something that an implementor can use to build a product.
That translation is either implicit or explicit. In FCP, SIP or any
'channel' model, I believe it's implicit. ie. The mapping from
reference to implementation model is pretty much one-to-one and
In your hypothetical case, where the mapping isn't so self-evident,
the protocol standard has to be more explicit about describing how
SAM entities map to entities in the implementation architecture.
The only thing that SAM requires -- indeed the only thing that SAM
can require-- is that the mapping be functionally equivalent to the
reference model at some well-defined interface (ie. the protocol
The burden of the implementation architecture (the protocol standard)
is to clearly demonstrate this functional equivalence.
>Since people seem to feel that SAM covers queuing, then it has to address
these issues at that
>level. But I still feel very uncomfortable with all that stuff (even if it
>did exist today) being in an architecture document - how are we going to
>Parallel, Fibre, SSA, SBP queuing issues all in the degree needed in SAM?
If my earlier remarks haven't adequately addressed your concerns, let's
continue this conversation at the upcoming plenary.
I suggest rather than continue this debate, it would be more
producutive to for you to begin looking at possible implementation
architectures that address your issues so we can deal with specifics.
>Another trivial example is LUN space. We have a very large space defined
>in SAM - do I have to support that on the device? Clearly I will not, but
>it is not clear to me how people would interpret SAM if we are
>confusing over that standards for standards and implementation issues.
>And your original wording seemed to imply that I would be required to
>support that stuff at the device level.
For the example you cite, SAM is quite clear on this issue. A protocol
standard can support a smaller LUN field but cannot support a larger one.
The reason for limiting the length was so an initiator would know how
much room to allocated for storing a logical unit number.
More information about the T10