Process Associators revisited

[Bob Snively]

* From the T10 Reflector (t10 at t10.org), posted by:
* Bob Snively <Bob.Snively at EBay.Sun.COM>
*

To:		NCITS T10 members, NCITS T11 members

From:		Bob Snively

Subject:	Process Associators revisited

EXECUTIVE SUMMARY AND CONCLUSIONS:

After an extensive teleconference about the possible capabilities of
process associators and possible alternative mechanisms that could
achieve the same goals with improved features, Carl Zeitler, Tom
Coughlan, and I have agreed upon a desirable alternative approach.

All the desired functionality considered possible with process
associators can be achieved by implementing a separate address
identifier for each logical port behind a single physical port.  The
use of multiple address identifers through the same port eliminates the
problems associated with switch functions, error recovery, and CRN
definitions.  Together with the access control proposal recently made
in the SCSI working group (see T10/99-245R2), this also allows LUN
level access security for each process.  The corrections to FCP-2 to
include this capability are logical and straightforward.  No other
standards are effected.

This memo outlines the following items:

	1)  Technical goals desired
	
	2)  Difficulties with process associators
	
	3)  Proposed implementation using multiple port IDs for initiators
		
1)  TECHNICAL GOALS DESIRED

In large processor complexes, it may be desirable to divide the processor
complex up into sets of relatively independent SMP processor groups.  The
selection of which I/O ports belong to which processor group is often
quite simple, with a particular I/O port being granted for the exclusive use
of one of the processor groups.  However, if there are cases where two
processor groups may need to control one I/O port, there should be a 
mechanism to create a logically independent initiator function for each
of the processor groups accessible through the port.

Similar requirements may exist for independent operating systems running
within a processor group, though these are typically handled using a 
common microkernel that manages memory and I/O allocation and locking.

It may be desirable to separately zone the two logical initiators behind
the same port, allowing both routing and access control to be performed
not only at the destination nodes, but in switch nodes.

2)  DIFFICULTIES WITH PROCESS ASSOCIATORS

Process associators are presently defined as a logical identifier of an
image behind a port.  The process associators are outside the
definitions of SCSI device identifiers, SCSI access control mechanisms,
and SCSI task identification.  As a result, significant problems are
encountered in execution of FCP-2 sequences, especially error-recovery
sequences, SCSI reservations, and SCSI access control functions.

The process associators are buried in the device header segment of the payload.  
As a result, switches must decode the frame payload to identify the routing
of a sequence and whether or not zoning restrictions will be applied to
the sequence.  The information thus obtained must be maintained and
distributed to other switches that may pass frames of that sequence to
be sure they are managed properly.

The process associators are provided only once in each sequence, and perhaps
only once in each exchange.  As a result, switches must maintain enough
context and end-to-end protocol awareness to properly control access to
an end-point.

Significant changes will be required to FC-FS, FCP-2, and perhaps other
documents to make the process associators usable at all.

3)  PROPOSED IMPLEMENTATION USING MULTIPLE ADDRESS IDS FOR INITIATORS

Each port is identified by an address identifier.  The concept of
having multiple valid address identifiers on a single port is common in
FC-AL, the switch standards, and all service standards, although it is
often implied rather than explicitly documented.

In FC-AL, the FL_Port receives and operates with any D_ID transmitted to
it for which it has an actual physical port or a mapping of a physical
port on another of the switches ports.  Similar behavior is typical for
all the well-known addresses.  If I understand the behavior correctly,
B-B credit is managed on a port-to-port basis, independent of address, while
E-E credit is managed on an end-port to end-port basis, dependent on
address.

While we would normally call these addresses "aliases", the term alias has
a special meaning in Fibre Channel, where such additional addresses are
used to create groupings of ports, rather than to divide a single port
into multiple instances.  The manipulation tools defined for FC aliases are
not appropriate to the management of multiple address identifiers for a 
single port.

To create an alternate image for a single port, the port needs only to
perform a new login with an additional world-wide name.  After that, it
behaves exactly like any normal port and can perform the complete
FC-2 management functions and the FCP-2 initiator and/or target functionality
just like any port, totally independent of other address identifiers that
may be defined for the same port.  This meets the desired technical
goals.

Requirements for this to be successful include:

	A switch should be capable of keeping active logins for multiple 
	address identifiers on a single point-to-point.  This
	is already standard for loop links.
	
	A multiple address identifer N_Port or NL_Port should be capable of
	accepting frames for the specified list of address identifiers.
	Most public NL_Ports have at least some of this capability already.
	Some N_Ports have the capability.
	
	Multiple world-wide port names should be available for multiple address
	identifier N_Ports to avoid the complexities of changing FC-FS,
	FCP-2, and perhaps other standards that tie flogi, plogi, and
	access control functions to a single WWN per port.  Alternative
	approaches are certainly possible.
	
	The port is sufficiently sophisticated that it can either perform
	error recovery for multiple address identifiers at the same time
	or perform one error recovery at a time while gracefully delaying
	other error recovery operations.



----------------------------------------------------------------
Bob Snively			     Phone:	  (510) 574-9051
Sun Microsystems Computer Company      
Mail Stop NWK 04-104
901 San Antonio Road	             E-mail: bob.snively at sun.com
Palo Alto, CA 94303
----------------------------------------------------------------


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org