Process Associators revisited

[Andrew Hisgen]

* From the T10 Reflector (t10 at t10.org), posted by:
* Andrew Hisgen <hisgen at jurassic.eng.sun.com>
*
Bob,

What is the effect of the multiple addresses and multiple port WWN's
on the Persistent Group Reservation concepts?  Would each address
and WWN be considered a distinct entity for registration and
reservation purposes?

Thanks,
--Andy Hisgen
Solaris Clusters

> X-Authentication-Warning: t10.t10.org: lohmeyer set sender to 
owner-t10 at t10.org using -f
> Date: Tue, 30 Nov 1999 11:24:08 -0800 (PST)
> From: Bob Snively <Bob.Snively at ebay.sun.com>
> Subject: Process Associators revisited
> To: fc at network.com, t10 at t10.org
> MIME-Version: 1.0
> Content-MD5: R+eU/BkxOlk3+fa6c1nCgw==
> X-Message-Number: 394
> 
> * 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

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