Subject: RE: P1394> units and logical units definition

From: "Turner, Randy" <[email-masked]>
Date: Mon, 16 Mar 1998 21:20:58 -0800

I thought we had a pretty firm idea on the handling of logical units.

Does this discussion require clarification of the current profile
document, for full understanding?

Also, is there need for a teleconference on this or any other subject
prior to the next face-to-face meeting?

Randy

---

From: Greg Shue <[email-masked]>
Date: Thu, 19 Mar 1998 11:36:59 -0800 (PST)

Hi all,

I've been thinking about the Unit/Logical Unit/LUN modeling a
bit, and there may be a better way to approach figuring out an
appropriate solution.  Let's see if the following makes sense.

The following associations come directly out of the SBP-2 spec
(rev 3a):

  SBP-2 "targets" are Units.
  Each target (unit) shares one Management Agent across all it's LUNs.
  Units are made up of one or more Logical Units. (SBP-2 sec 4.2)

  Each Logical Unit within a Unit may be of a different type.
  Each Logical Unit represents a "device model" and has a
  specific "type" which ammends the "command set" parameter.

  The "Command Set" is LUN specific (wither the value is found in
  the Logical Unit Directory or inheirited from the Unit
  directory).  It identifies the class of commands transferred in
  the "command block" field within the CDB.

  The SBP-2 "device server" is a component of a logical unit
  responsible to execute tasks initiated by _command_blocks_
  that specify data transfer or other device operation.

Now, I think the PWG has concensus that we do NOT want any transport
client data transferred within the CDB.  All the transport client
data should be contained within the data block associated with the
ORB carrying the commands.

Is this true?  (I'll assume so. :-)

So, our SBP-2 based solutions requires that the "Command Set"
field indicate (only) that the "PWG 1394 communications standard"
commands are supported.

I haven't thought about the multi-login implications,
but for our single-login solution:

  Our command set is providing one reliable, bidirectional,
  connection-oriented, byte- or buffer-style communications path
  within one login, within one LUN.
  
  So:

    The Logical Unit provides transport services to exactly one
    associated service (transport client).

    It may be easily modeled as having, per login:
      
      one message queue for data traveling from initiator through target
      one message queue for data traveling through target to initiator
      status associated with those queues
      configuration parameters associated with those queues
      an SBP-2 Fetch Agent (for moving data between queues & 1394 memory)
      an SBP-2 Unsolicited Status sending agent
      a command execution agent which coordinates everything.

      an ideal link between the other end of the message queues and
	_the_ assicated service.

    The Execution Agent processing the "PWG 1394 communications
    command set" fits the definition of an SBP-2 "device server".

      So our SBP-2 device is really a communications device
      associated with (routed to) a (remote) service!

  Now, this model means that:

    Login scope:
      The AGENT_RESET register write only affects the Fetch Agent.

    Logical Unit scope:
      Each Logical Unit (indirectly) provides a Service
      (one session per node at a time).

      The characteristics of that service (remaining protocol
      layers, application command sets and revisions) are not
      appropriately described by using the current 1212 fields
      found in a Logical Unit Directory or Unit Directory.

      The device_type field found in the Logical_Unit_Number entry
      indicates the "peripheral device type implemented by the
      logical unit."  This is most appropriately used to indicate
      that the SBP-2 "device server" is a "communications type",
      as opposed to indicating the "type" of the assocaited service.
      (This is especially true given that it is only 5 bits in size!)

      The LOGICAL_UNIT_RESET command (sent to the encapsulating
      Unit's Management Agent) affects all the connections
      (Logins) established through only this Logical Unit.

    Unit scope:
      Each Unit (indirectly) provides a set of Services (Is this
      a Function?  It's consistent with our original FDS ideas.)

      The TARGET_RESET command (sent to the encapsulating Unit's
      Management Agent) affects all the connections (Logins)
      established through ALL Logical Units within the Unit.

Does this make sense?  Is it reasonable?

-- 
Greg Shue
Hewlett-Packard Company
Office Products Division			[email-masked]
----------------------------------------------------------------