SAM-2: Clarification of Protocol Services

JoeBre at Exabyte.COM JoeBre at Exabyte.COM
Mon Jun 7 22:25:33 PDT 1999

* From the T10 Reflector (t10 at, posted by:
* JoeBre at Exabyte.COM
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