Proposal for IEEE company_id based formats for FC-PH world-wide identifiers

[DeKoning, Rod]

* From the SCSI Reflector (scsi at symbios.com), posted by:
* "DeKoning, Rod" <rdekonin at ppdpost.ks.symbios.com>
*

Larry, Mike, Bob, et.al.,

Below, Larry discusses a mechanism to associate a controller (node) name to 
a Logical Unit.  This concerns me (and possibly others?) for the following 
reasons.

I went back to my personal notes for the July Serial Concerns Meeting to be 
sure we had discussed this point adequately, and I believe that we covered 
this topic in some detail.  At that meeting, we discussed the fact that we 
wanted to purposely break the link between the Volume Logical Unit WWN and 
the Node Name of the device reporting the LUN's WWN.  This is to ensure that 
we provide the following capabilities:

1. Allow for dual controller environments in which the LUNs may be addressed 
|from different controllers with different node IDs.
2. Allow for hot swapping of devices used to access the LUNs.


In the final analysis, (at least as I recall and recorded it) we are trying 
to encourage OS drivers and applications to avoid making a static link 
between a Volume Logical Unit and the device (controller) that is used to 
access the Volume Logical Unit.  In general the OS drivers should be 
concerned with the WWN of the LUNs, and not the access devices since the 
data they are concerned with is associated with the LUNs and not the access 
device(s).

Please let me know if this is not consistent with the July Serial Concerns 
discussion.

Thanks,
Rod D

By the way, not linking the Logical Unit to the device is a key aspect to 
some of the changes we are proposing in the SCC2 model using the ASSIGN and 
DEASSIGN commands.  These commands allow Volumes to be assigned or 
deassigned Logical Unit Numbers to different controllers connected to the 
same storage.  To take advantage of such a capability, the system OS must be 
concerned first and foremost with the Volumes WWN, and only then, its 
physical path.


 ----------
>From: Larry Chen
>To: scsi; serial_solutions
>Cc: Mike Wenzel
>Subject: RE: Proposal for IEEE company_id based formats for
>FC-PH world-wide identifiers
>Date: Thursday, December 19, 1996 12:59PM
>
>
>*
>* From the serial_solutions Reflector, posted by:
>* Larry Chen <larryc at maxstrat.com>
>*
>* To post to this Reflector, send email addressed to
>serial_solutions at zk3.dec.com
>*
>
>Hi Mike,
>
>Assume the following configuration:
>
>Host Computer <----FC-AL----> RAID controller + disk drives + enclosure
>
>The host computer is attached directly to the RAID controller only
>(not the disk drives). The RAID controller will manage the disk drives
>and export virtual LUNs to the host computer.
>
>At the SCSI initiator's side and level, I wanted a mechanism to associate 
the
>virtual LUNs with its RAID controller. This mechanism would be general 
enough
>to work for both the simple disk drive case and for the RAID case.
>
>Below, I will attempt to describe the entities at the FC and SCSI layers
>for my current configuration.
>
>At the FC transport layer
>-------------------------
>Port entity is a SIM in CAM terminology.
>
>Node entity is the RAID controller (or more specifically,
>        the RAID controller's Field Replaceable Unit (FRU)).
>
>
>At the SCSI layer
>-----------------
>LUN entity is a virtual LUN.
>
>RAID controller entity is the FRU.
>
>
>
>In my single RAID controller configuration, the FC Node entity and the
>SCSI RAID controller entity are equivalent (and probably will have the same
>value).
>
>Port name - any old WWN
>Node name - IEEE Registered Format
>Virtual LUN name - IEEE Registered Extended Format
>RAID controller name - IEEE Registered Format
>
>and the association field could be used to associate the Virtual LUNs
>with its RAID controller.
>
>A problem arises when multi-RAID controller complexes are introduced.
>Now, the RAID controller entity is ambiguous (FRU vs. the virtual
>RAID controller) and the FC Node entity and the SCSI RAID controller
>entity are probably not the same.
>
>At this point, I will not be pursuing this matter any further (unless
>someone is willing to stand-up with me).
>
>As an observation, RAID devices seem much more complex when compared to
>the simple disk drive case. I hope the RAID Industry will form some
>initiatives that will rectify this soon.
>
>Please call me if there are any further questions.
>
>Regards,
>Larry
>On Thu, 19 Dec 1996 11:27:42 -0800  Mike Wenzel wrote:
>>Hi Larry,
>>
>>I agree with a previous post, the following description is too vague to
>>really follow what is happening.  Could you give a scenario, including the
>>topology and node name of the controller and controlled device, then show
>>what specifically would appear on the device's Device ID INQUIRY page
>>(I assume that's what's involved) to correlate the devices?  If you get 
time
>>to do this, please post it to the broader distribution list: I'm shure a
>>number of people were confused and that even more didn't really understand
>>the scheme.
>>
>>Best Regards and Seasons' Greetings,
>>
>>Mike Wenzel
>>mw at core.rose.hp.com
>>
>>>I was ready to go to Dallas and make a formal proposal but
>>>fortunately, Bob Snively mentioned that I could use the
>>>24-bit company_id and 36-bit Vendor Specified Identifier
>>>fields from the virtual LUN's WWN in IEEE registered
>>>extended format to get a pseudo WWN (60-bits only) for its RAID
>>>controller node instead.
>>
>
>----------------------------------------------------
>Larry Chen                 Tel: 408.383.1600 (x116)
>Maximum Strategy, Inc.     Fax: 408.383.1616
>801 Buckeye Court       E-mail: larryc at maxstrat.com
>Milpitas, CA 95035
>----------------------------------------------------
>
>
>
>
>
>
>
*
* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com