SAM-2: Clarification of Protocol Services

George Ericson gericson at
Tue Jun 8 17:55:51 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* "George Ericson" <gericson at>
LLP at Service Delivery Ports providing the lower level communications
ULP is contract between application client and device server.

I think that task manager is essentially a proxy for the application client.
The task manager is responsible is:
1) forwarding commands to either all or a specific device (generally an LU)
of its target, and,
2) remembering outstanding commands so that it can forward aborts

If there is consensus on this, then rather than delete the ULP/LLP
definitions, I'd prefer to firm them up.

On your concern with respect to recursion of layers.  Here is one way to
look at it that yields a model conformant to that described in SAM and
On studying the implications of supporting hierarchical and virtual devices,
I was led to make explicit the bus that the normal set of a targets LUs are
on as internal target bus 0.  The model allows a target to have other busses
as well. A useful way to model these internal busses is as SCSI interconnect
subsystems with service delivery ports with target relative identifiers that
are defined relative to the attached target device.  Devices attached to
these interconnect subsystems are either a Logical Unit, or another SCSI
target Device.  These devices are addressed by LUN or Target ID.
Effectively, these are the identifiers of the service delivery ports
attached to the interconnect subsystem in its Domain.  In effect, a target
manager always acts as a forwarding initiator to the devices behind it.  (An
interesting twist, a Logical Unit can be thought of as a SCSI Target Device
with no back-end devices and where the target implements a device server
instead of a target manager.
George Ericson
CLARiiON Advanced Storage Division
Data General
508 480 7349
GEricson at

-----Original Message-----
From: JoeBre at Exabyte.COM [mailto:JoeBre at Exabyte.COM]
Sent: Tuesday, June 08, 1999 1:26 AM
To: gericson at; roweber at; T10 at Symbios.COM
Cc: JoeBre at Exabyte.COM
Subject: RE: SAM-2: Clarification of Protocol Services

George -

My real complaint with the discussion of ULP & LLP is that they cloud the
salient points of the architecture. In reading SAM-2, I get the sense that
the discussion of ULP and LLP is setting up the idea of roles that objects
in numerous layers of an architecture can play with respect to each other.
One is left (okay, _I_ am left) with the impression that a given object can
provide an interface to a second object (in an upper layer) in which it
plays the LLP role, and another interface to a third object (in a lower
layer) in which it plays the ULP role. These objects in each layer can also
play both roles - having an interface to an upper layer in which it plays
the LLP role, and an interface to a lower layer in which it plays a ULP

This definition of roles in a layered architecture is a powerful idea in an
architecure similar to the OSI networking protocol stack. However, the
remainder of the SAM-2 document, it seems that only two layers are discussed
in terms of the Protocol Service interactions defined therein - one playing
the ULP role, and the other playing the LLP role. No attempt seems to be
made to tie a specific layer (or better yet, a particular architectural
object) to either the ULP or LLP role.

It seems to me that the whole discussion could be made clearer by
eliminating the brief discussion of ULP & LLP, and tie the Protocol Service
interactions to specific layers -- or preferably, to specific architectural

I would like to respond to your assertion that

> "SAM-2 defines the APIs for the LLP in Section 5.3."

at which layer interface do these APIs exist? Do they exist at the interface
between the SCSI Application Layer and the SCSI Protocol Layer, or do they
exist at the interface between the SCSI Protocol Layer and the Physical
Interconnect Layer? My assertion would be the former, but I do not believe
the doc specifies as such.

(Quite frankly, I wanted to use the term API in my original post, as the
Protocol Service interactions d*amn sure look like an API. However, it
appears that pains have been taken to _not_ use that term (API) in the doc.)

Parhaps a step in the right direction would be to state that the SCSI
Application Layer plays the ULP role, and the SCSI Protocol Layer plays the
LLP role in practical applications. I believe this fits with the complete
documentation set, with SPC, SBC, SSC, et al bing ULPs, and SIP, FCP, et al
being LLPs. I believe this allows one to assign the Device Server, Task
Manager, and Application Client to the roles of ULP objects, and the Service
Delivery Port to the role of LLP object.

Joe Breher
Exabyte Corp

> -----Original Message-----
> From: George Ericson [mailto:gericson at]
> Sent: Monday, June 07, 1999 10:09 PM
> To: roweber at; 'T10, Reflector'
> Cc: JoeBre at Exabyte.COM
> Subject: RE: SAM-2: Clarification of Protocol Services
> Ralph,
> Notions of ULP and LLP are very useful.  Don't delete them.  SPI and
> FC4-SCSI down are implementations of LLP's.  The same SCSI
> ULP runs over
> either.  The SCSI ULP API is defined by SCSI SPC and various
> other varients
> for specific sets of peripheral device types.  This is
> generically defined
> by SAM-2 r10 in Chaper 5 as the Execute command.  SAM-2
> defines the APIs for
> the LLP in Section 5.3.  I do agree with other comments on
> this subject that
> the write-up could be clearer with respect to exactly which
> objects support
> each of the methods defined.
> George Ericson
> CLARiiON Advanced Storage Division
> Data General
> 508 480-7349
> GEricson at
> -----Original Message-----
> From: owner-t10 at Symbios.COM [mailto:owner-t10 at Symbios.COM]On Behalf Of
> Ralph Weber
> Sent: Tuesday, June 01, 1999 11:12 AM
> To: T10, Reflector
> Cc: JoeBre at Exabyte.COM
> Subject: Re: SAM-2: Clarification of Protocol Services
> * From the T10 Reflector (t10 at, posted by:
> * Ralph Weber <ralphoweber at>
> *
> Joe,
> I believe that the notes below (from about page ix in the front
> matter of the SAM-2 working draft) says about the same thing your
> e-mail says but with less detail.
>    The technical editor is considering a careful review of
>    the working draft, with an eye toward overly abstract model
>    abstractions. Examples are:
>        a) Overly general layering terms and discussions; and
>        b) Discussion of a new application client for each new
>           request or task management function.
>    The layering seems overly general and thus confusing. SCSI has
>    two (or at most three) layers. The question of two or three layers
>    depends on whether the service delivery port is a layer. The two
>    "main" layers are the command and control layer
> (application client,
>    device server, and task manager) and the service delivery
> subsystem.
>    The description appears amenable to substantial simplifications.
>    LLP and ULP could disappear. Generalized interfaces could
> be replaced
>    with a small number of specific interfaces. Does T10 see
> value in this
>    kind of simplification?
> I will keep your e-mail to review before undertaking the
> changes described
> above.  However, it could be several months before I start
> that work, as
> I have a more immediate problem with multi-port devices.
> If you feel that I do not properly understand your concerns,
> please contact
> me.
> The one area where your e-mail raises a concern that I do not
> necessarily
> share is in the following statement:
>    ... the Application Client and the Device Server are
> members of this
>    layer, however this is not made explicit.
> To some degree, the Application Client and Device Server are peers.
> However,
> no rigorous effort has been made to formalize this
> relationship.  This is a
> matter of history, as SCSI was developed without benefit of
> formal layered
> models.  I am sympathetic to that history and reluctant to
> break long-held
> concepts solely to create a rigorous formal model for SCSI.
> Furthermore, it may not be possible to create a formal layer
> to house the
> Application Client and Device Sever because SCSI
> intentionally defines the
> latter more completely than the former.  At is core, SCSI is
> about what
> the Target does, and thus about what the Device Sever does.
> SCSI avoids
> specifying Application Client behavior except where
> absolutely necessary.
> This is a reasonable approach for SCSI, since the committee
> is dominated
> by manufacturers of SCSI device hardware, not by system house software
> engineers.
> For these reasons, I am not sanguine about making a formal layer to
> house the Application Client and Device Server.  The looser, peer
> relationship will always be there, however informal it may be.
> Thanks.
> Ralph...
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list