Process Associators revisited
hisgen at jurassic.eng.sun.com
Wed Dec 1 09:35:09 PST 1999
* From the T10 Reflector (t10 at t10.org), posted by:
* Andrew Hisgen <hisgen at jurassic.eng.sun.com>
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
> 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
> 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
> 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
> just like any port, totally independent of other address identifiers that
> may be defined for the same port. This meets the desired technical
> 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
More information about the T10