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 gregs@sdd.hp.com ----------------------------------------------------------------