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