PRLI proposal
Bob Snively
Bob.Snively at eng.sun.com
Thu Apr 14 01:21:39 PDT 1994
Review of FCP and FC-SB with respect to PRLI/PRLO
FCP selected the PRLI/PRLO function defined by SB to communicate
the required FCP parameters among the various SCSI devices.
As the result of review comments on the FCP, I have more completely
examined the PRLI/PRLO function and believe that there should
be some modifications in the way it behaves.
PRESENT FC-SB PRLI/PRLO
At present, the PRLI/PRLO service parameter pages are defined
to specify an originator/responder Process Associator
pair and an originator-required set of service parameters.
The responder then accepts the service parameters, modifying
those it must to operate properly. It could indicate that it
was impossible to modify the service parameters to a specified value.
Note that there is an implicit assumption that the characteristics
of the appropriate independent logical processes defined by the
responder's Process Associator are somehow known to the originator of the
PRLI. At present, SB does not define a mechanism. The Name Server
could eventually do so, but that would require that SB always had
a Name Server. There is no way to PRLI successfully to an
unknown configuration of processes behind an N_Port.
Furthermore, there is an assumption that the host (or channel)
creates image pairs associating a host Process Associator with
a device Process Associator. Communication outside these pairs
could not take place. If a host had two PA's and a device had
two PA's, up to four separate pages would have to be provided
to provide complete logical connectivity.
The FC-SB PRLI/PRLO does not tell how the PRLI/PRLO will be used
for that FC-4.
FCP PRLI/PRLO REQUIREMENTS
FCP, being based on the peer-to-peer SCSI protocol, makes far
fewer demands on the host's (initiator's) knowledge of the device
(target). The desirable behavior is for each initiator to identify
to each of the attached targets the characteristics and Process
Associators that it has available. Each target should make
available to each initiator the characteristics and Process Associators
it has available. Now that each has full knowledge of the
capabilities of the other, some ports (usually initiators) will
define whatever image pairs are required, but still be able to
access any other devices using the information previously shared.
For interoperability, the PRLI/PRLO protocol should be completely
enough described so that any attached device can participate without
the use of a Name Server.
PROPOSED STATEMENT OF PRLI/PRLO PROTOCOLS
The following ideas should be included in the PRLI/PRLO definition.
Some of these ideas require modification in the text of FC-SB, annex A.
1) If a Name Server can identify the approximate capabilities
of a device or host and can identify the Process Associators
selected by that device or host, the PRLI payload
with the defined PRLI response may be adequate.
2) If a Name Server is not installed, is not able to identify
the Process Associators of an attached port, or is not
used by the system, then the following
protocol may be used by either the initiator/channel or the
target/device.
a) The requesting device performs a PRLI command.
In each service page, the device specifies the
Originator Process Associator as valid and identifies
the capabilities of that Process. If the
Originator does not use Process Associators, then
it will specify that the Originator Process Associator
is also invalid and will provide the capabilities of the
port. The Responder Process Associator is specified
as invalid so that the entire responding port can examine the
capabilities of the Originator Processes.
b) The responding device performs a PRLI accept.
In each response page, the device specifies the
Responder Process Associator and the capabilities
of the Process. If the responding device does not
use Process Associators, the Responding Process
Associator is specified as invalid.
In the response page, the device may specify
a valid Originator Process Associator, indicating to
the originator that the defined Originator/Responder
image pair is valid and that the returned capabilities
represent the Responder's capabilities as modified
to meet any special requirements that had been presented
by the Originator.
In the response page, the device may specify
that the Originator Process Associator is invalid,
indicating to the originator that it is sending
the Responder Process Associators and capabilities
for reference by the Originator port. The
originator port then has enough information to
elect to form image pairs as in 1 above if desired.
If image pairs are not formed, but Process Associator
information has been exchanged, then the software
behind each port is allowed to use any specified
Responder Process Associator through any Originator
Process Associator. This would be the normal SCSI
case, where any initiator could access any target.
3) Implicit PRLI is allowed for closed systems that have
other mechanisms, including possibly exclusive configurations, for
understanding the properties of the attached devices.
Hope to hear from you all soon so that I can formulate a formal proposal
for FCP.
Bob
More information about the T10
mailing list